GNU is dying
Phoronix: Musl Libc 1.0 Is Going To Be Released Real Soon
I've been informed by the musl development camp that they intend to release version 1.0 of their standard C library in the next few weeks...
GNU is dying
Standard MIT license ... ummh ...
My laptop with XFCE runs Alpine Linux with musl libc and Alpine Linux 3.0 will be shipped with musl.
One of the nice things with musl is that it is pretty strict when it comes to standards. So if your project builds with musl libc, then it is a good sign that you are doing things "right".
No offence, but isn't this MUSL guy the one who is criticizing systemd with lacking knowledge? How do we know this libc of their is any good?
Remember that this is from someone who is very much a perfectionist.
Rich's take seems to be that it's not suitable for there to be any possibility for anything less than a kernel or hardware bug to crash the core system components (such as init and the libc).
Some examples of how far he takes that are his insistence that the dynamic linker and libc must be one file that can be upgraded atomically. If they aren't, a mismatch might make a program executed at precisely the wrong time crash.
Likewise, he considers this a possible race condition:
At least 99% of the time, these are going to be irrelevant.Code:unlink("/lib/ld-musl-i386.so.1"); //remove the musl dynamic linker //Until this next line returns, the system cannot start dynamically linked programs symlink("/lib/libc.so", "/lib/ld-musl-i386.so.1");
But there is a tiny window during the update when you could have something fail to start--which could, at least in theory, be the moment that something important starts....
Similarly, he maintains that malloc() should succeed only when there is actually the memory to fill every request that has been made so far, since overcommit leads to the OOM killer.
(emphasis was mine)This could perhaps be used to switch to a new version without rebooting. ... Unfortunately, this brings us back to the issue of PID 1 being special. For normal applications, if re-execing fails, the worst that happens is the process dies and gets restarted (either manually or by some monitoring process) if necessary. However for PID 1, if re-execing itself fails, the whole system goes down (kernel panic).
So basically his point is, you can 'solve' the problem with re-exe, but then you create new problems with reliable error handling. Which of course will require a lot of more smart solutions.... A bit down the road you will have tons of smart solutions for problems that didnt really need to be there in the first place, similar to what you have on Windows systems. I his point of view it would be better to not create those problems in the first place by keeping pid 1 small.
I don't think that qualifies for "lack of knowledge" or "ignoring the knowledge". It qualifies for "disagree" though.
(He could have worded himself a bit better by saying "systemd makes it impossible to reliable upgrade without rebooting" since people who do lack knowledge defines 'impossible' different)
I do find it very interesting that you can not openly criticize or disagree with how things in systemd is engineered nowdays. If you do - even if you have valid points - people will make others believe that you "lack knowledge", true or not.