←back to thread

428 points ahamez | 1 comments | | HN request time: 0.218s | source
Show context
dwattttt ◴[] No.45008529[source]
The reminder to "never break userspace" is good, but people never bring up the other half of that statement: "we can and will break kernel APIs without warning".

It illustrates that the reminder isn't "never change an API in a way that breaks someone", it's the more nuanced "declare what's stable, and never break those".

replies(4): >>45008615 #>>45008791 #>>45013042 #>>45023886 #
delta_p_delta_x ◴[] No.45008791[source]
Even if the kernel doesn't break userspace, GNU libc does, all the time, so the net effect is that Linux userspace is broken regardless of the kernel maintainers' efforts. Put simply, programs and libraries compiled on/for newer libc are ABI-incompatible or straight-up do not run on older libc, so everything needs to be upgraded in lockstep.

It is a bit ironic and a little funny that Windows solved this problem a couple decades ago with redistributables.

replies(3): >>45009117 #>>45009576 #>>45010177 #
Retr0id ◴[] No.45009117[source]
otoh staticly-linked executables are incredibly stable - it's nice to have that option.
replies(1): >>45009151 #
delta_p_delta_x ◴[] No.45009151[source]
From what I understand, statically linking in GNU's libc.a without releasing source code is a violation of LGPL. Which would break maybe 95% of companies out there running proprietary software on Linux.

musl libc has a more permissive licence, but I hear it performs worse than GNU libc. One can hope for LLVM libc[1] so the entire toolchain would become Clang/LLVM, from the compiler driver to the C/C++ standard libraries. And then it'd be nice to whole-program-optimise from user code all the way to the libc implementation, rip through dead code, and collapse binary sizes.

[1]: https://libc.llvm.org/

replies(5): >>45009258 #>>45009341 #>>45009570 #>>45009571 #>>45010638 #
loeg ◴[] No.45009341[source]
You can (equivalently) distribute some specific libc.so with your application. I don't think anyone other than GNU maximalists believes this infects your application with the (L)GPL.
replies(2): >>45011087 #>>45013890 #
Retr0id ◴[] No.45011087[source]
You'd need to distribute ld.so also, otherwise you'll run into ld/libc incompatibilities.
replies(1): >>45015996 #
loeg ◴[] No.45015996[source]
Sure.
replies(1): >>45026587 #
1. account42 ◴[] No.45026587[source]
... and ld.so needs to be at a specific absolute path so you can't just distribute it along with your application, you need to use an actual container for this.