What is, really, the point of standardization?
Standardization helps, mainly, to make things easier for users and developers. I see this as a noble goal. But, as you state, there are some important issues and concepts about standardization that need to be addressed.
- Choice is good
- Choice helps make better software
- Choice allows a "different strokes for different folks" ideology to reign
- Lack of choice would mean the end of distributions as we know them
- Things are good now; why change?
First, to address point 1 and its ancillary points: standardization does not mean the end of choice. I agree that choice is good, that it helps to make better software, and that it allows for more specialized tools to develop. That's why I'm not arguing against sane choice. Sure, it would be nice to have thousands of different package managers, because, in theory, that would create a whole lot of competition that would in turn lead to some really excellent package management tools being developed.
Unfortunately, as experience so often teaches, theory != practice. While four or five competing package management solutions would theoretically lead to great development and a myriad of other benefits, in practice all it does is cause headaches.
Let's say I'm Joe User. I could be Joe Poweruser or Joe Administrator; "Joe User" is not meant to signify a dumb newbie but rather an average user. I want to install this neat program I found on Freshmeat called galeon. Unfortunately, I'm using Slackware, and the galeon people don't provide Slackware packages. Either I compile my own, and install it without package management, or I create my own Slackware package, or I just say, "Fuck it," and go look for software provided in TGZ package format.
As frustrating as that is for the user, consider what it is like for the developer! Helix Code currently maintains seven different package "distributions" (not counting variations within distributions like RH 6.x vs. RH 7.x packages). Seven! Does that strike anyone else as pretty stupid? Helix has to spend time creating and maintaining these packages, or else they lose a prospective part of their userbase. Wouldn't it be easier for them to create one package instead of seven?
That's why I think standardization on this front is good. You'll notice that I'm not saying, "Standardize everything! twm and vi for everyone; hack the kernel to prevent fvwm and emacs from running!" Honestly, can you say that package management system really matters that much in choosing a distribution? It matters from the perspective of users who think, "More developers use RPM than DEB or TGZ or SLP, so I'm going to install an RPM-based distribution," like me, but there aren't many people I know of who embrace dpkg and shun rpm. They're pretty much the same, if we exclude apt (which has nothing to do with the packaging system, as the recent modification of an RPM-based apt shows).
As for filesystem layout, standardization can't hurt here, either. I don't like Debian because of its filesystem layout. Sure, documentation shows up in /usr/doc, and configuration stuff is almost always in /etc, but that's because that's where the LSB says things should go. Red Hat is also moving towards LSB-compliance.
There is no benefit in distributions having varied filesystem layout, and the major drawback of a lack of implemented standard is that a universal package management system is made almost impossible. Heck, if there was a standard filesystem hierarchy, makefiles would be made to use the standard. Is there any benefit to having packages/makefiles installing stuff in fairly arbitrary places? Wouldn't it be much better if you knew for sure that binaries went in /usr/bin, as opposed to having them possibly be in /usr/bin, /usr/local/bin, /usr/local/jimmyjoe/bin, and /opt/bin?
In short, your freedom of choice is only being marginally limited with this idea of standardization on the package management front. In my opinion, ease of creation, installation, and management of package far outweighs the freedom to choose virtually identical package managers.
[ Parent ]