4 ms·

This is great and all but it’s fundamentally a toy. There are a number of tradeoffs involved here, all so that the same binary runs on multiple operating system

This is great and all but it’s fundamentally a toy. There are a number of tradeoffs involved here, all so that the same binary runs on multiple operating systems, which isn’t actually very useful. If your program isn’t vaguely portable to begin with, it still won’t work.

semiquaver 3y ago
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.
tstack 3y ago
> all so that the same binary runs on multiple operating systems, which isn’t actually very useful. I like to mention my use case when this comes up: my log file viewer (https://lnav.org https://lnav.org) uploads an agent to remote hosts in order to tail log files on that host[1]. While lnav itself is not built using cosmo, the agent is. So, it works on multiple OSs without having to compile and include multiple versions of the agent. [1] - https://lnav.org/2021/05/03/tailing-remote-files.html https://lnav.org/2021/05/03/tailing-remote-files.html
- folknor 3y ago
  Man oh man, how come I didn't find this tool 6 months ago? I think you need more topics/tags on the github repo :-D Extremely cool, I will definitely check out lnav when I get a chance. I've been battling with the big players for a few months now and their systems are just so overengineered and complex for my needs that it's silly. I just need tail -f for 10-ish servers and desktops. I haven't even read the project readme, but I presume lnav is exactly what I wanted. Excellent!
- dizhn 3y ago
  I just wrote a similar thing. A simple CLI that posts alerts and heartbeats to Alerta. I used Go mainly for the same reason. (But I also couldn't write it in C or C++ :D)
bambax 3y ago
Not sure what you mean by that, but a lot of great things start as toys. That even explains part of their success: nobody pays attention to toys, and once they become ubiquitous it's too late to fight them.

semiquaver 3y ago

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.

tstack 3y ago

> all so that the same binary runs on multiple operating systems, which isn’t actually very useful. I like to mention my use case when this comes up: my log file viewer (https://lnav.org https://lnav.org) uploads an agent to remote hosts in order to tail log files on that host[1]. While lnav itself is not built using cosmo, the agent is. So, it works on multiple OSs without having to compile and include multiple versions of the agent. [1] - https://lnav.org/2021/05/03/tailing-remote-files.html https://lnav.org/2021/05/03/tailing-remote-files.html

folknor 3y ago
Man oh man, how come I didn't find this tool 6 months ago? I think you need more topics/tags on the github repo :-D Extremely cool, I will definitely check out lnav when I get a chance. I've been battling with the big players for a few months now and their systems are just so overengineered and complex for my needs that it's silly. I just need tail -f for 10-ish servers and desktops. I haven't even read the project readme, but I presume lnav is exactly what I wanted. Excellent!
dizhn 3y ago
I just wrote a similar thing. A simple CLI that posts alerts and heartbeats to Alerta. I used Go mainly for the same reason. (But I also couldn't write it in C or C++ :D)

bambax 3y ago

Not sure what you mean by that, but a lot of great things start as toys. That even explains part of their success: nobody pays attention to toys, and once they become ubiquitous it's too late to fight them.