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

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.

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)

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

> universally executable native applications

To achieve that you'll need some kind of compatibility layer. Perhaps something like wine? Or WSL? Or a VM?

Then you'll have what we already have with JVM and similar

https://justine.lol/ape.html -- αcτµαlly pδrταblε εxεcµταblε

this works for actual compiled code. no vm, no runtime, no interpreter, no container. native compiled machine code. just download and double-click, no matter which OS you use.

"Please note this is intended for people who don't care about desktop GUIs, and just want stdio and sockets without devops toil."

cosmopolitan-libc has aspirations (but not concrete plans) to add SDL interfaces for all supported platforms. this would allow APE executables to compile-in cross-platform UI toolkits like QT.

Aspirations are nice and all. Java's had them for three decades now.

How different would that be from Flatpak

Does it make linux applications run on Windows or mac?