Not logged in
Log in now
Create an account
Subscribe to LWN
Deadline scheduling: coming soon?
LWN.net Weekly Edition for November 27, 2013
ACPI for ARM?
LWN.net Weekly Edition for November 21, 2013
GNU virtual private Ethernet
That's silly. You can have strlcat() and strlcpy(), yet be compatible
Posted May 21, 2009 9:23 UTC (Thu) by danpb (subscriber, #4831)
Posted May 21, 2009 10:12 UTC (Thu) by nix (subscriber, #2304)
One complaint I really can't have about Ulrich is his commitment to a stable ABI. Yes, he's canned stuff in the past that has broken things like the JDK, but those were internal symbols exposed because the linker had no way to hide them at the time. The public interface really has maintained stability, right down to legacies of glibc's embryonic days like strfry()/memfrob() which have probably been used by about one person in the entire history of the world.
Posted May 21, 2009 12:50 UTC (Thu) by liljencrantz (guest, #28458)
Posted May 21, 2009 16:36 UTC (Thu) by nevyn (subscriber, #33129)
I've written patches for glibc that fixed bugs in functions pretty much every application uses, and have been accepted. I've spoken to people who have contributed even more.
I've yet to speak to _anyone_ who has anything better to say about working with Drepper than "he's actually an ok human being, if you meet him in real life".
To say I've contributed to glibc less because of Drepper, would be a vast understatement. It's been a running joke for a long time, that if you don't need to contribute to glibc don't ... and if you do, open a Red Hat Bugzilla so you just have to deal with Jakub.
The biggest problem I see with eglibc is that due to the compatibility requirements there are a large amount of things that can't be done. They really seem to be trying to stay very close to glibc, so the only thing it changes is that you can now s/Jakub/eglibc/ in the above.
Posted May 22, 2009 11:14 UTC (Fri) by liljencrantz (guest, #28458)
Other then that, I agree with your comment. Drepper is by default terse to the point of approaching continuous rudeness. When people try to waste his time, he will flame them. He even perceives people as wasting his time when they are actually making valid questions sometimes. He is hard to work with. Glibc would be better of if he wasn't.
But much like Theo, Drepper is an exceptional project leader when it comes to technical aspects. The most relevant question is, would glibc be better of without him? Would it be better if an average coder with good people skills was managing the project? My guess would be no, that all the combined lost contributions from other people are smaller in value than his contributions to Glibc. Same thing with Theo. On the other hand, my guess would be that Jörg Shilling and the XFree86-people fall on the other side of that line. But that's just me guessing.
Posted May 23, 2009 9:07 UTC (Sat) by nix (subscriber, #2304)
Did you really not see that?
Posted May 23, 2009 10:04 UTC (Sat) by liljencrantz (guest, #28458)
Posted May 23, 2009 11:37 UTC (Sat) by nix (subscriber, #2304)
I could dig up dozens of examples but it's too depressing and it's a bank
holiday here and I have two flashy new Nehalems to bring up (die, old
ten-year-outdated PIIIs! ... only thing is I'm not sure 36Gb RAM in the
two combined will be enough ;} )
Posted May 23, 2009 9:22 UTC (Sat) by nix (subscriber, #2304)
Drepper is an exceptional project leader when it comes to technical
He drops subsystems that he thinks are rarely used or that
relate to architectures he merely finds unpleasant (e.g. MIPS, ARM)
without listening to anyone pointing out that he might be wrong and
without saying why; more than once he's rejected contributions,
implemented them nearly identically himself some time later and credited
himself alone in NEWS (I suspect anyone working in academe decided never
to go near glibc again when that happened for the first time); he mostly
refuses to give rationales for technical rejections so that people can fix
whatever was wrong with their patches. Whether this is because he's scared
of being convinced otherwise or just arrogant I have no idea... but can
you imagine what would happen to the kernel, say, if it was run that way?
90% of the useful stuff we now have, maybe more, would simply not be
He's such a hard maintainer to deal with that an entire mailing list was
created whose sole reason for existence was that it was somewhere where
people could talk about glibc without Ulrich growling at them every five
minutes for 'abusing' libc-alpha@ by, uh, discussing alpha releases of
glibc on it. I have never seen *that* in any other project.
Developers can be in a project to scratch their own itch: but I think
glibc is proof that large free software project maintainers need other
goals too. First and foremost I think they have to be driven by a desire
to make software that others can hack on easily and that does what users
want, and in both of these areas Ulrich falls down like a lead balloon
(especially when you note that glibc's users are random developers,
and we've seen how he treats them when they dare to ask for help with one
of his glibc-only totally-undocumented public APIs).
Posted May 23, 2009 10:15 UTC (Sat) by liljencrantz (guest, #28458)
As to dropping good patches and then reimplementing them himself while taking full credit, I had not heard such accusations before. Do you have any specific patch set in mind, something to validate this?
Posted May 23, 2009 11:51 UTC (Sat) by nix (subscriber, #2304)
Posted May 24, 2009 10:06 UTC (Sun) by man_ls (guest, #15091)
Posted May 24, 2009 11:45 UTC (Sun) by nix (subscriber, #2304)
Posted May 23, 2009 12:06 UTC (Sat) by nix (subscriber, #2304)
This is in effect the split that has long existed anyway: it's only that
the distro stuff was split across dozens of repositories, which made it
very hard for people building their own glibc to do so. Now it's made much
easier, and everyone is in their ideal positions and can be happy :) and
Ulrich doesn't have to talk to anyone he doesn't want to, ever again,
which I suspect will make him happy. Or at least less grumpy. :)
bindresvport is another good case
Posted May 25, 2009 14:00 UTC (Mon) by saffroy (subscriber, #43999)
Posted May 21, 2009 21:19 UTC (Thu) by nix (subscriber, #2304)
It was implemented at the same time as a heap of K&R-related horrors and a
fix to strstr(): I suspect Roland was very bored after that and wanted to
do something fun to flush his brain out. Hence the glorious uselessness
that is strfry() and memfrob(). Their negative consequence is principally
that they sort lexicographically next to heavily used functions, and there
is no attempt to sort objects in libc.so according to frequency of use: so
these two functions reside permanently in memory on most Linux systems,
dragged in because the other str*() and mem*() functions are next to them
and in essentially continuous use.
Posted May 22, 2009 10:59 UTC (Fri) by liljencrantz (guest, #28458)
I didn't know it was McGrath that implemented them, but it doesn't change the fact that Drepper is (IMO) well within his right to say that he does not wish to waste his time by partaking in the joke, and when people again and again try to force him to do so, he is well within his right be grumpy.
The guys that keep pushing the patch are like some nerds I know, who keep making jokes about something very nerdish, e.g. phasers or VAX systems, in a group of people completely indifferent to the subject. Nobody gets the joke, nobody laughs, but they keep pushing the joke, trying to explain why it's funny instead of just dropping it.
Posted May 23, 2009 9:04 UTC (Sat) by nix (subscriber, #2304)
Personally I think that's a rather discreditable attitude in a maintainer,
but maybe that's just me.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds