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

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

[Philip K Dickhead]

Talk about "embedded crap". This ancient troll seems to be lodged between your ears!

Hope it works

[AvitarX]

I would hate the embedded version's maintainer to not want to fix a bug that was simply for 'for the sole benefit of this desktop crap.'

Don't be so Glib

[powerlord]

It might be "Egier" to use, but how far will it stray from the original project (that everyone else is currently using), or is it the first leak in the Dam before everyone jumps ship.

Its especially ironic given the push that netbooks have had over the past year, and the emphasis on Power savings that is pushing developers to consider using ARM chips, and by extension Linux (since Windows just plain won't run on them :) ).

If the OSS community doesn't support an opportunity to get our foot in the door (in a BIG way), by putting "our" OS on the "longest running and lightest" Netbooks/Notebooks that come out (or put our software out with known bugs), then we deserve to reap what we sow.

Re:Don't be so Glib

[ta bu shi da yu]

The ABI is compatible with glibc, this doesn't preclude them from including new functions like strlcpy and strlcat - which again looks like something that Ulrich Drepper doesn't think is a good idea. In fact, the man went so far as to reject the patch, stating that:

This is horribly inefficient BSD crap. Using these function only
leads to other errors. Correct string handling means that you always
know how long your strings are and therefore you can you memcpy
(instead of strcpy).

Beside, those who are using strcat or variants deserved to be punished

Fork couldn't have come soon enough!

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

[Timothy Brownawell]

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 don't think this means "easy to upgrade", but rather "the maintainer isn't an asshole".

Re:Might be a good idea

[fm6]

Drepper does come across as an asshole totally antagonistic to ARM and embedded development. But after a little googling, I'm convinced his thinking is a little more complicated than that. Basically, he seems to think that glibc is poorly suited to embedded applications, and wishes that ARM developers would develop their own specialized libcs.. He's also concerned that in GCC development, the needs of some platforms that happen to have powerful backers (such as AIX) get more priority than their mindshare deserves.

He's got some good points. He does express them in a way that's unnecessarily offensive and combative. But that doesn't make him an asshole. That makes him a typical geek!

Re:Might be a good idea

[Nicholas Evans]

It's horribly inefficient BSD crap. Get your Drepper quotes right!

Re:Might be a good idea

[Geoffreyerffoeg]

He's got some good points. He does express them in a way that's unnecessarily offensive and combative. But that doesn't make him an asshole. That makes him a typical geek!

Then we need fewer typical geeks, and more atypical geeks.

Re:Might be a good idea

[evanbd]

He's got some good points. He does express them in a way that's unnecessarily offensive and combative. But that doesn't make him an asshole. That makes him a typical geek!

Then we need fewer typical geeks, and more atypical geeks.

Indeed. For the record, I don't think he is a typical geek. But if that's your definition of typical geek, then the typical geek is an asshole.

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

[ThePhilips]

Drepper has had this coming for many, MANY years.

Frankly, I'd say Ulrich is fitting person for a project like glibc.

I do not think his a bad guy, it's just a job of glibc maintainer (which is a central piece of "Linux OS", second most important after kernel) would make out of anybody an a**hole.

I'd say his job is 99.9% of times saying "NO" to all the silly proposals flying all the time on glibc mail lists.

But it's just in this case he was wrong. Shit happens.

Re:FINALLY

[Anonymous Coward]

He refused nscd patches to fix issues in glibc that had numerous gross errors like:

1) assumed all replies arrived in one packet
2) database storage mishandling
3) zero-length returns from syscalls due to unrelated signals

  And then last year he "found" many of these bugs and finally fixed them the same way, after rejecting the same patches 3 years earlier. Ulrich Drepper is the reason nscd sucked so badly for so many years in Linux, as he's the reason for so much other suckage, and the reason most distributions end up with a heavily forked glibc anyway. This is just sharing those forks - the forks happened many years ago in every distribution that works. Even Redhat has a glibc that's heavily forked from the mainline, and they pay him.

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.

Re:FINALLY

[Curtman]

Get Dan Bernstein in that match and you could sell it on pay-per-view.

Hans Reiser death match... Ahhh shit, probably still too soon for that one.

Re:uClibc

[profplump]

uClibc is not binary compatible with glibc, so you can't compile on one and run on the other. Heck, uClibc is generally not even binary compatible across versions -- you have to recompile the whole system every time you update uClibc.

That's not to say uClibc isn't useful, but it doesn't have the same goals (or features) as glibc or eglibc.

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:uClibc

[impaledsunset]

uClibc is created for embedded systems, meaning that it might lack some of the features that glibc has. Debian doesn't work only on embedded systems, and therefore it needs a full libc with all bells and whistles. eglibc is a glibc fork, which might be targetting embedded systems, but retains full source and binary compatibility with glibc, and I would assume that any useful feature would still be there, possibly optional.

And they switch not because they want lightweight libc, but because they want more friendly upstream. uClibc doesn't seem to be a good choice if that is the reason.

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

[Anonymous Coward]

Not only that, but Drepper was taking with where the change was being made. He was suggesting that the alternative implementation be in an architecture-specific file rather than changing the generic implementation.

In other words, in this particular case, the idea was that the original patch would incur a performance hit to x86 and other mainstream architectures in compensating for ARM's differing alignment. Consequently Drepper wanted the change to be done in a platform-specific file outside of his purview.

Re:For the greater good

[BSAtHome]

The code hit an assert() in glibc. That is per definition a bug. You should never implement an assertion and then complain if someone hits it and confronts you with the design choices of that time. When you are informed of a triggered assert(), then you should act like a man and fix the code.

Re:For the greater good

[Areyoukiddingme]

Reading the context didn't help his case any. I read the bug report, and the attached patch, and was appalled that Ulrich thought he was defending good code. If the code is expected to run on even ONE other platform, what he was doing was incredibly stupid. It doesn't matter if the vocal constituency is on a platform that doesn't please Ulric. There is more than one officially supported platform, so therefore his opinion was idiocy of the highest order.

Anybody who thinks it's a good idea to depend on the size of structure padding, on one specific platform, with one specific compiler, and code a memory violation on that expectation, deserves all the vitriol the community can muster. Take his compiler away from him. He's not fit to write C.

Re:uClibc

[OrangeTide]

Because uClibc has(had) inferior threading and performance. And it is(was) missing the GNU extensions that many popular FOSS projects depend on.
There is also newlib and dietlibc. In many ways I find newlib to be better than uClibc, although I still tend to use uClibc for projects because it's good enough and we already use it.

Re:uClibc

[Red Flayer]

Why this and not uClibc?

Because uClibc brings us one step closer to Cthulhulibc.

That which lies dead but dreaming must not be awoken, especially on embedded devices.

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.

I make a living on this embedded crap

[bzzfzz]

Devices like MP3 players, set top boxes, and mobile phones account for far more GLIBC deployments than desktops and servers.

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

[atari2600]

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

^ Actual Quote.

Re:GLIBC is the cause for all binary incompatibili

[phantomlord]

Not even an old program written from Loki Software Entertainment would run on a modern Linux Mint (2.6 kernel) for example unless in a chroot'd sandbox. Truly sadistic, that I even remember this happening even on the same kernel branch. Bruce Perens would address this better than I, but my time is worth more elseware.

You can do it by installing the old libraries and using LD_LIBRARY_PATH and LD_PRELOAD. See the Gentoo Wiki archives for information and a tarball of the necessary libraries.

Not the most elegant solution, but it's easier than dealing with a chroot.

Re:"So what" vs "Wow, unbelievable"

[Chris Burke]

And the developer has every right to make that call

Who said or implied otherwise in any way shape or form? Seriously.

Getting in a pissing match over support for an irrelevant feature doesn't inspire me with confidence in Debian's leaders.

But ARM is a supported architecture, used enough at least that they found the bug, and the bug was in glibc and thus affects all distributions that use glibc. What would make me lose confidence in Debian's leaders is if they agreed that because it's an "irrelevant" architecture that it shouldn't be fixed.

And just because the bug in question may be "irrelevant" for Debian, the real issue they're getting in a pissing match over is an obstinant maintainer of one of the most important pieces of software in any linux distro. Switching to a libc with a friendlier upstream maintainer over an irrelevant bug makes a hell of a lot more sense than waiting until it's a critically important bug that the current guy decides he won't fix for some stupid reason, now doesn't it?

Re:The problem isn't GLIBC. It's Ulrich Drepper.

[elevator]

• Fine. Whatever. I'll revert it, assholes.

And this is from a single bug report alone.

You are aware I hope that the last comment (and one earlier) is from a fake Drepper? (check the mail addy)? :)

Re:uClibc

[LaminatorX]

That is not dead which can ACPI, and with strange ions charge is stored on Li.

Re:Doesn't matter

[Code Master]

When your embedded system has 8-16 MB of Flash and SD RAM, it matters.

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

[ta bu shi da yu]

I know! For the record, he was talking about the problems of the patch in aquatic environments. "It's working fine everywhere but this carp architectures."

I'm not surprised that the project's been forked after reading this bug. Not only was he wrong, but he was adamantly wrong. It was only when his employer (RedHat) stepped in that it looks like they solved the issue.

Some of Ulrich Drepper's finer points

[bconway]

From TFA: 1 2 3 4

Debian forks glibc, Drepper forks Debian

[David Gerard]

[To be posted tomorrow, probably]

The Debian project has dropped the use of the GNU project's glibc C library, substituting the eglibc fork, as glibc maintainer Ulrich Drepper refused patches or bug reports for several architectures Debian relied on.

"Any change will negatively impact well designed architectures for the sole benefit of this embedded crap," said Drepper. "Famously good architectures like x86. Can you believe, these people wanted their C library to work in systems with shells other than bash! These people must think they're signing my pay check."

Drepper has, in retaliation, announced his own fork of Debian. It will be created in cooperation with Joerg Schilling and Tuomo Valkonen and be based on OpenSolaris with Ion running on XFree86 as the standard window manager. "Keith Packard ruined X," said Valkonen. The standard file system will be ext4, given its proven ability to cause data loss in user software the maintainers consider ill-written.

The project will be licensed under both the intersection and union of the GPL, LGPL, CDDL, MIT and the thing TuomoV wrote for Ion. This is not anticipated to be a problem in practice with real-life users, at least not until one exists.

"YOU!" said David Dawes of XFree86. "YOU'VE BEEN TALKING TO THEM, HAVEN'T YOU! YOU'RE CONSPIRING WITH THEM! THOSE GUYS! THEY STOLE IT ALL! THEY PUT A RADIO IN MY HEAD! LINUX/BSD WEENIES! I'LL SHOW 'EM! HELL YES!" "That means he's onside with us," said Valkonen. "Dave's been a bit terse since he finally lost it trying to fix his own broken modeline."

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

[schon]

I'm not surprised that the project's been forked after reading this bug. Not only was he wrong, but he was adamantly wrong.

Wow. Looks like he went to the Theo DeRaadt School of Social Graces.

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

[larry bagina]

For even more context, look at the patch. The "negative impact" is a couple extra microseconds of cpu time to memset 20 bytes instead of 3. I guess 32-bit x86 ought to be enough for anyone.

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

[A Nun Must Cow Herd]

That's quite a read, you have to go out of your way to get multiple people writing comments like this one:

"Wow, you are a bastard. I hope you die alone. :D"

How do people with an attitude like Drepper's become maintainers of crucial projects? He seems obviously unsuitable (whether he has superb technical skills or not).

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

[larry bagina]

yes, nanoseconds. If that.

Just for kicks, I compared memsetting 20 bytes (aligned) vs 3 bytes (unaligned) with llvm-gcc (which can output code in a dozen assembly languages).

For mips, sparc, and ppc32, a 3-byte unaligned memset must be done 1 byte at a time, so the 20 byte memset is only 2 instructions more (5 32-bit stores).

For 64-bit alpha and ppc64, the 20-byte memset only uses 3 instructions (2 64-bit stores + a 32-bit store).

x86 (and arm, for that matter) can do a 3-byte memset as a 8-byte set and a 16-byte set.

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

[ta bu shi da yu]

Indeed - and not just ordinary, non-involved people. In one bug alone, he managed to upset Gentoo's Mike Frysinger, he told Petr Baudis of SuSE that "I never saw your name on my paycheck. Since if that's not the case you cannot order me around., and gave the MirOS developer Thorsten Glaser cause to comment on Drepper's standards.

Nice going!