Debian Switching From Glibc To Eglibc

ceswiedler writes "Aurelien Jarno has just uploaded a fork of glibc called eglibc, which is targeted at embedded systems and is source- and binary-compatible with glibc. It has a few nice improvements over glibc, but the primary motivation seems to be that it's a 'more friendly upstream project' than glibc. Glibc's maintainer, Ulrich Drepper, has had a contentious relationship with Debian's project leadership; in 2007 the Debian Project Leader sent an email criticizing Drepper for refusing to fix a bug on glibc on the ARM architecture because in Drepper's words it was 'for the sole benefit of this embedded crap.'"

Comments

Might be a good idea

[je ne sais quoi]

Speaking as a Debian user who has had some major upgrade problems directly caused by glibc, anything that's "more upstream friendly" is okay by me. I've had my system totally screwed by glibc problems before, so badly that the only thing I could think of to do was to reinstall (it was while installing on a new machine, so it was okay). Whenever I see that glibc in the upgrade list for apt-get upgrade, I get a little queasy to this day though, along with upgrading the locales package.

Re:Might be a good idea

[xant]

These are not necessarily unrelated. You can't rule out the possibility that glibc problems are caused by a reluctant maintainer not fixing known issues because the known issues are a hassle.

That said, I cast a very skeptical eye on anyone who says glibc toasted their system. What they usually really mean is "I installed this unsupported sid package, which required a newer glibc version, and it brought in the kitchen sink with it because of the dependency tree, and now I'm toast."

Re:Might be a good idea

[bytesex]

It is a problem that is starting to pervade glibc anyway - the last few years seem to have been solely dedicated to 'tarting up' glibc with thread-safety and locale-awareness (and UTF). To keep things just as speedy, they have 'macrofied' a lot things; a lot of things you used to think were functions are now actually macros (which is a disaster for re-linking, but that's another discussion (I'm looking at you, Oracle !)). And it's not just embedded stuff that suffers (although they suffer the most); if I run a server which does not use threads, then any re-entrancy adds a few instructions per call. I don't know - it just adds up where it shouldn't. The ability to use a glibc as efficiently as possible according to your wishes, /should/ become an option. Do it via multiple glibc's, make the compiler choose them via #defines, or via relocation-on-the-fly, I don't care. But it's gotta happen. Not everybody likes that java-finish on their functionality.

FINALLY

[Anonymous Coward]

Drepper has had this coming for many, MANY years.

He has pissed off practically everybody in the FOSS world at least once.

Good riddance.

I hope this ends up like the gcc/egcs thing a while back. In the end the old gcc was shut down and egcs was renamed back to gcc.

It would be for the best of glibc if this Drepper dude got removed from the project.

I still think we should organize a mud wrestling match between Ulrich and Theo.

Re:FINALLY

[ak3ldama]

There is always the possibility that he is right. Adding something to glibc just for ARM and embedded devices might be a bad idea, an embedded "fork" is probably what was needed.

Re:FINALLY

[emurphy42]

Drepper's complaint was that the fix would slow things down on other architectures. The counterarguments were (1) he was relying on an assumption that could be broken under other circumstances as well, and (2) a different version of the fix that would actually speed things up on all architectures. (I assume these things are correct because some version of the fix was eventually accepted.)

Re:FINALLY

[TheRaven64]

Sure he's a bit abrupt on the glibc dev list, but does any of that really interfere with his role as package maintainer?

Yes. When he refuses to incorporate the string manipulation functions that don't perform silent truncation, that's a security problem. Every BSD libc (including Darwin/OS X) has strlcat() and friends, but Drepper decided they were 'inefficient BSD crap'. A few projects, like OpenSSH, just include a copy of the ones from OpenBSD libc in their own code, but other projects over the years have just fallen back to strncat() and friends if the safe versions aren't available, and had security problems on GNU platforms that didn't apply elsewhere.

If you're going to refuse patches for no reason other than the fact that you're an idiot, then it is affecting the project you maintain and a fork is an excellent idea.

More context

[Anonymous Coward]

This has nothing to do with "x86 only". All ABIs designed by people who have a
bit of understanding require no change. Any change will negatively impact well
designed architectures for the sole benefit of this embedded crap. But your own
version of the file in the add-on.

He wasn't saying that embedded systems were inherently crap. It sounds to me like he has a disagreement with some specific set of design choices.

downstream from debian

[C0vardeAn0nim0]

downstream we have many, many distros now adays.

so, if this eglibc becomes the default, it'll end up being the default in pretty much all debian based distros like ubuntu, mepis, xandros, etc.

a repeat of the whole xfree86/x.org thing ?

Re:downstream from debian

[TopSpin]

a repeat of the whole xfree86/x.org thing ?

A repeat of that, and also a repeat of the GCC/EGCS fork. This isn't the first major fork in FOSS history and it won't be the last. Both the Xfree86/Xorg and GCC/EGCS forks resulted in improvements to the progress and maintenance of these systems/tools.

Perhaps another glibc fork is overdue. Remember that the GNU C library that Ulrich is paid by Redhat to maintain was, for a long time, forked by Linux kernel developers. Consider also that there are already at least 5 alternative C library implementations (Bionic, dietlibc, uClibc, Newlib, Klibc) for Linux, all revolving around the embedded use case. Is it any wonder this fork pre-appends E for embedded as a name? Embedded Linux is absolutely crucial to the future of Linux generally; Linux has its foot in the door of many institutions because it's easy to embed.

There is no actual technical reason (including performance regressions) a C library implementation need be exlusively 'embedded' or not. It certainly makes development more difficult as more conditions appear in the source and the build system gets more complex. C library developers/maintainers should be capable of dealing with that degree of complexity. Lightweights need not apply.

By its nature a C library must contend with so many architectures and use cases that no one developer can possibly encompass all the required knowledge. Perhaps having a prima donna like Ulrich play gate keeper is not optimal.

For the greater good

[Rob Riggs]

That quote in the story is way out of context. Ulrich's words were:

Any change will negatively impact well designed architectures for the sole benefit of this embedded crap.

As the maintainer of GLIBC, he has to be the steward for the greater good of all users. And sometimes that means pissing off a vocal constituency.

Re:For the greater good

[Burkin]

He claims random crap like that all the time when he refuses to fix bugs.

Re:For the greater good

[LizardKing]

He's not fit to write C.

Which is probably why glibc source code looks like preprocessor soup.

Re:For the greater good

[Flavio]

>> He's not fit to write C.
> Which is probably why glibc source code looks like preprocessor soup.

Glib looks like preprocessor soup because it has to be portable and fast. The only sane way to avoid using the preprocessor is to move the logic into the C code. This usually results in better readability, but destroys performance. The insane way would be to duplicate code, which has a disastrous impact on maintainability.

Yay!

[Omnifarious]

I've been wishing for ages for maintainership to be taken away from Ulrich Drepper. Every single bug report I've seen submitted to him has been shot down for some stupid, insane reason, even when it's been accompanied by a patch. He's a bad maintainer.

One example, I submitted and update to an EBCDIC encoding used on IBM mainframes. The encoding had several choices for what should be encoded as the newline character. It wasn't clear which one should be used, but the z/OS system I was using had definitely chosen a particular one. Glibc had chosen a different one. I submitted a patch that changed it and Ulrich rejected it saying that there wasn't a standard and so my version was no more valid than the version that was in the library.

And, on another case, it was clear that the /etc/localtime was being read for each and every field that was being printed in strftime. This both caused things to be slow, and it also created a race condition if that file was changed. I recommended to the person who found the bug that he submit it. He did, and Ulrich rejected it for some bizarre reason I can't recall.

He is an awful maintainer, and I really hope the project is taken away from him by this fork.

What an ugly situation

[erroneus]

I recall the brief and mild concern over the push to change from XFree86 to X.org. The reasons for doing so were pretty clear and obvious and most people (except for the XFree86 people themselves) that it was simply necessary as the needs of the community outgrew XFree86's visual range. In short, the people wanted more than XFree86 could collectively deliver. (XFree86 people? You were such dumbasses... what better way to show how useless you could be?)

But this story is different. Now we have a maintainer who doesn't believe in what the people and the market are interested in doing -- moving Linux into smaller and smaller devices. "Embedded crap?" Indeed! The future of computing is not more powerful single boxes, but smaller networked devices that work together and the operating system will eventually become less relevant if not entirely irrelevant. This "embedded crap" is where all devices are headed. Many popular consumer gadgets and some really high-end consumer gadgets are already utilizing embedded Linux as the means of making some really cool things happen. The community will not stand for one or a few pig-headed people to impede that.

Either GLibc needs to pull his head out of his ass or he will make himself and his project irrelevant. Worse, if your name and reputation were to be muddied because your project was killed off by the community because "you don't want to work and play well with others" then the odds of people wanting to work with you socially or professionally in the future are greatly reduced and your technical skills, wisdom and experience will have been wasted.

Would it surprise anyone to know that many ice cream sellers only like one or two flavors? Why, then, do they sell so many other kinds?! The reason is obvious.

Re:A rant

[taniwha]

look at the bug - the problem is caused not by the arm per-se but by GCC for the arm's choice to round align structures to 8-byte boundaries - he's coded in an assert that verifies that the number of bytes left over after an align of a 1 byte in a structure is always 3. There's no requirement in C that structure alignment should be to 4-byte boundaries.

As someone else mention putting in the assert was a smart thing to do - it tests an assumption that the original programmer made - the fact that it went off meant that the original assumption isn't true and the code should be changed to match a new understanding of reality rather than denying it

Re:At Least It's Egier to Use and Less Glib

[RubberDuckie]

Mod parent up, as the above are Drepper's words with a bit more context. Nothing like stirring up the pot a bit with sensational headlines.

Re:A rant

[jmorris42]

> Drepper never suggested not to fix a bug for the ARM architecture....

Couldn't be bothered to read the linked bug discussion could you. Beyond rejecting a fix for an actual problem he even went so far as to say "No, Arm is not supported." Which was of course news to a lot of folks, since Debian has been shipping an official ARM port for years. If glibc isn't accepting patches for platforms Debian is officially supporting it is totally understandable they would adopt a fork that does.

Some of Ulrich Drepper's finer points

[bconway]

From TFA: 1 2 3 4

Re:Doesn't matter

[mzs]

Ha! That's a great idea in principle, though I don't know how I would feel about there being a /compat dir containing glibc on Linux, you know it would be needed. It also would be a lot of work to get apps and libs that have workarounds or have come to expect (even without knowing it) glibc-isms to be fixed. The other thing is that there are lots of programs that rely on glibc internals to link. They would need a recompile. Then there are those programs that actually use glibc internals, and there are more of those than you think. For a while there that was the only way to really get internationalization to work right with glibc.

In any case I think the Debian folks use a BSD libc in some ports and there was a some work on BSD libc in Gentoo. That all sort of came to the problems I outlined above when trying to use BSD libc on i386.

Re:At Least It's Egier to Use and Less Glib

[BrokenHalo]

How do people with an attitude like Drepper's become maintainers of crucial projects?

I have absolutely no evidence to back this up, but perhaps he has a borderline case of Asperger's syndrome or some other form of autism. It's not unknown for such a characteristic to have a worthwhile outlet in the programming world, since obsessive perfectionism is really useful in dealing with low-level code like compilers and filesystems.

But it does make it pretty hard to get along with such individuals.

ARM design is way better than x86

[slashbart]

I mean seriously. The nastiest microprocessor architecture that anyone has ever come up with is x86. It's an Intel cultural thing, all their processors (afaik) suffer from this.

Re:Don't be so Glib

[hyc]

Oddly enough, I have to agree with Drepper here, strcat() et al are terrible, and anyone using them *does* deserve to be punished. (Odd because of the many other disagreements I've had with him, on bug 4980 and elsewhere.)

But what do I know, it's not like I ever maintained a C compiler, high performance C library or multitasking kernel before. (Oh wait, I did...)

Get either the FSF or Fedora on board

[Khopesh]

I know Red Hat employs Drepper (or something like that), but a move by Debian has little meaning without support from other sources. It's been shown that even Ubuntu doesn't always follow suit with its upstream Debian Sid (e.g. they ship Firefox, not Iceweasel).

This absolutely MUST gain traction. Somebody must bite. Nokia could put it in Qt Embedded, Fedora could use it by default (and thus pressure Red Hat), Ubuntu could take a real look at it, FreeBSD could make the move, the Free Software Foundation could make a statement, etc.

Otherwise, we risk yet another rift in an already fractured community.

He's a nexus so he'll always make someone unhapp

[thaig]

Various people want various things out of him and he arbitrates somehow.

It's impossible for a lot of people not to be disappointed. I have experienced it - people can demand a lot of contradictory things from a maintainer and be cross when they don't get them.

His mistake is not to have trusted lieutenants - a posse to support him and also moderate him.

But I have little respect for the moaners on this thread. Fork and do the work yourself if you're not happy.