Hacker News Reader

Comment by mprovost | Hacker News Reader

Every time I see an update from Justine I get so excited. It's like watching the future of computing unfold in real time. It makes me wish we could send them back in time - all of the pieces to make this work have been in place for a long long time but nobody connected all the dots. The funniest part of this post are the instructions to integrate it with autoconf. All of that autotools nonsense wouldn't have had to exist if this had been around!

View on HN

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.

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?

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.

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.

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.

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!

Except modern HTTP and the whole security stack isn't part of those APIs either.

> 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) 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

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!

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)

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.

Definitely exciting. Portability of binaries is such a problem these days with all the angst around ABI compatibility in the Linux kernel and the push for containerization (e.g. lots of distros going towards Snap/AppImage). Justine's work seems like it's working towards a research idea from Alan Kay about developing a kind of "Model T" library that provides a solid core for all computing [0].

I'm also kind of jealous. Like most of us I work on big systems with millions of lines of spaghetti code. I think that building very small, reliable tools like Justine's would be much more impactful work.

[0] https://web.archive.org/web/20070625105727/http://www.intel-...

exactly!

Reply on news.ycombinator.com