add directory docs
This commit is contained in:
gohigh
180
docs/Install-Guide/install-guide-2.2.2/node22.html
Normal file
180
docs/Install-Guide/install-guide-2.2.2/node22.html
Normal file
@@ -0,0 +1,180 @@
|
||||
<!DOCTYPE HTML PUBLIC "-//W3O//DTD W3 HTML 2.0//EN">
|
||||
<!Converted with LaTeX2HTML 95.1 (Fri Jan 20 1995) by Nikos Drakos (nikos@cbl.leeds.ac.uk), CBLU, University of Leeds >
|
||||
<HEAD>
|
||||
<TITLE>1.6 The Design and Philosophy of Linux</TITLE>
|
||||
</HEAD>
|
||||
<BODY>
|
||||
<meta name="description" value="1.6 The Design and Philosophy of Linux">
|
||||
<meta name="keywords" value="gs">
|
||||
<meta name="resource-type" value="document">
|
||||
<meta name="distribution" value="global">
|
||||
<P>
|
||||
<BR> <HR><A NAME=tex2html1928 HREF="node23.html"><IMG ALIGN=BOTTOM ALT="next" SRC="next_motif.gif"></A> <A NAME=tex2html1926 HREF="node8.html"><IMG ALIGN=BOTTOM ALT="up" SRC="up_motif.gif"></A> <A NAME=tex2html1920 HREF="node21.html"><IMG ALIGN=BOTTOM ALT="previous" SRC="previous_motif.gif"></A> <A NAME=tex2html1930 HREF="node1.html"><IMG ALIGN=BOTTOM ALT="contents" SRC="contents_motif.gif"></A> <A NAME=tex2html1931 HREF="node250.html"><IMG ALIGN=BOTTOM ALT="index" SRC="index_motif.gif"></A> <BR>
|
||||
<B> Next:</B> <A NAME=tex2html1929 HREF="node23.html">1.6.1 Hints for UNIX </A>
|
||||
<B>Up:</B> <A NAME=tex2html1927 HREF="node8.html">1 Introduction to Linux</A>
|
||||
<B> Previous:</B> <A NAME=tex2html1921 HREF="node21.html">1.5 About Linux's Copyright</A>
|
||||
<BR> <HR> <P>
|
||||
<H1><A NAME=SECTION00360000000000000000>1.6 The Design and Philosophy of Linux</A></H1>
|
||||
<P>
|
||||
<A NAME=secintrodesign> </A>
|
||||
<P>
|
||||
<A NAME=448> </A>
|
||||
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.
|
||||
<P>
|
||||
<A NAME=449> </A>
|
||||
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''.
|
||||
<P>
|
||||
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.
|
||||
<P>
|
||||
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.
|
||||
<P>
|
||||
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
|
||||
<A NAME=450> </A>
|
||||
operating system.<A NAME=tex2html130 HREF="footnode.html#451"><IMG ALIGN=BOTTOM ALT="gif" SRC="foot_motif.gif"></A>
|
||||
<P>
|
||||
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,
|
||||
<A NAME=452> </A>
|
||||
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).
|
||||
<P>
|
||||
<A NAME=453> </A>
|
||||
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.
|
||||
<P>
|
||||
<A NAME=454> </A>
|
||||
<A NAME=455> </A>
|
||||
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</em> the
|
||||
developers, more than anyone else.
|
||||
<P>
|
||||
Anyone who has a new feature or software application to add to the system
|
||||
generally makes it available in an ``alpha''
|
||||
<A NAME=457> </A>
|
||||
<A NAME=458> </A>
|
||||
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 <A HREF="node235.html#appftplistnum">C</A>) 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.
|
||||
<P>
|
||||
After the initial problems in the alpha code have been fixed, the code
|
||||
enters a ``beta'' stage,
|
||||
<A NAME=460> </A>
|
||||
<A NAME=461> </A>
|
||||
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.
|
||||
<P>
|
||||
Keep in mind that these are only conventions---not
|
||||
<A NAME=462> </A>
|
||||
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.
|
||||
<P>
|
||||
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</em>, 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.
|
||||
<P>
|
||||
The Linux software is generally released as a <em>distribution</em>,
|
||||
<A NAME=465> </A>
|
||||
<A NAME=466> </A>
|
||||
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 <A HREF="node51.html#secinstalldistributions">2.1</A>.
|
||||
<P>
|
||||
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</em> 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.
|
||||
<P>
|
||||
<BR> <HR>
|
||||
<UL>
|
||||
<LI> <A NAME=tex2html1932 HREF="node23.html#SECTION00361000000000000000">1.6.1 Hints for UNIX novices</A>
|
||||
<LI> <A NAME=tex2html1933 HREF="node24.html#SECTION00362000000000000000">1.6.2 Hints for UNIX gurus</A>
|
||||
</UL>
|
||||
<BR> <HR><A NAME=tex2html1928 HREF="node23.html"><IMG ALIGN=BOTTOM ALT="next" SRC="next_motif.gif"></A> <A NAME=tex2html1926 HREF="node8.html"><IMG ALIGN=BOTTOM ALT="up" SRC="up_motif.gif"></A> <A NAME=tex2html1920 HREF="node21.html"><IMG ALIGN=BOTTOM ALT="previous" SRC="previous_motif.gif"></A> <A NAME=tex2html1930 HREF="node1.html"><IMG ALIGN=BOTTOM ALT="contents" SRC="contents_motif.gif"></A> <A NAME=tex2html1931 HREF="node250.html"><IMG ALIGN=BOTTOM ALT="index" SRC="index_motif.gif"></A> <BR>
|
||||
<B> Next:</B> <A NAME=tex2html1929 HREF="node23.html">1.6.1 Hints for UNIX </A>
|
||||
<B>Up:</B> <A NAME=tex2html1927 HREF="node8.html">1 Introduction to Linux</A>
|
||||
<B> Previous:</B> <A NAME=tex2html1921 HREF="node21.html">1.5 About Linux's Copyright</A>
|
||||
<BR> <HR> <P>
|
||||
<BR> <HR>
|
||||
<P><ADDRESS>
|
||||
<I>Matt Welsh <BR>
|
||||
mdw@sunsite.unc.edu</I>
|
||||
</ADDRESS>
|
||||
</BODY>
|
||||
Reference in New Issue
Block a user