Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Debian Switching From Glibc To Eglibc

timothy posted more than 5 years ago | from the dismissed-with-cause dept.

Debian 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.'"

cancel ×

565 comments

Sorry! There are no comments related to the filter you selected.

At Least It's Egier to Use and Less Glib (4, Funny)

eldavojohn (898314) | more than 5 years ago | (#27851525)

Mod me down, boys.

Re:At Least It's Egier to Use and Less Glib (0, Insightful)

Anonymous Coward | more than 5 years ago | (#27851583)

Linux just isn't ready for the desktop yet. It may be ready for the web servers that you nerds use to distribute your TRON fanzines and personal Dungeons and Dragons web-sights across the world wide web, but the average computer user isn't going to spend months learning how to use a CLI and then hours compiling packages so that they can get a workable graphic interface to check their mail with, especially not when they already have a Windows machine that does its job perfectly well and is backed by a major corporation, as opposed to Linux which is only supported by a few unemployed nerds living in their mother's basement somewhere. The last thing I want is a level 5 dwarf (haha) providing me my OS.

Re:At Least It's Egier to Use and Less Glib (5, Funny)

Philip K Dickhead (906971) | more than 5 years ago | (#27851607)

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

Re:At Least It's Egier to Use and Less Glib (-1, Offtopic)

Anonymous Coward | more than 5 years ago | (#27851761)

lol

Re:At Least It's Egier to Use and Less Glib (5, Informative)

atari2600 (545988) | more than 5 years ago | (#27852245)

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

^ Actual Quote.

Re:At Least It's Egier to Use and Less Glib (3, Interesting)

RubberDuckie (53329) | more than 5 years ago | (#27852451)

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:At Least It's Egier to Use and Less Glib (0, Flamebait)

sulfide (1382739) | more than 5 years ago | (#27852023)

Linux just isn't ready for the desktop yet. It may be ready for the web servers that you nerds use to distribute your TRON fanzines and personal Dungeons and Dragons web-sights across the world wide web, but the average computer user isn't going to spend months learning how to use a CLI and then hours compiling packages so that they can get a workable graphic interface to check their mail with, especially not when they already have a Windows machine that does its job perfectly well and is backed by a major corporation, as opposed to Linux which is only supported by a few unemployed nerds living in their mother's basement somewhere. The last thing I want is a level 5 dwarf (haha) providing me my OS.

so true, all of it. good job

Don't be so Glib (5, Insightful)

powerlord (28156) | more than 5 years ago | (#27851623)

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.

Delicious (0, Offtopic)

binarylarry (1338699) | more than 5 years ago | (#27851561)

This wouldn't happen to be THE Ulrich DrPepper of the legendary DrPepper clan, would it?

Re:Delicious (1)

ildon (413912) | more than 5 years ago | (#27851683)

That's exactly how I originally read the post and was slightly confused until I reread it.

Re:Delicious (0)

Anonymous Coward | more than 5 years ago | (#27851797)

DrPepper killed my father you insensitive clod!

uClibc (1, Interesting)

Anonymous Coward | more than 5 years ago | (#27851595)

Why this and not uClibc?
http://www.uclibc.org/

Re:uClibc (1)

Tubal-Cain (1289912) | more than 5 years ago | (#27851727)

Glibc compatibility?

Re:uClibc (5, Informative)

profplump (309017) | more than 5 years ago | (#27851753)

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.

Re:uClibc (4, Informative)

lobiusmoop (305328) | more than 5 years ago | (#27851773)

Agreed. It's what Gumstix [gumstix.com] 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.

Re:uClibc (5, Insightful)

impaledsunset (1337701) | more than 5 years ago | (#27851787)

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.

Re:uClibc (5, Informative)

OrangeTide (124937) | more than 5 years ago | (#27851849)

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 [sourceware.org] and dietlibc [www.fefe.de] . 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 (5, Funny)

Red Flayer (890720) | more than 5 years ago | (#27851873)

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.

Re:uClibc (4, Funny)

fuzzyfuzzyfungus (1223518) | more than 5 years ago | (#27851955)

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.

because it's buggy? (0)

Anonymous Coward | more than 5 years ago | (#27851897)

Apparently to this date its system() call still freaks out when interrupted by signal, returning failure condition when the spawn in fact succeeded.

Re:uClibc (2, Informative)

hardburn (141468) | more than 5 years ago | (#27852125)

IIRC, uClibc can't run Apache. There's a place for uClibc, but that place isn't a generalized distribution like Debian.

Hope it works (5, Funny)

AvitarX (172628) | more than 5 years ago | (#27851615)

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.'

Re:Hope it works (1)

Thinboy00 (1190815) | more than 5 years ago | (#27851985)

fork while fork;

Re:Hope it works (1, Informative)

Burkin (1534829) | more than 5 years ago | (#27852135)

Yo Dawg! We herd you liek forking software, so we put a fork in your fork so you can fork while you forking!

Re:Hope it works (0)

Anonymous Coward | more than 5 years ago | (#27852163)

Fork you!

Re:Hope it works (1)

ThePhilips (752041) | more than 5 years ago | (#27852391)

Embedded folks generally more flexible and closer to the ground, compared to many high profile Linux celebrities who generally are kept on payroll by server companies. And Linux on servers this is 95+% x64 - other architectures and application fields simply do not interest them. Or in other words: they are not paid for doing it.

Forking is right way to go here.

Might be a good idea (5, Interesting)

je ne sais quoi (987177) | more than 5 years ago | (#27851647)

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 (5, Insightful)

Timothy Brownawell (627747) | more than 5 years ago | (#27851975)

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".

FINALLY (5, Interesting)

Anonymous Coward | more than 5 years ago | (#27851663)

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 (4, Funny)

David Gerard (12369) | more than 5 years ago | (#27851699)

Ulrich, TuomoV and Joerg Schilling.

Re:FINALLY (2, Insightful)

DaGoodBoy (8080) | more than 5 years ago | (#27851859)

I'm sure the EGlibc and EGcs naming was not entirely coincidental.

Re:FINALLY (4, Informative)

Anonymous Coward | more than 5 years ago | (#27851923)

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

I mean other than the fact that he rejects small, well-designed patches to the build system because the problem doesn't affect him -- he insists that no mere mortal should build glibc anyway.

And maybe he packages the system to fail with no useful errors when building with the default options on i386 -- but he also capriciously and unilaterally decides which platforms are supported both as targets and build systems, and again, mere mortals shouldn't attempt to build glibc in the first place.

And he doesn't package releases into tarballs, and only tags new releases on his schedule, even if the last release has major bugs with committed, tested patches in wide use downstream -- but he does apply tags on an arbitrary schedule to code that may or may not have been widely tested, so at least releases are predictable.

Re:FINALLY (1)

MichaelSmith (789609) | more than 5 years ago | (#27852361)

Okay I get that you don't like the guy. But do you need to post anon? Its not like he has a rocket launcher [theage.com.au] or anything.

Re:FINALLY (5, Insightful)

ThePhilips (752041) | more than 5 years ago | (#27852433)

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 (2, Interesting)

ak3ldama (554026) | more than 5 years ago | (#27852447)

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.

Efficiency? (1)

Tubal-Cain (1289912) | more than 5 years ago | (#27851691)

Since this is primarily over embedded systems, I assume it will also be more efficient?

Re:Efficiency? (3, Informative)

Anonymous Coward | more than 5 years ago | (#27851751)

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.

Re:Efficiency? (1)

TinheadNed (142620) | more than 5 years ago | (#27852055)

Depends what you mean by efficient. UClibc is more efficient in space, but less efficient in size. The most telling indication of this is that uclibc does all 32bit math operations by converting to 64bit, performing the 64-bit maths, and then converting back.

That's never quick.

Re:Efficiency? (1)

Tubal-Cain (1289912) | more than 5 years ago | (#27852339)

Depends what you mean by efficient. UClibc is more efficient in space, but less efficient in size.

Could you define what you mean by 'space' ?

Mod parent lunatic (0)

Anonymous Coward | more than 5 years ago | (#27852371)

Depends what you mean by efficient. UClibc is more efficient in space, but less efficient in size. The most telling indication of this is that uclibc does all 32bit math operations by converting to 64bit, performing the 64-bit maths, and then converting back.

That's never quick.

More efficient in space, but less in size? That makes no sense at all.

What's worse, you have absolutely no idea what you're talking about when it comes to uclibc's math library: first of all, most of the math in uclibc is done in hardware units (whatever the hardware size for float/double and int (16/32-bit)). This is the same for glibc. In many cases, the math has to be emulated, which makes it slower, but glibc isn't going to do a lot better in these corner cases either.

No, uclibc's real drawbacks are that it's not ABI-compatible with glibc, it's nowhere near as portable as glibc, and that it's threading, rpc and networking components are far inferior to the much larger glibc. On the other hand, uclibc can, compiled code-wise, fit entirely in the cache of many ARM microcontrollers, which translates into real speed gains on those machines.

Important question. (0, Offtopic)

Sybert42 (1309493) | more than 5 years ago | (#27851737)

What does this have to do with the Singularity?

More context (2, Interesting)

Anonymous Coward | more than 5 years ago | (#27851767)

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.

Re:More context (0)

Anonymous Coward | more than 5 years ago | (#27851995)

It's working fine everywhere but this carp architectures.[

More context that you seemed to miss.

Re:More context (4, Funny)

dgatwood (11270) | more than 5 years ago | (#27852205)

everywhere but this carp architectures

Seems pretty fishy to me.

Re:More context (4, Insightful)

hardburn (141468) | more than 5 years ago | (#27852219)

Looking elsewhere through the bug comments, it seems that there are assumptions in the glibc code that could break whenever the gcc people feel like it, even on x86. This was something that needed to be fixed, and isn't specific to x86 or any other non-embedded arch.

Also, when has x86 ever been a "well designed architecture"?

GLIBC is the cause for all binary incompatibility (0, Flamebait)

Anonymous Coward | more than 5 years ago | (#27851769)

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.

There should be hybridized Elf Static binary that can address this issue. Link layer is realy sucking a nut when it comes with programming, and GNU would make quite an imrpovement to have an application base that allows you to have multiple compilations in the same binary with a link-layer "tree" to how it would execute and with whether internal libraries (static) or even multiple different sets of internal libraries that are even addressable from an advanced prorgaming implementation of sentience as would a rolling book shelf archival track.

Also should be able to run a program even if a certain library is not available and not immediatly used in what function the program is performing immediaty; control the execution branch to libraries that aren't used but in certain situations, even so far is creating that library interface to return a default value so as to "satisfy" that depencancy such as a routine IsItHotOutside() to return a value int 0 without even processing anything, or able to re-direct that to another routine or function in a competing library without having it conflict with the library already used (it might be the same library but different version).

Anyhow, thanks a lot toolchains, bintools, glibc and whomever gobblers can't implement a standard without ruining the binary compatibility image that should let everthing play together.

Re:GLIBC is the cause for all binary incompatibili (0)

Anonymous Coward | more than 5 years ago | (#27851855)

Haha, these days I don't even bother trying to run old Loki games, I have much better luck getting the Windows versions running under Wine :P

Re:GLIBC is the cause for all binary incompatibili (-1, Flamebait)

IntlHarvester (11985) | more than 5 years ago | (#27852257)

Sadly, nobody really gives a shit about Linux binary compatibility.

- The users are all hairy free-software hippies

- Hordes of basement-dwelllers have nothing better to do but to recompile the same software over and over again. (QA optional)

- The business model for Linux distros requires breaking everything every six months, so that businesses pay you to stop breaking things.

- Distros also love the customer lock-in aspects. Aforementioned gnu/hippies don't notice because St. Stallman says it's impossible to lock-in with open source.

Upshot is: expect linux binary compatibility never. It won't happen.

Re:GLIBC is the cause for all binary incompatibili (5, Informative)

phantomlord (38815) | more than 5 years ago | (#27852261)

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 [gentoo-wiki.info] for information and a tarball of the necessary libraries.

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

Re:GLIBC is the cause for all binary incompatibili (0)

Anonymous Coward | more than 5 years ago | (#27852309)

Actually you're wrong: The biggest cause of failure for linux games wasn't actually glibc, it was stdc++, followed by smpeg, followed by other C++ libraries.

I speak this as someone who during the gcc 2.96/3.x fiasco had multiple library toolchains installed in an attempt to keep my stack of ~5 linux games functional. The only one out of any of those that is still easily run is Quake3 (the rest having broken thanks to the coreutils retards deciding to get rid of 'cruft' like tail -xxx formatting, which all the loki install scripts use for extracting the compressed data!)

Honestly when I care about backwards compatibility I have to go create a fake root dir, and jump through all kinds of hoops. Reason I just reverted to a mostly full-time Windows Gaming Box (Usually Win2K, but it's about time I'll have to install WinXP to continue gaming. All this Windows Live crap isn't installable under Win2K, although pretty much everything else is!)

IMHO this is still a massive snafu for linux and is likely never going to see resolution. But hey, everybody needs their source right? :D

Inmates running the asylum much? (0)

Anonymous Coward | more than 5 years ago | (#27851775)

A bug is a bug, jackass. Just fix the damn thing.

Re:Inmates running the asylum much? (1)

Cramer (69040) | more than 5 years ago | (#27852363)

It's only a bug if it effects him.

I often want to shoot people who develop code for other people to use and then refuse to even listen to the issues those other people have with said code.

downstream from debian (5, Interesting)

C0vardeAn0nim0 (232451) | more than 5 years ago | (#27851781)

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 (1)

Mr. Underbridge (666784) | more than 5 years ago | (#27852323)

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

That's what I'm seeing. A coup more than a fork.

Thankfully, FOSS allows a group to vote the bully off the island.

For the greater good (5, Interesting)

Rob Riggs (6418) | more than 5 years ago | (#27851795)

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 (2, Insightful)

Anonymous Coward | more than 5 years ago | (#27851949)

The thing about a vocal constituency in OSS is they can do what you wont and then replace you......

Re:For the greater good (1)

Jeff DeMaagd (2015) | more than 5 years ago | (#27851961)

Still, it looks like a fork in the eye though, it seems to be worded to suggest that embedded systems aren't well designed architectures.

But I'm not involved in embedded systems, it might well be true, it seems to still be worded in a needlessly inflammatory way, even if it's not as inflammatory as the article snippet.

Re:For the greater good (5, Interesting)

Burkin (1534829) | more than 5 years ago | (#27851969)

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

Re:For the greater good (0)

Anonymous Coward | more than 5 years ago | (#27852423)

Burkin claims random crap like that all the time when he answers to posts.
aka: [citation needed]

Re:For the greater good (5, Informative)

Anonymous Coward | more than 5 years ago | (#27852003)

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 (5, Insightful)

BSAtHome (455370) | more than 5 years ago | (#27852105)

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 (3, Insightful)

Burkin (1534829) | more than 5 years ago | (#27852175)

But that would actually involve Ulrich actually admitting that he's ever been wrong.

A rant (4, Insightful)

jmorris42 (1458) | more than 5 years ago | (#27852155)

> 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?

Re:A rant (1)

Pieroxy (222434) | more than 5 years ago | (#27852253)

Do you know anything about the issue? I mean, at all?

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

Re:A rant (2, Interesting)

taniwha (70410) | more than 5 years ago | (#27852311)

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 (5, Insightful)

Areyoukiddingme (1289470) | more than 5 years ago | (#27852213)

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:For the greater good (1)

gbjbaanb (229885) | more than 5 years ago | (#27852305)

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 to be a Windows developer using Microsoft-only tools in a Microsoft-only shop.

Actually, people who think that probably are devs in shops like that.

Re:For the greater good (4, Interesting)

LizardKing (5245) | more than 5 years ago | (#27852429)

He's not fit to write C.

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

People still use Linux? (-1, Flamebait)

Anonymous Coward | more than 5 years ago | (#27851821)

Speaking of switching, why haven't you switched to OS X yet?

Are you stupid or just slow?

Re:People still use Linux? (0)

Anonymous Coward | more than 5 years ago | (#27851915)

Both.

Yay! (5, Interesting)

Omnifarious (11933) | more than 5 years ago | (#27851877)

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:Yay! (4, Insightful)

Estanislao Martnez (203477) | more than 5 years ago | (#27852053)

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.

Um, if you're describing that right, isn't he right to reject your patch? What if I'm a user of another EBDDIC system, and that system uses the choice that's in the library? Does that mean that if your patch is accepted, my patch to undo yours should be equally accepted?

Re:Yay! (1)

LaminatorX (410794) | more than 5 years ago | (#27852291)

I'd bet money that IBM EBCDIC z/OS deployments vastly outnumber all other EBCDIC implementations combined. At the very least "Do EBCDIC like IBM" should be the default option.

Re:Yay! (1)

mwvdlee (775178) | more than 5 years ago | (#27852335)

IBM's EBCDIC standard is just like standards in general; there are so many different flavours to choose from.
I'm not quite aware of the different versions of EBCDIC, but they generally have different version for different currencies and such; there are a lot of codepages for EBCDIC and IBM allows you to use any one you wish.

Re:Yay! (0)

Anonymous Coward | more than 5 years ago | (#27852317)

Um, isn't EBCDIC an IBM standard? Isn't z/OS an IBM system?

Are there multiple IBM systems doing it differently? If not, if IBM has a standard way of doing it, that's probably the way to do it for EBCDIC.

If there really are a wild zoo full of incompatible EBCDIC encodings out there, then I guess one is as good as another. But if there is an established way of doing it in the IBM world, and the Glibc guys don't care about following the established way, that's a different matter.

Re:Yay! (4, Informative)

Omnifarious (11933) | more than 5 years ago | (#27852355)

Um, if you're describing that right, isn't he right to reject your patch? What if I'm a user of another EBDDIC system, and that system uses the choice that's in the library? Does that mean that if your patch is accepted, my patch to undo yours should be equally accepted?

I suppose that is sort of correct. But the major EBCDIC system out there that people use these days is z/OS. I sort of doubt you could've actually found another system the change affected because it didn't change all EBCDIC encodings, just a specific version of the EBCDIC encoding.

What I did is I created my own encoding that was named very similarly and carefully rebuilt glibc with every update. But that was a poor solution in several respects because that encoding is mentioned by name in several IBM manuals.

I guess I would've appreciated a tiny bit of discussion, or perhaps the mention of a different system my change would've affected negatively. Neither were forthcoming, and I really doubt there is such a system.

I make a living on this embedded crap (5, Informative)

bzzfzz (1542813) | more than 5 years ago | (#27851881)

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

not amazed (1)

Ingcuervo (1349561) | more than 5 years ago | (#27851891)

but can they run linux?

"So what" vs "Wow, unbelievable" (4, Insightful)

pla (258480) | more than 5 years ago | (#27851939)

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.

Re:"So what" vs "Wow, unbelievable" (0)

Anonymous Coward | more than 5 years ago | (#27852109)

This could be a huge thing as Ubuntu is based on Debian (taking many things from debian unstable). I would say that is the currently largest followed distro as of right now.

While it probably wouldnt happen right away many of the people who work one work on the other. So the leap to Ubuntu using this would not be that far.

I read the original rant. Probably fired off in anger or not read out loud. However it seems as the 'change' is not being made because of 'performance reasons' with no numbers to back it up either way. Maybe he 'knows' it doesnt perform well but not sharing the numbers with the rest of the class only make him look bad.

Also once 1 or 2 big distros switch you can be shuffled off to never never land very quickly by the rest just ask xfree86.

Re:"So what" vs "Wow, unbelievable" (4, Informative)

ArsonSmith (13997) | more than 5 years ago | (#27852223)

Actually Debian is quite prevalent in the embedded space. It's a very consistent develop environment across 11 supported architectures and an additional 5-10 unsupported ones.

Re:"So what" vs "Wow, unbelievable" (1)

PCM2 (4486) | more than 5 years ago | (#27852227)

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.

Perhaps not, but if the hardware vendors start cranking out netbooks based on ARM chips, it would be nice if Debian (or its downstream distros, such as Ubuntu) would function well on that platform -- especially considering that Windows (other than Windows CE) currently doesn't. I don't know whether Drepper objects to patches that cater to embedded-as-in-ARM or just embedded-as-in-ROM, but either way it seems pretty shortsighted to claim that the standard C library doesn't need to support code intended for this-or-that target.

Re:"So what" vs "Wow, unbelievable" (5, Insightful)

Chris Burke (6130) | more than 5 years ago | (#27852283)

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:"So what" vs "Wow, unbelievable" (1, Informative)

Anonymous Coward | more than 5 years ago | (#27852359)

If that were the only feature, or the only instance of this sort of behavior, I'd agree. But this is par for the course for Ulrich. He regularly refuses well-formed patches -- things that wouldn't break anything else, are demonstrably broken, and that are widely used downstream -- because they don't fit his view of how you should build glibc. If you file a legitimate bug report there's an 87% chance that he'll whine about vendor bugs or your build environment, even if the bug is a mainline issue, and sometimes even if it's a problem of which he's already aware but doesn't want to admit. And if you disagree with any choice he makes there's no way to even get him to explain his rationale, even if you cite RFCs or other evidence of a possible error on his part.

And that's just the actual detrimental-to-the-code stuff, let alone the nastiness he spews on a personal level.

Anonymous Coward (0)

Anonymous Coward | more than 5 years ago | (#27851999)

Not too smart of a thing to do.

This will end up a mess. Just like everything else Debian attempts to fork because they _think_ they know better than upstream.

History is repeating itself once again here.

Re:Anonymous Coward (3, Funny)

Burkin (1534829) | more than 5 years ago | (#27852031)

Is that you Joerg?

Re:Anonymous Coward (1)

profplump (309017) | more than 5 years ago | (#27852249)

Exactly. We all know that Ulrich is the epitome of well-reasoned, thoughtful package maintenance, as opposed to the dictatorial behavior of those Debian admins -- I mean, who are they to want to comply with RFCs and compile for platforms other than gnu-linux-x86?

Imagine (-1, Redundant)

sexconker (1179573) | more than 5 years ago | (#27852051)

Imagine a Beowulf cluster of these.

I mean

But does it run Linux?

No wait

How many Libraries of Congress can it hold?

Won't someone explain this in terms of a car analogy!?

Re:Imagine (2, Informative)

Culture20 (968837) | more than 5 years ago | (#27852193)

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.

Re:Imagine (1)

C0vardeAn0nim0 (232451) | more than 5 years ago | (#27852295)

as you wish...

it'd be like a car maker changing the tires supplier from firestone to goodyear because firestone refused to change the thread pattern.

I read the bug reports that he was pissed at (1, Redundant)

cant_get_a_good_nick (172131) | more than 5 years ago | (#27852057)

It seems to be a dick size war between him and Drepper. Not saying he's wrong to be pissed, but yanking your libc seems a bit much for a pissing match.

Not Just for embedded devices (3, Insightful)

John Goerzen (2781) | more than 5 years ago | (#27852081)

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.

API/ABI compatibility? (3, Insightful)

pathological liar (659969) | more than 5 years ago | (#27852087)

From eglibc's mission statement [eglibc.org] :

"Retain API and ABI compatability with GLIBC wherever feasible."

Yeah, that's going to end well...

What an ugly situation (3, Interesting)

erroneus (253617) | more than 5 years ago | (#27852123)

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:What an ugly situation (1)

Areyoukiddingme (1289470) | more than 5 years ago | (#27852377)

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.

I'll dispute that the OS will ever become irrelevant. As a way to bundle up a familiar set of useful libraries for use by other developers, it's here to stay. Irrelevant to the 'consumer' perhaps, but that's not what we're talking about here. Only the developer cares what's happening to the C standard library. This article, and decision, are about the needs of the developer.

I'm not convinced that your prediction that smaller networked devices will supplant more powerful single boxes is true, either. The concept of the server is too useful to abandon. The thing is, whichever of us is right about the future of the hardware, Ulrich is wrong about the software. I can easily see some of the crap he defends to the death causing trouble on desktops, too, not just embedded scenarios.

The problem isn't GLIBC. It's Ulrich Drepper. (4, Informative)

GreatBunzinni (642500) | more than 5 years ago | (#27852177)

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 [sourceware.org] such as:

  • Stop reopening bugs. Search the web if you want an explanation, I don't have
    anything handy and certainly have no interest in writing it up.
  • Strange, I never saw your name on my paycheck. Since if that's not the case you
    cannot order me around.
  • Stop reopening the bug. If you want explanations pay somebody.
  • Dammit, stop opening the bug. It is obvious that you know *NOTHING* about the
    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.
  • Stop reopening the bug. And this is also no discussion forum. Go somewhere else.
  • Stop commenting.
  • Idiot. There is no bug. Don't reopen.
  • Fine. Whatever. I'll revert it, assholes.

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.

Doesn't matter (4, Insightful)

0xABADC0DA (867955) | more than 5 years ago | (#27852197)

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.

Re:Doesn't matter (-1, Troll)

Burkin (1534829) | more than 5 years ago | (#27852301)

and have a 1+mb

Oh my god! Not 1 whole megabyte! How will our modern computers with gigabytes of HDD space and 100s of megs of ram ever be able to handle a 1+ megabyte binary!

Drepper's comments .. (1)

SlashDev (627697) | more than 5 years ago | (#27852203)

.. are very typical of opensource developpers. Try asking Wietse Venema (Postfix developper) for a special feature... That being said, this isn't a feature request, rather a bug (from the embedded perspective). A special module could be written for embedded devices, that way, the module can be enhanced, bug-fixed or whatever, without negatively affecting the main program. But wait! What if the module has a nifty feature eh????

and the story is? (0)

Anonymous Coward | more than 5 years ago | (#27852315)

flaming aside
as the article says

---------
--- check_pf.c.old 2007-04-25 19:05:18.000000000 +0300
+++ check_pf.c 2007-10-06 00:54:45.000000000 +0300
@@ -53,21 +53,18 @@ make_request (int fd, pid_t pid, bool *s
          struct rtgenmsg g; /* struct rtgenmsg consists of a single byte. This means there
                are three bytes of padding included in the REQ definition.
- We make them explicit here. */
- char pad[3];
+ We use pad as a mark for the size of the data we need. */
+ char pad;
      } req;
      struct sockaddr_nl nladdr;

- req.nlh.nlmsg_len = sizeof (req);
+ req.nlh.nlmsg_len = offsetof (struct req, pad);
usw

open source gets the job done, open source development processes use heated language as a community debates, lots of smoke and lightning, what is really new here

eglibc is I'm sure a fine thing for what it really brings beyond glibc (out of my expertise to be honest)...

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?