Hacker News Reader

And to assume that only the syscall ABI layer is important is quite the understatement. I have software from the 90s that would work perfectly fine if it weren't for the fact that /etc/mtab is now a symlink. And that is just an example of the most smallish change -- not going to enter into the bazillions of binaries that are broken due to changes in audio APIs (even though the syscall numbers are still the same).

Static linking for future-proofing/compatibility has never been a valid argument in my experience. Not only it is much easier to fix (and debug) a broken dynamically linked binary than a statically linked one, I would even dare to say that statically linked binaries break much more frequently than dynamically linked ones when you change the rest of the system. Even when you include the breakage from libraries changing under the feet of the dynamic binaries.

There is a distinction between a fully-static binary and a non-fully-static one, which is what I think the article refers to. A fully static binary will not need to call the dynamic linker at all, and tools such as "file" or "ldd" will identify such binaries differently. A fully static binary will also run even in the complete absence of any userspace support for its architecture (assuming the hardware and kernel do support it) - e.g. a static AArch64 binary will run on a 32-bit ARM distribution, if the CPU supports AArch64.

True, however...

> assuming the hardware and kernel do support it

Assuming kernel support is doing a lot of heavy lifting there. To put it another way, why is a syscall better than any other stable ABI? If both kernel and stable library are distributed together then why should it be considered different?

Indeed, Linux is the outlier here. Maybe it's better. But the designers of, say, Solaris, Mac and Windows didn't think so.

Even Linux isn't really the outlier. The syscall convention is stable, but you're not statically linking the kernel into your binary.

A "library OS" like FreeRTOS does exactly that: the kernel is just another library, with functions that you call like any other static dependency. You can only run one process (the OS & your userspace code are that process).

Really the "fully static" side is only seen in practice in RTOSes and similar embedded systems work. Being able to dynamically load more than a single process is just too handy to give up entirely. I don't think the opposite extreme has even been tried (every single symbol in its own .so, even within the kernel), the overhead would be ridiculous.

If a kernel and library really are always distributed together, so religiously iron clan that you can and should treat them as a single object, then why are they not in fact a single object?

A syscall may not be inherently too different from any other interface, but a single interface is certainly different from two interfaces.

Author here.

Kernel support is actually easy: since Linux hardly ever removes syscalls, just build your fully-static executable on the oldest Linux you have, and then deploy it on all of your relevant machines.

The syscalls used by all of your libraries, if they work on that oldest Linux, would work on the newer ones.

In fact, this is why AppImage "Best Practices" includes building on the oldest system. [1]

[1]: https://docs.appimage.org/reference/best-practices.html?high...

If you build against, say, RHEL5, you presumably acquire vulnerabilities in relevant libraries, give up hardware support, and still can't guarantee it will run correctly. That's at least because Linux interfaces aren't stable in general, specifically the pseudo-filesystem ones, thinking of real examples.

Author here.

This is exactly what I was getting at. Thank you.

The word "static" is being conflated with "stable".

A "static interface" isn't a thing. There's stable and unstable interfaces, and static and dynamic linkage. Not strongly related.

I'm distributing my code as a bootable USB drive.