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.'"
Mod me down, boys.
My work here is dung.
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.'
Wow, sent an e-mail as suggested when clicking on "use classic" banner, and got a fast response that addressed my msg
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.
This space for rent. All reasonable inquiries will be entertained at proprietors discretion.
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.
Not really in any way that you'd notice. It comes down basically to the fact that, despite glibc being rather portable, Drepper is a bit of an asshat towards the ARM community, and Debian needs to work on more than a dozen architectures without asshattery.
It's also not so much of a fork as it is a "branch", sort of like the cherry-picking that happens to generate the -mm tree of the kernel; it's not 100% of the same sauce, but it's close enough that mostly nobody cares.
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.
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.
Agreed. It's what Gumstix seems to be using for their tiny ARM-based boards, it's a good lightweight alternative to the increasingly bloated glibc.
ARM is getting big these days, it's not a market to sideline.
"I bless every day that I continue to live, for every day is pure profit."
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 ?
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.
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
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.
“Common sense is not so common.” — Voltaire
Because uClibc brings us one step closer to Cthulhulibc.
That which lies dead but dreaming must not be awoken, especially on embedded devices.
"Trolls they were, but filled with the evil will of their master: a fell race..." -- J.R.R. Tolkien on Olog-hai
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
Devices like MP3 players, set top boxes, and mobile phones account for far more GLIBC deployments than desktops and servers.
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.'
And the developer has every right to make that call, just as eglibc has every right to make a fork that cares more about the embedded world, and Debian's maintainers have a right to switch.
That said, I have two main thoughts on this issue.
First, only a complete idiot would ignore the fact that one of Linux's primary strengths lies in the embedded market. Refusing to fix a relatively easy bug because it "only" affects that market sounds like something Microsoft would force on us "for your own good", such as DRM or the UAC.
Second, Debian (as a stock install, I don't include remastered lightweight Knoppix variants in that category) does not have a significant presence in the embedded device market. Such uses either involve a platform-specific lightweight distro where available, or the devs take a roll-your-own approach. Getting in a pissing match over support for an irrelevant feature doesn't inspire me with confidence in Debian's leaders.
Be nice, now, Cthulhu has excellent standby performance. I don't see any laptops that can stay in S3 for untold aeons before the age of man.
Is that you Joerg?
I think there is some shallow reading going on here.
eglibc has a number of features that are useful in general. It happens that embedded systems have a strong need for these features, but they are generally useful as well. I've discussed it with one of the Debian glibc maintainers, and he said that eglibc is basically a patchset atop glibc implementing new features and fixing bugs. I think of it similar to the relationship between go-oo.org and OpenOffice. Distributions have to fix these bugs anyway, because upstream won't. So why not adopt a standard patchset to do so collectively?
This has no implications for a change of focus away from the desktop or anything like that.
From eglibc's mission statement:
"Retain API and ABI compatability with GLIBC wherever feasible."
Yeah, that's going to end well...
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.
IIRC, uClibc can't run Apache. There's a place for uClibc, but that place isn't a generalized distribution like Debian.
Not a typewriter
> As the maintainer of GLIBC, he has to be the steward for the greater good of all users.
No, it needs to be correct code. If ARM happens to be the only platform that currenty exercises the bug it is still a bug. Goddamn people, I swear we are getting as blase about fixing bugs as a Microsoft shop. There is no such thing as a good bug, a less important bug, etc. If it is a bug and someone has a patch for it you APPLY THE DAMNED PATCH. If you have a problem with the patch you write a better patch. Not patching at all is never be the answer.
I really hate updating my systems these days, because for every bug fixed it seems you get a fresh new one. Make it shiny, we will fix the bugs later! Of course later never comes, eventually the crap piles up too high and somebody decides to just start over. Which explains the piles of discarded stuff and the new one that also doesn't quite work in most areas, especially in system administration.
Seriously, the Free Software world needs to call a timeout. Establish a core and devote every available resource into making that core bug free and secure. Then allow no change to be committed to that core without extensive peer review to prevent new bugs from getting in. The Linux kernel is hopeless, no chance of getting it to stop and clean up and x.org is currently in a period of upheaval, but the layer above each could be stabilized. Not just coreutils, but everything including the core widget sets, admin tools. Get things to a point where an ordinary userland package will (not might) work even it it wasn't built against the exact same release.
And finish hashing out the whole new /dev/, dbus, etc. and settle the API down enough to document the damned thing. I know UNIX, but this new stuff totally confuses me. WHere does one go to even find out how it is supposed to work? Which of course isn't how it currently DOES sorta work. How does one even know if a particular piece of documentation, sketchy and incomplete as it will certainly be, documents what was, what currently is or what is intended to be?
Democrat delenda est
The problem isn't GLIBC. The only problem is this idiot Ulrich Drepper. He demonstrates time and again that he is incompetent and has no business being in a position that is forced to interact with other people. This Ulrich Drepper character has the nerve to say stuff in bug report discussions like this such as:
anything handy and certainly have no interest in writing it up.
cannot order me around.
issue at hand. Otherwise you would have noticed that this code has been
entirely rewritten in the current code. It uses a very different implementation
which allows to handle this situation differently.
And this is from a single bug report alone. Why exactly does GNU tolerate such a thoughtless idiot in such a fundamental position in such an important project? Moreover, this idiot Ulrich Drepper even shuns support important architectures such as ARM apparently due to nothing more than whims. How can this be?
GNU is supposed to be a project for it's users by it's users. You don't go far if you rely on antisocial morons to handle PR stuff.
Slashdot, fix your code or at least hire someone who is competent at it to do it for you.
Won't someone explain this in terms of a car analogy!?
Car analogy ho!
"Toyota recently announced that it will be switching manufacturers of its most commonly used drive trains because the original manufacturer said that the changes Toyota requested were 'for the sole benefit of this hybrid/electric crap.'"
In other words, in three years time, glibc might be used only by RHEL6, and Ulrich Drepper will just be forking eglibc and calling it glibc.
The problem is that programming a libc is the worst kind of programming... you have to be compatible with N different standards that are incompatible with each other. A lot of the functions you have to implement are impossible to simultaneously be correct and not make you puke (see printf). And on top of that, nobody even cares since they're all using some high-level library to call your libc functions anyway.
I really wish somebody would come out with a decent libc for linux though. With glibc, you either compile statically and have a 1+mb binary that's still dynamically linked anyway because you used a socket or your program just doesn't run on some systems and you have dll hell far worse than on any Windows. If you've ever had to deliver a non-OSS binary for linux you know what I'm talking about.
Dietlibc is the most convenient alternative by far, but it has several bugs, is slow, and errno is not threadsafe. For instance printf("%2d\n", 222) prints nothing. But if you test your software you can use it really easily, just CC="diet gcc". The uClibc is better, but it's a pita to use, requiring its own entire toolchain.
Since nobody actually pays for developers to work on libc, you end you with whoever crazy people will actually work on it. So while the fork is a good thing, it's probably just going to be more of the same.
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.
Don't leave your mind so open that your brain falls out. Don't close it so much that you cut off the blood.
Sadly, nobody really gives a shit about Linux binary compatibility.
BSD does.
Does he have 6 fingers on his left hand?
Of Code And Men
That is not dead which can ACPI, and with strange ions charge is stored on Li.
From TFA: 1 2 3 4
Interested in open source engine management for your Subaru?
[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."
http://rocknerd.co.uk
Since he never explained the rational for the "fix," and instead preferred to spam "Do not reopen this, this is not a bug," instead, I would say he is not. A bug comment discussion like that would get me reprimanded or fired.
Hopefully it'll stray as far as possible, given that the original project seems to have serious attitude issues with accepting their bugs and simply applying supplied patches! I know little about GLIBC internals, but even I can see how crack-happy the maintainers seem to be, and could probably do a better job myself. All I can say is thank god this is being forked away from those nut-jobs, and hopefully everyone else WILL jump ship too.
Did you actually read #3? strfry() is a joke function, an silly Easter egg that had been included in Glibc since time immemorial and unfortunately cannot be removed for fear of breaking compatibility.
Anyone with half a brain can see that fixing "bugs" in ancient Easter eggs is a waste of developers' time. If I were in Ulrich Drepper's position, my response would be similar to his, but with more insults.
Can we PLEASE get the moderation confirm button back!?!?!?!
I use eglibc, and I like it better. For instance, when I was a bit distressed to discover that glibc shipped with scripts which require bash or ksh (not a good fit for a TINY embedded system), I went and looked. The dependencies there could be EASILY removed with no significant harm done -- and the scripts would work. One of them took me all of twenty minutes to clean up to make it functional with any POSIX shell.
This isn't rocket science. It also isn't software engineering. I was first disappointed with glibc's performance somewhere around 1996, and it's never really won me over since. eglibc seems to me to be a much nicer approach.
(Full disclosure: I think $dayjob funds some eglibc development, and we certainly use it.)
My blog: http://www.seebs.net/log/ --- My iPhone/iPad app: http://www.seebs.net/seebsfrac/
I,m surprised that this isn't quoted by Microsoft as a "typical" example of cooperative open-source development.
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.
I'm seeing lots of comments about how horrible a maintainer he is...but somehow he's still the maintainer. I have to assume that he's actually good at something or else he would have already been replaced.
Can anyone give some insight on what qualities he has that explain how he has managed to keep the position as glibc maintainer?
I'm just trying to see the other side of the picture here.
*sigh* back to work...
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.
>> I'll immediately walk away from glibc...
Promises, promises.
I am very small, utmostly microscopic.