[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Linux: a gentle, growing approach

On Sun, Oct 13, 2002 at 11:50:18AM -0700, Josh Rehman wrote:
> I want to master Linux. I figure there are two ways to learn Linux
> system administration and usage. The first is to install a distribution
> and then explore it's nooks and crannies. The second is to begin with a
> seed and *grow* the nooks and crannies as needed. The former method is
> overwhelmingly used; I'd like to see more of the latter, because it's
> the more effective approach for advanced studies.

	I suspect that although the second is more effective, it is
incredibly difficult to implement; especially with complex systems that
have evolved instead of being designed.

> I believe that the second approach is superior because complexity is
> best understood when the student understands why the complexity was
> introduced in the first place. And the best way to accomplish *that* is
> to present the student with the problems that the complexity was
> originally introduced to solve. Then when they are stumped, you can give
> them the answer and they can say, "ah".

	Yes, that is an excellent way of teaching people.  I use it upon
myself, when I try to learn a new technology.  I'll search around for an
elegant pre-built solution to a problem; because I suspect that someone
has encountered it before and solved it well.  This typically works.

> WRT GNU/Linux in general and the Debian distribution in particular,
> there are several aspects of the OS that still baffle me, and frankly
> intimidate me with their complexity. The boot process is one of these,
> as is the nature of the filesystem, dev and proc in particular. Logging
> is opaque to me. There are many aspects of the system where it is not
> clear where the responsibilities of one program ends and the other
> begins. I find the blurred distinction between shell scripts and
> compiled programs to be confusing. Not to mention the dizzying array of
> configuration files and their baroque syntax!

	Unfortunately, you have stumbled upon that fact that your
computer is a general purpose calculator, and is ridiculously complex.
I can tell you what you need to learn about before your confusion can
completely disappear.

The boot process on an i386 machine (which I assume you have) is the
result of a design decision that IBM made in the 1980s.  You will
probably want to learn how the BIOS works, and about reserved sections
of your hard disk.

In the UNIX world, everything (well, almost) is a file.  Thus, the /dev
and /proc filesystems appear to be files to all your programs, and you
can manipulate them in that way.  To know more about the /dev
filesystem, you will want to look at major/minor numbers from the
original UNIX.  The /proc filesystem controls various aspects of the
kernel, and can be considered as pieces of the kernel exported to file.

Logging is done through syslogd and klogd.  Their documentation may
explain things better; for they are quite simple programs.

The quick difference between shell scripts and compiled programs is that
shell scripts are human-readable, and need to be interpreted by other
programs to turn them into executable machine code.  Compiled programs
are already executable machine code.

Configuration files... well, they just evolved that way.  There's not
much you can do about their differing syntax, although there are many
projects that try to unify them into a single interface.  Typically,
configuration files are designed to be easy to parse, and then they just
grow as more features are added to the program they configure.

> I am looking to understand and manipulate a Linux system with the
> minimum number of tools to accomplish certain simple goals. The goals
> increase in complexity. Tools should be introduced only as needed to
> accomplish a goal that is simply impossible (or would require an
> inordinate amount of shell or c work) with a current toolset. 

	Doing this, you will be very far from the level a beginner would
start at.  UNIX was originally a toy operating system, made to test a
new filesystem, to drive a video-display terminal, and to just much
around with.  One of the first uses of UNIX was to program (and program
in) C, as well as typeset books for AT&T Labs.  In this context, the
base tools presume that you are an operating system hacker who likes to
manipulate source files and documentation.  Since this is UNIX in its
purest and simplest form, you may wish to study Operating System theory
and play with teaching operating systems.  As well, studying compiler
theory will help immensely, especially since you'll learn about regular

	With these, you can get by incredibly decently, with only the
tools that Aho, Keringhan, Ritchie, Thompson and Bourne had kicking
around.  It won't be a pleasant situation, but you can get work done.
Ever since then, we've really just been trying to make UNIX (and
UNIX clones) more powerful and easier to use.


Reply to: