Hacker News new | ask | show | jobs
by Piskvorrr 404 days ago
The devil is in the details.

What do you mean, "requires Windows 11"? What is even "glibc" and why do I need a different version on this Linux machine? How do I tell that the M4 needs an "arm64", why not a leg64 and how is this not amd64?

In other words, it's very simple in theory - but the actual landscape is far, FAR more fragmented than a mere "that's a windows/linux/mac box, here's a windows/linux/mac executable, DONE"

(And that's for an application without a GUI.)
1 comments
fifilura 404 days ago
Yes, it is difficult, but difficult problems have been solved before.

With dependency management systems, docker, package managers.

MacOS and Windows is closed source and that is of course a problem, I guess the first demo would be universally runnable linux executable on Windows.

link
int_19h 404 days ago
> I guess the first demo would be universally runnable linux executable on Windows.

The other way around is easier, and already exists thanks to Wine and the ability of Linux kernel to register custom executable formats (https://docs.kernel.org/admin-guide/binfmt-misc.html)

link
Piskvorrr 403 days ago
I have been trying. As I may not have been entirely clear the first time:

It's not that hard to wrap your python/java/whatever app in a polyglot executable that will run on your Linux box, on your Mac, and on your Windows box. Here's a much harder target: "I would like to take this to any of such boxes, of reasonably vanilla config, and get it to run there, or at least crawl. 'Start and catch fire' doesn't count, 'exit randomly' doesn't count." The least problematic way to do this is "assume Java", and even that is wildly unsuccessful (versions and configs and JVMs, oh my!). The second least problematic is "webpage" (unless you are trying to interact with any hardware).

The differences in boxes within an OS are often as large as differences across OSes. Docker was supposed to help with this by "we'll ship your box then," and while the idea works great, the assumption "there's already a working Docker, and/or you can just drop a working Docker" is...not great: you just push everything up a level of abstraction, yet end up with the original problem unsolved and unchanged. (There's an actual solution "ship the whole box, hardware and everything," but the downsides are obvious)

link