[Posted January 24, 2026 by corbet]
Version 2.43 of the GNU C Library has been released. Changes include support for the
mseal()and
openat2()system calls, experimental support for building with the Clang compiler, Unicode 17.0.0 support, a number of security fixes, and much more.
Yay for Clang
Posted Jan 25, 2026 20:50 UTC (Sun)
by jmalcolm (subscriber, #8876)
[Link] (36 responses)
Yay for Clang
Posted Jan 25, 2026 21:07 UTC (Sun)
by mb (subscriber, #50428)
[Link] (2 responses)
Well, all of Gnome, systemd, glibc and many many other projects predate musl.
So it's not really surprising, that musl is second class.
Same thing for clang. When it came along the ecosystem was already established.
I really don't see a "chosen walled garden" here.
It's just how history evolved.
Yay for Clang
Posted Jan 27, 2026 9:20 UTC (Tue)
by jmalcolm (subscriber, #8876)
[Link] (1 responses)
Yay for Clang
Posted Jan 27, 2026 10:42 UTC (Tue)
by farnz (subscriber, #17727)
[Link]
I am talking about the idea that I can create new APIs and demand that people use them.
In FOSS generally, this is extremely hard to do unless you provide all the developer time for the projects people care about. You can create a new API, but unless it solves a problem that people have, you'll just get ignored no matter how many demands you make.
And that then makes calling anything that's FOSS a "walled garden" quite an entitled position to hold; you're saying simultaneously that the same entity does all the work that you're depending on without asking for payment from you, while also not doing it to the standard you want them to do it to. You could break this by providing people who do more work than the "walled garden" owner, for example - but you're not doing so, while complaining that someone who provides the labour to make things happen isn't doing what you want.
Yay for Clang
Posted Jan 25, 2026 21:14 UTC (Sun)
by Wol (subscriber, #4433)
[Link] (2 responses)
Yay for Clang
Posted Jan 27, 2026 8:32 UTC (Tue)
by jmalcolm (subscriber, #8876)
[Link] (1 responses)
Yay for Clang
Posted Jan 27, 2026 9:41 UTC (Tue)
by anselm (subscriber, #2796)
[Link]
To quote the "History" section on the systemd Wikipedia page: "Lennart Poettering and Kay Sievers, the software engineers then working for Red Hat who initially developed systemd,"
Like many prominent Linux developers, Lennart Poettering and Kay Sievers “worked for” Red Hat in the sense that Red Hat was paying them a stipend to enable them to do whatever it was that they would be doing anyway. It's not as if their boss called them into his office one morning and told them to write systemd.
Also, systemd became popular not merely because Red Hat pushed it once it was there, but because most other mainstream distributions, too, quickly realised that it was a huge improvement on the status quo (including Upstart, which had run into limitations of its design). At that point, Linux was the only Unix-like system that still relied on the System-V init approach from the 1980s; all commercial Unixes had already moved on to newer infrastructure that was more like systemd than it was like System-V init, and it was fairly clear that something new and more suitable for the 21st century was needed on the Linux side, too.
Yay for Clang
Posted Jan 25, 2026 21:18 UTC (Sun)
by willy (subscriber, #9762)
[Link] (27 responses)
Yay for Clang
Posted Jan 25, 2026 21:36 UTC (Sun)
by josh (subscriber, #17465)
[Link] (11 responses)
Yay for Clang
Posted Jan 25, 2026 22:32 UTC (Sun)
by Cyberax (✭ supporter ✭, #52523)
[Link] (6 responses)
Yay for Clang
Posted Jan 25, 2026 22:46 UTC (Sun)
by josh (subscriber, #17465)
[Link] (5 responses)
I'm all for them taking a stand against PAM and NSS. But then, they need a strategy for a replacement. Not just "oh, don't use those", but a solution. For instance, a daemon that loads any NSS module and speaks some reasonable protocol that musl will check for by default.
Yay for Clang
Posted Jan 25, 2026 23:00 UTC (Sun)
by Cyberax (✭ supporter ✭, #52523)
[Link] (4 responses)
The solution is NSCD, it's supported natively by musl for NSS.
Yay for Clang
Posted Jan 26, 2026 3:59 UTC (Mon)
by josh (subscriber, #17465)
[Link] (3 responses)
Interesting. That appears to be new as of less than a year ago, but it does look promising. That's helpful. Perhaps distros should be adding that to Recommends or equivalent now.
Yay for Clang
Posted Jan 26, 2026 6:37 UTC (Mon)
by joib (subscriber, #8541)
[Link] (1 responses)
NSCD the protocol might be decent enough(?), but nscd the daemon is a horrible architecture, and said architecture is a big reason why it has largely been replaced with sssd.
Yay for Clang
Posted Jan 26, 2026 8:01 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Yay for Clang
Posted Jan 26, 2026 7:57 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Yay for Clang
Posted Jan 27, 2026 0:48 UTC (Tue)
by turistu (guest, #164830)
[Link] (2 responses)
Yay for Clang
Posted Jan 27, 2026 8:05 UTC (Tue)
by mchapman (subscriber, #66589)
[Link] (1 responses)
Under memory pressure, systemd's daemons call malloc_trim to ask the C library to release unused heap space. This function isn't implemented by Musl.
It might be the case that Musl doesn't need it. But I think that would mean it would be mapping and unmapping single pages at a time, which doesn't seem likely.
Yay for Clang
Posted Jan 27, 2026 11:44 UTC (Tue)
by wahern (subscriber, #37304)
[Link]
Yay for Clang
Posted Jan 27, 2026 9:15 UTC (Tue)
by jmalcolm (subscriber, #8876)
[Link]
Yay for Clang
Posted Jan 27, 2026 8:55 UTC (Tue)
by jmalcolm (subscriber, #8876)
[Link] (13 responses)
Yay for Clang
Posted Jan 27, 2026 9:22 UTC (Tue)
by Wol (subscriber, #4433)
[Link] (11 responses)
Yay for Clang
Posted Jan 27, 2026 10:22 UTC (Tue)
by jmalcolm (subscriber, #8876)
[Link] (8 responses)
Yay for Clang
Posted Jan 27, 2026 10:38 UTC (Tue)
by Wol (subscriber, #4433)
[Link]
Yay for Clang
Posted Jan 27, 2026 11:18 UTC (Tue)
by farnz (subscriber, #17727)
[Link] (5 responses)
But I romanticize the notion that Open Source means software ideas openly competing with the best implementation winning in the end. I want a Linux ecosystem that leads to better software as you describe. For that to happen, innovation is required but collaboration is essential. The worst case scenario is a project stifling competition not through technical superiority but rather through market power. At least, that is my view.
The thing I think you're missing is that a FOSS project effectively cannot stifle competition through market power, because the rights to modify the program for any purpose and to distribute your modified program inherently break market power. If I attempt to force a lesser solution on the world via my "market power", everyone who disagrees with me can fork the previous version and do things the way they want to, and no matter how much market power I have, I cannot force people to use my version and not the fork.
This does not, however, mean that only technical merit matters. "Best implementation" is a rather woolly term, and one way in which an implementation can be "the best" is if it gets the social side sufficiently better than a technically superior project that's hostile to outsiders. For example, Canonical tried to set things up (via CLAs) so that they'd have control over Mir and Upstart, and a consequence of that was that both projects effectively failed to gain traction, even with technical superiority over the alternatives. Similar things were tried with the OpenOffice trademarks, and the result was that LibreOffice (which is technically superior, too) took over the space OpenOffice used to live in.
And note that the OpenOffice case, in particular, was one where the lesser alternative technically tried to use its market power to stifle competition.
Yay for Clang
Posted Jan 27, 2026 11:41 UTC (Tue)
by Wol (subscriber, #4433)
[Link] (4 responses)
Yay for Clang
Posted Jan 27, 2026 11:50 UTC (Tue)
by farnz (subscriber, #17727)
[Link] (2 responses)
No, you're missing the point. If WordPerfect was FOSS (it wasn't), then you could maintain WordPerfect to your needs, and keep it in use, even if the WordPerfect developers took it down a "become a Word clone" route.
And I have looked at your previous post, and your rant here - there's nothing about "market power" in either of them, but rather about social influences, and your refusal to accept the mathematical proof that MV is a strict subset of relational in terms of what a database can do, since there is a 1:1 (in terms of number of operations) translation of MV into relational, but not the other way round.
Note that this doesn't mean that any implementation of relational is inherently better - after all, an MV design could well have better developer experience than a relational design - but that a technically perfect relational database can do everything any MV database can, with the same performance as, or better than, an MV database.
And yes, FOSS projects can stifle competition by being technically superior, or socially superior - but they cannot do so via market power.
Yay for Clang
Posted Jan 27, 2026 13:09 UTC (Tue)
by Wol (subscriber, #4433)
[Link] (1 responses)
Yay for Clang
Posted Jan 27, 2026 13:24 UTC (Tue)
by farnz (subscriber, #17727)
[Link]
For the first point - just because something is technically better in theory does not mean that all implementations are inherently better. Compare MySQL and PostgreSQL, for example - they both implement the same theory, yet do not have the same feature sets.
For the second: because SQL is not a great representation of relational, and you need an optimizer to go from the SQL query to a decent relational query. In addition, relational allows you to simply describe some very complex queries that in MV are simply not possible, and the optimizer allows the database engine to find a fast way to perform that query - where in MV, you just don't do that because you can't.
Put another way, those questions are like "why are planes not as good as buses at taking me on a 50 mile trip? Why do planes need autopilots, when buses don't - it's easy to show that an autopilot for buses would cost more than it saves?".
Yay for Clang
Posted Jan 27, 2026 11:51 UTC (Tue)
by pizza (subscriber, #46)
[Link]
Yay for Clang
Posted Jan 27, 2026 11:29 UTC (Tue)
by pizza (subscriber, #46)
[Link]
Yay for Clang
Posted Jan 28, 2026 18:51 UTC (Wed)
by rgmoore (✭ supporter ✭, #75)
[Link] (1 responses)
And seeing as this discussion seems to be about systemd, their attitude - whether you like it or not - seems to be "we're a linux-targeted utility, so who needs to care about other systems and standards". And the result is far better performance on linux.
Correlation isn't causation. It seems to me that the main reason systemd provides good performance is that they got the basic architecture right, not that they focused exclusively on the latest version of Linux, glibc, etc. Limiting their support to the latest, greatest versions likely boosted development speed when the project was getting off the ground, but that's different from their runtime performance.
Now that systemd is mature, it's probably time to go back and improve support for systems that got left out by the choice to focus on the newest versions of the most common stuff. I don't think systemd is ever going to support a different kernel, but they are actually working on musl support. They've gone from not supporting musl at all to limited support, and there's a plausible path forward using a shim library to provide functions that aren't in musl.
Yay for Clang
Posted Jan 28, 2026 19:47 UTC (Wed)
by bluca (subscriber, #118303)
[Link]
systemd builds and runs on on pretty much all non-EOL LTS distributions, most definitely not just "latest, greatest versions"
Yay for Clang
Posted Jan 27, 2026 9:45 UTC (Tue)
by taladar (subscriber, #68407)
[Link]
I strongly disagree with your last point since even just having a second variant of a dependency or a second option for anything you communicate with vastly complicates a code base. This is not the kind of change you can make in a way that completely insulates the original developers of a project from all the work involved. It affects readability, ease of API changes, constrains new features,...
Yay for Clang
Posted Jan 27, 2026 9:26 UTC (Tue)
by jmalcolm (subscriber, #8876)
[Link]
systemd musl support is WIP
Posted Jan 26, 2026 23:13 UTC (Mon)
by pevik (subscriber, #112535)
[Link] (1 responses)
systemd musl support is WIP
Posted Jan 27, 2026 9:02 UTC (Tue)
by jmalcolm (subscriber, #8876)
[Link]
Thank you for pointing out that the PostmarketOS and Adelie folks have been doing the work to bring systemd to musl. The chorus of replies above would have us believe that the musl ecosystem is full of freeloaders. Very far from it.
RISC-V
Posted Jan 25, 2026 21:00 UTC (Sun)
by jmalcolm (subscriber, #8876)
[Link]
Mathematical functions
Posted Jan 25, 2026 21:11 UTC (Sun)
by ubhofmann (subscriber, #47368)
[Link] (1 responses)
Mathematical functions
Posted Jan 26, 2026 6:33 UTC (Mon)
by joib (subscriber, #8541)
[Link]
It seems the techniques for generating math functions that are correctly rounded (to within 0.5 ulps) for all valid inputs, and are decently fast, is a relatively new thing. And then there are all the new floating point functions (new functions, as well as old functions for new floating point formats), handling rounding modes, and whatnot. Then add in SIMD implementations (libmvec) etc etc., and it's just a huge amount of work.