Debian Switching From Glibc To Eglibc 565
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.'"
uClibc (Score:1, Interesting)
Why this and not uClibc?
http://www.uclibc.org/
Might be a good idea (Score:5, Interesting)
FINALLY (Score:5, Interesting)
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.
More context (Score:2, Interesting)
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 (Score:5, Interesting)
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 ?
For the greater good (Score:5, Interesting)
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.
Yay! (Score:5, Interesting)
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.
Re:For the greater good (Score:5, Interesting)
What an ugly situation (Score:4, Interesting)
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 (Score:3, Interesting)
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:For the greater good (Score:5, Interesting)
He's not fit to write C.
Which is probably why glibc source code looks like preprocessor soup.
Re:FINALLY (Score:2, Interesting)
Re:At Least It's Egier to Use and Less Glib (Score:4, Interesting)
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 (Score:4, Interesting)
> 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.
Re:FINALLY (Score:5, Interesting)
Some of Ulrich Drepper's finer points (Score:5, Interesting)
From TFA: 1 [sourceware.org] 2 [sourceware.org] 3 [sourceware.org] 4 [sourceware.org]
Re:uClibc (Score:1, Interesting)
Really? I made uClibc cross compile perl 5.8 for ARM on x86 one time. Talk about a bitch! I'd be pretty sure uClibc could at least run apache 1.3 if not 2.0 threaded.
Compiling up stuff for uClibc is most often acomplished by severe munging of some projects makefiles to accomidate the task since they are so heavily twined into glibc.
Re:downstream from debian (Score:4, Interesting)
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.
Re:FINALLY (Score:5, Interesting)
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:Might be a good idea (Score:3, Interesting)
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:Doesn't matter (Score:4, Interesting)
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:For the greater good (Score:4, Interesting)
>> 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.
Re:For the greater good (Score:1, Interesting)
I might use assert() to say that caller is an idiot.
Re:At Least It's Egier to Use and Less Glib (Score:2, Interesting)
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.
Re:At Least It's Egier to Use and Less Glib (Score:0, Interesting)
You guys do realize that a bunch of the Drepper's on that bug are actually people pretending to be him after the bug was posted on reddit right ?
Re:Might be a good idea (Score:3, Interesting)
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.
ARM design is way better than x86 (Score:3, Interesting)
Re:Don't be so Glib (Score:3, Interesting)
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...)
Re:At Least It's Egier to Use and Less Glib (Score:1, Interesting)
A bunch? Actually only two. And they were mostly harmless. Insisting that there is no bug, insulting people, can't be bothered to give any explanation, or even hints to an explanation other than "google it", that all was the real Drepper.
Re:Don't be so Glib (Score:1, Interesting)
The NT kernel is very portable. It's run on i860, MIPS, Alpha, PowerPC, IA64, SPARC, x86, and x86-64 over the years. Most of the platform-specific stuff is in the HAL. Microsoft could probably port the XP userland to ARM in a couple of weeks, and Office would likely not need much more than a recompile. This wouldn't help third-party developers, but they did buy a company that made a nice x86 emulator (ran over 50% of native speed for most tasks on PowerPC).
The problem is that ARM is an embedded CPU. A high end ARM - say a 1Ghz Cortex A9 probably has less horse power than a low end x86 - say a 1.33Ghz Atom. It's not just clockspeed, ARM is aimed at low power embedded applications. That forces compromises to keep the chip small and low power. And it affects things like the design of the memory subsystem too.
Now Intel always aimed at the desktop/server market, really at environments where CPU horsepower was everything and power consumption was not an issue. Of course with Core and even more with Atom they are moving down into the space ARM has traditionally occupied. Still, they aren't there yet. x86 uses more power, and not all of that is due to being an inelgant architecture.
Emulating x86 on ARM will, even with an absolutely brilliant emulation layer give a very poor use experience because ARM is aimed at a very different market where there is less demand for raw CPU speed. I'd bet a Cortex A9 will run x86 code slower than an Atom. And that's an issue - an Atom is already too slow IMO.
I agree about NT kernel portability, but I don't think Office is very portable at all. It was never ported to Risc platforms for example. Office 2010 will be both 32 and 64 bit, but at the moment it is 32 bit only. And Windows users don't just want Office, they want to run third party applications too. Realistically there is zero chance of those getting ported to ARM.
Look what happened with Itanium - it was aimed at servers and had an in order x86 core to run x86 code. That was still apparently too slow for the market. I don't really see it the situation changing either. There will be far more low power x86 CPUs in the future - the AMD Neo and Intel CULV will both have much more performance than Atom, albeit at a higher TDP. Of course x86 will never beat ARM on power consumption, but I don't think there be much overlap between high end ARM and low end x86 on performance either. That makes emulating x86 on ARM a risky proposition.
Get either the FSF or Fedora on board (Score:3, Interesting)
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 (Score:3, Interesting)
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.