Slashdot Mirror
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.'"
Why this and not uClibc?
http://www.uclibc.org/
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.
Gentlemen! You can't fight in here, this is the war room!
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.
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 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 ?
What ? Me, worry ?
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.
the growth in cynicism and rebellion has not been without cause
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.
Need a Python, C++, Unix, Linux develop
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.
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
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.
> 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.
Democrat delenda est
From TFA: 1 2 3 4
Interested in open source engine management for your Subaru?
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.
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.
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 ?
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.
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...)
-- *My* journal is more interesting than *yours*...
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.
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.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
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.
Use my userscript to add story images to Slashdot. There's no going back.
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.
This is all just my personal opinion.