Linux's glibc monoculture is not a bad thing

January 10, 2018

Given yesterday's entry about glibc and the Linux API, it's hard to avoid concluding that glibc is basically a monoculture in Linux, with no real competition or alternative. Initially I expected to be unhappy about this since I have a reflexive dislike of monocultures, but after thinking about it more, I think that glibc's monoculture is actually not a bad thing. In fact, I'll go so far as to say that it's how open source should work.

Okay, I confess that I deliberately wrote that to be a bit over the top. So I'll phrase the same situation differently: not having other projects pointlessly trying to compete with glibc is how open source should work (but often doesn't).

If you've been around the open source world for a while, you've seen more than one project that was apparently started because people couldn't just pick one thing to focus all their effort on but had to find some small difference that 'justified' a whole second project with a whole second set of work being done, to very little overall net gain. Over and over again the open source world has N versions of substantial projects that are essentially the same. Oh, sure, there's almost always some reason, but if you take a few steps back and look at the overall pattern, it sure feels like Not Invented Here syndrome is at work at least a fair bit of the time.

(Okay, there's also politics, personalities, and sometimes licensing. Linux has never been an antiseptic and purely technical place, not that the BSDs have been either.)

Given that Linux has several graphical desktops (with libraries and a collection of programs) and religious wars over init systems, there's no obvious reason why we wouldn't also have multiple competing standard C libraries. Instead, we basically have glibc and then a number of other libcs with different goals that are explicitly not trying to be direct replacements or competitors with glibc. For once, almost all of the development effort that's going to a crucial layer of Linux is working on a single project, not being spread over a bunch of NIH competitors.

At the same time, Linux is still open to alternatives and replacements for glibc. For example, the kernel developers haven't said that glibc is the only supported standard C library or ignored backwards compatibility with user space if glibc could paper over the cracks. This is undoubtedly helped by the existence and popularity of real alternatives to glibc like musl and Bionic. If you want (or need) something significantly different to glibc, Linux will still let you get it.

(And things that are intended to be portable outside of Linux will probably accept patches to build with musl and so on.)

As long as glibc development doesn't stagnate or wind up going in bad technical directions, a monoculture around it certainly doesn't seem to be a bad thing. So on the whole I'm happy to see Linux avoiding duplicate work for once.

(At the same time I'll note that glibc is not flawless and yes, I'd like it to be better. Also, in the past there were serious issues with glibc development and some of the people involved in it; see eg here. But back then there was a serious glibc alternative and some Linux distributions actively used it. Both parts of that situation could happen again.)

Written on 10 January 2018.
« Glibc and the Linux API
Open source software licenses matter »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Wed Jan 10 23:01:25 2018
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.