Glibc Steering Committee Dissolves; Switches To Co-Operative Development Model 102
First time accepted submitter 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."
Re:Summary (Score:5, Insightful)
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."
Re:Excessive "modularity" can become hell. (Score:2, Insightful)
Agree on that. Similarly, even though GTK+ purports to be cross platform, I never use it because of the many libraries it requires, GLib, ATK, Pango, WhatEver. It's just too much pain to get them all right and distribute the stuff to somebody not running GNU/Linux. GTK+/GNOME guys suffer badly from overgeneralization. They just don't realize that nobody is going to give a shit about their complex system and want to modify its tiny little details using their wonderful module system.
Re:Drepper and Theo are great men. Respect them. (Score:4, Insightful)
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.
Comment removed (Score:4, Insightful)
Re:Summary (Score:5, Insightful)
When I wrote about pragmatism I was thinking of this problem [redhat.com] 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.
Re:Summary (Score:2, Insightful)
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.
Sometimes there is a point to that type of thinking. This is not one of those times.
The original definition of memcpy() defined overlapping copies as "undefined" behavior not for any good API design reason which would stand the test of time (it's usually a bad idea for APIs to permit inputs which cause "undefined" behavior without returning an error code or throwing an exception or whatever), but rather because it made the implementation smaller.
That's because memcpy() is literally from the dawn of the C Standard Library, when the Bell Labs hackers were trying to squeeze as much functionality as they could into machines which look pathetically small by today's standards. Sometimes they went a little too far down the minimalism path. This was one of those times. Today, there is no legitimate reason to have that gotcha hiding in memcpy. It doesn't save enough space and it doesn't save enough time.
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.
At this point, the long term planning is in favor of just aliasing memcpy() to memmove(). The definition of memcpy() where it has "undefined" behavior for overlapping regions was one of those short term concessions to reality, ~40 years ago. We can move on. It won't hurt, promise. ;)