\chapter{Introduction}

\begin{quote}
How much does it cost to entice a dope-smoking \unix\ system guru to
Dayton?\\ 
\raggedleft Brian Boyle\index{Boyle, Brian}, {\em Unix World\/}'s 
First Annual Salary Survey
\end{quote}

\section{Who Should Read This Book}

Are you someone who should read this book?  Let's answer by asking some
other questions: Have you just gotten \linux\ from somewhere, installed it,
and want to know what to do next?  Or are you a non-\unix\ computer user
who is considering \linux\ but wants to find out what it can do for you?

If you have this book, the answer to these questions is probably
``yes.''  Anyone who has \linux, the free \unix\ clone written by
Linus Torvalds\index{Torvalds, Linus}, on their PC but doesn't know
what to do next should read this book.  In this book, we'll cover most
of the basic \unix\ commands, as well as some of the more advanced
ones.  We'll also talk about GNU Emacs\index{GNU Emacs}, a powerful
editor, and several other large \unix\ applications.
\glossary{application}

\subsection{What You Should Have Done Before Reading This Book}

This book relies on a few things that the author can't control.  First of
all, this book assumes that you have access to a \unix\ system.
(Unfortunately, it's a bit hard to learn without getting wet!) More
importantly, this \unix\ system should be an Intel\index{Intel} PC running
\linux.  This requirement isn't necessary, but when versions of \unix\
differ, I'll be talking about how \linux\ acts---nothing else.

\linux\ is available in many forms, called distributions.  It is hoped
that you've found a complete distribution such as SoftLanding Linux
Systems or the MCC-Interim release and have installed it.  There are
differences between the various distributions of \linux, but for the
most part they're small and unimportant.  (Occasionally in this book
you'll find places that seem a little off.  If you do, it's probably
because you're using a different distribution from mine.  The author
is interested in all such cases.)

If you're the superuser \glossary{superuser}\index{superuser} (the
maintainer, the installer) of the system, you also should have created
a normal user account for yourself.  Please consult the installation
manual(s) for this information.  If you aren't the superuser, you
should have obtained an account from the superuser. 

You should have time and patience.  Learning \linux\ isn't
easy---most people find learning the Macintosh\index{Macintosh} Operating
System is easier.  However, many people feel that \linux\ is more powerful.

In addition, this book assumes that you are moderately familiar with some
computer terms.  Although this requirement isn't necessary, it makes
reading the book easier. You should know about computer terms such as
`program' and `execution'.  If you don't, you might want to get
someone's help with learning \unix.

\section{How to Avoid Reading This Book}

The best way to learn about almost any computer program is at your
computer.  Most people find that reading a book without using the
program isn't very beneficial.  Thus, the best way to learn \unix\ and
\linux\ is by using them.  Use \linux\ for everything you can.
Experiment.  Don't be afraid---it's {\em possible\/} to mess
things up, but you can always reinstall. Keep backups and have fun!

For better or for worse, though, \unix\ isn't as intuitively obvious as
some other operating systems. Thus, you will probably end up reading at
least the first couple of chapters in this book.

The number one way to avoid using this book is to use the on-line
documentation that's available. Learn how to use the {\tt
  man}\ttindex{man} command---it's described in
Section~\ref{man-section}.

\section{How to Read This Book}

The suggested way of learning \unix\ is to read a little, then to play
a little.  Keep playing until you're comfortable with the concepts,
and then start skipping around in the book.  You'll find a variety of
topics are covered, some of which you might find interesting.  After a
while, you should feel confident enough to start using commands
without knowing what they should do.  This is a good thing.

What most people regard as \unix\ is the \unix\
shell\index{shell}\glossary{shell}, a special program that interprets
commands.  In practice, this is a fine way of looking at things, but
you should be aware that \unix\ really consists of many more things,
or much less.  (Depending on how you look at it.)  This book tells you
about how to use the shell\index{shell}, programs that \unix\ usually
comes with, and some programs \unix\ doesn't always come with.

The current chapter is a meta-chapter---it discusses this book and how
to apply this book to getting work done.  The other chapters contain:

\begin{description}
\item [Chapter~\ref{unixinfo}] discusses where \unix\ and \linux\ came
  from, and where they might be going.  It also talks about the Free
  Software Foundation\index{Free Software Foundation} and the GNU
  Project\index{GNU Project}.
\item [Chapter~\ref{bootup}] talks about how to start and stop using
  your computer, and what happens at these times.  Much of it deals
  with topics not needed for using \linux, but still quite useful and
  interesting.
\item [Chapter~\ref{shell-chapter}] introduces the \unix\ shell.  This
  is where people actually do work, and run programs.  It talks about
  the basic programs and commands you must know to use \unix.
\item [Chapter~\ref{x-chapter}] covers the X Window System. X is the
  primary graphical front-end to \unix, and some distributions set it
  up by default.
\item [Chapter~\ref{shell2-chapter}] covers some of the more advanced
  parts of the \unix\ shell. Learning techniques described in this
  chapter will help make you more efficent.
\item [Chapter~\ref{emacs-chapter}] describes the Emacs text
  editor. Emacs is a very large program that integrates many of
  \unix's tools into one interface.
\item [Chapter~\ref{commands-chapter}] has short descriptions of many
  different \unix\ commands. The more tools a user knows how to use,
  the quicker he will get his work done.
\item [Chapter~\ref{funny-chapter}] describes some of the larger,
  harder to use commands.
\item [Chapter~\ref{error-chapter}] talks about easy ways to avoid
  errors in \unix\ and \linux.
\end{description}

\section{\linux\ Documentation}

This book, \uguide, is intended for the \unix\ beginner.  Luckily, the
Linux Documentation Project is also writing books for the more
experienced users.

\subsection{Other \linux\ Books}

The other books include {\em Installation and Getting Started\/}, a
guide on how to aquire and install \linux, {\em The\/ \linux\ System
Adminstrator's Guide\/}, how to organize and maintain a \linux\
system, and {\em The \/\linux\ \/Kernel Hackers' Guide\/}, a book
about how to modify \linux. {\em The \linux\ Network Administration
Guide} talks about how to install, configure, and use a network
connection.

\subsection{HOWTOs}

In additon to the books, the Linux Documentation Project has made a
series of short documents describing how to setup a particular aspect
of \linux. For instance, the {\tt SCSI-HOWTO} describes some of the
complications of using {\tt SCSI}---a standard way of talking to
devices---with \linux.

These {\tt HOWTO}s are available in several forms.

\subsection{What's the Linux Documentation Project?}

Like almost everything associated with \linux, the Linux Documentation
Project is a collection of people working across the globe.
Originally organized by Lars Wirzenius\index{Wirzenius, Lars}, the
Project is now coordinated by Matt Welsh\index{Welsh, Matt} with help
from Michael K. Johnson.\index{Johnson, Michael K.}

It is hoped that the Linux Documentation Project will supply books
that will meet all the needs of documenting \linux\ at some point in
time.  Please tell us if we've suceeded or what we should improve on. You
can contact the author at {\tt greenfie@gauss.rutgers.edu} and Matt Welsh
at {\tt mdw@cs.cornell.edu}.

\section{Operating Systems}

% what purpose this section serves is unclear.  Why it is here is
% unclear. Why I don't delete it now is unclear. But I want something
% very vague here---can anyone think of a good thing?

An operating system\glossary{operating system}'s primary purpose is to
support programs that actually do the work you're insterested in. For
instance, you may be using an editor so you can create a document. This
editor could not do its work without help from the operating system---it
needs this help for interacting with your terminal, your files, and the
rest of the computer.

%An operating system is not the tool that does the work, it's the tool that
%{\em supports\/} the work.  It's tempting to just want to modify the
%operating system for its own sake, and if you feel this way often, I
%suggest you find a copy of {\em The\/\linux\ Kernel Hackers' Guide\/}.

If all the operating system does is support your applications, why do you
need a whole book just to talk about the operating system? There are lots
of routine maintenance activities (apart from your major programs) that you
also need to do.  In the case of \linux, the operating system also contains
a lot of ``mini-applications'' to help you do your work more efficently.
Knowing the operating system can be helpful when you're not working in one
huge application.

Operating systems (OS, for short) can be simple and minimalist, like
DOS\index{DOS}, or big and complex, like OS/2\index{OS/2} or
VMS\index{VMS}.\footnote{Apologies to DOS, OS/2, and VMS users. I've
used all three, and each have their good points.} \unix\ tries to be a
middle ground.  While it supplies more resources and does more than
early operating systems, it doesn't try to do {\em everything\/} like
some other operating systems.
% Ah. Well, the operating systems that tried to do everything, like
% Multix and that big one from IBM actually came before Unix. -M

% talk to ast about problems & flamewars concerning operating system
% limitations. :^)
The original design philosophy for \unix\ was to distribute
functionality into small parts, the programs.\footnote{This was
  actually determined by the hardware \unix\ original ran on. For some
  strange reason, the resulting operating system was very useful on
  other hardware.} That way, you can relatively easily achieve new
functionality and new features by combining the small parts (programs)
in new ways. And if new utilities appear (and they do), you can
integrate them into your old toolbox. Unfortunately, programs grow
larger and more feature-packed on \unix\ as well these days, but some
of the flexibility and interoperability is there to stay. When I write
this document, for example, I'm using these programs actively; {\tt
  fvwm} to manage my ``windows'', {\tt emacs} to edit the text,
\LaTeX\ to format it, {\tt xdvi} to preview it, {\tt dvips} to prepare
it for printing and then {\tt lpr} to print it. If I got a new, better
dvi previewer tommorow, I could use it instead of {\tt xdvi} without
changing the rest of my setup.

When you're using an operating system, you want to minimize the amount
of work you put into getting your job done.  \unix\ supplies many
tools that can help you, but only if you know what these tools do.
Spending an hour trying to get something to work and then finally
giving up isn't very productive.  Hopefully, you already know how to
use the correct tools---that way, you won't use the hammer to try and
tighten a screw.

% comment on ``All in One'' vs. ``all-encompassing'' PC apps or
% minicomputers?

The key part of an operating system is called the
``kernel.''\glossary{kernel} In many operating systems, like Unix,
OS/2\index{OS/2}, or VMS\index{VMS}, the kernel supplies functions for
running programs to use, and schedules them to be run.  It basically
says program A can get so much time, program B can get this much time,
etc. One school of thought says that kernels should be very small, and
not supply a lot of resources, depending on programs to pick up the
work.  This allows the kernel to be small and fast, but may make
programs bigger.  Kernels designed like this are called
micro-kernels.\glossary{micro-kernel} Another group of people believe
that kernels that offer more services to applications are better and
make more efficent operating systems.  Most versions of \unix\ are
designed like this, including \linux.  While it may seem at first that
all micro-kernels should be smaller than all macro-kernels, the terms
``micro'' and ``macro'' really aren't referring to size of the kernel
but a philosophy of operating system design.  

% Local Variables: 
% mode: latex 
% TeX-master: "guide" 
% End:
