Debian Switching From Glibc To Eglibc

ceswiedler writes "Aurelien Jarno has just uploaded a fork of glibc called eglibc, which is targeted at embedded systems and is source- and binary-compatible with glibc. It has a few nice improvements over glibc, but the primary motivation seems to be that it's a 'more friendly upstream project' than glibc. Glibc's maintainer, Ulrich Drepper, has had a contentious relationship with Debian's project leadership; in 2007 the Debian Project Leader sent an email criticizing Drepper for refusing to fix a bug on glibc on the ARM architecture because in Drepper's words it was 'for the sole benefit of this embedded crap.'"

Comments

At Least It's Egier to Use and Less Glib

[eldavojohn]

Mod me down, boys.

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

[Philip K Dickhead]

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

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

[atari2600]

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

^ Actual Quote.

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

[RubberDuckie]

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

[ta bu shi da yu]

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

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

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

[schon]

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

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

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

[larry bagina]

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

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

[Darinbob]

I was actually surprised anyone even objected, and to object in such a poor way. Agreeing or disagreeing with someone else's ABI is irrelevant. If we all want to go back to the days of assuming only a single OS and single CPU exists, and that portability just gets in the way of true genius, we can always use Windows.

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

[Chris Burke]

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

Really? Since that's a single cache line in either case, the difference is actually going to be more like maybe a dozen nanoseconds on a modern x86 (when it was going to take around 100ns in the base case assuming a cold cache miss).

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

[A Nun Must Cow Herd]

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

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

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

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

[totally bogus dude]

That particular comment was in response to something posted by a fake Drepper. Check the email address for comment #40.

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

[larry bagina]

yes, nanoseconds. If that.

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

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

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

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

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

[A Nun Must Cow Herd]

Thanks - I'm surprised their bugzilla installation makes it so easy to superficially impersonate people in posts.

Still, some of the other comments are pretty strong too. He seems to have a knack for winding people up.

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

[BrokenHalo]

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.

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

[ta bu shi da yu]

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

Nice going!

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

[noundi]

... in Drepper's words it was 'for the sole benefit of this embedded crap.'"

Aurelien Jarno has just uploaded a fork of glibc called eglibc...

I love FOSS.

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

[Anonymous Coward]

Slashdot is at least as bad, you cannot imagine how many people here claim to be me. A. Coward

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

[nedlohs]

"Fine. Whatever. I'll revert it, assholes." - what a great way to resolve the bug.

He basically told everyone "if you want something changed just bother me enough and I'll give in".

That's going to make him the most productive developer ever!

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

[Hal_Porter]

He said "embedded carp"

http://sourceware.org/bugzilla/show_bug.cgi?id=5070#c1

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

[Hal_Porter]

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

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

Not on the internet you don't.

Oops, I mean

Wow, you are a bastard. I hope you die alone.

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

[MikeBabcock]

While funny, when was Theo wrong exactly?

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

[A_Non_Most_Cow_Herd]

Thanks - I'm surprised their bugzilla installation makes it so easy to superficially impersonate people in posts.

Disregard that, I suck cocks.

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

[Anonymous Coward]

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

[TeknoDragon]

That bug is hilarious. Must read!

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

[Philip K Dickhead]

Um, didn't you die in 1982?

And again, in 1991. And again, in 1964. And again, in 2047.

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

[ContextSwitch]

I have a slightly different take on the situation.

I don't know anyone involved, I only know Redhat by name and I only have a superficial view of what's in glibc but, reading between the lines, I think that Mr. Drepper's protestations about money and who pays it have nothing to do about paying for free software but are his way of telling us that he was told to make this change, he didn't like it but had no choice and the bickering on this bug was like everyone else picking at an open sore of his.

He didn't give any reasons for the change because he could do that and keep his job.

Anyway, it's all just wild speculation on my part.

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

[the_B0fh]

For a lot of people, Theo is wrong by being right and being blunt about it. When Theo calls you an idiot, pretty much, you're an idiot at that time. Most people just can't handle it.

I've asked stupid questions before, but Theo had never called me an idiot, and had offered extra help. But I didn't try to tell Theo that he was an idiot either.

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

[Rakarra]

Mods, I don't think the AC deserved the Troll mod. While he certainly could have phrased it more politely, he's absolutely right.

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

[Rakarra]

"Fine. Whatever. I'll revert it, assholes." - what a great way to resolve the bug.

Hover over the name to see the registered email address -- that was someone else using his name.

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

[badkarmadayaccount]

.. of Social Graces

Learn to read please.

uClibc

[Anonymous Coward]

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

Re:uClibc

[Tubal-Cain]

Glibc compatibility?

Re:uClibc

[profplump]

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

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

Re:uClibc

[lobiusmoop]

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.

Re:uClibc

[impaledsunset]

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

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

Re:uClibc

[OrangeTide]

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

Re:uClibc

[Red Flayer]

Why this and not uClibc?

Because uClibc brings us one step closer to Cthulhulibc.

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

Re:uClibc

[fuzzyfuzzyfungus]

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.

Re:uClibc

[hardburn]

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

Re:uClibc

[LaminatorX]

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

Re:uClibc

[mu22le]

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

were you aware of this video or is it just a coincidence?

Re:uClibc

[Anonymous Coward]

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

[fuzzyfuzzyfungus]

Superb work, good sir. I am most impressed. Obviously, I can't actually mod in that direction.

Re:uClibc

[Darinbob]

Or newlib as well, also popular on some embedded systems. Though it's a bit small for a full embedded Linux.

Re:uClibc

[johannesg]

Applause!

This is why I come to Slashdot ;-)

Re:uClibc

[Aardpig]

Chtulhulibc? That's the one where there's no fork(), just spawn(), right?

Re:uClibc

[Evil Pete]

Wooohooo! Excellent post. Very clever, well done.

Re:uClibc

[MikeBabcock]

I don't understand why anyone would believe uClibc or other micro libc variants are binary compatible, but they certainly are useful and often very powerful.

Hope it works

[AvitarX]

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

Re:Hope it works

[Thinboy00]

fork while fork;

Re:Hope it works

[Burkin]

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

[ThePhilips]

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.

Re:Hope it works

[mikiN]

Hear, hear!

config EMBEDDED
        bool "Not for Aunt Tilly!"

        For wizards and experts only,
        Kbuild people don't like this!
        Don't spam the mailing list with support questions!

-
Remember CML2, anyone? The noble attempt to replace the Linux kernel config language (which makes even JCL or RPG/38 seem like high Latin)? That one went with a "splash" on the LKML and found a new home in emDebian, too.

When reading Dreppers' comments, my browser died with a SIGEGOTOOBIG.

Re:Hope it works

[beav007]

When reading Dreppers' comments, my browser died with a SIGEGOTOOBIG.

Ah, the old SIGFAULT. You should recompile with Eglibc.

Re:Hope it works

[Rakarra]

No one should know that much about memes.

No one.

Don't be so Glib

[powerlord]

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

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

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

Re:Don't be so Glib

[TheStonepedo]

I know you mean Windows in the XP/Vista/2007 sense, but historically Windows CE/Mobile has run on ARM chips. While current netbook users demand slightly more out of their machine than they'd have had in a PDA five years ago, an up-to-date mobile edition of Windows would run on embedded chips splendidly (or as splendidly as Windows runs).

Re:Don't be so Glib

[Stewie241]

Well, if you had read the summary, you would notice that it is binary and source compatible. I would assume that they would stay relatively close except in cases where glib is being uncooperative.

Re:Don't be so Glib

[Anonymous Coward]

What's the point of forking if it's binary and source compatible?

Re:Don't be so Glib

[FlyingBishop]

Please read the summary.

The maintainer is hostile to ensuring compatibility on ARM.

Re:Don't be so Glib

[ta bu shi da yu]

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

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

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

Fork couldn't have come soon enough!

Re:Don't be so Glib

[jabjoe]

Doesn't matter what Windows it is. Windows on ARM won't have any software. It can't use the mountain of x86 Windows software, which has always been it's advantage until now. Because of the closed nature of the platform, it's not like everything can just be recompiled for ARM. Linux on the other hand has been multi-platform for a long time, all the software is open source, so most stuff was changed so it can compile on other platforms (including ARM). Linux comes to the table very strong on ARM, where as Windows without Windows software is pointless.

Re:Don't be so Glib

[DrXym]

I don't disagree, Windows mobile would run great on ARM processors. However anyone expecting a desktop experience from a netbook with ARM and Windows mobile is going to be sorely, sorely disappointed. The apps are nowhere near sophisticated enough for desktop use meaning the overall experience will be pretty lousy, more like a glorified PDA.

By contrast virtually all of a standard Linux desktop will compile to ARM. You might be missing some important pieces like Flash player, Sun Java and some other stuff, but the core experience would all be there. You'd get Firefox, OpenOffice, media players and everything else, subject to the system's other limitations such as memory & disk footprint.

Re:Don't be so Glib

[Random Walk]

By contrast virtually all of a standard Linux desktop will compile to ARM. You might be missing some important pieces like Flash player, Sun Java and some other stuff, but the core experience would all be there. You'd get Firefox, OpenOffice, media players and everything else, subject to the system's other limitations such as memory & disk footprint.

Yes, and here's the catch. It has been my experience that if you want a Linux desktop that can compete with the offerings from Microsoft, in compatibility, functionality, and eye candy, you are looking into something pretty heavyweight: Gnome or KDE, OpenOffice, Firefox, all of them heavyweight stuff, not to mention the ever-increasing number of deamons that are running in the background (hald, NetworkManager, Dbus, ...). It doesn't work well on low-end hardware on which Windows XP will still run smoothly.

Re:Don't be so Glib

[TheRaven64]

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). Using the same approach as Rosetta, where the app is emulated but it calls the native platform libraries (so a lot of the app's CPU time is spent executing native code) you'd probably get decent, though not stellar, performance for most apps. Games, obviously, would not be so good, but that one important business app that keeps you from ditching Windows would probably run.

Re:Don't be so Glib

[lilo_booter]

But, umm, he's right. He may have been abrupt in the way he phrased his initial response, but his reasoning is not at fault.

Re:Don't be so Glib

[DrXym]

The problem with full blown Windows running on ARM (assuming they could make it work) is you get all of the bloat but few of the benefits. When NT was officially supported on x86 and Alpha, I can't recall any 3rd party application which were compiled for Alpha. Maybe a few database apps but precious little else. This meant the platform required x86 emulation plus a bunch of stub DLLs for the 99.99% of apps that never bothered to run natively. Perhaps this is feasible on a workstation but I doubt it is on a netbook where space and performance are tight enough already. May as well not bother at all with ARM if you're going to stick a full blown Windows on it.

Re:Don't be so Glib

[hyc]

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:Don't be so Glib

[BlueLightning]

It doesn't work well on low-end hardware on which Windows XP will still run smoothly.

Which is a moot point since we're talking about ARM, on which Windows XP will not run.

Re:Don't be so Glib

[TheRaven64]

Most apps aren't CPU-bound these days though, and the few bits that are heavy on the CPU tend to be things like drawing routines that are in standard libraries. If you've got a native port of Office, you can run most of your apps in emulation and still get good enough performance for a netbook. Open source apps, for example FireFox, can typically be recompiled and there are quite a lot of these on Windows systems these days. Any single netbook model produced so far has sold a lot more units than DEC/Digital ever sold Alpha-based Windows boxes, so it becomes a much more attractive market for commercial Windows developers to start targeting. If Microsoft shipped an ARM emulator with Visual Studio and provided the same kind of one-click mechanism for creating fat binaries that Apple offers then I imagine a lot of software would be ported very quickly.

Re:Don't be so Glib

[powerlord]

If Microsoft shipped an ARM emulator with Visual Studio and provided the same kind of one-click mechanism for creating fat binaries that Apple offers then I imagine a lot of software would be ported very quickly.

THey'd also need to make the OS able to handle fat binaries. It should also up the space requirements quite a bit.

Re:Don't be so Glib

[GreyFish]

What happens if/when there is an x86 -> arm jit runtime compiler?

Remember apple has a nice ppc -> x86 jit for when it switched to intel cpu's, so it's not impossible.

and don't forget than dotnet is cpu independent!

Re:Don't be so Glib

[DrXym]

That's a lot of ifs in there. Microsoft are finding it hard enough to persuade devs to build 64-bit native apps due to the hamfisted way they went about releasing a 32 bit and 64 bit version of Vista and the either/or build model in the tools. Fat / universal binaries would be nice but they haven't even done it for x86. I don't see any possibility of them ever doing anything for as niche as a range of netbooks running ARM.

Even with fat binaries, apps (including all those parts of Windows itself) still need to be compiled and tested on each architecture. Issues caused by endianess, padding and whatnot would demand full regression testing. About the only thing which is mostly unaffected by underlying architecture would be the .NET framework apps but even a lot of them are tainted by dependencies on unmanaged DLLs meaning emulation would have to work with them too.

I just don't see it being feasible for the limited payoff. If a netbook wants full Windows they'd be far better off just shoving an x86 chip in there and be done with it. I don't doubt that more ARM enabled netbooks will turn up but they're more likely to be running Windows Mobile with all that entails.

Re:Don't be so Glib

[samjam]

Yes but did you read the thread?

strlcat was the salvation for those who have already been punished by legacy applications abominable use of strcat.

Sam

Re:Don't be so Glib

[jabjoe]

It will be slow and fat making Windows apps, that are already slow and fat, even worse.
Dotnet apps also have a terrible habbit of being fat and slow, which is crap for desktop machines where more hardware is not a solution. That will be even worse on a netbook!

Going back to Win32, I believe WINE can already been hooked up so WINE client apps can be in an emulated environment and the WINE server native.... So if all the work of the apps is actually in system calls, it might run ok....

But by far and away the best solution is an open source solution so they can compiled for the native architecture and have any fat cut out. Windows and it's apps can go hang.

Re:Don't be so Glib

[powerlord]

What happens if/when there is an x86 -> arm jit runtime compiler?

Remember apple has a nice ppc -> x86 jit for when it switched to intel cpu's, so it's not impossible.

and don't forget than dotnet is cpu independent!

Good questions, but unfortunately for MS its a different situation.

1. Apple's Rosetta works because it the Intel hardware its running on is more powerful than the PPC hardware its emulating. A better example would be VirtualPC on Apple PPC hardware running Windows. It worked, but it was dog slow compared to VMWare or Parallels on Apple Intel hardware.

Another option some people have mentioned, that goes along with Rosetta is the idea of "Fat Binaries" where one "binary" actually includes multiple binaries for different architectures. Apple did this with their Universal Binaries that contain both PPC and Intel code inside them. This allows the same binary to work on multiple architectures. Its a great idea and contains the flexibility to let you support multiple architectures, but I think MS would need to modify the OS to support it, and even then, it balloons the size of the binary because of all the "redundant" pieces that most users won't even use. This isn't something that you want for a netbook. On OSX this extra space can often run in to the GB depending on how many applications you have installed. Once of the big things in Snow Leopard is that removing PPC support allows Apple to start stripping out that cruft themselves (at the expense of no longer supporting PPC hardware from 3-4 years ago).

2. .Net is SUPPOSED to be architecture independent, and most of the stuff that is developed for Mono is, but a lot of the stuff MS develops make calls to WINtel specific libraries. They (MS) would have to port these libraries to ARM. They could certainly do it, but I doubt it would just be "recompile the source" since a lot of those libraries were probably not coded with portability in mind, let alone making sure that the architecture supports the features the libraries are expecting, in the format they are expecting.

Re:Don't be so Glib

[Just Some Guy]

It doesn't work well on low-end hardware on which Windows XP will still run smoothly.

Apples and oranges. ARM is a netbook platform, not something you'd want to build a high-end gaming rig around. Ubuntu's Netbook Remix launcher is becoming popular in that space, and it's incredibly competitive there. I have an EeePC 701 that nicely runs all the apps you mention, with an attractive and convenient front-end. What's not to love?

Re:Don't be so Glib

[Just Some Guy]

But, umm, he's right. He may have been abrupt in the way he phrased his initial response, but his reasoning is not at fault.

No, he's not. The entire point of not using assembler is to have the language do convenient stuff for you. What's more efficient, reasonable, and secure: implementing those nice functions well in one standardized library, or forcing each programmer to re-implement them - probably poorly?

memcpy for string manipulation, my ass. I thought we'd moved past that.

Re:Don't be so Glib

[lilo_booter]

That wasn't why I was saying he was right - the strl* functions disguise errors which should not occur if the application is coded correctly. They may avoid a crash, but they won't necessarily provide the desired results and that could be far worse...

Re:Don't be so Glib

[Hal_Porter]

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.

Re:Don't be so Glib

[ta bu shi da yu]

How? If that crash is someone deliberately smashing the stack, I don't see any issue. If there's a bug, then there is a bug and it should be corrected. There's no disguising of the error really... someone is going to notice the data is wrong (depending on the context) and fix it up anyway.

Re:Don't be so Glib

[petrus4]

Yes, and here's the catch. It has been my experience that if you want a Linux desktop that can compete with the offerings from Microsoft, in compatibility, functionality, and eye candy, you are looking into something pretty heavyweight: Gnome or KDE

In terms of eye candy, Enlightenment thrashes the pants off either of the "Big Two." Where E doesn't win though is in terms of the really important things...E16 at least doesn't have a bottom anchored Start Menu or a trivial means of changing your wallpaper. ;)

Re:Don't be so Glib

[Just Some Guy]

Ahh, OK. I still prefer to think of them as a last line of defense in case I make a mistake elsewhere. That is, don't necessarily rely on them, but hope they catch something you otherwise might've missed.

Re:Don't be so Glib

[TheRaven64]

I agree with a lot of what you say, but:

Look what happened with Itanium - it was aimed at servers and had an in order x86 core to run x86 code

There is a massive difference between server workloads and laptop workloads. The kind of market Itanium was aiming for is one where you have 90+% CPU utilisation a lot of the time. A typical laptop, on the other hand, does not. Looking at my CPU load history, it hasn't gone over 20% for a long time, around 70% of the time it is spending doing anything is in the kernel. Even a much slower CPU, with an emulation layer for userspace apps, would result in the same performance, just with a higher percentage CPU load.

Re:Don't be so Glib

[digsbo]

Disagree. I could run Ubuntu 8.10 and XP equally well on my old Pentium II 400MHz/512Mb laptop. Gnome without effects is about as responsive as XP without desktop effects.

Re:Don't be so Glib

[AzureDiamond]

There is a massive difference between server workloads and laptop workloads. The kind of market Itanium was aiming for is one where you have 90+% CPU utilisation a lot of the time. A typical laptop, on the other hand, does not. Looking at my CPU load history, it hasn't gone over 20% for a long time, around 70% of the time it is spending doing anything is in the kernel. Even a much slower CPU, with an emulation layer for userspace apps, would result in the same performance, just with a higher percentage CPU load.

Well the plan with Itanium was that you'd run a native OS and native server applications. x86 compatibility was something you only needed very occasionally. Still the chip was panned for poor x86 performance. Mind you the native performance wasn't poor but it wasn't exactly stellar either.

Re:Don't be so Glib

[umeboshi]

this doesn't preclude them from including new functions like strlcpy and strlcat

While that's true, including those functions would break the ABI, so they aren't going to be added. Although, it's very possible they will be added at some point in a future release.

Look at the bottom of the announcement.
http://lists.debian.org/debian-devel/2009/05/msg00175.html

Re:Don't be so Glib

[gangien]

ok so why is strcat so terrible. I'm trying to imagine, and i'm failing to see it.

Re:Don't be so Glib

[marcosdumay]

Hum, what world are you caming from? Desktop Linux needs some resources, but will run smootly on anything that can run XP. It will run smootly on quite worse systems if 3D hardware acceleration is provided.

Also, you can get quite a passable desktop experience from lightweight DEs, that won't need all those resources... And most deamons use no processing and can be swapped to disk (not on netbooks, ok) most of the time. For the remaining little time they are running, you can annoy the user with no consequence, they are used to much more hassle from Windows "pauses" (I don't really know what causes them, badly designed FS, deadlocks, whatever).

Re:Don't be so Glib

[hyc]

You and the vast majority of C programmers, it seems.

Security aside, think of it from an efficiency perspective: it always starts from the beginning of the target string (since it has no other information available to it), iterates to the end, and then begins catenating the second string. This gives you O(n^2) behavior when catenating multiple times to the same string. The str* functions are some of the worst ever designed...

There are two obvious fixes:
  1) always record explicit lengths of your strings, so that you can catenate by just memcpying to the end of a given target string
  2) use my strcopy() function, which returns the pointer to the terminating NUL at the end of the target string.

E.g., this is legal and useful:
strcat(strcat(strcpy(a,b),c),d);

but it's slow because each strcat starts over from the beginning. If strcpy/strcat always returned the pointer to the end of the target string, instead of the pointer to the beginning of the target string (which is what strcopy() does) then you get no efficiency loss, and you only need one function instead of two:

strcopy(strcopy(strcopy(a,b),c),d);

After you fix this basic inefficiency you can of course define strn/strl variants as you see fit...

Re:Don't be so Glib

[Harik]

Performance is meaningless when your program is trivially exploited by hostile input. The problem with strcat is it assumes every pointer is in a unique address space with infinite ram. Since there's no such thing on any processor in existence, the shortcomings become rapidly clear.

The issue is the assumption that a single pointer to the first character of a string gives you all the information that you need - this is horribly broken. You have to have at minimum two pieces of information - where it's located, and how large the buffer allocated is. Knowing how 'full' it is currently is a nice optimization. It's not possible to represent those three things with a single char * pointer, so all the string functions are inherently broken.

Don't use null-terminated strings for text processing in your application under any circumstances. I don't care how smart you are - if you're smart enough to get it "right" you're going to be writing your own string library anyway. Get a decent C string library, or migrate to C++ and use std::string, or use another higher-level language. When you need to use a system/library call that needs a char *, you can get that from your String. (foo.c_str(), etc)

Re:Don't be so Glib

[Harik]

(In case it's not obvious, this comment was directed at gangien, not hyc)

Re:Don't be so Glib

[gangien]

OK i understand your point. But, because a function doesn't fit your use case you think they're terrible and should never be used?

in most cases that this type of thing will make no difference.

Re:Don't be so Glib

[hyc]

What other use case *is* there for strcat???

"make no difference" try profiling some actual code before you say that. I have, it does. It's the difference between having a poky slow AppleShare server and having the fastest one in the world. (Yes, I wrote that while at Locus Computing.) It's the difference between having a poky slow LDAP server and having the fastest one in the world. (Yes, I wrote that - OpenLDAP today is the world's fastest directory server; in 2000 it was a pig.)

Efficiency *always* matters. People who think "it makes no difference" are the programmers responsible for all the crap bloatware in the world today... Just because they're in the majority doesn't make them right.

Re:Don't be so Glib

[gangien]

ok let's take an example of a program where i know i used strcat

where did i use it? well in this case i only used it at start up. building strings to send to another program. Gonna tell me that made my program slow? cus it sure didn't. especially not next to initlizing the libraries that i had to do, which didn't affect anythign either.

But let's bring another example i did, i had to append a large ass string over and over? know what i did? exactly what you described, kept track of the length and appended it from there. Gonna tell me strcat would have sucked there? well yes, it would have. Funny thing, i avoided it, in that case. (i didn't even realize i had a case illustrating your point about strcat)

What's the saying, 10% of your code runs 90% of the time? so you wanna optimize your 90% of your code with stuff like this? Why not do the thing in ASM?

Efficiency *always* matters. People who think "it makes no difference" are the programmers responsible for all the crap bloatware in the world today... Just because they're in the majority doesn't make them right.

Being efficient enough is always important, over optimizing isn't. There's only 1 case i can think off, where me using strcat would have had a noticeable impact, and that would be a compiler in college i wrote a few years ago now. I think i had a funky usuage of it in there. But even in that case, would it have mattered? nope. instead of compiling in 1 second it took 2? great. don't care, my prof didn't care, and even if it somehow was reused, and it became a problem? I would have fixed it anyways.

Might be a good idea

[je ne sais quoi]

Speaking as a Debian user who has had some major upgrade problems directly caused by glibc, anything that's "more upstream friendly" is okay by me. I've had my system totally screwed by glibc problems before, so badly that the only thing I could think of to do was to reinstall (it was while installing on a new machine, so it was okay). Whenever I see that glibc in the upgrade list for apt-get upgrade, I get a little queasy to this day though, along with upgrading the locales package.

Re:Might be a good idea

[Timothy Brownawell]

Speaking as a Debian user who has had some major upgrade problems directly caused by glibc, anything that's "more upstream friendly" is okay by me.

I don't think this means "easy to upgrade", but rather "the maintainer isn't an asshole".

Re:Might be a good idea

[TheRaven64]

Which, unfortunately, is the problem with glibc. Remember the fact that he refused to incorporate the safe string handling functions because they were 'inefficient BSD crap,' forcing portable OpenSSH and a number of other projects to include their own copies of things like strlcat()/strlcpy() to work on GNU systems?

Re:Might be a good idea

[fm6]

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

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

Re:Might be a good idea

[xant]

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:Might be a good idea

[Sir_Lewk]

As a Debian User, you are the downstream. "Upstream" is where it comes from, "downstream" is where it goes.

Re:Might be a good idea

[je ne sais quoi]

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

It was actually during a dist-upgrade, but from sarge to etch (kde was hugely out of date for an end user). In my defense though, why should my system get so hosed while trying to do that? I thought the entire point of having a package manager was to make those kinds of things seamless. glibc is the only package that hosed my whole system doing that. Even having problems with locales required me to revert and just reinstall some things. I think that having a package maintainer who is more open to fixing bugs in existing releases (such as is shown in some of those bug reports that people have listed here) would make life much easier for transitioning and make it more flexible about which packages depend on it. This is especially important for such a low level package like glibc. But hey, what do I know.

Re:Might be a good idea

[Nicholas Evans]

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

Re:Might be a good idea

[Geoffreyerffoeg]

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

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

Re:Might be a good idea

[thethibs]

Wow! a glibc BSOD?

Re:Might be a good idea

[pz]

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

Sorry, being unnecessarily offensive and combative is the very definition of an asshole. The term fits.

Re:Might be a good idea

[danieltdp]

I'm sorry to disagree, but that make him an asshole. A geeky one, but basically an asshole

Re:Might be a good idea

[evanbd]

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

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

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

Re:Might be a good idea

[Curien]

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

No, it really does make him an asshole.

Re:Might be a good idea

[Anonymous Coward]

What are you going to do, sterilize us? Fat lot of good that would do.

Re:Might be a good idea

[heson]

You blame upstream for a packaging bug? It's impossible to blame anyone than debian QA for that one.

Re:Might be a good idea

[bytesex]

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.

Re:Might be a good idea

[miro f]

wow I don't think I've ever seen anyone cop it this hard for a comment before...

Re:Might be a good idea

[David Gerard]

He has an overwhelmingly clear case of Asshole Personality Disorder.

Re:Might be a good idea

[SharpFang]

Yeah, right. I bought this dongle which was supported only in Vista, so I installed Vista and...

You know, fuck you.

Re:Might be a good idea

[ThePhilips]

At the time of strlcpy()/strlcat() inception I read their OpenBSD man pages and it took me a while to understand what the operations are really improving compared to memcpy()/snprintf(). Yes, they are safer than traditional str*cpy()/str*cat(), yet largely redundant, as no self respecting programmer have ever used them for anything else but helloworld.c.

If portability isn't issue (and if you asking for strlcpy()/strlcat() it is apparently not), then for most simple programs you are better off using GNU extension asprintf(). It is also supported by BSD and is magnitudes safer than cascades of str*cat().

Re:Might be a good idea

[Schraegstrichpunkt]

I am sick and tired of yet another patch that hoses the system requiring a bare-metal install to fix.

I don't know what you are talking about. I'm running Debian unstable, and I've never had to do a bare-metal install to fix any problems on my machine, which I set up 8 years ago. (I've moved my filesystem from machine to machine over the years as I upgraded the hardware.) Maybe once or twice, I've booted Knoppix to fix a kernel upgrade that I botched, but that's it. In 8 years.

Seriously, if your distro is so screwed up that you need to do bare-metal installs to fix things, you need to switch distros.

Re:Might be a good idea

[GodfatherofSoul]

Yes, more women!

Re:Might be a good idea

[MikeBabcock]

You have to love his replacement example:

*((char *) mempcpy (dst, src, n)) = '\0';

Re:Might be a good idea

[fm6]

Hmm. Is a geek with good communications skills still a geek?

Moot point. After seeing further evidence, I'm forced to admit that I was wrong. Drepper is your classic online asshole. His problem is not the way he communicates his ideas. His problem is a total indifference to ideas that conflict with his.

Re:Might be a good idea

[fm6]

Please. All geeks are unnecessarily offensive and combative. Most non-geeks would use those words to describe the discussion you and I are now having.

That said, I'm now forced to admit that Drepper has an attitude that does indeed go beyond geekiness and into pure assholedom.

Re:Might be a good idea

[ta bu shi da yu]

Yeah, I know. It makes finding bugs just that much more easier.

Re:Might be a good idea

[fm6]

Consider that most people would regard an argument that's really just a contradiction as pretty assholish, especially when 2 other posts have already made the same point.

Re:Might be a good idea

[fm6]

Uh, dude, you do realize that you just contradicted me without explaining why I'm wrong. Exactly how is that less assholish than what Drepper does?

Re:Might be a good idea

[fm6]

the last few years seem to have been solely dedicated to 'tarting up' glibc with thread-safety and locale-awareness (and UTF)

"Tarting up"? Thread safety and g11n are considered basic requirements of development platforms these days.

Which is not to disagree with your main point about conditionals. Though I wonder whether the "tartiness" has as much impact on performance as you think it does.

Re:Might be a good idea

[danieltdp]

What?! Were?! Are you calling me an asshole?! Jokes appart, parent said the guy was more of a nerd than an asshole and I disagreed with him.

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

My reply:

I'm sorry to disagree, but that make him an asshole. A geeky one, but basically an asshole

From were I came, this is called discuss, talk, disagree or argue. Nothing assholish by any means.

Maybe you didn't understand my argument. I will try to explain: his BEHAVIOR makes him an asshole, and his BACKGROUND makes him a nerd. The fact that both happens together doesn't mean one thing causes the other.

Re:Might be a good idea

[fm6]

Discussion and argument means explaining yourself. You didn't do that. You just contradicted me.

Re:Might be a good idea

[marcosdumay]

The funny thing is that both the 'tarting up' and the not 'macrifying' are correctly removed by gcc if you care to ask for some optimization. So, both 'tarting up' will not make your programs slower (you have nothing to worry) and 'macrofiling' won't make any program faster (glibc developers should worry).

Re:Might be a good idea

[NemesisEnforcer]

The parent is absolutely right. People like to justify Drepper's behavior by saying that it does not impact the quality of work. That justification could possibly be the stupidest and most wrong thing I've ever heard -- in the history of humankind.

There used to be this absolute tool on the gamedev.net forums, and maybe he was Drepper in disguise. The person was extremely smart, but he would go out of his way to be curt to posters. Hi s justification was that being civil and polite is not efficient. I'd be willing to cede that to him, but he, and everyone like him, miss the more important point: you're useless to the team if you can't work with the team.

What I want know is why do people do it, what drives that behavior? Do they get some kind of kick out of being unnecessarily hostile?

Re:Might be a good idea

[Rakarra]

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

It sounds like you're arguing that the typical geek is an asshole. I'm not sure I'd disagree with that either.

Re:Might be a good idea

[Nevyn]

Remember the fact that he refused to incorporate the safe string handling functions [...] like strlcat()/strlcpy()

-1, Fail at C. strl*() are not safe, they are safer than strn*() sure ... but that isn't the same thing. Hell it's not even like they are efficient, which is the usual C hacks fallback for using 1980s interfaces today.

If you want a small, faster, easy to use and safe C string API go use one, or any number of others that are designed for other criteria. With this new fangled shared library technology, we can now put shared functions in more than one file call libc.

Also when he refused to add them, their defintion was different on both platforms that implemented them ... not that it makes Drepper a nice person, but he wasn't all wrong about strl*().

Re:Might be a good idea

[fm6]

By normal standards, we are. But these things are relative. Around here, you take a certain about of O&C as normal and don't interpret it as assholeness.

But there are people who are so obnoxious and closeminded that they rate as assholes even by the restricted standards of the geek community. I've since become convinced that Drepper fits that definition. But not because he's O&C and says things like "embedded crap". He's an asshole because he's treating glibc as his private property, not a community effort he's just coordinating.

Online communities can be O&C and still be a community. (Most are!) But Drepper doesn't want glibc to be a community at all.

Re:Might be a good idea

[TellarHK]

Unfortunately, what it really does is make him _both_.

Re:Might be a good idea

[Curien]

Because I did not do so while exerting my influence over a community project. We are mostly-anonymous users engaged in discussion about a topic over which we have no control and in which we are not the actors. Drepper, on the other hand, was acting as a central point of authority over a major free software project; the standards of behavior are higher. It's not a "him vs me" thing; it's a "that situation versus this situation" thing. If I had made that kind of comment on the bug tracker for the free software project *I* maintain, I would be just as much of an asshole as he is.

Frankly, I found your comment to be utterly counterproductive. There is a sadistic streak in geek culture which wallows in schadenfreude when a person of technical prowess insults and degrades another who is perceived to be his lesser. This is no more civilized than the schoolhall bully who shoves his physically weaker classmate into a locker or any other of the "typical" behaviors observable in maintstream culture. Your dismissal of it as "boys will be boys" only serves to mistakenly justify it in the minds of miscreants.

All that, and I didn't even ask for money!

Re:Might be a good idea

[fm6]

You're wrong!

Re:Might be a good idea

[Curien]

You asshole. ;-)

Re:Might be a good idea

[fm6]

Yeah, my post was pure assholedom. And why? Because I refused to engage properly with the conversation you were trying to have with me. That's all there is to being an online asshole, whatever hairs you choose to split.

Re:Might be a good idea

[Curien]

Uh, I was making a joke. That's what the winking smiley thingy means.

Re:Might be a good idea

[fm6]

Yeah, I know you were making a joke. I looked for the smiley that means "OK, I admit it, I was wrong" but I couldnt' find it.

FINALLY

[Anonymous Coward]

Drepper has had this coming for many, MANY years.

He has pissed off practically everybody in the FOSS world at least once.

Good riddance.

I hope this ends up like the gcc/egcs thing a while back. In the end the old gcc was shut down and egcs was renamed back to gcc.

It would be for the best of glibc if this Drepper dude got removed from the project.

I still think we should organize a mud wrestling match between Ulrich and Theo.

Re:FINALLY

[David Gerard]

Ulrich, TuomoV and Joerg Schilling.

Re:FINALLY

[DaGoodBoy]

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

Re:FINALLY

[Anonymous Coward]

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

[MichaelSmith]

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 or anything.

Re:FINALLY

[ThePhilips]

Drepper has had this coming for many, MANY years.

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

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

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

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

Re:FINALLY

[ak3ldama]

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.

Re:FINALLY

[Anonymous Coward]

Ulrich, TuomoV and Joerg Schilling.

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

Re:FINALLY

[FourthAge]

Only if David Dawes of XFree86 fame shows up and demands a credit clause.

Re:FINALLY

[emurphy42]

Drepper's complaint was that the fix would slow things down on other architectures. The counterarguments were (1) he was relying on an assumption that could be broken under other circumstances as well, and (2) a different version of the fix that would actually speed things up on all architectures. (I assume these things are correct because some version of the fix was eventually accepted.)

Re:FINALLY

[David Gerard]

I can see it now.

"YOU! 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!"

The only theory anyone's been able to come up with is that Dawes finally lost it trying to fix his own broken modeline.

caps filter caps filter caps filter caps filter caps filter caps filter caps filter caps filter caps filter caps filter

Re:FINALLY

[Anonymous Coward]

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

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

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

Re:FINALLY

[TheRaven64]

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

Yes. When he refuses to incorporate the string manipulation functions that don't perform silent truncation, that's a security problem. Every BSD libc (including Darwin/OS X) has strlcat() and friends, but Drepper decided they were 'inefficient BSD crap'. A few projects, like OpenSSH, just include a copy of the ones from OpenBSD libc in their own code, but other projects over the years have just fallen back to strncat() and friends if the safe versions aren't available, and had security problems on GNU platforms that didn't apply elsewhere.

If you're going to refuse patches for no reason other than the fact that you're an idiot, then it is affecting the project you maintain and a fork is an excellent idea.

Re:FINALLY

[xant]

Honestly, even if none of that were true, you're not allowed to be an asshole any more if you are in charge of a major project. Open source is a *community*, and people flee the community when it's populated by assholes. Darwinian selection tends to filter out assholes in this environment, because it doesn't take all that much to advance a better project, even if the asshole is extremely gifted.

Re:FINALLY

[welshbyte]

If Debian users want to use the strl* functions and others from BSD libc they can get them from the libbsd* packages, but of course that's far from ideal.

Re:FINALLY

[X0563511]

The guy knows what he is doing, too. If you haven't, I suggest reading his paper:

http://people.redhat.com/drepper/cpumemory.pdf

Re:FINALLY

[Curtman]

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

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

Re:FINALLY

[EveLibertine]

He has pissed off practically everybody in the FOSS world at least once.

Good riddance.

Because the FOSS world is full of well balanced individuals who would never get unreasonably pissed off at the drop of a hat.

Re:FINALLY

[Darinbob]

How about a one day furlough for Reiser to join in?

Re:FINALLY

[joe_n_bloe]

Ulrich, TuomoV and Joerg Schilling.

I remember writing Joerg a couple of times asking where could we (a university) send him money for a license for dvdrecord, so our dvd burning chain didn't abruptly break every time one of his temporary keys expired. Did I get a response? Of course not!

Heck of a business plan, writing non-free software but not accepting orders for it.

Re:FINALLY

[Thuktun]

Please go back and re-read the post to which you replied. I think you missed something, like some small amount of sarcasm.

Re:FINALLY

[Anonymous Coward]

You wonder why you aren't 5 insightful? No you don't or you wouldn't post as AC.

strl* functions are made to be as fast as possible and as useful as possible so that retards like you don't use strn* and str* crap to win a few bytes or cycles.

-1 on truncation is completely useless. Look at Microsoft safe string functions for reference on real crap.

Oh, truncation happened! Alarm!, alarm! call a handler. Okay, let's try again with a bigger buffer and hope to be luckier this time or waste yet another call with strlen(at this point you should have done strlen and memcpy).

BTW, growing buffers are slow and problematic for many reasons you wouldn't understand anyways. Go back to your Java.

I post as AC because I happen to have modpoints.

Re:FINALLY

[Austerity Empowers]

This proves he understands computer architecture, particularly for the x86 and knows how to write code that works very well on his targeted hardware. A lot of people do, particularly in hardware development, firmware and (get ready) embedded development. Not everyone, I'm sure he gets lots of crappy patches.

That doesn't qualify him to lead anything, nor does it excuse the attitude. If he wants to pull off the Asperger's thing and obsess over every lost access cycle, he should do it as a code contributor while a more dynamic personality handles the project leadership.

Put another way, any program can be optimized down to nothing if you throw out all the requirements. He doesn't seem to balance the two very well, nor does he want to share his insight with others as to why he makes arbitrary decisions.

Re:FINALLY

[shutdown -p now]

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

It's not "just this case". Google is your friend. Or, heck, just read the comments in this discussion. You'll find plenty of mentions of him being an asshole when he did indeed screw up, with references and all.

Re:FINALLY

[mati.stankiewicz]

Well, why didn't he admit it? "It's not a bug, it's a feature"?
Maintainer or not he is an asshole.

Re:FINALLY

[osee]

funny, that was my thought exactly.

Is it only my feeling that Ulrich and some others (Theo, Joerg) have anger management issues?

It's like Ulrich takes arbitrary input about his project as personal insults. Then he gets really worked up over them and blurts some offensive response. That is probably way less offensive than he originally intended but still...

It's such a shame I have so narrow a view of these people. They might be fun drinking buddies. :-D

Re:FINALLY

[David Gerard]

He's undeniably brilliant, and also undeniably not the easiest person to work with.

Re:FINALLY

[MikeBabcock]

I dare say, the reason I support open source and free software is because developers of all types can be total jerks like this.

There are plenty of closed-source developers who are equally closed-minded (excuse the potential pun) and having no rights to their software prevents helpful forks like this.

Plenty of other very good developers have this attitude problem, and I sympathize -- when you spend your day dealing with people substantially less intelligent than you, it can be difficult to see merit in anyone else's code at all.

Enlightenment, Reiserfs, qmail, etc. are all results of programmers with these types of attitude issues, and are often side-lined as a result despite sometimes superior ideas, programming or algorithms as a result of personality.

Re:FINALLY

[sparkz]

Drepper, and glibc is also a big part of the G in GNU/Linux. The reason people fear upgrading glibc is that it is so central to the rest of the code they run on a GNU/Linux system. I don't know Drepper, or Schilling, or others, personally, but I respect the fact that they do far more than I do, and that they know far more than I do about libc level issues. I have been using GNU/Linux for 13 years or more, and in that time it has become perfectly clear to me how critical the work of people like Drepper are to the GNU/Linux ecosystem. Similarly, that is why the credit of GNU/Linux is so much more important that the "I heart Ubuntu" fanboy stuff. Sorry to be an old fart, but some of us care about design and engineering. Other people want pretty wallpaper. That's fine, Linux has plenty of room to accomodate both, and more besides.

Re:FINALLY

[DrSkwid]

> some of us care about design and engineering.

and you chose Linux? Time to review your metrics.

Re:Delicious

[ildon]

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

Efficiency?

[Tubal-Cain]

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

Re:Efficiency?

[Anonymous Coward]

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?

[TinheadNed]

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?

[Tubal-Cain]

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

Re:Efficiency?

[osee]

Interplanetary and interstellar void. Pretty cold place. As big as anything.

Even this UClibc would fit.

More context

[Anonymous Coward]

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

[dgatwood]

everywhere but this carp architectures

Seems pretty fishy to me.

Re:More context

[hardburn]

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

Re:More context

[Anonymous Coward]

I hadn't read the whole thread when I replied.

Looking at it more it seems like he's calling the ARM ABI crap because it breaks his brittle code which makes unwarranted assumptions about structure alignment and padding.

How is it that this idiot is working on something as important as glibc?

Re:More context

[Chuck Chunder]

At least Drepper wasn't being koi about it.

Re:More context

[Darinbob]

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

I'm still not sure that x86 is really an architecture...

Re:More context

[grcumb]

everywhere but this carp architectures

Seems pretty fishy to me.

I dunno, I think he has every right to be worried about how his cod scales.

Re:More context

[mikiN]

Nah, he's just thinking about Sturgeon's Law. Ninety percent of everything is crab.

downstream from debian

[C0vardeAn0nim0]

downstream we have many, many distros now adays.

so, if this eglibc becomes the default, it'll end up being the default in pretty much all debian based distros like ubuntu, mepis, xandros, etc.

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

Re:downstream from debian

[Mr. Underbridge]

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.

Re:downstream from debian

[TopSpin]

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:downstream from debian

[Randle_Revar]

it'll end up being the default in pretty much all debian based distros like ubuntu, mepis, xandros, etc.

I don't know if that is guaranteed. It would be easier to change, but they could choose to stay with glibc if they really wanted.

Now, if Fedora where to follow Debian in this, I think that *everyone* would follow sooner (Debian downstreams, probably) or later (likely SuSE, Slackware, others).

Re:downstream from debian

[Randle_Revar]

Oh, yeah, he works for them. I guess that make it less likely, but you never know... Or maybe RH will reconsider his position as maintainer.

For the greater good

[Rob Riggs]

That quote in the story is way out of context. Ulrich's words were:

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

As the maintainer of GLIBC, he has to be the steward for the greater good of all users. And sometimes that means pissing off a vocal constituency.

Re:For the greater good

[Anonymous Coward]

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

Re:For the greater good

[Jeff DeMaagd]

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

[Burkin]

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

Re:For the greater good

[Anonymous Coward]

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

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

Re:For the greater good

[BSAtHome]

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

Re:For the greater good

[Burkin]

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

Re:For the greater good

[Areyoukiddingme]

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

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

Re:For the greater good

[gbjbaanb]

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

[LizardKing]

He's not fit to write C.

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

Re:For the greater good

[ThePhilips]

Embedded architectures are never well designed. Their purpose is not to win "best design" award - but to be cheap and efficient.

Embedded systems are extremely high volume market. Sparing few transistors here there often saves $$$$$ when you get into shipment volumes with 4-6 zeros at the end. Software development is often one time effort, that's why such oddities (as Ulrich have complained about) with easy workarounds are quite common. Main savings are coming from actual H/W costs.

Re:For the greater good

[tyrione]

He's not fit to write C.

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

If I only had mod points for sarcastically insightful.

Re:For the greater good

[ihavnoid]

What is worse, is that the original code doesn't even looks like it is 'supposed to give better performance on x86'.

The code was assuming that struct alignments are done in four bytes. Good luck when it becomes something larger, because I guess it will increase to something bigger in a not-so-distant future.

Re:For the greater good

[TheRaven64]

Take his compiler away from him. He's not fit to write C.

We've known that for years. Glibc was is one of the main reasons I prefer to develop on *BSD. I wonder if that will change with Eglibc.

Re:For the greater good

[lgw]

I use Microsoft-onlt tools in a Microsoft-only shop these days, and I'd never make this mistake. You have to support both 32-bit and 64-bit systems, with associated difference in struct padding, in a Microsoft-only world too, you know.

Re:For the greater good

[noidentity]

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.

Yep, that's exactly what I figured was the problem, assumption that the hardware handles misaligned accesses. This kind of thing is used in memory copies and sometimes string routines. Seems simple enough; default to the portable variant that makes no unaligned accesses, and provide an #ifdef'd non-portable one that assumes unaligned accesses (and perhaps little-endian byte order). It would be sad if these techniques were wide-spread, rather than limited to a few core bottleneck routines.

Re:For the greater good

[imbaczek]

yeah, and we all know the universe couldn't handle THAT.

Re:For the greater good

[Blakey Rat]

And it wasn't *that* long ago that Windows had fully supported and debugged Itanium and Alpha ports, either. I'm sure Microsoft at the very least is keeping those CPU issues in-mind while working on newer kernels, even just in case some miracle happens and tomorrow everybody dumps their x86 computers for Alphas.

Re:For the greater good

[Flavio]

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

[Flavio]

s/glib/glibc/

Gnome's glib is actually very clean and readable.

Re:For the greater good

[lgw]

Microsoft has always supported (at least) two platforms internally, to avoid becoming Intel's bitch. If you support any 2 platforms, you've probably done most of the work to support a third you haven't thought of yet.

Re:For the greater good

[VGPowerlord]

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

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

[citation needed]

bconway posted 4 citations earlier.

Re:For the greater good

[LingNoi]

Maybe but look at this bug.

I have no previous knowledge of this guy however he looks like an emotional asshole who should be on daily wtf, not maintaining an important piece of software.

Re:For the greater good

[petermgreen]

The itanium port is still supported on server editions, just not on desktop editions.

Afaict the alpha and itanium ports were never supported on the same version. Alpha support ended with a win2K rc. IIRC itanium support was introduced with a late port of win2K.

Re:For the greater good

[Anonymous Coward]

I might use assert() to say that caller is an idiot.

Re:For the greater good

[shutdown -p now]

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.

The problem is that the code before the fix wasn't generic at all. It could break on any architecture, and, in fact, it isn't even guaranteed to work on x86.

Re:For the greater good

[Random Walk]

Duh. I have a simple measurement for libc lack of quality: the number of #ifdef's I need to work around library bugs or oddities. *BSD beats all large commercial UNIX (AIX, HP-UX, Solaris) and Glib combined. In all fairness, FreeBSD is better than OpenBSD, but both show the lack of developer manpower.

Re:For the greater good

[LizardKing]

Glib(sic) looks like preprocessor soup because it has to be portable and fast.

Then why does the libc in NetBSD not look like preprocessor soup - yet it still outperforms Linux?

Re:For the greater good

[ThePhilips]

Not many. I worked mostly with PowerPC/32 based ones and a bit with some (very) old ARM, x86 (Geode) and M68K.

CPUs themselves are fine. But architectures using them are more than often odd. While programming Linux drivers, I personally never had to deal with the peculiarities, as I was using commercially supported embedded distro (BlueCat, MontaVista) where most of the things were already taken care of. Diffing MontaVista kernel versus vanilla kernel was turning up many interesting things they had to do for some proprietary embedded architectures. Nothing not doable, yet it was quite eye-opening what tricks H/W manufacturers has to use to keep systems profitable.

Later on, I also worked for company which was producing niche proprietary embedded system based on PowerPC and M68K CPUs. It was also quite interesting hearing from H/W folks motivation behind throwing out some parts to save say $2.50, when in the end whole system cost something like $2000. Whatever was crippled in hardware (recurring cost) is quite easy to workaround in software (one-time cost).

Re:For the greater good

[petrus4]

Then why does the libc in NetBSD not look like preprocessor soup - yet it still outperforms Linux?

Maybe because the people working on the BSDs actually know how to code?

That's tended to be my hypothesis, anywayz. ;)

Re:For the greater good

[thaig]

They only have to make it work on netbsd, perhaps?

Re:For the greater good

[marcosdumay]

They only HAVE to make it work on netbsd, but they put all BSDs and Linux in it just for the fun.

Re:For the greater good

[julesh]

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.

Which is, of course, utter bollocks, as the change could have been wrapped in #ifdef _ARM ... #endif, at which point it would only have effected "this embedded crap".

Re:For the greater good

[mahadiga]

Since both are Open source, only users (and not developers) need to worry.

Re:For the greater good

[DrSkwid]

Plan 9 only manages [9 architectures](http://www.kix.in/plan9/mirror/sources/plan9/) and uses Mkfiles to specify the architecture to build for, no runtime CPU checking required, no pre-processor soup, totally readable source code, and you can debug code running on a different architecture across the network, even after it's crashed.

Yay!

[Omnifarious]

I've been wishing for ages for maintainership to be taken away from Ulrich Drepper. Every single bug report I've seen submitted to him has been shot down for some stupid, insane reason, even when it's been accompanied by a patch. He's a bad maintainer.

One example, I submitted and update to an EBCDIC encoding used on IBM mainframes. The encoding had several choices for what should be encoded as the newline character. It wasn't clear which one should be used, but the z/OS system I was using had definitely chosen a particular one. Glibc had chosen a different one. I submitted a patch that changed it and Ulrich rejected it saying that there wasn't a standard and so my version was no more valid than the version that was in the library.

And, on another case, it was clear that the /etc/localtime was being read for each and every field that was being printed in strftime. This both caused things to be slow, and it also created a race condition if that file was changed. I recommended to the person who found the bug that he submit it. He did, and Ulrich rejected it for some bizarre reason I can't recall.

He is an awful maintainer, and I really hope the project is taken away from him by this fork.

Re:Yay!

[Estanislao Mart�nez]

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!

[LaminatorX]

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!

[mwvdlee]

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!

[Omnifarious]

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.

Re:Yay!

[Blakey Rat]

The IBM implementation has to represent about 99.9% of all EBCDIC systems in existence. Ignoring it is just asinine.

Re:Yay!

[Randle_Revar]

I didn't realize there were modern EBCDIC systems out there. Kind of scary to think about.

Re:Yay!

[Omnifarious]

IBMs are backwards compatible to a degree that is almost insane. Programs that think they're working with rotating drums still work on a modern IBM mainframe.

Re:Yay!

[Eunuchswear]

What do you mean "the IBM implementation"? Which IBM implementation?

Check out IBM's list

Nearly 400 different versions.

Re:Yay!

[petrus4]

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.

Yes, but now we will go from a bash reliant libc, to a libc which will be impossible to port to any other distribution or platform because of the degree to which Debian will change it, in order for it to be compatible with that system. If I have to choose between bash or the Debian dev team as barriers to entry for libc portability, I'll take bash in spades. ;)

Re:Yay!

[ta bu shi da yu]

Sounds like there's a bigger issue at hand here. Surely there is a way of setting the EBCDIC code page to determine this? Is there something I'm missing?

Re:Yay!

[shallot]

One of them took me all of twenty minutes to clean up to make it functional with any POSIX shell.

Yes, but now we will go from a bash reliant libc, to a libc which will be impossible to port to any other distribution or platform because of the degree to which Debian will change it, in order for it to be compatible with that system.

You seem to be unaware of the actual meaning of POSIX shell - that's the common shell syntax the purpose of which is to make shell scripts portable.

I make a living on this embedded crap

[bzzfzz]

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

Re:I make a living on this embedded crap

[droopycom]

Really ?

Care to give names of products who actually use GLIBC and not uClibc ?

Re:I make a living on this embedded crap

[tyrione]

The iPhone and iTouch for two.

Re:I make a living on this embedded crap

[antime]

Apple don't use glibc in any of their OSes.

Re:I make a living on this embedded crap

[jonwil]

90% of Motorola's linux products (including the EZX and MOTOMAGX phone platforms) use glibc.

Re:I make a living on this embedded crap

[VGPowerlord]

I can see why he might be confused, though, as the Apple toolchain has gcc, autoconfig, automake, and autoheader in it.

Re:I make a living on this embedded crap

[midicase]

I develop "embeddded" systems for the broadcast industry. Most every piece of broadcast equipment in a satellite truck and cable head end system runs some flavor of glibc in Linux.

I quote embedded since it can mean different things to different people. We use a 233 MHz PPC processer with 128 Meg Ram which easily handles 60Mbit high-def streams. Relative to a modern desktop, our base system it is a bit light, but it's plenty enough to run the full glibc.

Re:I make a living on this embedded crap

[MrResistor]

I develop "embeddded" systems for the broadcast industry. Most every piece of broadcast equipment in a satellite truck and cable head end system runs some flavor of glibc in Linux.

I very much doubt that's the case.

I worked at Grass Valley until late 2004, and to my knowledge they had no products running Linux, and no plans to use it anywhere. There were a few products we inherited when Thomson bought Philips broadcast division that ran some flavor of *nix (Neutrino on Automation, and I don't recall what was on Spirit since I only had to deal with firmware and never actually saw a full system). Everything else used some proprietary embedded OS like VxWorks for the actual work, plus some NT variant for UI on the bigger systems like Profile and Kalypso.

I helped a friend do a presentation for SEMPTE recommending they consider Linux, and nobody seemed to really be into the idea (they had some strange idea that they could sue MS if Windows didn't function properly).

I'm sure Linux has crept into some products, but I'm fairly certain that claiming even a significant percentage of equipment in any broadcast facility runs Linux is a gross exaggeration.

"So what" vs "Wow, unbelievable"

[pla]

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"

[ArsonSmith]

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"

[PCM2]

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"

[Chris Burke]

And the developer has every right to make that call

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

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

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

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

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

[Anonymous Coward]

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.

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

[petermgreen]

Getting in a pissing match over support for an irrelevant feature doesn't inspire me with confidence in Debian's leaders.
You can call it irrelevent if you like but the fact is debian has always prided itself on wide portability. Debians own stats place the arm variants somewhere in mid-field users wise. Its way behind i386 and amd64, way ahead of ia64, mips, mipsel and s390 and in the same order of magnitude as powerpc and sparc.

It seems to me that eglibc is the result of the distros who care about arm realising that given upstreams current status inserting another layer between the distros that care about arm and glibc will reduce duplicated effort and probablly improve compatibility between arm distros.

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

[snaz555]

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 they're trying to change this and find glibc an obstacle.

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

[vlm]

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.

I guess you'd be surprised then. If an embedded developer wants a small, stable, flexible supported distro that works on a dozen or so archs, Debian's #1.

The fundamental problem is you don't understand what Debian is. It's not a top down corporate structure devoted to next quarters results. If a developer volunteers to work on embedded systems, how to you intend to stop them merely because you don't think he/she has been successful in the past? Good luck stopping them.

Such uses either involve a platform-specific lightweight distro where available, or the devs take a roll-your-own approach.

Big mistake. An embedded dev's job is to write a nice UI for their NAS box, not to replicate all the work of the Debian security team, or attempt to replicate the work the Debian sysadmin team did to set up the world wide mirror network.

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

You must not know much, if anything, about Debian. It's not a company. Its sort of an organized free software uniculture that operates in near total anarchy. Trust me, he's not going to get "fired" or written up.

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

[sjames]

Since by embedded crap, Drepper meant any ARM and Debian supports ARM, I wouldn't be too hard on Debian leadership for making the switch.

While it is Drepper's call, it's worth considering too that what he was doing there just happens to work. Nothing at all guarantees that it will (or even should) work with the next compiler version or on any given platform the toolchain gets ported to. The compiler is free to insert padding wherever it needs to for performance. His code depends in it not doing that, but fails to instruct it not to with the packed attribute (admittedly, a non-standard itself, but at least it's documented).

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

[Geoffreyerffoeg]

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

Check the eglibc home page. This isn't the only case where he's viciously attacked people who have pointed out bugs and sent him patches.

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

[dbIII]

It was just somebody lost and reporting a bug in the wrong place - pissing off the maintainer a little bit and resulting in a three line reply with an insulting middle line. Now we only get to see the insult without the suggestion of putting the code where it belongs.
If you look at the thread the bug had already been fixed two months before in the port where some thought it belonged (sysdeps/unix/sysv/linux/arm/check_pf.c) instead of in the main branch where the submitter thought it belonged.
Not only is this out of context it also is from two years back. It's as petty on Debian's part as it would be going off at RMS for his "linux? Never heard of it. Haha" comments for most of the 1990s. It's almost as petty as the Iceweasel squabble over the logo. I suspect that the person at Debian responsible for this petty press release should be a little more honest in their tantrums instead of cherry picking two year old quotes out of context.

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

[ToasterMonkey]

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.

Honest question, why should the glibc maintainer be concerned with which market Linux is strong in, or what direction it takes, or if there even is a Linux tomorrow? This seems to happen a often now, long time free software developers are basically ostracized for not putting Linux at the center of the universe or supporting its cause - whatever that is, and it most certainly is separate from GNU's goals. I'm not suggesting this particular problem is specific to Linux, you did that. In general though, this seems to be the case.

It also kind of makes you wonder if the OSS crowd realized that openness does not excuse you from the politics of dealing with throngs of people and instead exposes you to more of it.

Go ahead.. what if everyone, and I mean EVERYONE used OSS (more to the point, YOUR) software? Would testing requirements change? How would developers start responding to millions of user complaints vs. thousands? Could individuals realistically contribute in that environment with the higher testing costs (in time & resources)? The "don't like it, fork/write it yourself" model doesn't scale. The only way I can imagine it is if OSS development eventually evolves into a corporate-like hierarchy where responsibility and ownership trickle downward through multiple layers. We've already figured that out though.... *ahem* commercial software *cough* and people say that model isn't really open, even when it is.. OpenOffice, OpenSolaris, any OSS project with commercial backing pretty much. Maybe non-profit OSS organizations are the answer to this. They'd face the obvious problem of reminding everyone that free != free or find some other method of funding. Ugh, OSS really digs itself a hole leading people to think free == free. Good luck with that.

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

[shutdown -p now]

This bug I haven't seen linked to in the comments in this story yet, but it's another gem.

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

[Sam H]

The following survey disagrees with your perception of Debian not having a significant presence in the embedded market: http://www.linuxdevices.com/articles/AT7065740528.html . I suggest you back up your statement with relevant information if you wish to use it as an argument.

Also, Ulrich Drepper does not have "every right" to disregard the ARM platform as long as it is listed as a supported architecture. My request to the steering committee can be seen here: http://lists.debian.org/debian-glibc/2007/10/msg00038.html

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

[SharpFang]

Still, it was fixed in the port, leaving the trunk vulnerable, because it depended on assumptions about properties that can be changed. Also, the patch didn't impact performance of x86.

So not only he was wrong on both accounts (it did not at cost to supported architectures, and it didn't only benefit "embedded crap"), he was abusive.

In the other bug - the faulty /etc/hosts handling -

- He broke the standard
- He claimed it's the badly written apps fault when the bug occured, even when shown a scenario where two correctly written apps communicating with each other are affected.
- He claimed he has reasons to keep it that way instead of fixing it, stronger than reasons the bug reporter gave
- He refused to disclose his reasons (demanded money to disclose them)
- Upon examination it appeared his reason was a nanosecond saving in a once-a-hour function.

So, it wasn't just being abusive, or just wrong, or just lazy. That was a "La la la I don't hear you" style of stupid refusal to either fix your mistake or even allow others to do it for you.

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

[SharpFang]

"And the developer has every right"

Only when his claims are true.
In that case his statement was false on both accounts (that change would fix a potential bug on x86, and not affect x86 performance adversely).

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

[petrus4]

You must not know much, if anything, about Debian.

God, I love this. Anyone (and I mean anyone) who is in any way remotely critical of Debian, gets this response immediately fired at them from the cheerleading squad.

Kudos on the compelling argument there, Slick. Totally airtight, and utterly unassailable rhetoric. ;)

Re:Anonymous Coward

[Burkin]

Is that you Joerg?

I read the bug reports that he was pissed at

[cant_get_a_good_nick]

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.

Re:I read the bug reports that he was pissed at

[Minwee]

yanking your libc seems a bit much for a pissing match

That and it can make you go blind.

Re:I read the bug reports that he was pissed at

[Nimey]

On the other hand, this is Debian. If any major distro is going to get into a pissing match on principle, it's them.

Not Just for embedded devices

[John Goerzen]

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?

[pathological liar]

From eglibc's mission statement:

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

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

Re:API/ABI compatibility?

[mzs]

glibc itself does not stay binary compatible to prior versions, that itself is a real PITA.

Re:API/ABI compatibility?

[larry bagina]

From their faq:

the EGLIBC maintainers regularly merge GLIBC changes into EGLIBC.

Re:API/ABI compatibility?

[shutdown -p now]

They only need to do that until most Linux distros switch to eglibc, and only for glibc versions up to that point. After that happens, who will care about glibc?

Re:API/ABI compatibility?

[pathological liar]

People who pay for support for commercial software which only has glibc as a supported platform (which will be most of it for the foreseeable future.)

Re:API/ABI compatibility?

[SharpFang]

As long as GLIBC does things outright WRONG...

(say, your app, conforming to RFC, allows values at which GLIBC crashes?)

What an ugly situation

[erroneus]

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

[Areyoukiddingme]

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.

Re:What an ugly situation

[erroneus]

Debian goes and all Debian variants will follow. Many projects key strongly with Debian and so it is likely that projects like GNOME will follow. You can see how this could play out without thinking too hard.

Re:What an ugly situation

[petrus4]

I'll dispute that the OS will ever become irrelevant.

OSes won't become irrelevant, and UNIX in broader terms won't, but Linux itself might.

The kernel is 60 Mb compressed, these days. That's bloated as hell. Linus and friends are way too focused on the big iron that is being used by their corporate sponsors; the whole flap with Con Kolivas showed that.

The other real issue is that most of the people working on Linux are Windows immigrants who truthfully wouldn't be able to genuinely code their way out of a wet paper bag. As an overall design, Debian is absolutely terrible, although I know I'll get the usual fanboys in response to this, telling me I have no clue...and that's fine.

Ten years ago, we had a scenario where Linux was better from a code point of view, but the impediment in its' path was superficiality and intellectual laziness in the consumer.

That is no longer true, and we're threatening to head towards a scenario where code superiority to Windows isn't something that can be claimed as much as it used to be, as well.

- I keep hearing negative reports from all directions about KDE 4.

- As noted, the kernel keeps getting more and more bloated, with the kernel team's management turning a deaf ear to anyone who isn't directly putting bread in their jar. Three cheers for Free Software, eh? ;)

- Ubuntu's hardware support is generally good for about the first 5-10 minutes it takes for someone to run the installation routine, and after that, all bets are off. I've had sound randomly die for no apparent reason, with ALSA needing a complete reinstall, and my video card drivers developing weird problems as well. Then there were the number of other people I saw on the Freenode help channel with similar issues.

- The package management problem, contrary to mainstream perception, is most definitely NOT solved. Library issues with subpackaging still exist, and the reliance on precompiled binaries has proven bad for system robustness more or less in general, especially when you get novice users installing binary packages from different distros and expecting them to work together. Abandoning source compilation simply in order to satisfy idiots who demand instant gratification is not an appropriate response. If they don't want to do the necessary work for a quality system, let them go back to Windows where they belong.

Complacency is setting in, and the frantic, desperate, insanely irrational need to be a carbon copy of Microsoft Windows has also never been more chronic, or more damaging.

Re:What an ugly situation

[Areyoukiddingme]

You may not be wrong, but your arguments are self-contradictory. You lament the flakiness of hardware support just moments after complaining that the kernel (source) has gotten quite large. Where do you think the drivers are? You claim that hand-building every package in a system is the way to go, right after complaining about the kernel. You do realize that the binary of a hand-built kernel can be less than half a megabyte, right? Who cares if the source is 60 megs or 600 megs. If it builds to something you can still boot from floppy, for your system, you've got nothing to complain about. You complain that the kernel developers only listen to big iron manufacturers for servers, then complain that there's some frantic need to become a carbon copy of Windows, i.e. a desktop OS. Which is it? I think you need to reexamine your priorities. At the moment, you're as schizo as Linux development itself.

I agree, the state of sound support in Linux is miserable. It's been miserable for a decade and it's still miserable. The existence of OSS did nobody any favors.

I would argue that package management is less of a problem than the build problem. Building any given package out of the box can be very difficult. The autotools are a nightmare of epic proportions. When they work, you're golden, but when they don't, nothing can help you. The scons project is trying to address that (among others), but it's like tilting at windmills.

I do see problems developing because of the tug of war between the server-oriented Linux developers and the desktop-oriented developers. But so far, the server side of thing is still so far beyond anything Windows can offer that I don't really see this concern you have about being a carbon copy of Windows. It's physically impossible to administer a Windows sytem remotely over a slow dial-up modem. Problems develop faster than they can be solved at that speed. A Linux machine can still be administered at smoke signal bitrates. As for the desktop, Linux isn't there yet, no question, and it will take lots more source (the bloat that bothers you so much) to get there, but I foresee the possibility that Linux will be able to offer things on the desktop that Windows can never offer. ATI giving up hardware specs for its video cards opens doors. Somebody somewhere will be able to exploit that opening, and the results may be spectacular.

Or they may be like Linux sound. We can wait and see, or roll up our sleeves and participate, either way. Something will happen though.

Re:What an ugly situation

[Eunuchswear]

The kernel is 60 Mb compressed, these days. That's bloated as hell. Linus and friends are way too focused on the big iron that is being used by their corporate sponsors; the whole flap with Con Kolivas showed that.

What are you smoking?

# ls -l /boot/vmlinuz-2.6.26-2-686
-rw-r--r-- 1 root root 1505680 2009-03-26 09:22 /boot/vmlinuz-2.6.26-2-686
 
# ls -l uImage-2.6.22.18
-rwxr-xr-x 1 root root 1979292 May 8 12:49 uImage-2.6.22.18

That's 1.5Mb on my Core Solo laptop. ~2Mb on my ARM.

Re:What an ugly situation

[Eunuchswear]

Who cares about the size of the source? He was whining about bloat. If bloat isn't compiled into the kernel I'm using why should I care?

A rant

[jmorris42]

> 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

[Pieroxy]

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

[taniwha]

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:A rant

[jmorris42]

> 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:A rant

[tyrione]

BINGO! Your last two paragraphs nails it with specifics.

Re:A rant

[Bob The Cowboy]

Not patching at all is never be the answer.

Ok, I guess you're right ;o)

3c3
< 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.
---
> 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 the answer.

Re:A rant

[TheRaven64]

Correct me if I'm wrong, but doesn't that mean that the code will also fail on Alpha? It's been a while, but I seem to recall that Alpha required 8-byte alignment too. The surprise here is not that people have got fed up with Drepper, it's that anyone ever listened to him.

Re:A rant

[elfprince13]

Mod this man up. Ubuntu at least is getting a little better, but there was a while when with every new release would break something at a really low level on my system, like when they switched from /dev/hdaN to /dev/sdaN to just using volume id's right in a 2 year period, and I'd have to boot into another OS to edit my fstab. And I haven't found any distros where tutorials more than a year old are more likely to help than to screw something up.

Re:A rant

[elfprince13]

That probably wasn't correct context for "really low level" but you get my point.

Re:A rant

[BikeHelmet]

I just updated to the new Ubuntu, and now my SATA controller doesn't work. It corrupted a partition before I figured it out and put in an PCI card to handle my drives.

Unfortunately, now my drives are juggling around. /dev/sda one boot, /dev/sdb another boot!

Bless the new code. Who cares about backwards compatibility?

Re:A rant

[Blakey Rat]

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.

Ah, yes, that would be the CADT development model: http://www.jwz.org/doc/cadt.html

Also be sure to read Joel Spolsky's article helpfully titled "Things you should never do": http://joelonsoftware.com/articles/fog0000000069.html

Re:A rant

[LingNoi]

That's why I stick to the LTS releases.

Re:A rant

[cptnapalm]

I got what you meant and I agreed :) In the context of what you were talking about (a fully functioning system), that stuff is pretty low level.

Re:A rant

[smash]

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.

I think you're looking for FreeBSD. This is exactly what the freebsd-core team are for...

Re:A rant

[something_wicked_thi]

Have you considered that:

If it is a bug and someone has a patch for it you APPLY THE DAMNED PATCH

and

For every bug fixed it seems you get a fresh new one

might be related?

Re:A rant

[dkf]

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.

Some projects have worked that way for a long time. They still have bugs, but they tend to be of the "Oh, that probably shouldn't work that way" kind rather than the "Oh, that buffer overrun looked bad" kind. But it is equally important to keep on accepting new features; stagnation is death because developers abandon the project.

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?

I like the rule that "the code isn't done until it's got automated tests and documentation". Tests mean that new bugs are at least kept somewhat under control (even if they're not a proof of correctness, they at least catch silly errors) and docs mean that people can use it. And yes, it's often worthwhile hiring a tech writer to get the docs usable by people outside the group developing the software; it is far too easy to be blind to inexplicable quirks and odd workarounds...

Re:A rant

[jabjoe]

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?

Documen-what? Use the source Luke. This is big part why I love open source. Source is the ultimate documentation. I can read how anything I fancy works! Documentation is always going to have problems keeping up with the source. Source should be written to read (or at least refactored to read, or at least commented when neither is possible). I know it sounds crazy, but I honestly find http://source.winehq.org/ some of the best COM/Win32 documentation. It sometimes suffers from not matching the exact behaviour, or not being implemented, but that's about the same as msdn. ;-)

Just wish I could drop Windows entirely and still get paid....

Re:A rant

[UnknownSoldier]

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

It's called 'The CADT Model', one of the reasons why OSS sucks. Fortunately this one negative doesn't outweigh the (other) positives.

Re:A rant

[meander]

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

Try Debian Linux. There are 3 main flavours.

1) unstable - pretty much the latest software, has bugs, can crash.

2) testing - lasted in 'unstable' for awhile & survived. is pretty good for most desktops, rare crashes, but fairly up to date.

3) stable - tried and tested. stable, but usually an older version. use it when your system MUST work.

You can pick your own trade off between stability & the latest software. Personally, most of my system is 'testing', with a few favored applications from 'unstable' for the latest features. If they crash, you can always go back to the less feature full, but more stable option.

Re:A rant

[debatem1]

Documen-what? Use the source Luke. This is big part why I love open source. Source is the ultimate documentation. I can read how anything I fancy works! Documentation is always going to have problems keeping up with the source.

Opinions like this kill good projects. Document your damn code.

Re:A rant

[petrus4]

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!

This, very simply, is the entire problem.

Real technical quality isn't a priority to Linux people any more.

The only priority is emulating Windows as closely as possible.

Everything else is considered secondary to that, and the entire system continues to suffer as a result. Making "the desktop," the sole priority is going to end up destroying Linux.

Re:A rant

[jmorris42]

> Try Debian Linux. There are 3 main flavours.

Believe it or not, I do know a bit about Debian. And it sucks too from the quality standpoint these days. Allow me to demonstrate.

I have these old EPIA machines I'm repurposing. They will be off the net most of the time with occasional dialup access. I don't want to be seeing them back on my bench anytime soon. So that eliminated Fedora since F10 will go unsupported before years end. RHEL & clones are out since nothing new runs on an EPIA. (In their past life they ran WBEL3 just fine, but that's pretty old.) Ubuntu doesn't make it to the installer before going foom. Ok, Debian.

Nope. Debian 4.0 and 5.0.1 have something hosed in the name service. No network, no desktop. A minute and twenty seconds from entering name/password until the desktop appears because Nautilus is hanging for a whole minute. GDM does a similar but shorter hang everytime the login appears. Ain't deployable. I have been configuring TCP/IP, on linux no less, for going on fifteen years and I haven't found the problem in a few hours of config file twiddling, googling and even got desperate enough to pop into #debian. If I can't figure it out is safe to assume 90%+ of users won't figure it out and simply try something else. btw, Fedora 10 works just fine without anything in the network port.

But don't believe me try it yourself. Install a machine from a CD/DVD without anything plugged into the network port. Bring up the new machine and watch GDM sit and spin. Log in and watch Nautilus sit and spin. Dig out an old 4.0 install media and try again. Be appalled that something like that could make it into TWO stable releases. Debian 5 comes on 5 DVDs now instead of the 4 that 4.0 released, but while quantity has gone up quality apparently hasn't.

And I'm only picking on Debian because you brought it up like some sort of all purpose solution. I could rip on RH's stuff with more experience to make it more vicious. I could start by noting just how many totally different fracking print configuration systems they have shipped without finishing any of them.

Re:A rant

[BikeHelmet]

The old one is Via, and the new one is SiliconImage.

Re:A rant

[jabjoe]

I commented when it is needed. A pet hate of mine of is over commented code. Sane naming is much better than comments.

I'm not against a comment above the function explaining the function's roll. That doesn't get in the way.
And of course this is often for automatic documentation.
Wine I feel is an example of getting it right, not too much, not too little, http://source.winehq.org/

Anyone who duplicates code in comment form needs to be shot!
Can they not read code? If not, what the hell are they doing writing it!
I have see code so heavy commented you couldn't read the code. I've seen code where the function is called GetName with a comment telling you it gets the name. I wish I was joking.

Re:A rant

[debatem1]

commented code != documented code.

End users need docs too.

Re:A rant

[Ex-Linux-Fanboy]

No network, no desktop. A minute and twenty seconds from entering name/password until the desktop appears because Nautilus is hanging for a whole minute. GDM does a similar but shorter hang everytime the login appears.

OK, silly question: Why not remove GDM and Nautilus and replace it with XDM and KDE or some other desktop environment?

Another thought: If this is a DNS issue (I bet it is; you can find out if it is with strace), why not set up a DNS server on the localhost that does nothing but send some reply so these programs get the DNS reply they're waiting for. I have a tiny simple DNS server that might fit the bill if this is your issue.

Any reason we're not buying XP licenses and putting Windows XP on these computers?

Re:A rant

[mr_mischief]

In general you're right. In the specific cases of running some legacy closed-source application on top of Linux, you're wrong. Binary compatibility is really good when all you have is a binary copy of something. Binary compatibility of kernel modules isn't that important, sure. Binary compatibility of applications linked against your shared libraries within the same major version is.

Re:A rant

[jabjoe]

Users require very different documentation, as unrelated from the code as possible. I don't think anyone sane would argue against that can of documentation. The documentation I'm against is where it's the code in english form, that is stupid because it will never match the code, either because it will drift out of date or because it was what it was meant to do not what it does.

Re:A rant

[debatem1]

Users require very different documentation, as unrelated from the code as possible.

Depending on what kind of user you have.

The documentation I'm against is where it's the code in english form,

Its called literate programming, and smarter programmers than you or I swear by it.

that is stupid because it will never match the code,

then your programmers aren't doing their job- the code isn't complete until the docs are.

either because it will drift out of date or because it was what it was meant to do not what it does.

This last thing doesn't make sense to me. Could you clarify?

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

[GreatBunzinni]

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:

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

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

[elevator]

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

And this is from a single bug report alone.

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

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

[Anonymous Coward]

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.

Have you ever delt with glibc development, or do you base this on reading a single bug?

One thing Ulrich Drepper is NOT is incompetent. He is extremely competent, and if you boot Linux you're running a ton of his code. In fact, he is so competent he has keep maintainership for years despite his finely tuned confrontational style where he seems to know *exactly* the response to write that will create the worst reaction in whoever he is responding to. I know, it has happened to me, but luckily I'm out of that game for now. If I was still dealing with it day-to-day, like Debian glibc maintainers, it would drive me nuts too.

The other thing to consider is that glibc, being the base of pretty much everything else, can be like a candle to a moth attracting people who really, truely have no idea. This can become tiresome, and may explain why some of the elitism comes about. You don't want the real development lists turning into a Ubuntu newbie user forum.

I wish eglibc well!

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

[abigor]

I personally enjoy this old classic:

http://sources.redhat.com/ml/libc-announce/2001/msg00000.html

Scroll down to the thanks list, and read below. Not saying who is right or wrong here, but it makes for some funny reading.

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

[Vellmont]

Huh. I didn't read through the bug reports, but the few I've read through it didn't seem like there was any point where you you definitively say "Ulrich is wrong here". Bugs are sometimes a matter of perspective about where the problem lies.

If you ask me, his problem is he's a dick, not that he's "wrong".

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

[Nimey]

This guy sounds like even more of an asshole than TdR, and that's an accomplishment. Plus he's a whiny little bitch when he doesn't get his way.

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

[TheRaven64]

There's a big difference between Drepper and TdR: Theo is usually actually right when he's being an asshole. Drepper has no such excuse.

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

[BasharTeg]

It's pretty clear from a Google search and from the comments in bugs where this guy has treated people who are either trying to help or trying to report what they consider reasonable bugs like shit, that this guy is just a complete asshole.

What's great is now Slashdot has helped the world understand what an asshole he is.

I hope Redhat enjoys the great PR that comes from someone like this who acts like a total cunt and then signs "@redhat.com" to everything.

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

[lgw]

One thing Ulrich Drepper is NOT is incompetent.

If you're job is to lead a development effort, people skills are more important than technical skill. Being an asshole makes you incompetant. If you just want to be some asshole writing good code in the corner, you can do that, but that isn't waht makes a good project leader!

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

[larry bagina]

The morale of this is that people will hopefully realize what a control freak and raging manic Stallman is. Don't trust him. As soon as something isn't in line with his view he'll stab you in the back. *NEVER* voluntarily put a project you work on under the GNU umbrella since this means in Stallman's opinion that he has the right to make decisions for the project.

s/Stallman/Ulrich Drepper/g

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

[Spit]

Theo also fixes bugs.

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

[smash]

Having read that post, I can see why he's acting like some people consider to be "an asshole".

He's been fucked over by Stallman/GNU, hence his reluctance to fix bugs that he does not want to fix.

Have a read of the stuff linked to by the parent, and read between the lines.

Not to get into a religious flamewar on licensing, but what he says with regards to the GNU license makes sense to protect your own code from hostile takeover by RMS (by putting out a new version of the GPL).

I don't think he's an asshole per se`, he's acting like one because of reasons that (to him) are justified.

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

[Burgundy Advocate]

Not saying that Ulrich isn't an ass, but as far as Stallman: JWZ has had similar thoughts.

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

[blind biker]

We are aware. And we are aware that all the previous ones were genuine Ulrich abuse. I think the ones where he talks about paychecks are especially offensive.

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

[GreatBunzinni]

Have you ever delt with glibc development, or do you base this on reading a single bug?

I believe it is easy to understand that if this problem was limited to a single uncivilized reaction towards a single clueless user on a single bug report no one would ever seriously ponder the possibility of forking such a complex project.

One thing Ulrich Drepper is NOT is incompetent. He is extremely competent, and if you boot Linux you're running a ton of his code. In fact, he is so competent he has keep maintainership for years despite his finely tuned confrontational style where he seems to know *exactly* the response to write that will create the worst reaction in whoever he is responding to.

He is incompetent due to the very nature of his job. He is paid not only to write code but also to interact with all glibc users who may wish to contact the project due to any issue related to that particular software project. If his job involved being locked in a basement somewhere away from all traces of humanity where he would code to his heart's content without having any contact without the outside world then there wouldn't be any problem. But that isn't his job. He also needs to interact with users, communicate with them, listen to what they have to say and handle cases where a party in that interaction is wrong in order to get a positive outcome. Moreover, due to the very nature of his job he is also assumes the responsibility of being a sort of public figure of that project responsible for public relations and the project's image.

Due to that, if someone in that position happens to be an antisocial moron who can't help being a dick... That person will end up making the project look bad and suffer the consequences that his own moronic actions cause. That's what makes him incompetent. Due to the nature of this project, being an antisocial moron makes you unfit to be in that position, as much as being a great PR person without any noticeable programming skills would also make that project suffer, although in different ways.

I know, it has happened to me, but luckily I'm out of that game for now. If I was still dealing with it day-to-day, like Debian glibc maintainers, it would drive me nuts too.

If a company pays someone to work in a project and his antisocial behaviour leads the company's clients to not only run away but also start off a competing project, would that employee still be considered competent? He would be fired on the spot. That's what is happening with glibc.

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

[GreatBunzinni]

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

Thanks to point it out. When I started copy/pasting the quotes I made sure to look at the email address to see if it was a redhat one but after browsing the first half dozen ones it got so repetitive that I started paying attention only to the name. Damn laziness :D

Once again, thanks for pointing it out.

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

[petrus4]

Due to that, if someone in that position happens to be an antisocial moron who can't help being a dick... That person will end up making the project look bad and suffer the consequences that his own moronic actions cause.

Autism is very often about specialisation. Have a look at the proverbial mathematical savants. They're unbelievable with mathematics, but their entire neurology is so strongly specialised towards just that one ability that they very often can't communicate at all, and sometimes can barely feed themselves or do other things either.

That is possibly the case with Ulrich. (and maybe Theo as well, I don't know)

In other words, if he genuinely is a Godlike programmer, it is possible that his brain is so specialised towards tasks in that one particular area, that he simply doesn't have the neurological resources left to be able to communicate effectively as well. Meaning that while he might be great to have in a coding position, Red Hat might also have to hire someone else next to him as well, in order to handle the actual PR side.

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

[flameproof]

If you think that's funny, try juxtaposing this against the whole idea of "community driven software". Drepper makes his own brand of Personal Fascism sound like his god-given duty while seemingly giving nodding support to Arm at the same time:

"The OS (kernel + everything else) has been ported to many architectures. While I don't care a bit about it, I concede that having it available for some embedded architectures like Arm is useful."

Seems he's updated his Mussolini-esque personality - or opinion - since 2005!

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

[HunterZ]

My favorite part is when someone tries to defend him and gets yelled at too:

------- Additional Comment #26 From Ulrich Drepper 2008-07-08 03:28 -------

Stop reopening the bug. And this is also no discussion forum. Go somewhere else.

------- Additional Comment #27 From Paul Wankadia 2008-07-08 04:48 -------

I concur, Ulrich. This bug has been discussed to death and only the trolls are
reopening it. If anyone wishes to "me too" this bug, please open a new bug.
Thanks.

------- Additional Comment #28 From Ulrich Drepper 2008-07-08 05:08 -------

Stop commenting.

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

[badkarmadayaccount]

<xml><Theo De Raat><joke>Shut up, Linus, go break your drivers again or something.</joke></Theo De Raat></xml>

Re:Imagine

[Culture20]

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.

Doesn't matter

[0xABADC0DA]

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

[Code Master]

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

Re:Doesn't matter

[TheRaven64]

Maybe someone should port one of the BSD libcs to Linux. There are two things I hate about developing on GNU/Linux: the kernel (with its stupid 'lets dump everything in a text file and make the developer write a different parser for every architecture interfaces) and glibc (with its weird interfaces that change depending on random, semi-documented, #defines, its old bugs, and its lack of several useful functions). Porting a BSD libc would fix half of that.

Re:Doesn't matter

[lgw]

Having space available is simply no excuse for bloatware. Good code is tight. Bloated code is crap. It's fine to not *care* that code is crap, because it's crappiness doesn't affect you (err, unless you're the package maintainer!), but don't try to claim it's not crap.

Re:Doesn't matter

[tyrione]

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!

I have hundreds of multi-byte binaries that could sure use the trimming.

Re:Doesn't matter

[mzs]

Seriously, somebody mod this up.

Re:Doesn't matter

[mzs]

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:Doesn't matter

[Hatta]

If you've ever had to deliver a non-OSS binary for linux you know what I'm talking about.

Well don't do that then.

Re:Doesn't matter

[xiaomai]

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.

Actually, I think that Redhat pays Ulrich to work on glibc.

Re:Doesn't matter

[raynet]

I tried to up mod but didn't have enough memory

Re:Doesn't matter

[mr_da3m0n]

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

If that's the case then you don't use glibc anyways, you use uClibc or dietlibc. At the very least that seems to be what most embedded systems are doing nowadays.

Re:Doesn't matter

[petrus4]

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.

Yep. The GNU monoculture at work.

Re:Doesn't matter

[Anonymous Coward]

for the sole benefit of this embedded crap?

Re:Doesn't matter

[MikeBabcock]

OMG, do you live in a country that only has 1 litre of gasoline left? Why do you care if your car uses 10 or 50 gallons per trip?

Efficiency is often worthwhile just for its own sake. There's no reason to make a fifty line program compile to a megabyte in size because it linked against the C library, just like there's no reason for a car to use 50 gallons of gas to get you to the corner store.

Re:Doesn't matter

[tepples]

If you've ever had to deliver a non-OSS binary for linux you know what I'm talking about.

Well don't do that then.

Do you know of a workable business model for OSS video game development and publishing, other than online-only games?

Drepper's comments ..

[SlashDev]

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

Re:Anonymous Coward

[profplump]

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?

Re:GLIBC is the cause for all binary incompatibili

[phantomlord]

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

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

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

Re:Imagine

[C0vardeAn0nim0]

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.

Re:Inmates running the asylum much?

[Cramer]

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.

Re:GLIBC is the cause for all binary incompatibili

[Tubal-Cain]

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

BSD does.

Re:Delicious

[Poltras]

Does he have 6 fingers on his left hand?

No - it's people who don't read.

[thaig]

It seems that he was completely correct in this case, if you read what he says. Oh, but you didn't . . .

Re:No - it's people who don't read.

[Rycross]

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.

Re:No - it's people who don't read.

[tyrione]

It seems that he was completely correct in this case, if you read what he says. Oh, but you didn't . . .

I read what was said. The guy was unresponsive until the point where RedHat stepped in and had to negotiate a deal with another company regarding this issue. It was then that the ahole gave any useful feedback.

Re:No - it's people who don't read.

[Max Littlemore]

No he wasn't, and I read the whole thing.

No explanation in comments, documentation or the bug report. He was specifically asked for an explainaintion and he effectively said "I couldn't be bothered, fuck off". When he did finally implement a fix, having ignored valid patches provided, he didn't mark the ticket as fixed, he just pretended the ticket didn't exist and there was never a bug. He even insisted he be paid to fix it.

There is absolutely nothing correct about this action as a maintainer of an important library. He deserves every piece of shit that is thrown at him, and then some. Someone with this attitude has no place as a maintainer - this case clearly illustrates the difference between a benevolent dictator like Linus Torvalds and an incompetent loon like Robert Mugabe.

should I s/he/you/g on this post? You seem to be jumping to his defence throughout the comments here by making assertions and not bothering to back them up. Are you in fact him?

Re:No - it's people who don't read.

[remmelt]

You know, you can also be right without being a total asshole.

Re:GLIBC is the cause for all binary incompatibili

[Nutria]

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

I can't remember the last time I had to compile from source. It was a long, LONG time ago.

Some of Ulrich Drepper's finer points

[bconway]

From TFA: 1 2 3 4

Re:Some of Ulrich Drepper's finer points

[Dahamma]

Wow. #2 actually had me laughing out loud. That's pretty unusual for a bugzilla report :)

Re:Some of Ulrich Drepper's finer points

[oldhack]

Yep, I second #2 (haha) - good stuff.

Re:Some of Ulrich Drepper's finer points

[Stiletto]

From reading those posts, it is pretty clear that this guy seems like a total douchebag and in my view has no business maintaining any serious open source project, let alone something as important as glibc.

Particularly #3. Someone finds a bug, submits a patch, and in return gets mocked for their effort. How great.

Re:Some of Ulrich Drepper's finer points

[fm6]

I just wrote this post defending Drepper, but now I take it all back. It's perfectly reasonable to expect a maintainer to explain his actions. Responding with "you don't write my paycheck" makes him an asshole, pure and simple.

It occurs to me that Redhat does pay Drepper's salary. I assume that he gets to maintain glibc because they're donating his time? I'm sure they know, even if he doesn't, that donating resources to an open source project does not give them ownership of said project. If I were one of these frustrated developers who's tired of Drepper's BS, I'd find out how his boss is and have a word.

Re:Some of Ulrich Drepper's finer points

[Dahamma]

Responding with "you don't write my paycheck" makes him an asshole, pure and simple.

Yep, and the comment "Paid $1 via Paypal. Please fix" was my favorite response!

Re:Some of Ulrich Drepper's finer points

[Profane MuthaFucka]

He's not just screwed himself, but he singlehandedly made RedHat just a little bit more irrelevant. They should terminate him.

Re:Some of Ulrich Drepper's finer points

[mati.stankiewicz]

They should terminate him.

Sending robots from future just doesn't work.

Re:Some of Ulrich Drepper's finer points

[Just Some Guy]

Particularly #3. Someone finds a bug, submits a patch, and in return gets mocked for their effort. How great.

Side note for anyone who actually wants strfry to be statistically valid: the fix doesn't completely fix it.

Suppose that __random_r returns a value between 0 and 9, inclusive. Suppose than len is 8. In that case, j %= len maps to:

old new
---+---
0 | 0
1 | 1
2 | 2
3 | 3
4 | 4
5 | 5
6 | 6
7 | 7
8 | 0
9 | 1

In this example, 0 and 1 occur twice as often as any other value. The fix for this problem is to pick a threshold close to 2^31 that is a multiple of len, and keep requesting values for j until you get one less than the threshold. Then you'll get an even distribution on j %= len.

Re:Some of Ulrich Drepper's finer points

[fm6]

Does too. The Terminator franchise has earned millions so far.

Loki Software? Yeah.

[KingAlanI]

My copy of Railroad Tycoon II for Linux wasn't working at all, on Ubuntu 8.04, obviously 2.6.something [I did try Ubuntu forums, they didn't have a working answer either]. Well, at least I won't bother on 9.04 either...

Since that didn't work, I visited a certain Swedish website for the Windows version, and that worked just fine on my XP box.

Re:Loki Software? Yeah.

[jguthrie]

I could never do anything in Railroad Tycoon II except run out of money, but I was just running Civilization: Call to Power last night on my 64-bit Debian box last night, so what's all this noise about nothing working?

Re:Loki Software? Yeah.

[phantomlord]

RT2 is working on AMD64/glibc 2.9 (multilib) under Gentoo with no extra (old) libraries needed for me.

Debian forks glibc, Drepper forks Debian

[David Gerard]

[To be posted tomorrow, probably]

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

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

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

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

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

Re:Debian forks glibc, Drepper forks Debian

[Randle_Revar]

That's awesome. Mod parent up!

Re:Debian forks glibc, Drepper forks Debian

[David Gerard]

This could be the most obscure string of geek jokes ever written. It makes GNUphone seem comprehensible to outsiders.

Re:Debian forks glibc, Drepper forks Debian

[hduff]

This could be the most obscure string of geek jokes ever written.

Laughed so hard I hurt myself.

Then I realized I understood all the jokes and that scared the s**t outta me.

Re:Debian forks glibc, Drepper forks Debian

[gbarules2999]

the intersection and union of the GPL, LGPL, CDDL, MIT and the thing TuomoV wrote for Ion.

This ranks among the best lines ever uttered by a Slashdot poster.

Re:Debian forks glibc, Drepper forks Debian

[David Gerard]

Final version up now. More hopelessly obscure geek jokes!

Re:Debian forks glibc, Drepper forks Debian

[marcosdumay]

"run EMACS on the HURD kernel and be operated by writing eLisp macros on the fly"

From the GnuPhone

Man, I'm hurting for one of those :) And also scared, of course.

Re:Debian forks glibc, Drepper forks Debian

[badkarmadayaccount]

Actually a LGPL-like variant of CDDL and/or with GPL v.2 exception clauses, with some Anti-DRM measures from GPL v.3 would be just what the doctor ordered for a non-fractured community. Possibly with LaTeX license clauses. I'm completly serious. Also, could somebody explain the above joke? I only understood parts of it.

As far as possible!

[CarpetShark]

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.

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.

contentious project manager with a god complex?

[nurb432]

He friends with Theo perhaps?

( its a joke, laugh )

Re:contentious project manager with a god complex?

[Anonymous Coward]

The funny thing is that he’s not friends with Theo. Theo tried to make strlcpy and strlcat the de facto standard, in order to reduce the number of buffer overflows, but Drepper famously rejects them as “horribly inefficient BSD crap.”

When I saw this interview, where Theo complains that “one person decided to be difficult,” my immediate thought was Drepper.

Re:contentious project manager with a god complex?

[petrus4]

Personally, I call it Hundred Acre Wood Syndrome.

Most autistics *do* tend to have our own internal/mental reality, and it of course goes without saying that we're the God of that, and so sometimes it gets difficult for us to get used to the idea that just because we are internally, that doesn't mean that we can be Christopher Robin in the outside world/consensus reality as well.

No, Ulrich Drepper's response was appropriate

[tetromino]

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.

Re:No, Ulrich Drepper's response was appropriate

[Anonymous Coward]

Anyone is free to waste his/her own time. Applying a patch takes a trivial amount of time in any sane project. If someone wants to fix an easter egg, I say let them.

Re:No, Ulrich Drepper's response was appropriate

[Mr. Slippery]

Applying a patch takes a trivial amount of time in any sane project.

Performing the necessary configuration management, code review, and regression testing -- for a patch is non-trivial in any responsbily-maintained project.

Re:No, Ulrich Drepper's response was appropriate

[danieltdp]

An explanation like yours would go miles ahead of ulrich's. The guy is an asshole

Re:No, Ulrich Drepper's response was appropriate

[antime]

So it shouldn't have been a problem to apply it to glibc then.

Re:No, Ulrich Drepper's response was appropriate

[miro f]

Who cares what the original intent of the function was, if there's a function with a bug it should be fixed. There could be any number of valid uses for this particular function and there's no reason to ignore a patch when it's been nicely provided for you.

Re:No, Ulrich Drepper's response was appropriate

[Just Some Guy]

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.

Oh, really? There's no mention of that in the man page, and if it's there and documented as a working function, then it should damn well work as advertised.

Shit like that is just embarrassing. How am I supposed to advocate this stuff to my boss with a straight face? What other "in jokes" am I missing out on and accidentally relying on because no one bothered to tell me not to?

Re:No, Ulrich Drepper's response was appropriate

[julesh]

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.

Funny, the function's man page doesn't say it's a joke. Nor does it warn developers that the function is deprecated. As long as this is a documented, non-deprecated function _it should work_. And when you have somebody submit a patch to fix a potential issue with it, you don't insult them. That's just good manners.

Re:No, Ulrich Drepper's response was appropriate

[finite_automaton]

What other "in jokes" am I missing out on and accidentally relying on because no one bothered to tell me not to?

memfrob(3)

Re:No, Ulrich Drepper's response was appropriate

[Just Some Guy]

But how would I know that was someone's idea of a joke? It's a documented function for hiding strings - it says so right in the man page. Suppose I needed to hide a string, found that, used it, hit a bug, and sent a patch to Drepper. What indication would I have that I was wasting his time with a nonsensical fix?

Re:GLIBC is the cause for all binary incompatibili

[mzs]

Wow this should have not been modded as flamebait. We should have simply addressed the better ways to do what the AC suggested. Honestly Linux is pretty decent about being backwards compatible at the syscall level. What is a real PITA is how glibc and libstdc++ do not remain backwards compatible. The BSDs do a much better job of backwards compatibility, and Solaris does an exceptional job. I just simply think that the Linux people do not care so much about that sadly. There were some backwards compat issues that made sense (like teh move from COFF to ELF and the broken relocation types originally used in ELF) but others have not made sense:

Yet again changing the relocation types.
Various times the C++ library broke backwards compatibility.
Various times that glibc broke backwards compatibility.

Also what is up with changing the options to programs in /usr/bin willy nilly?!

FUCK

[that_itch_kid]

Can we PLEASE get the moderation confirm button back!?!?!?!

Re:FUCK

[MrNemesis]

Doing things with two clicks is SO web 1.0 - with One-Click Moderation you're a part of the new and exciting world of up-to-the-minute moderating technology. Here at Slamazon we're always looking to ways to improve your ability to incorrectly moderate reactionary posts in an apparently successful attempt to court controversy and flamewars.

Note to marketing: please don't mention how reading a thread on slashdot 2.0 now requires eleventy billion clicks and sliding ineffable slidey things around, instead concentrate on how users need no longer tire themselves with the appallingly stone aged scrollwheel.

Coming soon... the AutoTroll-a-tron!

Re:GLIBC is the cause for all binary incompatibili

[VGPowerlord]

I can't remember the last time I had to compile from source. It was a long, LONG time ago.

In a galaxy far, FAR away?

Re:GLIBC is the cause for all binary incompatibili

[Nutria]

In a galaxy far, FAR away?

Vainly humorous as your comment is, the answer is "no". Been living in the same house since I started using Linux.

Re:If only that ol' .so library can be recognized

[phantomlord]

Linux death 2.6.29-gentoo-r3 #1 SMP Wed May 6 00:04:53 EDT 2009 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 4400+ AuthenticAMD GNU/Linux
gcc version 4.3.3 (Gentoo 4.3.3-r2 p1.1, pie-10.1.5)
GNU ld (GNU Binutils) 2.18
glibc 2.9_p20081201-r2

I've got a dozen or so Loki games installed and all of them work despite me being on AMD64 (with multilib). No chroot required, though a few of the games require you to load them with the old ld-linux.so.2

$ cat bin/smacx
LD_LIBRARY_PATH="/usr/lib/Loki_Compat/" /usr/lib/Loki_Compat/ld-linux.so.2 /usr/local/games/smac/smacx.dynamic &

Re:GLIBC is the cause for all binary incompatibili

[ishobo]

and Solaris does an exceptional job.

Indeed. I have a client that is running an application on SunOS 5.10 that it wrote in 1994 for 5.3. That is one of the major selling points of Solaris. I am simply amazed that it is readily dismissed by the Linux camp.

Yay!

[seebs]

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

Drepper in a rant vs RMS

[cptnapalm]

In a 2001 rant against RMS (on which I take no stand here) he wrote this:

Despite what Stallman believes, maintaining a GNU project is NOT a privilege. It's a burden, and the bigger the project the bigger the burden. I have no interest to allow somebody else to tell me what to do and not to do if this is part of my free time. There are plenty of others interesting things to do and I'll immediately walk away from glibc if I see a situation like this coming up again. I will always be able to fix my own system (and if the company I work for wants it, their systems).

Re:Drepper in a rant vs RMS

[gatkinso]

>> I'll immediately walk away from glibc...

Promises, promises.

That bug report was well worth a read

[Chrisq]

I,m surprised that this isn't quoted by Microsoft as a "typical" example of cooperative open-source development.

Re:That bug report was well worth a read

[MikeBabcock]

Its pretty typical of a whole class of self-important programmers around the world, many of whom write very good software most of the time but can't deal with other people.

Re:That bug report was well worth a read

[mr_mischief]

Many of them became so skilled with computers because they isolated themselves from people. Then, they find that they are working with other people on the software and are ill-prepared for it.

Embedded work leads enlightenment.

[gwythaint]

The great thing about "embedded crap" is that working on it leads to a greater understanding of how to program for desktops.

even strfry is apparently being used

[slashbart]

Joke?
Maybe not, maybe someone used that strfry function for some statistics demonstration code, and found out that it had statistical anomalies.
Instead of being glad that someone finds bugs in his code (apparently that person was using strfry) and even proposes the fix for him, he gets all snotty and offensive.

I think mr. Drepper should not be in a position as public leader of a project like this. Maybe they can put him in a cage with a high end computer or something, but the job of package maintainer also requires people skills, and an overall understanding of what the package is actually used for (including embedded and strfry apparently).

ARM design is way better than x86

[slashbart]

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.

Re:ARM design is way better than x86

[badkarmadayaccount]

Yeah, right. I agree, x86 is crap, but ARM ain't any better, it's like five or 6 ISAs have been dropped on the same die. The only good parts are mostly inside, except for the cool IF instruction that saves a lot of branching. I wonder if someone will get rid of the cruft, and add a do instruction that performs an instruction from memory without flushing the pipeline...</tangent>

Re:ARM design is way better than x86

[slashbart]

Funny. I programmed assembly on the original ARM processor (on the Acorn Archimedes). That instruction set was by far the cleanest that I've ever seen on any cpu. Pure risc. Apparently things have gotten uglier since.

Re:ARM design is way better than x86

[badkarmadayaccount]

Precisely. I'd say the prettiest assembler these days belongs to MIPS and SPARC, and maybe the Alpha (these days — ROFL), but I've never gotten lower than C, I just dabble, so I'm not an authority. OK, dabble a lot.

Re:Imagine

[David Gerard]

RHEL doesn't use vanilla glibc either.

G as GNU, but not eG as Exception-based license

[philtmp]

No, eGPL is not the license you're looking for... move along soldier... eGlibc is not related to ethical licensing scheme that will ruin the empire.

Re:G as GNU, but not eG as Exception-based license

[philtmp]

got a comment that I should link to the eGPL site: http://www.egpl.info/

Re:GLIBC is the cause for all binary incompatibili

[TheRaven64]

The BSDs generally have good backwards compatibility too. The FreeBSD kernel, for example, only changes interfaces with a new major version number, and in this case provides a compatibility module that exposes the old interfaces and provides a mechanism for using old versions of libc and so on. It uses the same set of techniques used to run Linux binaries on FreeBSD (somewhat ironically, it's often easier to run old Linux binaries on Solaris or FreeBSD than it is on Linux).

Any alternative to Glibc is a good thing

[petrus4]

In my experience Glibc is a bloated, flakey, temperamental mess, at least as far as trying to compile it from source is concerned. Admittedly, the recent version used in Linux From Scratch gave me probably the single smoothest compile of it I've ever had.

There were times in the past, however, that were nowhere near as trouble-free; especially when the LFS people made the horrible mistake of using Glibc builds from Red Hat's CVS. It would need patch after patch, and 3-4 times stopped dead partway through the compile for reasons that hadn't been documented (or apparently foreseen) by the LFS people, meaning I'd have to Google the errors and pray to God that someone had uploaded diffs somewhere.

Debian isn't exactly my favourite distribution, to be totally honest; but although they seem to be even more offensive than I myself manage to be most of the time, (which is no mean feat, I might add ;)) this may perhaps be their first internal fork which is actually based on logical sense.

A new libc is something which Linux has needed for quite some time now, and getting one is only going to be a blessing for all concerned. It would be nice if said new libc were also BSD licensed; but one can't have everything, I suppose. ;)

All the world's a VAX!

[argent]

All the world's got 32-bit twos-complement integers aligned on a 4-byte boundary, right?

That's exactly the kind of person I want supporting a portable runtime library. Not.

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

[petrus4]

[ ] You know that a lot of that answers were posted by Trolls that somehow smelled the fish.

(Tip: Move mouse over link after "From", look at href, know "mailinator.com", understand.)

Wow, Ulrich. I would have thought it almost certain that you'd have a Slashdot account.

Hi, by the way. ;)

Can someone explain his good points?

[Dan Ost]

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.

Re:Can someone explain his good points?

[virtual_mps]

For all the bitching about glibc, it works very well. I'd guess that most of the people complaining in this thread don't really know what they're talking about. (E.g., the complaints about ABI compatibility, which is really quite good.) And glibc has been improving over time, not getting worse. (That's not to say that there are no valid points, but the pile-on is way out of control.)

Re:People still use Linux?

[petrus4]

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

Are you stupid or just slow?

For some of us, it's because we're cheap bastards who can't afford a Mac.

For me, it's because while I'd be a lot happier simply using FreeBSD, (it has a license I like a lot more, and it's better technically in just about every respect other than hardware support) that would be boring. I'm addicted to pain and suffering, so I need to single handedly try and write solutions for what I perceive to be Linux's problems, which probably nobody will ever use, rather than simply using a system where all of said problems are already solved instead.

For the rest, however, it's because they're card carrying members of the cult of the GNU. In some ways, Linux has less in common with an operating system, and more with the Church of Scientology.

Re:If only that ol' .so library can be recognized

[MikeBabcock]

Excellent example. I'm sure a number of the whiners have never dealt with the hell that was shipping the proper version of MFC42.DLL with the application because Microsoft couldn't be bothered to figure out versioning their libraries.

There's also the issue of. . .

[JSBiff]

New lines of netbooks or very cheap/low power desktops that some manufacturers are interested in making, which would be based on ARM and probably run Linux (or maybe *BSD). Support for ARM looks like it is very important for that market. Those are, arguably, mass market 'desktop' systems, which just don't happen to be based on x86 or PPC.

Then there's things like mobile phones and others.

I can't see for the life of me why a developer would dismiss the embedded market as not needing glibc to work correctly on it?

Get either the FSF or Fedora on board

[Khopesh]

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

[thaig]

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.

Re:GLIBC is the cause for all binary incompatibili

[IntlHarvester]

Funny that you read "basement-dweller" and automatically assumed the comment referred to yourself.

Re:He's a nexus so he'll always make someone unhap

[marcosdumay]

"But I have little respect for the moaners on this thread. Fork and do the work yourself if you're not happy."

Lokks like they did exactly that. Why so little respect?

Re:He's a nexus so he'll always make someone unhap

[thaig]

There are lots of comments on this thread from people who didn't take the responsibility of starting a fork.

One can't value their complaints all that highly because they didn't care enough to take up the burden themselves.

As for eglibc, good for them and we'll see how they get along.

Re:If only that ol' .so library can be recognized

[mr_mischief]

Shipping the proper version -- and putting it in a private directory -- would have been nice back in the dark days of Win95 and Win98. I'm betting many software houses never had to deal with the further hell of specifying in which order applications needed to be installed, and which DLLs needed to be hand-copied back into place in DOS mode after the last of them. The desktop consultants in the field wrote manuals for the IT staff about how to build disk images for their users because installing two applications in the wrong order would break the earlier one altogether. Everyone figured out the "proper" DLLs to ship, and then overwrote everyone else's "proper" versions anyway rather than keeping them separate.

If you can't version, don't share promiscuously. Make a shared copy for all of your own applications, perhaps, but don't stuff a particular version of a library another software house is using into a common directory.

Let me see if I understand this....

[borgheron]

He's refusing to break other architectures so that a fix for ARM can go in? Umm... okay.. it sounds to me like the fix was probably not up to snuff.

It sounds to me that to fix the problem rather than forking would be much easier. Right now I'm forced to wonder if the fork breaks other things. I'm also now concerned about possible incompatibilities with my project. I suppose since it's ABI compatible there should be no problem, but I've heard promises like that before. Only time will tell.

Why exactly is he being crucified for this and, also... why is he being taken massively out of context on slashdot?

GC

What!!! What about WinCE?

[tjstork]

Actually, for Windows applications that are written by rules, using all the proper types of things, then yes, a Windows C app should recompile for ARM without too much of a problem and actually work.

In fact with the old Embedded Visual C++, you could target multiple CPUs and it would compile them all out. For a dumb checkers game I wrote, I had a release for ARM and a release for some other weird PDA chip, and it all just worked.

The biggest problem that most people would have in Windows apps, me thinks, would be if they were using native SDK code and they had rolled their own stuff for unpacking LPARAM and WPARAM. But, if you used the SDK macros for everything, used the macro types like LPSTR and LPCSTR and WORD and DWORD and the Windows structures for stuff, I would fully expect a recompile would just work out of the gate.

Hans was an asshole too.

[tjstork]

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

So when do you think he's going to chop his wife up, accidentally lose the passenger seat to the car, and get caught trying to leave the country with $4000 in cash?

Re:Hans was an asshole too.

[fm6]

Let's see, you're lumping casual rudeness with total inability to hold a real conversation. And you're lumping both with beating somebody to death. Oversimplify much?

Re:An execution manager would be nice.

[DrSkwid]

or you could just statically compile, shared libraries should be dead by now

Political as apposed to problems with glibc?

[PalmKiller]

What Ulrich Drepper was saying sounds bad in the quote, but it is pretty much correct, he could have said it nicer but if that is is opinion he has a right to voice it, ... that Politically Correct crap is for the birds. He does the base x86 version, another does the version ported to arm that is in the ports collection, so basically they just reported the problem to the wrong person then got upset when they were told he didn't care. So I do not see a problem with glibc in general, but in politics and/or general care and feeding of the Debian developers.