GNU C Library 2.43 released

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

to post comments

TX lock elision

Posted Jan 25, 2026 12:53 UTC (Sun) by ballombe (subscriber, #9523) [Link] (8 responses)

> * The support for TX lock elision of pthread mutexes has been removed on all
architectures (powerpc, s390x, x86_64).

Any detail ?

TX lock elision

Posted Jan 25, 2026 13:22 UTC (Sun) by csamuel (✭ supporter ✭, #2624) [Link] (7 responses)

The thread where it was decided to deprecate it (which started off as just S390x wanting to remove it as hardware support was deprecated in z16 and reduced in z17) is here: https://sourceware.org/pipermail/libc-alpha/2025-July/168... and the deprecation patch is here: https://sourceware.org/pipermail/libc-alpha/2025-July/168...

There was a very short thread on the removal itself, which includes this comment about ARM64 also obsoleting transactional memory support. https://sourceware.org/pipermail/libc-alpha/2025-November...

TX lock elision

Posted Jan 25, 2026 19:43 UTC (Sun) by ballombe (subscriber, #9523) [Link] (6 responses)

So it is yet another hardware feature that does not pan out.

TX lock elision

Posted Jan 25, 2026 20:23 UTC (Sun) by csamuel (✭ supporter ✭, #2624) [Link]

Sadly yes. Back in 2012 when we were getting our BlueGene/Q there was a lot of excitement about it having HTM but it never came to anything. There was this paper from IBM itself (PDF) https://dl.acm.org/doi/pdf/10.1145/2370816.2370836 which says:

> While it is widely expected that such overheads be significantly reduced in an HTM, one of the surprising findings of this performance study is that, the BG/Q HTM overhead, while much smaller than that of STM’s, is still non-trivial. The causes of HTM overheads are also very different from those of STM’s. For instance, BG/Q TM maintains speculative states in the L2 cache. This allows for transactions with a large memory footprint, the price to pay, however, is the overhead, where the L1 cache is either bypassed during a transaction or flushed upon entry to a transaction. The loss of cache locality is the dominant cause of BG/Q TM overhead

TX lock elision

Posted Jan 25, 2026 21:27 UTC (Sun) by josh (subscriber, #17465) [Link] (4 responses)

That's pretty much the history of transactional memory, both software and hardware.

https://imgur.com/a/cXCtzsr

TX lock elision

Posted Jan 26, 2026 6:22 UTC (Mon) by pthariensflame (subscriber, #169079) [Link] (1 responses)

For whatever it's worth, (software) transactional memory has found genuine sustained use in one specific ecosystem: Haskell, in which the monad-based effect control makes it a lot less error-prone to use.

TX lock elision

Posted Jan 27, 2026 1:49 UTC (Tue) by josh (subscriber, #17465) [Link]

I'm familiar (I used to program Haskell), but I also think it fits Haskell because it optimizes for compositional simplicity at the expense of performance.

TX lock elision

Posted Feb 8, 2026 17:33 UTC (Sun) by joib (subscriber, #8541) [Link] (1 responses)

Amusingly, it seems a patch queued up for the 6.20 (or 7.0 if Linus decides to bump the major version number?) kernel enables it on x86, with a mention in the commit msg stating that SUSE has been having it enabled for a long time.

https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.g...

7.0

Posted Feb 8, 2026 20:42 UTC (Sun) by corbet (editor, #1) [Link]

At the Maintainers Summit, Linus told us that the next release would be 7.0. No need to wonder about that — unless he changes his mind, of course.

Yay for Clang

Posted Jan 25, 2026 20:50 UTC (Sun) by jmalcolm (subscriber, #8876) [Link] (37 responses)

It is good to see progress on being able to build Glibc with Clang.

One of my least favourite things about the GNU ecosystem is how they have ironically chosen to make it a walled garden where choosing any of their stuff means having to use the rest of their stuff as well.

To be fair, I should probably be saying Red Hat Linux Platfrom instead of GNU as Red Hat controls all the parts of GNU that anybody cares about and some of my complaints are with Red Hat software outside of the GNU Project like Systemd. Systemd has always insisted on Glibc and not worked with musl for example. And GNOME requires Systemd. and Glibc only works with GCC.

On the one hand, I see the value of defining a standard "platform" that defines "Linux" as fragmentation has its costs. But one of the things I value most about Open Source is choice and how different implementations compete to drive innovation in the system.

I am not saying "Red Hat" as a user or customer as I do not use their products (other than as code in other distros). It is simply my view that what Red Hat sees as "Linux" tends to dominate what becomes standard in other distoros as well and that Red Hat is unconcerned or even hostile to interoperability outside their platform.

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)

I am not talking about timing. I am talking about the idea that I can create new APIs and demand that people use them.

A walled garden refers to a closed, controlled ecosystem, where a single operator dictates access applications, and infrastructure, restricting external, non-approved services

The issue is when things work fine until incompatibility is introduced. And even this is ok unless you resist attempts from others to bring compatibility back.

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)

> To be fair, I should probably be saying Red Hat Linux Platfrom instead of GNU as Red Hat controls all the parts of GNU that anybody cares about and some of my complaints are with Red Hat software outside of the GNU Project like Systemd.

Except, as I understand it, systemd is not (and never has been) Red Hat software ... okay, they were one of the first adopters, but that's not to say it's their software ...

> It is simply my view that what Red Hat sees as "Linux" tends to dominate what becomes standard in other distoros as well and that Red Hat is unconcerned or even hostile to interoperability outside their platform.

Well, they ARE the big fish in the pond. I don't like it (or Red Hat distros), but if you're the local Great White, why should you care about the small fry around you?

Cheers,
Wol

Yay for Clang

Posted Jan 27, 2026 8:32 UTC (Tue) by jmalcolm (subscriber, #8876) [Link] (1 responses)

> systemd is not (and never has been) Red Hat software

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

Lennart built systemd on Fedora and first released it to the world on a Fedora 13 QEMU image. I think Fedora was the first distro to adopt it. Fedora being the place that future Red Hat engineering appears first.

But it is not even important to my point that Red Hat invented systemd. My point is that, once they adopt it into their platform, they work to make it essential by making sure that the rest of the system relies on it.

> if you're the local Great White, why should you care about the small fry around you?

I cannot argue with that and it was not actually my intention to. I do not use Red Hat distros but I do enjoy a lot of the software that they create and or contribute to. And I do see the value in a standard Linux platform as the default.

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)

One of my least favourite things about the GNU ecosystem is how some people demand that other people do work to support their niche use case.

The source code is there. You have the right to do the work. You don't have the right to demand that SystemD supports musl. There's a cost to supporting multiple libc/compiler/architecture/... and it's up to the maintainer whether they want to pay that cost.

If you disagree with the maintainer's decision, you're free to publish your own fork. If you can attract other people to it, perhaps your fork becomes the default.

But this attitude of entitlement to other people's time and effort is horribly destructive. Framing it as "evil Red Hat" doesn't make it better.

Yay for Clang

Posted Jan 25, 2026 21:36 UTC (Sun) by josh (subscriber, #17465) [Link] (11 responses)

Also, relatedly, people always say things like "make systemd support musl" rather than "make musl support systemd"; there's always a direction to the entitlement. systemd didn't (past tense, they're adding basic musl support now) compile on musl because musl was missing functionality systemd expected. And systemd's current partial support for musl still reflects that:

> Incomplete support for musl libc is now available by setting the "libc" meson option to "musl". Note that systemd compiled with musl has various limitations: since NSS or equivalent functionality is not available, nss-systemd, nss-resolve, DynamicUser=, systemd-homed, systemd-userdbd, the foreign UID ID, unprivileged systemd-nspawn, systemd-nsresourced, and so on will not work. Also, the usual memory pressure behaviour of long-running systemd services has no effect on musl. We also implemented a bunch of shims and workarounds to support compiling and running with musl. Caveat emptor.

I appreciate musl (other than the slide towards permissive license), and I use musl for some use cases, but it *is* missing functionality. (NSS is awful, but it's an awfulness people rely on, so there needs to be a sufficiently compatible replacement. And that's not the only thing it's missing.)

Similarly, people say "GNOME should support non-systemd" rather than "non-systemd should add the functionality GNOME is relying on". And if you try to bring that up, it leads to one of the "well, systemd does too much" tirades. Turns out people *do* want that functionality. People wrote the software, people want to use the software, and at some point people want to stop having to support the less functional alternative.

Yay for Clang

Posted Jan 25, 2026 22:32 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link] (6 responses)

On the other hand, musl taking a principled stance against broken PAM and NSS can result in a better overall architecture. As people are forced to deal with not having these systems.

Otherwise, there's just no pressure to change anything.

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]

The NSCD daemon itself is a mess, but the NSCD protocol is dead simple. There is even a bridge allowing the use of NSS modules via NSCD: https://github.com/pikhq/musl-nscd/tree/master

It basically was ignored by everyone.

Yay for Clang

Posted Jan 26, 2026 7:57 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

NSCD has been supported in musl for more than a decade: https://github.com/kraj/musl/commits/ff441c9ddfefbb94e588...

Yay for Clang

Posted Jan 27, 2026 0:48 UTC (Tue) by turistu (guest, #164830) [Link] (2 responses)

> Also, the usual memory pressure behaviour of long-running systemd services has no effect on musl.

Can someone explain what they're trying to say in that hedged, convoluted statement?

Is it that musl's free(3) never ends up calling brk(2) or munmap(2) to actually release the freed up memory?

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]

musl does return memory to the kernel. See free at https://git.musl-libc.org/cgit/musl/tree/src/malloc/mallo... I haven't read closely enough to really understand the heuristics, or the general architecture for that matter, but off-the-cuff I'd guess it's pretty aggressive, but not stupid aggressive. It shouldn't be too difficult to explore. The code is incredibly short compared to ptmalloc, etc; not just free.c, but all of mallocng/.

Yay for Clang

Posted Jan 27, 2026 9:15 UTC (Tue) by jmalcolm (subscriber, #8876) [Link]

> people say "GNOME should support non-systemd" rather than "non-systemd should add the functionality GNOME is relying on"

I use Chimera Linux which does not use systemd. When GNOME announced their changes, the lead Chimera Linux dev very quickly announced that they would be doing the work to make GNOME. And this is the way it should be.

https://gts.q66.moe/@q66/statuses/01JXFJWFGBSB1KK9E7Y8JBFQN4

As before though, my complaint will be about how open GNOME is to accepting patches from other projects. GNOME does not have to do the work. But I hope they do not block it either.

And as with the NSS discussion in other comments, there is a difference between completely lacking a required capability and simply not using the exact API we want you to.

Yay for Clang

Posted Jan 27, 2026 8:55 UTC (Tue) by jmalcolm (subscriber, #8876) [Link] (13 responses)

> But this attitude of entitlement to other people's time and effort is horribly destructive.

I will take that criticism as that is a point I am normally making myself very strongly. In my view, it is perfectly acceptable for Open Source projects to develop for their own needs. If other projects have different needs they can add things themselves. In fact, I have advocated that some Open Source projects consider organizing as two projects: the core (serving whatever goals the core project has) and an "ecosystem" project around it that works to extend it. Desktop environments would be good examples of projects that could work using this model. So we agree on the point you are making.

That said, I do have two qualifying comments in this case:

First, when we are talking about things like C libraries, there are already open standards like POSIX. The "we are going our own way and you can join us or be left behind" attitude seems a little more destructive in this case. No?

Second, I do think Open Source projects should be open to receiving contributions that provide compatibility. Systemd as a project has not just "not done the work" to support musl. They have been actively hostile to anybody doing it.

In the past, when patches to build systemd on musl were submitted, they were rejected with the explanation that glibc is "the Linux API". I fully understand saying that the systemd devs should not have to do work to support musl. No problem with that. But saying that the only way you will let systemd build on musl is if musl implements the full glibc API is another thing entirely.

That is what I am talking about.

Yay for Clang

Posted Jan 27, 2026 9:22 UTC (Tue) by Wol (subscriber, #4433) [Link] (11 responses)

> First, when we are talking about things like C libraries, there are already open standards like POSIX. The "we are going our own way and you can join us or be left behind" attitude seems a little more destructive in this case. No?

No. It's unfortunate, but you don't have to read LWN for long to find a long litany of APIs that don't actually work, for one reason or another. Including Posix. There are or were quite a few cases of broken Linux behaviour, that were only fixed when Linus threw posix out the window and did something else instead.

I agree with you - throwing open standard C libraries out can be destructive. But so can sticking with them, when they're outright broken for whatever reason (poor design, out-of-date, no longer relevant, whatever ...)

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.

Cheers,
Wol

Yay for Clang

Posted Jan 27, 2026 10:22 UTC (Tue) by jmalcolm (subscriber, #8876) [Link] (8 responses)

Fair enough. Thanks for the response.

Of course, it is not always true that the best solution wins. FreeBSD has had to implement quite a few APIs and command-line switches that they do not consider superior. FreeBSD has had to add OCI container support despite already having Jails which they seem to like better. I am not a FreeBSD user BTW.

It is more about popularity than superiority. To the victor go the spoils. Which is the real world. I get that.

But what does "we're a linux-targeted utility" actually mean?

Let's look at musl. It is massively popular in the embedded space. There are A LOT of embedded Linux systems out there not running glibc. And Alpine Linux (musl based) is a massively popular container base. There are A LOT of Linux systems running musl in the cloud. And a growing number of other Linux distros, including the one I favour, use it too.

I do not agree with the folks that say Android is "Linux" but it certainly uses the Linux kernel. And it uses yet another C library (bionic).

So what does "Linux" targeted mean? The suggestion I made in my original post is that this means the Red Hat Linux Platform and the suite of engineering choices they have made. This is the most widely deployed set of software on Linux desktops and servers to be fair.

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.

Yay for Clang

Posted Jan 27, 2026 10:38 UTC (Tue) by Wol (subscriber, #4433) [Link]

> The worst case scenario is a project stifling competition not through technical superiority but rather through market power. At least, that is my view.

Amen :-(

WordPerfect is FAR superior to Word (and the world of Word clones we inhabit now). If Wine now has good WoW 16-bit support, I shall have to have another go at resurrecting my WP6.1 (for DOS!/Win3.1) and get that running again.

And my rants about Pick/MultiValue. I've just put a spec in to my boss and said "allow 2 weeks (8 including contingency) for using MV". I'll probably miss the 2 weeks - I don't consider myself a star programmer. But "allow 6 weeks, 24 including contingency, I *expect* to miss the 24, for using Relational/SQL".

There's far too much top-notch technology that gets eclipsed by marketing, monopoly EEE, or just the "ooh shiny" :-(

Cheers,
Wol

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)

> 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 misses the point COMPLETELY! What is the point of forking a broken design? And how are you supposed to rebuild your fork from the ground up with a fundamental new design?

That's the point of my WordPerfect/Word rants. Word won through EEE, and we now inhabit a world of Word clones. I could fork LibreOffice and try to impose the WordPerfect design on it, but is that going to go anywhere? Really?

Look at my previous post! I've quoted an ORDER OF MAGNITUDE increased productivity at my boss if I'm allowed to use MV. But the response from the world in general (and here on LWN) is "we're not interested. Relational is the standard". I actually expect my boss to be sympathetic - I'm quite likely to get the chance. But even if I succeed, it'll be an uphill battle to get wider adoption.

So yes, IT'S EASY for a FOSS project to help stifle competition, if it re-inforces a broken design paradigm. (To try and stay on topic with Clang - it can happen that you get a breakthrough. But Rust is only succeeding because people recognise that C is broken. Persuading people that Word and Relational are broken is extremely hard.)

Cheers,
Wol

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)

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

So how come modern relational databases are only now catching up with MV as far as what the actual database itself is capable of?

> 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 again, why does a SQL query need an optimiser? MV doesn't have an optimiser, because it's an easy proof it costs more than it saves.

Anyway, we're getting off topic and one of the editors will probably be stomping on this pretty quickly.

Cheers,
Wol

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]

>This misses the point COMPLETELY! What is the point of forking a broken design?

So you write something new instead. Either way the onus is on you to convince other folks that your fork/new design/whatever is "better" than what was there before. Or use something else entirely. Meanwhile, assuming both old and new are F/OSS, farnz's point about not being able to "stifle competition through market power" equally applies, because you're always free [1] to do your own thing.

[1] As in, have the legal ability. As opposed to other practical "have the skills/time/money/etc".

Yay for Clang

Posted Jan 27, 2026 11:29 UTC (Tue) by pizza (subscriber, #46) [Link]

> But what does "we're a linux-targeted utility" actually mean?

In this context, they rely on features/APIs that are provided _only_ by Linux-the-kernel. As in not implemented/provided by any other *nix/BSD.

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]

> If you disagree with the maintainer's decision, you're free to publish your own fork

The ability to fork is a strength of Open Source for sure. But forking on a whim does not serve the greater good. The power of Open Source is to collaborate on creating better software. This is the core thesis of the Open Source movement.

Forcing people to fork you to achieve basic interoperability is very destructive. As I have seen in other comments, I do not a project to do the work to serve other interests. But saying that it is totally ok behaviour for an Open Source project to be hostile to those efforts is not the answer. At least, not in my view.

systemd musl support is WIP

Posted Jan 26, 2026 23:13 UTC (Mon) by pevik (subscriber, #112535) [Link] (2 responses)

> Systemd has always insisted on Glibc and not worked with musl for example. And GNOME requires Systemd. and Glibc only works with GCC.

Thanks to postmarketOS folks systemd musl support is WIP:
https://postmarketos.org/blog/2026/01/25/pmOS-update-2026...

First PR has been merged (more work will be needed):
https://github.com/systemd/systemd/pull/38825

systemd musl support is WIP

Posted Jan 27, 2026 9:02 UTC (Tue) by jmalcolm (subscriber, #8876) [Link] (1 responses)

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.

systemd musl support is WIP

Posted Jan 30, 2026 11:36 UTC (Fri) by dtardon (subscriber, #53317) [Link]

Well, 39 of the 41 (somewhat) musl-related commits merged since systemd 258 were authored by systemd developers (mainly Yu Watanabe)...

This is based on a simple query:

git log v258.. --grep musl --no-merges src

RISC-V

Posted Jan 25, 2026 21:00 UTC (Sun) by jmalcolm (subscriber, #8876) [Link]

It is also nice to see a little RISC-V love.

"On RISC-V, an RVV-optimized implementation of memset has been added"

RVV is the RISC-V Vector extension. As RVV is part of the RVA23 profile requirements, I expect pretty much all 64 bit RISC-V chips to support RVV from now on. So this is an important optimization.

Mathematical functions

Posted Jan 25, 2026 21:11 UTC (Sun) by ubhofmann (subscriber, #47368) [Link] (1 responses)

> Additional optimized and correctly rounded mathematical functions have been imported from the CORE-MATH project, in particular acosh, asinh, atanh, erf, erfc, lgamma, and tgamma.

I'm surprised to see a constant flow of improvements in basic mathematical functions. I thought that those functions were already fully optimized long ago. The CORE-MATH project is quite interesting.

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.