Submitted by Via LWN, we found a blog post of a Debian maintainer which announces a new package: EGLIBC, a compatible reimplementation of the GNU glibc which “which will soon replace the GNU C Library”. Apparently the primary reason is the sadly famous bad maintainership aptitude of Ulrich Drepper, the main libc maintainer.
The blog post explains that even though EGLIBC is primarily aimed at embedded architectures it still has some very favourable features:
- More friendly upstream (especially with regard to embedded architectures): “Encourage cooperation, communication, civility, and respect among developers“; (as opposed to this).
- Stable branch with fixes for important bugs (a real one, not like the GLIBC one which is left unchanged).
- Better support for embedded architectures.
- Support for different shells (GLIBC only supports bash).
- Support for building with -Os.
- Configurable components (do we really need NIS or RPC support in debian-installer?).
- Better testsuite for optimized or biarch packages.
EGLIBC is source and binary compatible with the original GLIBC, and the package names will remain the same (except the source packages). Not all of the above features are yet taken advantage of, but the upload of the package is a first step.
GLIBC is a core package of the GNU project, so in all honesty, I never paid much attention to it. It’s just there, silently doing its job. However, reading through some of the bug reports, it does seem that its maintainer, Ulrich Drepper, is a bit of an ass. Since Free software/open source is not just about the code, but also the people around it, I say that any move away from certain types of people is a good one.
Still, this is all only one side of the story, so I reserve judgment on Drepper for now.
“..bad maintainership **aptitude** of Ulrich Drepper…”
Debian & aptitude; get it?! I’m guessing you meant “attitude,” but I love a good Freudian slip. =)
Then again… i supposed aptitude infers attitude as well. Still, funny… =)
Edited 2009-05-06 17:57 UTC
aptitude exists, and according to wikipedia,is “an innate, acquired or learned or developed component of a competency (being the others: knowledge, understanding and attitude) to do a certain kind of work at a certain level.”
which is different (as in a *complementary* quality, thus unrelated) from attitude, nor i can see how it infers it…
thus what i get is, drepper’s ability in pragmatically developing and maintaining such a vital component of such an important open source (and cross platform, btw) project, as GNU’s C library, is what is actually questioned
and, judging from the linked bug reports/threads, and the recently added usage of XML at the c library level to get memory allocation stats i’m more and more inclined to agree…
Edited 2009-05-06 18:20 UTC
After looking at the actual code (malloc_info @malloc/malloc.c), I can only agree.
Beyond the -highly- controversial decision to use XML in a C library, the code itself is more-or-less limited to debug usage and nothing else, as it simply fprintf’s a lot of junk into a FILE pointer. (A far better solution would have been to write multiple TLV’s into a user-supplied memory buffer)
– Gilboa
Or we could have another “missing” wife on our hands.
What a complete a**hole with absolutely zero interest in substantiating his reasons for making changes and breaking RFCs.
That’s second link about the IPv6 is classic. But then again he works for RedHat and this reminds me of the mind-numbingly pointless dribble that went on for a year or more between Apple trying to add changes to GCC and ObjC/ObjC++ and the RedHat maintainers of GCC.
We are close to seeing LLVM reaching C++ completeness and soon Apple will have a complete drop-in replacement, not to mention Debian can weigh the pros/cons for their project using LLVM as well. I’m glad llvm 2.5 is in Debian and hopefully llvm 2.6 brings complete C++ support.
You go to Ulrich’s blog and he has several rants about how bad other software projects coding is which is quite rich in irony to how arrogant he is when questioned on his own code.
http://udrepper.livejournal.com/
I’d suggest he learn to use the quotation construct as it makes his entries so much easier on the reader. His rant on OO.org PDF exports is one example of whining.
LLVM’s Clang (LLVM itself is not a compiler) is nowhere near having complete C++ support. You can compile C++ using LLVM-GCC which, of course, does not cut GCC out of the picture like you are apparently hoping for.
Usable C++ support in Clang is at least a year off for the basics, IMO, and probably 2+ years off to be truly feature comparable to GCC (including the improvements GCC is likely going to gain in that time, e.g. improved C++0x support).
Clang is being designed from the ground up with C++0x support built in. It will take a while but with the more maintainable code base going to LLVM, we’ll see who gets there first.
two words: strlcpy and strlcat.
While it might be a good idea to put these functions in, because so many want them, I think that they are overrated: they can avoid certain classes of errors, but in many cases string truncation is an error, period, and the real flaw is the use of fixed-length buffers.
Sure but considering all the useless crap he’s already added to GNU libc why not also add some actually useful functions?
Well, it might be a flaw in Java, but I hope you realize the sort of code that should be using these functions isn’t in the same league as Java applications. Anyways, the main application for strl* is variable-size string buffers so I don’t really see your point.
strl* functions are either or both faster and technically superior to all competitors in the same league. All alternatives are either unusable, slower, error prone or all of the aforementioned. An especially useless alternative is Microsoft’s strncpy_s which fails to replace both strlcpy and strncpy for the few legitimate uses the latter has.
Still, if truncation is an error in your aplication, you should check for it. What are you suggesting strlcpy should do that it doesn’t? Cry all over the place like strncpy_s?
I see…
Hm, I read it and to me it seems he makes a perfectly valid case for OO.org pdf exports having to big sizes compared to pdflatex.
Yes, please by all means equate a difficult to work with maintainer with a known killer. Classy.
And this is related because?
It’s related because it’s an example of usurping uncooperative project leads. Apple in this instance were tired of RMS refusing to put some features into GCC, so they decided they needed a better, more modern system they can manage theirselves.
It seems surprising that something as conservative as Debian is doing a radical decision like this; it’s something I’d have expected from Fedora first.
Still, an interesting development. I wonder whether going with BSD libc would have made sense as well – sharing the effort in central code like this would have been interesting twist of events.
me too
BSD code is for everyone to use and redistribute to their heart’s content – including GPL supporters (and reuse of bsd derived code in GPL projects happened quite a lot in early times afaik)
otoh, eglibc’s authors clearly mention E-mbedded systems as their target, and “GLIBC’s developers’ requirements” as motive for creating a specific library …
Drepper works for Red Hat (though he’s so strong-willed that Red Hat has little control over him). This would present a problem for Fedora choosing to go around him.
If Drepper were merely an ass, the solution would be simple: go around him. The problem is that he’s a brilliant developer, and glibc is of very high quality thanks to him. Unfortunately, he is extremely stubborn and never admits error.
Herr Drepper will eventually find that brilliance is not a substitute for basic civility.
According to the Bug-Reports ‘Discussions’ he’s having with some fellow developpers… He does look like a major asshole.
I sincerely hope that this is more the exception than the norm… But still… I would not hire that guy. He seems to have some serious attitudes issues…
If those bugzilla discussions are anything to go by, not really.
Stressed out & defensive after repeated confrontation, more like. Bugzilla (where people are doing real work) shouldn’t really become a soap opera for drama-thirsty outsiders.
No, the BugZilla entries are pretty illustrative of how Ulrich is. Those entries in BugZilla are very similar in tone to many of his posts on libc-alpha mailing list.
Yeah, he should be fired from Red Hat, it seems like no one wants him.
Yes, and some random guy you never met or worked with, in a website, should comment on how you should be fired from your job.
I’ll step to the task: you should be fired from your job. I, for one, don’t like you.
I’m not sure this is the correct response. Ulrich is a Redhat employee, so the suits there should recognize he is splintering a very important part of the Linux stack and take appropriate administrative action.
It is clear he doesn’t have the people skills to manage a project, but that doesn’t mean he isn’t a great individual contributor.
I’m not sure a fork is mandated at this point. Ideally, the embedded patches would be merged upstream.
a fork to get a project away from a domineering asshole is always merited.
Ulrich has always been a very focused person, but sadly his focus has always been Linux. Glibc has always claimed to be “portable” but then Ulrich (& one or two other Glibc contributors) seem to want to make porting or supporting Glibc on anything but Linux as difficult as possible. One example I’ve had to deal with on Syllable is the insistence that the kernel & toolchain must support the (non-standard) GNU TLS extensions (you might know them as the __thread storage specifier in GCC). This imposes external dependencies on any platform that wants to use Glibc, and the idea that GNU TLS is a non-standard extension to GCC & the ELF spec and might therefore be better as optionally supported seems to fly right past Ulrich: it works on Linux, so what’s the problem?
Now having said all of that, I’m not yet convinced anyone else can do as good a job of holding Glibc together and driving it forward as Ulrich is doing right now.
I’ll be watching EGLIBC with interest, but I’m not going to bank my house on it just yet…
For a moment there I thought “why the hell do they want TLS in the kernel” and then I realized they mean GNU Thread Local Storage and not GNU Transport Layer Security. Stupid either way though
<stupid question>
Edited 2009-05-06 19:42 UTC
I think we all know developers who are brilliant but can’t suffer “fools” easily. They can be a bit tempermental, but I think they get overwhelmed at all they have to do, and little bug reports often “bug” them more than the bugs themselves!
Typically when someone leads a multi-OS project, they must care about all platforms (or at least not actively hate them). When they start getting overly partial, crabby, and not fixing bugs, it usually means they need to take a break / hiatus from it.
I do think it’s a bit overreacting, he wasn’t that bad, I’ve seen worse. Still, you almost have to be a diplomat to work on community projects, and it’s not easy.
I think we should also all agree that people like that shouldn’t be let anywhere near anything that even vaguely looks like a management position. Just because you are an amazing programmer doesn’t mean you will do an amazing job managing a programming project.
Looking back at the really great managers I’ve had in my career non of them where great programmers, and all of them would be the first to admit that. But they knew how to organize and get the most out of people who where great programmers and how to work around those peoples weaknesses so that they could focus on their strength.
It’s too bad I cant mod you up because you speak the truth.
I completely agree.
We had a guy like this in the Kernel Team at NeXT. He was fired for being such a complete a-hole and non-productive in a team environment.
During the Apple merger Engineering weighed the pros and cons of his Mach talent versus his Personality.
If my memory serves me correctly, he was given a contract to sign with several stipulations in it. I can’t recall if he ever signed it as I was busy in Professional Services and had contracts to maintain and grow.
With the demise of Apple’s Enterprise Team you can figure out how poorly the overall team was managed–the reason I left before the boat in the group sprung a massive leak.
Edited 2009-05-07 00:09 UTC
Well, from the cherry picked examples, they didn’t seem to be foolish questions. And in several instances he wouldn’t admit to a problem he’d already fixed in CVS. That’s more than not suffering fools. Thats a denial of reality.
There’s a difference between fools and individuals who (correctly) point out problems with your changes and want to know why you did what you did.
Are you kidding? He makes Linus and Theo look civilized.
“If you want answers, pay me”. WTF?!?
That’s why I put “fools” in quotes. It’s not my agreement with the term.
While I disagree with his response, it’s true that you can’t expect him to bend over backwards and drop everything without incentive. It’s his right to not do what every random person wants. He has other things to do too. Sure, he could’ve been nicer, but nobody’s perfect.
I can’t help but be a bit concerned about this. On one hand, yes it’s good to get away from projects if their maintainers are unreasonable and/or are being assholes.
But on the other hand… This whole thing smacks of re-inventing the wheel yet again. I guess they’ve done it with every other component… why not the C library now. What, messing up the audio stack getting boring? They claim eglibc is binary compatible with glibc–personally, I’ll believe that when I see it. How long until we encounter some function that behaves ever so slightly differently under an obscure condition that made it past the compatibility and regression tests–assuming they did any, of course? It’s bad enough having to take into account all the different library versions and combinations we have already… and now we may end up having to add the C library–the most basic and what should most definitely be a relative constant–into that mix.
I know I’m going to get flamed by the Linux croud, but this is bloody ridiculous. This is why, from a commercial developer’s point of view, Linux is often a laughing stock. They’re replacing this, upgrading that, and forking the other on a near-constant basis… how the hell is anyone supposed to keep track and account for all these various combinations? Unbelievable, and rather pathetic when you come right down to it.
Edited 2009-05-06 21:28 UTC
I don’t see how this is offensive…or how Linux isn’t good for commercial development. An application can be compiled with a specific “max version” of symbols to use. elibc could provide compatibility with say (for example) glibc 2.4 symbols and probably be fine for most things.
Compile statically, for one. A multi-megabyte binary isn’t a big deal when the average consumer has a half a terabyte at their disposal. Choosing what to link with will make up about 1/1,000,000,000th of your total development time. This really won’t cause Adobe to abandon their Photoshop port.
Many (most?) commercial apps usually are compiled statically anyways, so…
If you’re using lgpl libraries compiling totally static can be a PITA. Also compiling opengl statically isn’t possible because of the different backend blobs provided by nvidia & ati.
That’s why I believe some baseline glibc symbol compatibility to be the most effective way to handle basic compatibility. “apbuild” allows you to do this.
? Glibc already versions all of it’s external symbols to achieve great forwards compatibility. The ABI hasn’t been broken in a very, very long time.
He means deliberately compiling against older versions of the symbols in glibc, so you can run the resulting binary on a wider range of distros.
http://autopackage.org/apbuild-apgcc.php
This does actually work pretty well. It doesn’t really help with other dynamically-linked libraries, of course, but most of those can just be shipped side-by-side with the binary. Glibc is the only one that’s impossible to distribute with the binary.
Well first of all eglibc was not created recently, it’s been around for several years. It’s also not a classical fork, more of a patchset to glibc to achieve what they want. So they are often syncing to glibc. Also to all those people worrying about competability, most distros already heavily patch glibc, so this is more of an effort from debian to unify these efforts. Think about it more as a buffer between Drepper and the “mortals”.
J
…I never expect maintainers of open source software to exhibit diva-like or butt-head like personality quirks.