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