Yay for Clang

Posted Jan 27, 2026 8:55 UTC (Tue) by jmalcolm (subscriber, #8876)
In reply to: Yay for Clang by willy
Parent article: GNU C Library 2.43 released

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

to post comments

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