Top
Best
New

Posted by generichuman 4/1/2025

The state of binary compatibility on Linux and how to address it(jangafx.com)
201 points | 143 commentspage 2
DrNosferatu 4/2/2025|
Zig CC + Vulkan would solve most of these issues:

1. Zig's toolchain statically links with musl libc, producing binaries that depend only on the Linux kernel syscall ABI, not any specific glibc version.

2. This eliminates all the symbol versioning nightmares (`GLIBC_2.xx not found`) that plague distribution across different Linux systems.

3. Vulkan provides a standardized, vendor-neutral GPU API that's supported across all modern graphics hardware, eliminating driver-specific dependencies.

4. The resulting binary is completely self-contained - no external library dependencies, no version mismatches, no containerization needed.

5. You get forward AND backward compatibility - the binary will run on both ancient and cutting-edge distros without modification.

The only real limitation is for NVIDIA CUDA-specific workloads, where you'd still need their proprietary stack.

Furthermore, for those who prefer a higher-level API, Zig CC + WebGPU offers similar benefits with a simpler programming model, though with slightly less mature implementations and a possible small performance overhead.

h4ck_th3_pl4n3t 4/2/2025||
Isn't the compatibility promise what syscalls essentially are?

Historically, they (almost) never break and they are steadily incremented to prevent overlaps in differences of parameters.

As WASI is also implementing syscalls for WASM, I'd argue that the binary format doesn't really matter as long as it's using the same syscalls in the end.

I understand this topic is mostly focussing on glibc/muslc problems, but if you want to develop stable software, use CGo free Go binaries. They likely will run in 10 years the same way they do today.

C ABI compatibility is a mess on linux mostly because upstream maintainers don't give a damn about semantic versioning. Just take a look at the SO file headers, and how they differ from upstream "semantic" versions of the library. As long as shared objects differ in versions due to breaking changes, and as long as the C ecosystem doesn't enforce correct versioning, this won't change.

ryao 4/2/2025||
> GLIBC is an example of a "system library" that cannot be bundled with your application because it includes the dynamic linker itself. This linker is responsible for loading other libraries, some of which may also depend on GLIBC—but not always.

Running WordPerfect on modern Linux is done by shipping both of those components:

https://github.com/taviso/wpunix

everdrive 4/2/2025||
There’s no reason to believe that widespread Linux adoption would not irrevocably damage the experience. It would end up looking something like Android. The same thing happened to the internet. It was ruined by mass adoption. You can call this gatekeeping, but nothing positive has come from getting most of the world onto social media.
thewebguyd 4/2/2025|
I'm inclined to agree with you here. As much as I'd love to see native apps from some big vendors (Adobe, in particular) if what it takes to get there is mass adoption of Linux on the desktop, I'm not sure I want it.

In a way, we already have it in the form of ChromeOS, and I certainly don't want ChromeOS or Android to be the default experience, or for the community to start to cater to that model.

All of the things Linux would need to become to get Windows level marketshare would strip away what makes it appealing in the first place, in particular, full user control. I don't want a nanny desktop, but that's exactly what it would become.

Linux can stay niche for those who appreciate it as it is.

knowaveragejoe 4/2/2025||
No discussion of Cosmopolitan or APE?
h4ck_th3_pl4n3t 4/2/2025|
Software and binary formats with a 100% chance of being blocked as malware doesn't count.
dp-hackernews 4/7/2025||
I'm surprised nobody has mentioned the "nix" package manager from NixOS as an alternative here...
mrbluecoat 4/2/2025||
> shipping software on Linux

That's a surprisingly hard nut to crack when containers won't work for your use case. We found https://github.com/silitics/rugix to work well in that situation.

advisedwang 4/2/2025||
golang seems to manage being 100% statically linked (unless you go out of your way, by using plugins). It just forgoes the stuff that the article mentions glibc doing dynamic linking for, and does it the simple and direct way.
okanat 4/2/2025|
What do you use golang for? If your answer is only web-dev and if you don't touch anything GUI, system libraries, PAM or VPNs, you simply haven't compiled something complex enough.
bee_rider 4/2/2025||
Really the title should be something like “the difficulty of releasing binaries on Linux and how to work around it.” It isn’t really an atrocious state, the goal of a distro should be to get useful software into the repos. Software not distributed in an open source format doesn’t really help there.
grumpy_coder 4/2/2025|
Related video about releasing games on linux, i.e. dlopen() all the things https://www.youtube.com/watch?v=MeMPCSqQ-34
More comments...