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.
Monolithic libraries are the way to go. They make software development much easier.
If you don't believe me, just look at the GNOME project. The last time I tried to build it from scratch by hand, there must have been at least 50 libraries I had to build first. That was several years ago, so there are probably many more that are needed now. Those were just libraries from the GNOME project, too! That's not including glibc, the many X libraries, Gtk+, and so forth! Don't forget that you'll need to start making sure you're using the right versions, too. Some of these libraries are released yearly, while others have a new release every week.
To realistically build something like GNOME, where they went absolutely stupid with unnecessary modularity, you need to use one of the scripts that are out there that'll do it all for you. Those scripts end up being a solution to a problem that shouldn't exist in the first place! They're only needed because what should be one monolithic library was split out into 60 smaller libraries. You'll need all of the libraries to get even a basic GNOME installation up and running, so there's no point in separating them.
It's not the 1980s any longer. We don't statically link everything using dumb linkers that can't strip out unused executable code. Modern OSes using dynamic linking and delayed loading only ever use the parts of libraries that are actually used.