5 ms·

Can you elaborate? I’m not sure I follow your argument. A requirement to write portable C doesn’t seem so insurmountable to render the project a mere toy. The

Can you elaborate? I’m not sure I follow your argument. A requirement to write portable C doesn’t seem so insurmountable to render the project a mere toy. The suite of useful tools included in the post seems like a good counter example to the claim that this is inherently not useful for anything serious. Fat multi-arch binaries are a thing on other platforms like darwin, where they are used extremely widely. What makes this approach so different?

refulgentis 3y ago
I don't understand what's useful here either. It's not inherently useful to have my `ls` on Mac be the same one as chromeOS, I'm happy with whatever is on either. If this means I can FFI link against one ONNX library instead of one for linux64, Linux ARM, macOS arm, macOS Intel, android, iOS, win x64, win ARM, I'm all for it though.
zamadatix 3y ago
Multi-arch seems completely different than multi-platform. The former is obviously useful, the user isn't necessarily going to understand why a program which ran on their MacBook isn't runnable on their older iMac because it's ARM only. The two programs can also still use highly specific OS integrations, GPU acceleration APIs, and make assumptions about being a macOS system. The stretch to multi-platform comes at a much higher cost in limitations for a much more dubious level of gain, as badass as it is from a technical perspective. When I say "cost" e.g. on Windows I have to rename the executable to end in .exe be able to launch it, when I do simple text based programs like nano do run... but they are completely unusable. Bash runs but I can't select, copy, or paste text with the mouse. It's borderline unusable if the app does more than behind the scenes processing only. With that in mind, "plugins" to cross platform applications instead of standalone apps could be an interesting use case though. That's something which has typically went towards per platform, interpreted/jited, or VM'd solutions - all of which have their downsides for a typical user, don't really care about the rest of the system as much, and don't need to be anything but "behind the scenes processing" in most cases.
pjmlp 3y ago
ISO C and POSIX don't provide support for anything beyond CLI applications and daemons. Sure if one wants to live in the world of UNIX before X Windows, I guess it is ok.
- rpdillon 3y ago
  This is true, but given that many applications are built using web tech now, this stack is sufficient to fire up a server and make an app available on localhost. I can see a lot of use cases for that, and it's something that wasn't there in UNIX before X Windows. I'd use this for my personal projects that provide a web interface, since I can build once and sync (using Syncthing) the actual binaries between my Android tablet, my Macbook, and my Intel laptop. Niche use case, but very neat!
  - pjmlp 3y ago
    Except modern HTTP and the whole security stack isn't part of those APIs either.

refulgentis 3y ago

I don't understand what's useful here either. It's not inherently useful to have my `ls` on Mac be the same one as chromeOS, I'm happy with whatever is on either. If this means I can FFI link against one ONNX library instead of one for linux64, Linux ARM, macOS arm, macOS Intel, android, iOS, win x64, win ARM, I'm all for it though.

zamadatix 3y ago

Multi-arch seems completely different than multi-platform. The former is obviously useful, the user isn't necessarily going to understand why a program which ran on their MacBook isn't runnable on their older iMac because it's ARM only. The two programs can also still use highly specific OS integrations, GPU acceleration APIs, and make assumptions about being a macOS system. The stretch to multi-platform comes at a much higher cost in limitations for a much more dubious level of gain, as badass as it is from a technical perspective. When I say "cost" e.g. on Windows I have to rename the executable to end in .exe be able to launch it, when I do simple text based programs like nano do run... but they are completely unusable. Bash runs but I can't select, copy, or paste text with the mouse. It's borderline unusable if the app does more than behind the scenes processing only. With that in mind, "plugins" to cross platform applications instead of standalone apps could be an interesting use case though. That's something which has typically went towards per platform, interpreted/jited, or VM'd solutions - all of which have their downsides for a typical user, don't really care about the rest of the system as much, and don't need to be anything but "behind the scenes processing" in most cases.

pjmlp 3y ago

ISO C and POSIX don't provide support for anything beyond CLI applications and daemons. Sure if one wants to live in the world of UNIX before X Windows, I guess it is ok.

rpdillon 3y ago
This is true, but given that many applications are built using web tech now, this stack is sufficient to fire up a server and make an app available on localhost. I can see a lot of use cases for that, and it's something that wasn't there in UNIX before X Windows. I'd use this for my personal projects that provide a web interface, since I can build once and sync (using Syncthing) the actual binaries between my Android tablet, my Macbook, and my Intel laptop. Niche use case, but very neat!
- pjmlp 3y ago
  Except modern HTTP and the whole security stack isn't part of those APIs either.