Linked by Thom Holwerda on Wed 6th May 2009 17:41 UTC, submitted by diegocg
Debian and its clones 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.
Order by: Score:
Freudian slip much? =)
by Fusion on Wed 6th May 2009 17:55 UTC
Fusion
Member since:
2005-07-18

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

Reply Score: 4

RE: Freudian slip much? =)
by silix on Wed 6th May 2009 18:17 UTC in reply to "Freudian slip much? =)"
silix Member since:
2006-03-01

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

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

Reply Score: 4

RE[2]: Freudian slip much? =)
by gilboa on Thu 7th May 2009 08:58 UTC in reply to "RE: Freudian slip much? =)"
gilboa Member since:
2005-07-06

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


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

Reply Score: 2

tyrione
Member since:
2005-11-21

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.

Reply Score: 11

elanthis Member since:
2007-02-17

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

Reply Score: 3

SamuraiCrow Member since:
2005-11-19

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.

Reply Score: 2

Soulbender Member since:
2005-08-18

two words: strlcpy and strlcat.

Reply Score: 4

JoeBuck Member since:
2006-01-11

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.

Reply Score: 3

Soulbender Member since:
2005-08-18

Sure but considering all the useless crap he's already added to GNU libc why not also add some actually useful functions?

Reply Score: 6

strl*
by sakeniwefu on Thu 7th May 2009 05:18 UTC in reply to "RE[2]: Let's hope Drepper's not a filesystem designer"
sakeniwefu Member since:
2008-02-26

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.


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?

Reply Score: 2

franzb Member since:
2007-12-08


What a complete a**hole with absolutely zero interest in substantiating his reasons for making changes and breaking RFCs.


I see...


His rant on OO.org PDF exports is one example of whining.


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.

Reply Score: 1

foljs Member since:
2006-01-09

Or we could have another "missing" wife on our hands.


Yes, please by all means equate a difficult to work with maintainer with a known killer. Classy.

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.


And this is related because?

Reply Score: 0

Kroc Member since:
2005-11-10

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.

Reply Score: 2

Debian
by vivainio on Wed 6th May 2009 18:14 UTC
vivainio
Member since:
2008-12-26

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.

Reply Score: 6

RE: Debian
by silix on Wed 6th May 2009 18:31 UTC in reply to "Debian"
silix Member since:
2006-03-01

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

Reply Score: 5

eglibc and fedora
by JoeBuck on Wed 6th May 2009 19:04 UTC in reply to "Debian"
JoeBuck Member since:
2006-01-11

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.

Reply Score: 6

RE: eglibc and fedora
by qu1j0t3 on Thu 7th May 2009 01:38 UTC in reply to "eglibc and fedora"
qu1j0t3 Member since:
2009-05-07

Herr Drepper will eventually find that brilliance is not a substitute for basic civility.

Reply Score: 5

Ulrich Drepper
by shadow_x99 on Wed 6th May 2009 18:16 UTC
shadow_x99
Member since:
2006-05-12

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

Reply Score: 5

RE: Ulrich Drepper
by vivainio on Wed 6th May 2009 18:42 UTC in reply to "Ulrich Drepper"
vivainio Member since:
2008-12-26

According to the Bug-Reports 'Discussions' he's having with some fellow developpers... He does look like a major asshole.


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.

Reply Score: 4

RE[2]: Ulrich Drepper
by Vanders on Wed 6th May 2009 20:16 UTC in reply to "RE: Ulrich Drepper"
Vanders Member since:
2005-07-06

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.

Reply Score: 4

RE: Ulrich Drepper
by diegoviola on Wed 6th May 2009 22:09 UTC in reply to "Ulrich Drepper"
diegoviola Member since:
2006-08-15

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


Yeah, he should be fired from Red Hat, it seems like no one wants him.

Reply Score: 4

RE[2]: Ulrich Drepper
by foljs on Thu 7th May 2009 09:24 UTC in reply to "RE: Ulrich Drepper"
foljs Member since:
2006-01-09

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.

Reply Score: 2

Correct response?
by kev009 on Wed 6th May 2009 18:17 UTC
kev009
Member since:
2006-11-30

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.

Reply Score: 3

RE: Correct response?
by spikeb on Wed 6th May 2009 18:41 UTC in reply to "Correct response?"
spikeb Member since:
2006-01-18

a fork to get a project away from a domineering asshole is always merited.

Reply Score: 6

I saw this coming years ago
by Vanders on Wed 6th May 2009 19:19 UTC
Vanders
Member since:
2005-07-06

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

Reply Score: 8

RE: I saw this coming years ago
by Soulbender on Wed 6th May 2009 19:39 UTC in reply to "I saw this coming years ago"
Soulbender Member since:
2005-08-18

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

Reply Score: 3

RE: I saw this coming years ago
by Soulbender on Wed 6th May 2009 19:41 UTC in reply to "I saw this coming years ago"
Soulbender Member since:
2005-08-18

<stupid question>

Edited 2009-05-06 19:42 UTC

Reply Score: 2

overworked and underpaid
by Rugxulo on Wed 6th May 2009 20:15 UTC
Rugxulo
Member since:
2007-10-09

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.

Reply Score: 1

RE: overworked and underpaid
by dagw on Wed 6th May 2009 20:24 UTC in reply to "overworked and underpaid"
dagw Member since:
2005-07-06

I think we all know developers who are brilliant but can't suffer "fools" easily.

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.

Reply Score: 12

RE[2]: overworked and underpaid
by Soulbender on Wed 6th May 2009 21:13 UTC in reply to "RE: overworked and underpaid"
Soulbender Member since:
2005-08-18

It's too bad I cant mod you up because you speak the truth.

Reply Score: 2

RE[2]: overworked and underpaid
by tyrione on Thu 7th May 2009 00:06 UTC in reply to "RE: overworked and underpaid"
tyrione Member since:
2005-11-21

"I think we all know developers who are brilliant but can't suffer "fools" easily.

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

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

Reply Score: 2

RE: overworked and underpaid
by Bill Shooter of Bul on Wed 6th May 2009 21:04 UTC in reply to "overworked and underpaid"
Bill Shooter of Bul Member since:
2006-07-14

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.

Reply Score: 5

RE: overworked and underpaid
by Soulbender on Wed 6th May 2009 21:24 UTC in reply to "overworked and underpaid"
Soulbender Member since:
2005-08-18

I think we all know developers who are brilliant but can't suffer "fools" easily.


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.

I do think it's a bit overreacting, he wasn't that bad, I've seen worse.


Are you kidding? He makes Linus and Theo look civilized.
"If you want answers, pay me". WTF?!?

Reply Score: 4

RE[2]: overworked and underpaid
by Rugxulo on Thu 7th May 2009 21:49 UTC in reply to "RE: overworked and underpaid"
Rugxulo Member since:
2007-10-09

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.


That's why I put "fools" in quotes. It's not my agreement with the term.

Are you kidding? He makes Linus and Theo look civilized. "If you want answers, pay me". WTF?!?


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.

Reply Score: 1

NOt really sure what to think
by darknexus on Wed 6th May 2009 21:24 UTC
darknexus
Member since:
2008-07-15

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

Reply Score: 7

RE: NOt really sure what to think
by bnolsen on Wed 6th May 2009 22:45 UTC in reply to "NOt really sure what to think"
bnolsen Member since:
2006-01-06

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.

Reply Score: 1

Alex Forster Member since:
2005-08-12

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.


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.

Reply Score: 3

wanderingk88 Member since:
2008-06-26

Many (most?) commercial apps usually are compiled statically anyways, so...

Reply Score: 1

bnolsen Member since:
2006-01-06

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.

Reply Score: 2

Vanders Member since:
2005-07-06

That's why I believe some baseline glibc symbol compatibility to be the most effective way to handle basic compatibility.


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

Reply Score: 2

ba1l Member since:
2007-09-08

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

Reply Score: 1

RE: NOt really sure what to think
by cycoj on Fri 8th May 2009 03:44 UTC in reply to "NOt really sure what to think"
cycoj Member since:
2007-11-04

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.


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

Reply Score: 3

Odd...
by Tuishimi on Thu 7th May 2009 00:19 UTC
Tuishimi
Member since:
2005-07-06

...I never expect maintainers of open source software to exhibit diva-like or butt-head like personality quirks.

Reply Score: 5