←back to thread

428 points ahamez | 2 comments | | HN request time: 0s | 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 #
1. cxr ◴[] No.45013890[source]
"GNU maximalist" is an odd choice of wording, since it would seem to imply people who are the most well-informed about the project's licenses, but anyone who thinks that distributing an LGPL library without your own app's corresponding source code is someone who flat out doesn't understand the LGPL.
replies(1): >>45016061 #
2. cxr ◴[] No.45016061[source]
A mistake in my own wording crept in here; this should have said:

> one who thinks that distributing an LGPL library without your own app's corresponding source code is forbidden is someone who flat out doesn't understand the LGPL