This commit is contained in:
gferg 2010-01-05 14:09:56 +00:00
parent 93311578db
commit 50bbd6ee5e
3 changed files with 141 additions and 82 deletions

View File

@ -4635,7 +4635,7 @@ How to change your Linux system so it uses UTF-8 as text encoding. </Para>
Unix-and-Internet-Fundamentals-HOWTO</ULink>,
<CiteTitle>The Unix and Internet Fundamentals HOWTO</CiteTitle>
</Para><Para>
<CiteTitle>Updated: Nov 2007</CiteTitle>.
<CiteTitle>Updated: Jan 2010</CiteTitle>.
Describes the working basics of PC-class computers, Unix-like
operating systems, and the Internet in non-technical language. </Para>
</ListItem>

View File

@ -44,7 +44,7 @@ requirements, and some resources. </Para>
Unix-and-Internet-Fundamentals-HOWTO</ULink>,
<CiteTitle>The Unix and Internet Fundamentals HOWTO</CiteTitle>
</Para><Para>
<CiteTitle>Updated: Nov 2007</CiteTitle>.
<CiteTitle>Updated: Jan 2010</CiteTitle>.
Describes the working basics of PC-class computers, Unix-like
operating systems, and the Internet in non-technical language. </Para>
</ListItem>

View File

@ -1,5 +1,6 @@
<?xml version="1.0"?>
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
<!DOCTYPE article PUBLIC
"-//OASIS//DTD DocBook XML V4.1.2//EN"
"docbook/docbookxx.dtd" [
<!ENTITY howto "http://www.tldp.org/HOWTO/">
<!ENTITY mini-howto "&howto;/mini/">
@ -24,6 +25,17 @@
</author>
<revhistory>
<revision>
<revnumber>2.11</revnumber>
<date>2010-01-05</date>
<authorinitials>esr</authorinitials>
<revremark>
Notice that it's mostly 64 bits now. Update the sections
on booting and running programs to describe X.
</revremark>
</revision>
<!--
<revision>
<revnumber>2.10</revnumber>
<date>2007-11-28</date>
@ -33,7 +45,6 @@
</revremark>
</revision>
<!--
<revision>
<revnumber>2.9</revnumber>
<date>2004-03-03</date>
@ -237,9 +248,14 @@ url="&howto;Unix-and-Internet-Fundamentals-HOWTO/index.html">
http:&howto;Unix-and-Internet-Fundamentals-HOWTO/index.html</ulink>.
</para>
<para>This document has been translated into: <ulink
url="http://theta.uoks.uj.edu.pl/~gszczepa/gszczepa/esr1iso2.htm">Polish</ulink><ulink
url="http://es.tldp.org/Manuales-LuCAS/doc-fundamentos-unix-internet/fundamentos.htm">Spanish</ulink>.</para>
<para>This document has been translated into: the following languages: <ulink
url="http://theta.uoks.uj.edu.pl/~gszczepa/gszczepa/esr1iso2.htm">Polish</ulink>
<ulink
url="http://es.tldp.org/Manuales-LuCAS/doc-fundamentos-unix-internet/fundamentos.html
">Spanish</ulink>
<ulink
url="http://docs.comu.edu.tr/howto/fundementals-howto.html">Turkish</ulink>
</para>
</sect2>
<sect2 id="feedback"><title>Feedback and corrections</title>
@ -264,20 +280,21 @@ resources.</para>
<sect1 id="anatomy"><title>Basic anatomy of your computer</title>
<para>Your computer has a processor chip inside it that does the actual
computing. It has internal memory (what DOS/Windows people call <quote>RAM</quote>
and Unix people often call <quote>core</quote>; the Unix term is a folk memory from
when RAM consisted of ferrite-core donuts). The processor and memory live
on the
computing. It has internal memory (what DOS/Windows people call
<quote>RAM</quote> and Unix people often call <quote>core</quote>; the Unix
term is a folk memory from when RAM consisted of ferrite-core donuts). The
processor and memory live on the
<firstterm>motherboard</firstterm><indexterm><primary>motherboard</primary></indexterm>,
which is the heart of your computer.</para>
<para>Your computer has a screen and keyboard. It has hard drives and a
CD-ROM and maybe a floppy disk. Some of these devices are run by
<firstterm>controller cards</firstterm> that plug into the motherboard and
help the computer drive them; others are run by specialized chipsets
directly on the motherboard that fulfill the same function as a controller
card. Your keyboard is too simple to need a separate card; the controller
is built into the keyboard chassis itself.</para>
<para>Your computer has a screen and keyboard. It has hard drives and an
optical CD-ROM (or maybe a DVD drive) and maybe a floppy disk. Some of
these devices are run by <firstterm>controller cards</firstterm> that plug
into the motherboard and help the computer drive them; others are run by
specialized chipsets directly on the motherboard that fulfill the same
function as a controller card. Your keyboard is too simple to need a
separate card; the controller is built into the keyboard chassis
itself.</para>
<para>We'll go into some of the details of how these devices work later. For
now, here are a few basic things to keep in mind about how they work
@ -341,7 +358,7 @@ system.</para>
<para>The loader does this by looking for a
<firstterm>kernel</firstterm><indexterm><primary>kernel</primary></indexterm>,
loading it into memory, and starting it. When you boot Linux and see
loading it into memory, and starting it. If you Linux and see
"LILO" on the screen followed by a bunch of dots, it is loading the kernel.
(Each dot means it has loaded another <anchor id="diskblock"/><firstterm>disk
block</firstterm> of kernel code.)</para>
@ -365,7 +382,15 @@ and how controllers will respond if they're present. This process is
called
<firstterm>autoprobing</firstterm><indexterm><primary>autoprobing</primary></indexterm>.</para>
<para>Most of the messages you see at boot time are the kernel autoprobing
<para>You may or may not be able to see any of this going on. Back when
Unix systems used text consoles, you'd see boot messages scroll by on your
screen as the system started up. Nowawadays, Unixes often hide the boot
messages behind a graphical splash screen. You may be able to see them by
switching to a text console view with the key combination Ctrl-Shift-F1. If
this works, you should be able to switch back to the graphical boot screen
with a different Ctrl-Shift sequence; try F7, F8, and F9.</para>
<para>Most of the messages emitted boot time are the kernel autoprobing
your hardware through the I/O ports, figuring out what it has available to
it and adapting itself to your machine. The Linux kernel is extremely good
at this, better than most other Unixes and <firstterm>much</firstterm> better
@ -378,7 +403,8 @@ a critical mass of users.</para>
boot process; it's just the first stage (sometimes called <firstterm>run
level 1</firstterm>). After this first stage, the kernel hands control to a
special process called &lsquo;init&rsquo; which spawns several housekeeping
processes.</para>
processes. (Some recent Linuxes use a different program called
&lsquo;upstart&rsquo; that does similar things)</para>
<para>The init process's first job is usually to check to make sure your disks
are OK. Disk file systems are fragile things; if they've been damaged by a
@ -399,35 +425,40 @@ daemons your system starts may vary, but will almost always include a print
spooler (a gatekeeper daemon for your printer).</para>
<para>The next step is to prepare for users. Init starts a copy of a
program called <command>getty</command> to watch your console (and maybe
more copies to watch dial-in serial ports). This program is what issues
the <command>login</command> prompt to your console. Once all daemons and
getty processes for each terminal are started, we're at <firstterm>run level
2</firstterm>. At this level, you can log in and run programs.</para>
program called <command>getty</command> to watch your screen and keyboard
(and maybe more copies to watch dial-in serial ports). Actually, nowadays
it usually starts multiple copies of <command>getty</command> so you have
several (usually 7 or 8) virtual consoles, with your screen and keyboards
connected to one of them at a time. But you likely won't see any of these,
because one of your consoles will be taken over by the X server (about
which more in a bit).</para>
<para>But we're not done yet. The next step is to start up various daemons
that support networking and other services. Once that's done, we're at
<firstterm>run level 3</firstterm> and the system is fully ready for
use.</para>
<para>We're not done yet. The next step is to start up various daemons
that support networking and other services. The most important of these is
your X server. X is a daemon that manages your display, keyboard, and
mouse. Its main job is to produce the color pixel graphics you normally
see on your screen.</para>
<para>When the X server comes up, during the last part of your machine's
boot process, it effectively takes over the hardware from whatever virtual
console was previously in control. That's when you'll see a graphical
login screen, produced for you by a program called a <firstterm>display
manager</firstterm>.</para>
</sect1>
<sect1 id="login"><title>What happens when you log in?</title>
<para>When you log in (give a name to <command>getty</command>) you
identify yourself to the computer. It then runs a program called
(naturally enough) <command>login</command>, which takes your password and
checks to see if you are authorized to be using the machine. If you
aren't, your login attempt will be rejected. If you are, login does a few
housekeeping things and then starts up a command interpreter, the
<firstterm>shell</firstterm>. (Yes, <command>getty</command> and
<command>login</command> could be one program. They're separate for
historical reasons not worth going into here.)</para>
<para>When you log in, you identify yourself to the computer. On modern
Unixes you will usually do this through a graphical display manager. But
it's possible to switch virtual consoles with a Ctrl-Shift key sequence and
do a textual login, too. In that case you go through the
<command>getty</command> instance watching that console tto call the
program <command>login</command>.</para>
<para>Here's a bit more about what the system does before giving you a shell
(you'll need to know this later when we talk about file permissions).
You identify yourself with a login name and password. That login name is
looked up in a file called /etc/passwd, which is a sequence of lines each
describing a user account.</para>
<para>You identify yourself to the display manager or
<command>login</command> with a login name and password. That login name
is looked up in a file called /etc/passwd, which is a sequence of lines
each describing a user account.</para>
<para>One of these fields is an encrypted version of the account password
(sometimes the encrypted fields are actually kept in a second /etc/shadow
@ -465,21 +496,17 @@ your personal files will live. Finally, your account entry also sets your
the command interpreter that <command>login</command> will start up to
accept your commmands.</para>
<para>What happens after you have successfully logged in depends on how you
did it. On a text console, <command>login</command> will launch a shell
and you'll be off and running. If you logged in through a display
manager, the X server will bring up your graphical desktop and you will
be able to run programs from it &mdash; either through the menus, or
through desktop icons, or through a <firstterm>terminal
emulator</firstterm> running a <firstterm>shell</firstterm>.</para>
</sect1>
<sect1 id="running-programs"><title>What happens when you run programs from the shell?</title>
<para>The shell is Unix's interpreter for the commands you type in; it's
called a shell because it wraps around and hides the operating system
kernel. It's an important feature of Unix that the shell and kernel are
separate programs communicating through a small set of system calls.
This makes it possible for there to be multiple shells, suiting different
tastes in interfaces.</para>
<para>The normal shell gives you the &lsquo;$&rsquo; prompt that you see
after logging in (unless you've customized it to be something else). We
won't talk about shell syntax and the easy things you can see on the screen
here; instead we'll take a look behind the scenes at what's happening from
the computer's point of view.</para>
<sect1 id="running-programs"><title>What happens when you run programs
after boot time?</title>
<para>After boot time and before you run a program, you can think of your
computer as containing a zoo of processes that are all waiting for
@ -499,16 +526,34 @@ are known as <firstterm>system calls</firstterm>.</para>
<para>Normally all I/O goes through the kernel so it can schedule the
operations and prevent processes from stepping on each other. A few
special user processes are allowed to slide around the kernel, usually by
being given direct access to I/O ports. X servers (the programs that
handle other programs&rsquo; requests to do screen graphics on most Unix boxes)
are the most common example of this. But we haven't gotten to an X server
yet; you're looking at a shell prompt on a character console.</para>
being given direct access to I/O ports. X servers are the most common
example of this.</para>
<para>You will run programs in one of two ways: through your X server
or through a shell. Often, you'll actually do both, because you'll
start a terminal emulator that mimics an old-fashioned textual console,
giving you a shell to run programs from. I'll describe what happens
when you do that, then I'll return to whaty happens when you run a program
through an X menu or desktop icon.</para>
<para>The shell is called the shell because it wraps around and hides the
operating system kernel. It's an important feature of Unix that the shell
and kernel are separate programs communicating through a small set of
system calls. This makes it possible for there to be multiple shells,
suiting different tastes in interfaces.</para>
<para>The normal shell gives you the &lsquo;$&rsquo; prompt that you see
after logging in (unless you've customized it to be something else). We
won't talk about shell syntax and the easy things you can see on the screen
here; instead we'll take a look behind the scenes at what's happening from
the computer's point of view.</para>
<para>The shell is just a user process, and not a particularly special one.
It waits on your keystrokes, listening (through the kernel) to the keyboard
I/O port. As the kernel sees them, it echoes them to your screen. When
the kernel sees an &lsquo;Enter&rsquo; it passes your line of text to the
shell. The shell tries to interpret those keystrokes as commands.</para>
I/O port. As the kernel sees them, it echoes them to your virtual console or
X terminal emulator. When the kernel sees an &lsquo;Enter&rsquo; it passes
your line of text to the shell. The shell tries to interpret those
keystrokes as commands.</para>
<para>Let's say you type &lsquo;ls&rsquo; and Enter to invoke the Unix
directory lister. The shell applies its built-in rules to figure out that
@ -530,6 +575,16 @@ start a game of Quake, for example. Or, suppose you're hooked up to the
Internet. Your machine might be sending or receiving mail while
<command>/bin/ls</command> runs.</para>
<para>When you're running programs through the X server rather than a shell
(that is, by choosing an application from a pull-down menu, or
double-clicking a desktop icon), any of several programs associated with
your X server can behave like a shell and launch the program. I'm going to
gloss over the details here because they're both variable and unimportant.
The key point is that the X server, unlike a normal shell, doesn't go to
sleep while the client program is running &mdash; instead, it sits between
you and the client, passing your mouse clicks and keypresses to it and
fulfilling its requests to point pixels on your display.</para>
</sect1>
<sect1 id="devices"><title>How do input devices and interrupts work?</title>
@ -619,7 +674,7 @@ network connection.</para>
<para>An operating system that can routinely support many simultaneous
processes is called <quote>multitasking</quote>. The Unix family of operating
systems was designed from the ground up for multitasking and is very good
at it &mdash; much more effective than Windows or the old Mac OS, which
at it &mdash; much more effective than Windows or the old Mac OS, which both
had multitasking bolted into them as an afterthought and do it rather poorly.
Efficient, reliable multitasking is a large part of what makes Linux
superior for networking, communications, and Web service.</para>
@ -854,10 +909,10 @@ logical calculations. When people write about computers having bit sizes
(calling them, say, <quote>32-bit</quote> or <quote>64-bit</quote> computers), this is what
they mean.</para>
<para>Most computers (including 386, 486, and Pentium PCs) have a word size
of 32 bits. The old 286 machines had a word size of 16. Old-style
mainframes often had 36-bit words. The AMD Opteron, Intel Itanium, and the
Alpha from what used to be DEC and is now Compaq have 64-bit words. </para>
<para>Most computers now have a word size of 64 bits. In the recent past
(early 2000s) many PCs had 32-bit words. The old 286 machines back in the
1980s had a word size of 16. Old-style mainframes often had 36-bit
words.</para>
<para>The computer views your memory as a sequence of words numbered from
zero up to some large value dependent on your memory size. That value is
@ -869,7 +924,7 @@ nightmares.</para>
<sect2 id="numbers"><title>Numbers</title>
<para>Integer numbers are represented as either words or pairs of words,
depending on your processor's word size. One 32-bit machine word is the
depending on your processor's word size. One 64-bit machine word is the
most common integer representation.</para>
<para>Integer arithmetic is close to but not actually mathematical
@ -880,9 +935,9 @@ notation. The highest-order bit is a <firstterm>sign
bit</firstterm><indexterm><primary>sign bit</primary></indexterm> which
makes the quantity negative, and every negative number can be obtained from
the corresponding positive value by inverting all the bits and adding one.
This is why integers on a 32-bit machine have the range
-2<superscript>31</superscript> to 2<superscript>31</superscript> - 1.
That 32nd bit is being used for sign; 0 means a positive number or zero, 1
This is why integers on a 64-bit machine have the range
-2<superscript>63</superscript> to 2<superscript>63</superscript> - 1.
That 64th bit is being used for sign; 0 means a positive number or zero, 1
a negative number.</para>
<para>Some computer languages give you access to <firstterm>unsigned
@ -917,12 +972,13 @@ six-character string only takes up two memory words. For an ASCII code
chart, type &lsquo;man 7 ascii&rsquo; at your Unix prompt.</para>
<para>The preceding paragraph was misleading in two ways. The minor one is
that the term &lsquo;octet&rsquo; is formally correct but seldom actually used; most
people refer to an octet as
<firstterm>byte</firstterm><indexterm><primary>byte</primary></indexterm> and
expect bytes to be eight bits long. Strictly speaking, the term &lsquo;byte&rsquo; is
more general; there used to be, for example, 36-bit machines with 9-bit
bytes (though there probably never will be again).</para>
that the term &lsquo;octet&rsquo; is formally correct but seldom actually
used; most people refer to an octet as
<firstterm>byte</firstterm><indexterm><primary>byte</primary></indexterm>
and expect bytes to be eight bits long. Strictly speaking, the term
&lsquo;byte&rsquo; is more general; there used to be, for example, 36-bit
machines with 9-bit bytes (though there probably never will be
again).</para>
<para>The major one is that not all the world uses ASCII. In fact, much of
the world can't &mdash; ASCII, while fine for American English, lacks many
@ -961,6 +1017,10 @@ unified set of Chinese/Japanese/Korean (CJK) ideographs. For details, see
the <ulink url="http://www.unicode.org/">Unicode Home Page</ulink>. XML
and XHTML use this character set.</para>
<para>Recent versions of Linux use an encoding of Unicode called UTF-8. In
UTF, characters 0-127 are ASCII. Characters 128-255 are used only in
sequences of 2 through 4 bytes that identify non-ASCII characters.</para>
</sect2>
</sect1>
<sect1 id="disk-layout"><title>How does my computer store things on disk?</title>
@ -1690,4 +1750,3 @@ fill-column:75
compile-command: "mail -s \"Unix and Internet Fundamentals HOWTO update\" submit@en.tldp.org <Unix-and-Internet-Fundamentals-HOWTO.xml"
End:
-->