Slashdot Mirror
Glibc Steering Committee Dissolves; Switches To Co-Operative Development Model
First time accepted submitter bheading writes "Following years under controversial leadership which, among other things, led to a fork (which was in turn adopted by some of the major distributions) the glibc development process has been reinvented to follow a slightly more informal, community-based model. Here's hoping glibc benefits from a welcome dose of pragmatism."
Ahahaha, really? That's hilarious. Damn, I remember Drepper. I was told "he's quite nice in person", but you'd never know it from how he acted over email.
Heh...I read through the summary and thought, "actually, we could do with less pragmatism and more with just doing what is right regardless of what the people keep requesting. Design by committee is the path to bloat. Then I clicked the links and saw this comment by Drepper in response to a bug report on arm:
It's working fine everywhere but this carp architectures. I'm not going to make the code perform worse just because of Arm. Providing your own copy of that file if you care.
That's not lack of pragmatism, that's lack of professionalism. In fact, this is a good time to point out that "nice in person" is code for "asshole, but too much of a coward to behave like one if the other person is within punching distance."
Warning: Opinions known to be heavily biased.
They are vilified as being "mean" or "intolerant" because they act like mean intolerant assholes.
A truly great programmer does not feel the need to belittle others' efforts. A truly great project leader does not feel the need to be rude and dismissive.
Compare Linus Torvalds, who is just as opinionated and can be just as abrupt, and yet somehow manages not to be widely perceived as a mean intolerant asshole. Consider the possibility that this is because he is also frequently observed being polite and saying nice things in public.
The Debian tag is there because they promoted the eglibc fork.
I am not quite sure that glibc is a GNU project. I thought for that to be true, the copyrights would have to be transferred to the FSF. Drepper posted a long rant a while back about how the FSF would do that over his cold, dead body.
When I wrote about pragmatism I was thinking of this problem where a modification to glibc's malloc() implementation broke the Adobe flash player. It is worth contrasting the attitude of Linus Torvalds in that thread with that of the glibc maintainers. I think most reasonable people would agree there is a trade off between supporting broken applications and ensuring things are done right. In this case, it would have cost glibc nothing to make a minor concession.
I understand your point, that it doesn't break anything else to make the concession. That said, this is exactly what I mean by "we need less pragmatism." The way I see it, overlapping memcpy is a bug, so that's what needed to be fixed. You code according to an API, and the moment that applications start depending on how you implement that API internally, you're asking for trouble. Pragmatically, you'd get flash working, but I'd actually be in favor of leaving the backwards copy in there even if it serves no other purpose than to expose bugs in people's code using your library.
I think doing things the right way is more important than getting things working for now, because it prevents things from breaking in the future. More long term planning and less short-term concessions is the way to go. That said, "this doesn't work at all on arm" problem was an actual bug on glibc's side. If he thinks the new way of doing things hurts performance in other architectures, then he can provide the different code paths with optimizations if he cares to do so.
Warning: Opinions known to be heavily biased.