% Linux Installation and Getting Started    -*- TeX -*-
% design.tex
% Copyright (c) 1992-1994 by Matt Welsh <mdw@sunsite.unc.edu>
%
% This file is freely redistributable, but you must preserve this copyright 
% notice on all copies, and it must be distributed only as part of "Linux 
% Installation and Getting Started". This file's use is covered by the 
% copyright for the entire document, in the file "copyright.tex".

\section{The Design and Philosophy of Linux}
\namedlabel{sec-intro-design}{The Design and Philosophy of Linux}

\index{Linux!philosophy|(}
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.

\index{UNIX!commercial}
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 quantitative 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 
\index{hacker}
operating system.\footnote{What I mean by ``hacker'' is a feverishly dedicated 
programmer, a person who enjoys exploiting computers and generally doing
interesting things with them. This is in contrast to the common 
denotation of ``hacker'' as a computer wrongdoer or outlaw.}

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, 
\index{Torvalds, Linus}
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). 

\index{Linux!development}
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.  

\index{bugs}
\index{Linux!bugs}
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 thrust behind
Linux development is not an effort to release perfect, bug-free code: it
is to develop a free implementation of UNIX. Linux is {\em 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'' 
\index{alpha}
\index{development!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~\ref{app-ftplist-num}) 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, 
\index{beta}
\index{development!beta}
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 
\index{development!conventions}
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 {\em 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 {\em distribution}, 
\index{distributions}
\index{Linux!distributions}
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~\ref{sec-install-distributions}.

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 {\em 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. 

\subsection{Hints for UNIX novices}

Installing and using your own Linux system does not require a great
deal of background in UNIX. In fact, many UNIX novices successfully
install Linux on their systems. This is a worthwhile learning experience, 
but keep in mind that it can be very frustrating to some. If you're
lucky, you will be able to install and start using your Linux system
without any UNIX background. However, once you are ready to delve
into the more complex tasks of running Linux---installing new
software, recompiling the kernel, and so forth---having background
knowledge in UNIX is going to be a necessity.

Fortunately, by running your own Linux system you will be able to
learn the essentials of UNIX necessary for these tasks. This
book contains a good deal of information to help you get 
started---Chapter~\ref{chap-tutorial-num} is a tutorial covering
UNIX basics, and Chapter~\ref{chap-sysadm-num} contains information
on Linux system administration. You may wish to read these chapters
before you attempt to install Linux at all---the information contained
therein will prove to be invaluable should you run into problems.

Nobody can expect to go from being a UNIX novice to a UNIX system 
administrator overnight. No implementation of UNIX is expected to run
trouble- and maintenance-free. You must be aptly prepared for the journey
which lies ahead. Otherwise, if you're new to UNIX, you may very well 
become overly frustrated with the system. 

\subsection{Hints for UNIX gurus}
Even those people with years of UNIX programming and systems administration
experience may need assistance before they are able to pick up and
install Linux. There are still 
aspects of the system that UNIX wizards will need to be familiar with 
before diving in. For one thing, Linux is not
a commercial UNIX system. It does not attempt to uphold the same standards as
other UNIX systems you have may have come across. To be more
specific, while stability is an important factor in the development of Linux,
it is not the {\em only\/} factor. 

More important, perhaps, is functionality.
\index{functionality}
In many cases, new code will make it into the standard kernel even though
it is still buggy and not functionally complete. The assumption is that it
is more important to release code which users can test and use than delay
a release until it is ``complete''. As an example, WINE (the Microsoft
Windows Emulator for Linux) had an ``official'' alpha release before it was
completely tested. In this way, the Linux community at large had a chance to
work with the code, test it, and help develop it, while those who found the
alpha code ``good enough'' for their needs could use it. Commercial UNIX
vendors rarely, if ever, release software in this manner.

\index{UNIX!commercial}
If you have been a UNIX systems administrator for more than a decade, and 
have used every commercial UNIX system under the Sun (no pun intended), 
Linux may take some getting used to. The system is very modern and 
dynamic.  A new kernel release is made approximately every few months. 
New software
is constantly being released. One day your system may be completely
up-to-date with the current trend, and the next day the same system is
considered to be in the Stone Age. 

With all of this dynamic activity, how can you be expected to keep up with the
ever-changing Linux world? 
\index{upgrading}
For the most part, it is best to upgrade
incrementally; that is, upgrade only those parts of the system that {\em need}
upgrading, and then only when you think an upgrade is necessary. For example,
if you never use Emacs, there is little reason to continuously install
every new release of Emacs on your system. Furthermore, even if you are an
avid Emacs user, there is usually no reason to upgrade it unless you find that
some feature is missing that is in the next release. There is little or no
reason to always be on top of the newest version of software. 

We hope that Linux will meet or exceed your expectations of a homebrew
UNIX system. At the very core of Linux is the spirit of free software,
of constant development and growth. The Linux community favors expansion over
stability, and that is a difficult concept to swallow for many people,
especially those so steeped in the world of commercial UNIX. You cannot
expect Linux to be perfect; nothing ever is in the free software world. 
However, we believe that Linux really is as complete and useful as any other
implementation of UNIX. 

\index{Linux!philosophy|)}
