My initial experience with Linux is probably typical. Although I've got years of experience with many different OS's, I started with a commercial "distro" (Red Hat) and, I freely admit, didn't really understand it.
... I installed and used packages, let Red Hat Network install whatever updates it wanted, and
slowly began to learn
how this system actually worked. I found that probably the hardest thing of all was to grok how the various parts of this system worked together, because it is
loosely-connected. In the "hope this helps" department, here goes ...
The Linux Kernel:
This what Linus Torvalds started writing. It resides in the
/boot directory and gets loaded into memory when you turn on the computer, by means of a "boot loader" such as
grub or the older
LILO. Once loaded, it always remains in memory (although it also contains "kernel modules" that can be loaded or removed, which is another story).
The Kernel is what IBM likes to call a
System Control Program, and that is exactly what it does: it controls the system (hardware), and not much more. It parcels out memory, schedules CPU time, controls hardware devices, and deals with the "interrupts" they produce. All very
low-level stuff. The term
device driver refers to a part of the kernel (usually a kernel module) that is responsible for recognizing and controlling a particular type of device.
System Libraries (e.g. glibc):
Most programs do not make direct calls to the kernel. Instead, they work with
libraries, which are found in
/lib. Like Windows
.DLL files, they are usually shared by many applications at once. Unlike Windows, there's a well-defined system by which many different versions of the same library can be installed at once. Well-behaved programs request the "latest" version but some applications require specific ones. The system command
ldconfig is important here.
Daemons (services):
This fanciful name refers to a program that is (usually) started when the system is booted, remains up all the time, and provides services to other programs. Everything from printing to file-sharing to the act of logging on is handled by them. When the system starts up, one process (process #1) named
init is started, and it starts all the other ones as directed by the file
/etc/inittab. Different arrangements of daemons can be requested by the mechanism of
runlevels. (See the files in
/etc/rc.n, where
n=0..6, which link to files in
/etc/init.d.)
X-windows:
Unlike Microsoft Windows, Linux uses a
de-centralized, client-server arrangement for handling graphics. An interesting feature of this system is that you can graphically log-on to a machine that has no graphics card of its own, through the network. Found in
/etc/x11, it is an unexpectedly complex but sophisticated subsystem.
Window managers; desktop (e.g. KDE, Gnome):
With Microsoft Windows, your graphical user interface (GUI) only looks and feels one way. With Linux you have a broad choice. The X-windows system mentioned previously relies upon
window managers to control the arrangement of windows on the screen and
desktops such as KDE, Gnome, FluxBox and AfterStep to specify how things look. The choice is yours.
The Shell (e.g. bash):
You can log-in to Linux using a command-line. You can open a "terminal" window (vdt) and issue commands. The program that accepts and processes these commands is called a
shell, and a common one is named "bash."
Commands, Paths:
Most of the commands recognized by a shell aren't built-in to the shell; they're programs. They're usually found in
/bin, /usr/bin, /usr/local/bin, and maybe
/sbin. The command
echo $PATH will tell you where bash knows to look.
Command files can also be located in the current directory, but bash
won't automatically look for them there. Commands found in the current directory must be prefixed by
./ (period slash). (Which is why you see people talking about
./configure)
To be sure, a system like this that is
loosely-connected, unlike Windows, does take time to "get to know." I hope that this high-level road map might help a little in figuring out just
where a particular problem you're having might lie. And instead of calling yourself a
and feeling somehow embarrassed by it ... you'll start to see that, when you
... there's a good reason for it! (And I assure you, it happens to us
all.)
.
