When new users encounter Linux, they often have a few misconceptions and
false expectations of the system. Linux is a unique operating system, and
it is important to understand its philosophy and design in order to use it
effectively. Time enough for a soapbox. Even if you are an aged UNIX
guru, what follows is probably of interest to you.
In commercial UNIX development houses, the entire system is developed with
a rigorous policy of quality assurance, source and revision control systems,
documentation, and bug reporting and resolution. Developers are not allowed
to add features or to change key sections of code on a whim: they must
validate the change as a response to a bug report and consequently ``check in''
all changes to the source control system, so that the changes can be backed
out if necessary. Each developer is assigned one or more parts of the system
code, and only that developer may alter those sections of the code while it
is ``checked out''.
Internally, the quality assurance department runs rigorous regression test suites on each new pass of the operating system, and reports any bugs. It is the responsibility of the developers to fix these bugs as reported. A complicated system of statistical analysis is employed to ensure that a certain percentage of bugs are fixed before the next release, and that the operating system as a whole passes certain release criteria.
In all, the process used by commercial UNIX developers to maintain and support their code is very complicated, and quite reasonably so. The company must have quantative proof that the next revision of the operating system is ready to be shipped; hence, the gathering and analysis of statistics about the operating system's performance. It is a big job to develop a commercial UNIX system, often large enough to employ hundreds (if not thousands) of programmers, testers, documentors, and administrative personel. Of course, no two commercial UNIX vendors are alike, but you get the general picture.
With Linux, you can throw out the entire concept of organized development,
source control systems, structured bug reporting, or statistical analysis.
Linux is, and more than likely always will be, a hacker's
operating system.
Linux is primarily developed as a group effort by volunteers on the
Internet from all over the world. Across the Internet and
beyond, anyone with enough know-how has the opportunity to aid in
developing and debugging the kernel, porting new software, writing
documentation, or helping new users. There is no single organization
responsible for developing the system. For the most part, the Linux community
communicates via various mailing lists and USENET newsgroups. A number of
conventions have sprung up around the development effort: for example,
anyone wishing to have their code included in the ``official'' kernel should
mail it to Linus Torvalds,
which he will test and include in the kernel
(as long as it doesn't break things or go against the overall design of the
system, he will more than likely include it).
The system itself is designed with a very open-ended, feature-minded
approach. While recently the number of new features and critical
changes to the system have diminished, the general rule is that
a new version of the kernel will be released about every few months (sometimes
even more frequently than this).
Of course, this is a very rough figure: it depends on a several factors
including the number of bugs to be fixed, the amount of feedback from users
testing pre-release versions of the code, and the amount of sleep that Linus
has had this week.
Let it suffice to say that not every single bug has been
fixed, and not every problem ironed out between releases.
As long as the
system appears to be free of critical or oft-manifesting bugs, it is
considered ``stable'' and new revisions will be released. The thust behind
Linux development is not an effort to release perfect, bug-free code: it
is to develop a free implementation of UNIX. Linux is for the
developers, more than anyone else.
Anyone who has a new feature or software application to add to the system
generally makes it available in an ``alpha''
stage-that is, a stage for
testing by those brave or unwary users who want to bash out problems with the
initial code. Because the Linux community is largely based on the Internet,
alpha software is usually uploaded to one or more of the various Linux FTP
sites (see Appendix C) and a message posted to one of the
Linux USENET newsgroups about how to get and test the code.
Users who download and test alpha software
can then mail results, bug fixes, or questions to the author.
After the initial problems in the alpha code have been fixed, the code
enters a ``beta'' stage,
in which it is usually considered stable
but not complete (that is, it works, but not all of the features may be
present). Otherwise, it may go directly to a ``final'' stage in which
the software is considered complete and usable. For kernel code, once it
is complete the developer may ask Linus to include it in the standard kernel,
or as an optional add-on feature to the kernel.
Keep in mind that these are only conventions-not
rules. Some people feel so
confident with their software that they don't need to release an alpha or test
version. It is always up to the developer to make these decisions.
You might be amazed that such a nonstructured system of volunteers, programming and debugging a complete UNIX system, could get anything done at all. As it turns out, it is one of the most efficient and motivated development efforts ever employed. The entire Linux kernel was written from scratch, without employing any code from proprietary sources. A great deal of work was put forth by volunteers to port all of the free software under the sun to the Linux system. Libraries were written and ported, filesystems developed, and hardware drivers written for many popular devices.
The Linux software is generally released as a distribution,
which is
a set of pre-packaged software making up an entire system. It would be
quite difficult for most users to build a complete system from the ground
up, starting with the kernel, adding utilities, and installing all of the
necessary software by hand. Instead, there are a number of software
distributions including everything that you need to install and run
a complete system. Again, there is no standard distribution-there are
many, each with their own advantages and disadvantages. We'll talk more about
the various available Linux distributions in
Section 2.1.
Despite the completeness of the Linux software, you will still need a bit of UNIX know-how to install and run a complete system. No distribution of Linux is completely bug-free, so you may be required to fix small problems by hand after installation. Running a UNIX system is not an easy task, not even for commercial versions of UNIX. If you're serious about Linux, bear in mind that it will take a considerable amount of effort and attention on your part to keep the system running and take care of things: this is true of any UNIX system, and Linux is no exception. Because of the diversity of the Linux community and the many needs which the software is attempting to meet, not eveything can be taken care of for you all of the time.