|[Home] [Credit Search] [Category Browser] [Staff Roll Call]||The LINUX.COM Article Archive|
|Originally Published: Sunday, 6 August 2000||Author: Master Sibn|
|Published to: featured_articles/Featured Articles||Page: 1/1 - [Std View]|
Linux: Governing Principle
Does Linux need a different developer hierarchy? Can OSS (Open Source Software) really be viable to the home user? Who, exactly is in charge of all this?
Advocates of the Microsoft approach to doing business often say that as a matter of convenience, every piece of software has some kind of coherence to it because it all comes from one place. This is touted as a good thing since they have only one outlet to check for updates. Although this is not a great thing, it's not entirely bad, either, as anybody who has ever searched the net for the newest libpthread-m.n.so could tell you.
It's a convenience, with some flaws, but the flaws can be worked around. It is simply not feasible for the home user to depend on dozens (even two or three) different websites for updates relating to security or stability.
The fact is, it's a huge convenience to be able to find all of your needed updates at `www.microsoft.com`. Or anywhere, for that matter. Linux users have no such luxury, yet.
There are some earnest attempts to cover these, including the venerable `freshmeat.net` and `sourceforge.net`, but so far nothing is comprehensive. Actually, many things are simply not coming together. I think it's positively swell that we can choose where to get our updates, but it would be better if:
Production lines spend days spinning off exact duplicates of one part in order to ensure compatibility with every piece of hardware that uses that part. KDE 2.0 is supposed to support GTK pixmap themes; this increases the compatibility of the two environments.
UNIX systems were designed at first to have parts work together with each other, and locally they do. It's only on the internet that the keys do not match the locks. I like to have things fit together, and this simply isn't doing the system any justice at all.
Also, the installations should be more generic, therefore interchangeable as well. For example, to install the Xfstt (X Font Server for TrueTypes), you have to `make && make install`. For most other programs, you must `./configure; make; make install`, and for the Kernel you must `make config; make bzImage; make dep; make modules; make modules_install` on an i386-based machine, with possibly more steps depending on what you're installing.
I can understand that the Kernel shouldn't necessarily have the same install routines as every other program because it is NOT any other program. I can understand that the way it is now is probably the best way to do it. I can't really think of any better way to do it, so we're stuck with that little inconsistency.
But really, even if a configure script is unnecesary, it should still be included; This way, when a user extracted/untarred a source archive, he could use the same generic command to install the package. The configure script could be something as simple as `echo "Configuration unnecessary. Please run 'make; make install'"`.
Some developers take an extra step and include an 'install.sh' script that will configure, make, and make install the package.
While all of these are nice steps, I think ultimately they aren't helping much. We need some more consistency. One of the obstacles to a make frontend application for X Windows is that the installation instructions must be specifically tailored to each program's installation instructions. With generic instructions, though, such a thing would cause no barrier whatever.
The objective of each developer ought to be consistency: an application is nothing if not consistent with itself and other applications, especially on the internet.
Security shouldn't be this time consuming to administer.
-msibn is in the harried process of moving to an undecided state, and offers apologies for any incoherence. While his opinions are not necessarily those of the crew at Linux.com, they are the only opinions that matter anyway. ;-)