[sf-lug] sf-lug Digest, Vol 31, Issue 20

[Rick Moen]

Quoting jim (jim at well.com):

> (good guess, i'd say: those whose experience is not 
> great probably would benefit from pointers to install 
> techniques. say, i bet they'd get such pointers if 
> they show up at a cabal date: 

Let's try a few pointers right now.  (This advice applies primarily to
people _helping others_ install Linux onto low-spec machine.  If utter
newcomers to Linux are also willing and able to follow this advice, I'll
be impressed -- and they will learn things that are extremely worthwhile.
At the same time, this is pretty technical, which is one reason why
installation onto low-spec hardware is an advanced topic.)


1.  Know your big-ticket RAM-gobbling items:  

o  the KDE, GNOME, and XFCE4 "desktop" suites, running as complete
   systems.  (By contrast, many individual apps _from_ those suites may 
   run just fine under a traditional-Unix-style lightweight window 
   manager, e.g., the excellent Abiword word processor packaged with
   GNOME and the Kspread spreadsheet packaged with KDE.)
o  the OpenOffice.org office suite and all of its constituent apps
o  almost all significant audio-video and graphics apps, starting with 
   The GIMP.
o  even Firefox and other Mozilla-based Web browsers may be marginal.
   (The amount of memory Firefox takes depends on how many sessions including
   tabs are active, and greatly on what content it's handling, but it 
   alone can _easily_ exceed 64MB, without even multiple tabs.)


2.  Know the system's init process and how to disable/enable particular
processes' startup at boot-up time.  For most Linux distributions, this
is System V Init, and the startup process is controlled through parsing
of the /etc/inittab file.  For Ubuntu variants, it's Upstart, controlled
by parsing the "jobs" text files in /etc/event.d/.


3.  If your system happens to run a "superserver" daemon (a daemon that
launches other services it controls, as they are requested), xinetd or
inetd, then know how to control what it is and isn't willing to run.
This is less important for RAM usage than for reducing security
exposure, _but_ if it turns out that none of the superserver's services
are actually needed (which is often the case), you can disable the whole
thing, which _does_ save RAM.


4.  (This is absolutely vital:)  Learn how to read the process table.
You really, really need to be able to read the output of, say, 
"ps auxw | less", notice the names, RAM usage, and other details of each
and every process that's running and know _why you want it running_.

The foregoing sentence is probably the key one for this entire posting: 
Particularly on a RAM-constrained machine:

o  You need to know _why_ you're running each process (i.e., know what
   happens if you kill it, and know why that would be A Bad Thing).
o  If a process isn't, in fact, needed, you need to know how it got 
   started, and shut off that startup.  If you don't know, you need to
   find out.
o  In order to understand where the RAM goes, you need to be able to 
   read and interpret the RAM statistics of "ps auxw" or some 
   equivalent command.  In particular, you need to understand what the
   "RSS" and "Shared" columns mean.

I mean, for Heaven's sake, what can be more important on a machine with
very little RAM than making sure it isn't wasted?  And yet, the people I
see helping others do installations, including those on sparse-RAM
machines, seem to have no idea, and don't even try.  That's pretty sad.


5.  You need to understand virtual consoles, and what they are and are
not good for.  I've seen innumerable low-RAM machines set up for Linux
that were essentially falling over from RAM shortage, and _every_ single
one of them turned out to have six virtual consoles running, supported
by "getty" processes that were all grabbing RAM -- which is just crazy.
Now, to be sure, the unused "getty" processes are pretty small and are
probably among the first to get swapped out to virtual memory, but the
point is:  Somebody just couldn't be bothered to disable pointless
wasteage of RAM, on a machine that badly needed it.