Musl Libc 1.0 Is Going To Be Released Real Soon

[phoronix]

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...

http://www.phoronix.com/vr.php?view=MTYyMzM

[Dharc]

GNU is dying

[DebianLinuxero]

Standard MIT license ... ummh ...


SCREW IT!

[ncopa]

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".

[caligula]

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?

[curaga]

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?

Yes, Felker is critical of systemd. Citation needed on "lacking knowledge".

[droste]

Yes, Felker is critical of systemd. Citation needed on "lacking knowledge".

Well not lacking knowledge but ignoring it He was the one that stated "systemd makes it impossible to upgrade without rebooting" in his blog and a few sentence later stated "With regards to upgrades, systemd's systemctl has a daemon-reexec command to make systemd serialize its state, re-exec itself, and continue uninterrupted"

[caligula]

Yes, Felker is critical of systemd. Citation needed on "lacking knowledge".

The reddit threads revealed lots of gaps in the articles argumentation. People in general believe systemd is much better than he thinks. So maybe he's wrong.

[Ibidem]

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:

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");

At least 99% of the time, these are going to be irrelevant.
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.

[ncopa]

Well not lacking knowledge but ignoring it He was the one that stated "systemd makes it impossible to upgrade without rebooting" in his blog and a few sentence later stated "With regards to upgrades, systemd's systemctl has a daemon-reexec command to make systemd serialize its state, re-exec itself, and continue uninterrupted"

From the blog post:

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).

(emphasis was mine)

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.