% "@(#)sag:$Id$"        
%--------------------------------------------------------------------
\chapter{Overview of a Linux System}
%--------------------------------------------------------------------

        \begin{raggedleft}
        \it
        A quote is needed. \\
        \end{raggedleft}
        \vspace{2em}

	\noindent
	This chapter gives an overivew of a Linux system.  First, the major
	services provided by the operating system are described.  Then,
	the programs that implement these services are described with a
	considerable lack of detail.  The
	purpose of this chapter is to give an understanding of the
	system as a whole, so each part is described in detail elsewhere.

\section{Various parts of an operating system}

	A UNIX operating system consists of a \defin{kernel} and some
	\defin{system programs}.  There also some \defin{application
	programs} for doing work.  The kernel is the heart of the operating
	system\footnote{In fact, it is often mistakenly considered to be the
	operating system itself, but it is not.  An operating system
	provides many more services than a plain kernel.}.  It keeps track
	of files on the disk, starts programs and multiplexes 
	the processor and other hardware between them to provide multitasking,
	assigns
	memory and other resources to various processes, receives packets
	from and sends packets to the network, and so on.  The kernel does
	very little by itself, but it provides tools with which all
	services can be built.  It also prevents anyone from accessing
	the hardware directly, forcing everyone to use the tools it provides.
	This way the kernel can control who gets to do what and can provide
	some protection for users from each other.  The tools provided
	by the kernel are used via \defin{system calls}; see manual page
	section 2 for more information on these.

	The system programs use the tools provided by the kernel to
	implement the various services required from an operating system.
	System programs, and all other programs, run `on top of the kernel',
	in what is called the user mode.
	The difference between system and application programs is one
	of intent: applications are intended for getting useful things
	done (or for playing, if it happens to be a game), whereas
	system programs are needed to get the system working.  A word
	processor is an application; \cmd{telnet} is a system program.
	The difference is often somewhat blurry, however, and is important
	only to compulsive categorizers.

	An operating system
	can also contain compilers and their corresponding libraries (GCC and
	the C library in particular under Linux), although not all
	programming languages need be part of the operating system.
	Documentation, and sometimes even games, can also be part of it.
	Traditionally, the oeprating system has been defined by the
	contents of the installation tape or disks; with Linux it is
	not as clear since the stupid thing is spread all over the
	FTP sites of the world.

\section{Important parts of the kernel}

	The Linux kernel consists of several important parts: process
	management, memory management, hardware device drivers, filesystem
	drivers, network management, and various other bits and pieces.
	Figure~\ref{fig:kernel-overview} shows some of them.

\begin{figure}[htb]
\begin{center}
\leavevmode \epsffile{overview-kernel.ps}
\end{center}
\caption{Some of the more important parts of the Linux kernel.}
\label{fig:kernel-overview}
\end{figure}

	Probably the most important parts of the kernel (nothing else
	works without them) are the memory management and the
	process management.  Memory management takes care of assigning
	memory areas and swap space areas to processes, parts of the
	kernel, and for the buffer cache.  Process management creates
	processes, and implements the multitasking by switching the
	active process on the processor.

	At the lowest level, the kernel contains a hardware device
	driver for each kind of
	hardware it supports.  Since the world is full of different
	kinds of hardware, the number of hardware device drivers is
	large.  There are often many otherwise similar pieces of
	hardware that differ in how they are controlled by software.
	The similarities make it possible to have general classes
	of drivers that support similar operations; each member of
	the class has the same interface to the rest of the kernel
	but differs in what it needs to do to implement them.  For
	example, all hard disk drivers look alike to the rest of the
	kernel, i.e., they all have operations like `initialize the
	drive', `read sector N', and `write sector N'.

	Some software services provided by the kernel itself have similar
	properties.  For example, the various network protocols have been
	abstracted into one programming interface, the BSD socket library.
	Another example are the various filesystems Linux supports:
	the kernel contains a \defin{virtual filesystem} (VFS) that contains
	all the operations for a filesystem, and a filesystem
	driver for each supported filesystem.  When some entity tries to
	use a filesystem, the request goes via the VFS, which routes
	the request to the proper filesystem driver.

\section{Major services in a UNIX system}

	This section describes some of the more important UNIX services,
	but without much detail.  They are described
	more thorougly in later chapters.

\subsection{\cmd{init}}

	The single most important service in a UNIX system is provided
	by \cmd{init}.  \cmd{init} is started as the first process of
	every UNIX system, as the last thing the kernel does when it
	boots.  When \cmd{init} starts, it continues the boot process
	by doing various startup chores (checking and mounting filesystems,
	starting daemons, etc).

	The exact list of things that \cmd{init}
	does depends on which flavor it is; there are several to choose
	from.  \cmd{init}
	usually provides the concept of \defin{single user mode}, in which
	no one can log in and \cmd{root} uses a shell at the console; the usual
	mode is called \defin{multiuser mode}.
	Some flavors generalize this as \defin{run levels}; single and
	multiuser modes are considered to be two run levels, and there
	can be additional ones as well, for example, to run X on the
	console.

	When the system is running, the two most important tasks of
	\cmd{init} is to make sure \cmd{getty}s are working (to make
	sure logins work), that various daemons are running, and to
	adopt orphan processes (processes whose parent has died; in
	UNIX \emph{all} processes \emph{must} be in a single tree,
	so orphans must be adopted).

	When the system is shut down, it is \cmd{init} that is in charge
	of killing all
	other processes, unmounting all filesystems and stopping the processor,
	along with anything else that it feels like doing.

\subsection{Logins from terminals}

	Logins from terminals (via serial lines) and the console (when not
	running X) are provided by the \cmd{getty} program.  \cmd{init}
	starts a separate instance of \cmd{getty} for each terminal for
	which logins are to be allowed.  \cmd{getty} reads the username
	and runs the \cmd{login} program, which reads the password.  If
	the username and password match, \cmd{login} runs the shell.  When
	the shell terminates, i.e., the user logs out, or when \cmd{login}
	terminated because the username and password didn't match,
	\cmd{init} notices this and starts a new instance of \cmd{getty}.
	The kernel has no notion of logins, this is all handled by the
	system programs.

\subsection{Syslog}

	The kernel and many system programs produce error, warning, and
	other messages.  It is often important that these messages can
	be viewed later, even much later, so they should be written to
	a file.  The program doing this is \cmd{syslog}.  It can be
	configured to sort the messages to different files according to
	writer or degree of importance.  For example, kernel messages
	are often directed to a separate file from the others, since
	kernel messages are often more important and need to be read
	regularly to spot problems.

\subsection{Periodic command execution: \cmd{cron} and \cmd{at}}

	Both users and the system administrator often need to run
	specific commands periodically.  For example, the system
	administrator might want to run a command to clean the
	directories with temporary files (\fn{/tmp} and \fn{/var/tmp})
	from old files, to keep the disks from filling up, since not
	all programs clean up after themselves correctly.

	The \cmd{cron} service is set up to do this.  Each user has
	a \cmd{crontab}, where he lists the commands he wants to
	execute and the times they should be executed.  The \cmd{crond}
	daemon takes care of starting the commands when specified.

	The \cmd{at} service is similar to \cmd{cron}, but it is
	once only: the command is executed at the given time, but it
	is not repeated.

\subsection{Graphical user interface}

	UNIX and Linux don't incorporate the user interface into the
	kernel; instead, they let it be implemented by user level
	programs.  This applies for both text mode and graphical
	environments.

	This arrangement makes the system more flexible, but has
	the disadvantage that it is simple to implement a different
	user interface for each program, making the system
	harder to learn.

	The graphical environment primarily used with Linux is called
	the X Window System (X for short).  X also does not implement
	a user interface; it only implements a window system, i.e., tools
	with which a graphical user interface can be implemented.
	The three most popular user interface styles implemented over
	X are Athena, Motif, and Open Look.

\subsection{Networking}

	Networking is the act of connecting two or more computers so that
	the can communicate with each other.  The actual methods of
	connecting and communicating are slightly complicated,
	but the end result is very attractive.

	UNIX operating systems have many networking features.  Most basic
	services---filesystems, printing, backups, etc---can be done
	over the network.  This can make system administration easier,
	since it allows centralized administration, while still reaping
	in the benefits of microcomputing and distributed computing, such
	as lower costs and better fault tolerance.

	However, this book merely glances at networking; see the
	Linux Network Administrators' Guide for more information,
	including a basic descriptions of how networks operate.

\subsection{Network logins}

	Network logins work a little differently than normal logins.
	There is a separate physical serial line for each terminal via
	which it is possible to log in.  For each person logging in via
	the network, there is a separate virtual network connection,
	and there can be any number of these\footnote{Well, at least
	there can be many.  Network bandwidth still being a scarce
	resource, there is still some practical upper limit to the
	number of concurrent logins via one network connection.}.  It is
	therefore not possible to run a separate \cmd{getty} for each
	possible virtual connection.  There are also several different
	ways to log in via network, \cmd{telnet} and \cmd{rlogin} being
	the major ones in TCP/IP networks.

	Network logins have, instead of a herd of \cmd{getty}s, a
	single daemon (per way of logging in; \cmd{telnet} and \cmd{rlogin}
	have separate daemons) that listens for all incoming login attempts.
	When it notices one, it starts a new instance of itself to handle that
	single attempt; the original instance continues to listen for
	other attempts.  The new instance works similarly to \cmd{getty}.

\subsection{Network file systems}

	One of the more useful things that can be done with networking
	services is sharing files via a \defin{network file system}.  The
	one usually used is called the Network File System, or NFS,
	developed by Sun.

	With a network file system any file operations done by a program
	on one machine are sent over the network to another computer.
	This fools the program to think that all the files on the other
	computer are actually on the computer the program is running on.
	This makes information sharing extremely simple, since it requires
	no modifications to programs.

\subsection{Mail}

	Electronic mail is usually the most important method for
	communicating via computer.  An electronic letter is stored
	in a file using a special format, and special mail programs
	are used to send and read the letters.

	Each user has an \defin{incoming mailbox} (a file in the
	special format), where all new mail
	is stored.  When someone sends a mail, the mail program
	locates the receiver's mailbox and appends the letter to the
	mailbox file.  If the receiver's mailbox is in an another 
	machine, the letter is sent to the other machine, which delivers
	it to the mailbox as it best sees fit.

	The mail system consists of many programs.  The delivery of mail
	to local or remote mailboxes is done by one program (e.g.,
	\cmd{sendmail} or \cmd{smail}), while the programs users use
	are many and varied (e.g., \cmd{Pine} or \cmd{elm}).  The
	mailboxes are usually stored in \fn{/var/spool/mail}.

\subsection{Printing}

	Only one person can use a printer at one time, but it is
	uneconomical not to share printers between users.  The printer
	is therefore managed by software that implements a \defin{print
	queue}: all print jobs are put into a queue and whenever the
	printer is done with one job, the next one is sent to it
	automatically.  This relieves the users from organizing the
	print queue and fighting over control of the printer.\footnote{Instead,
	they form a new queue \emph{at} the printer, waiting for their
	printouts, since no-one ever seems to be able to get the queue
	software to know exactly when anyone's printout is really finished.
	This is a great boot for intra-office social relations.}

	The print queue software also \defin{spools} the printouts on
	disk, i.e., the text is kept in a file while the job is in the
	queue.  This allows an application program to spit out the
	print jobs quickly to the print queue software; the application
	does not have to wait until the job is actually printed to
	continue.  This is really convenient, since it allows one to
	print out one version, and not have to wait for it to be printed
	before one can make a completely revised new version.

\section{The filesystem layout}

	The filesystem is divided into many parts; usually along
	the lines of a root filesystem with \fn{/bin}, \fn{/lib},
	\fn{/etc}, \fn{/dev}, and a few others; a \fn{/usr} filesystem
	with programs and unchanging data; a \fn{/var} filesystem with
	changing data (such as log files); and a \fn{/home} filesystem
	for everyone's personal files.  Depending on the hardware
	configuration and the decisions of the system administrator,
	the division can be different; it can even be all in one
	filesystem.

	Chapter~\ref{chap:walkabout} describes the filesystem layout
	in some detail; the Linux Filesystem Standard covers it
	in somewhat more detail.
