Login
You're viewing the discuss.systems public feed.

Replies

  • Oct 11, 2026, 1:59 PM

    @whitequark I know its super popular but I find so many of these projects powering embedded devices pushing people to heavy browsers as a primary method of interaction is becoming a problem. I'd rather see it die off. There aren't good alternatives but we can invent them rather than grovel at corporations to allow us access to our own hardware through the browser. Maybe we need a sandboxed version of Uxn/Varvara for flashing/device coms. Simple and portable tools that embrace personal computing.

    💬 1🔄 1⭐ 1
  • Oct 11, 2026, 2:37 PM

    @cararemixed I think there's a lot of things here that are worth unpacking:

    • there's a difference between using the browser as the sole/primary interaction method and as one of many. I ship a lot of native executables, and it costs me a fuck ton of effort to do it
    • one of the primary advantages of the browser in this application is that it is sandboxed and you aren't training people to run random executables with access to every device on their machine. none of the "simple" alternatives even try. even Flatpak barely attempts it (yes, I know about the USB portal)
    • i can't imagine running an FPGA toolchain on top of Uxn. so it's not very "personal" to me: it isn't solving my personal needs
    • it would not take a lot of effort to implement WebUSB for Servo, and that's not corporate
    💬 1🔄 0⭐ 1
  • Oct 11, 2026, 8:38 PM

    @whitequark I'm thinking more as glue to interface with USB devices not an entire solution to everything. Same way m291 calls mpg123 from uxn11.

    My personal experience as an end user is these often fail on my machines. Either weird AppArmor/sandbox issues on linux or being completely broken on OpenBSD and then I'm left with either no support or something which is a complete afterthought. I haven't seen Servo's story but having piles of python packages or non-portable browser behavior sucks.

    💬 0🔄 0⭐ 0
  • 💬 0🔄 0⭐ 0