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

Rick Moen rick at linuxmafia.com
Mon Jun 9 23:41:03 PDT 2008


(Some more along the same lines:)

Let's recap:  I pointed out that a lot of newcomers to the Linux
community, including those who are going around attempting to help
_other_ newcomers doing installations, seem to have absolutely no idea
how to customise a Linux installation, and simply walk away the moment
the semi-automated distribution installer ends.  I didn't really grasp
the magnitude of this problem until I heard that those "helpers" were
(in effect) telling people that sub-256MB RAM machines could not run
any Linux distribution beefier than the ultra-tiny, extremely limited
Damn Small Linux, Puppy Linux, and similar micro-distributions.

Which, when I heard they were handing out that advice, made me say
"Whiskey Tango Foxtrot?"  Because I thought it was obvious that such
machines, down to 64MB, make perfectly OK Linux machines -- with _real_ 
Linux distributions[1] -- as long as you're careful what you run.

What I was slow to realise is that most of our current crop of "helpers"
_have no idea how_ to be "careful what you run" -- even on a low-RAM
machine where that skill is crucial.  Doing so requires a small amount
of basic knowledge that they simply lack.  In summary:
 
1.  Know your big-ticket RAM-gobbling items.
 
2.  Know the system's init process and how to disable/enable particular
processes' startup at boot-up time.  (System V Init or Upstart.)

3.  Know how your superserver (xinetd or inetd) runs, if you run one,
and know when it's not needed and can be shut off.

4.  (Most important:)  Learn how to read the process table, e.g., 
"ps auxw | more" and "top -n 1 | more".  

  a) Know why you're running each process (what goes "boom" if you kill it).
  b) Know how to prevent (and to reenable) their restart at boot time.
  b) Know how to read ps's RSS and VSZ memory-usage columns, and top's
     VIRT and SHR memory-usage columns.[2]

5.  Know virtual consoles, and how to prune their number.
6.  Take notes on all post-installation changes.


That summary having been said, I thought I'd elaborate on an important
(yet somewhat different) part of item #2 ("know your system's init process"):
X11 configuration.

I keep seeing people who've installed some Linux distro onto a low-RAM
machine to run it as a low-end "desktop" box, and they're mystified and
disappointed that it's so sluggish.  I check the process table, and
there are half a dozen kdeinit or klauncher processes, an X session
manager, an automounter, a copy of dbus-launch, and so on.  

Me:  "Why are these things running?"
Them: <shrug>

This is not good.  If you're working on a low-RAM machine in particular,
but also just in general, you really need to be able to control what you
do and do not run -- and run only what's needed and wanted.

The bad news is:  X11 has always been something of a horrific mess.
Sticking to the traditional Unix-user's setup of a sparse window
manager, no session manager, no "desktop" framework wrappings (a la
GNOME, KDE, Xfce4) will limit the pain, but it's still a mess.

Here is a site that showcases many of your choices for X11 window
manager: http://xwinman.org/

Notice that there are screenshots showing the typical appearance of each
option.  Good starting places include:  fvwm, IceWM, Fluxbox.[3]  The
xwinman.org site also has some good, short, basic explanations about how
X11 works.  http://en.wikipedia.org/wiki/X_Window_System has some OK
parts, too.  Also:
http://en.wikipedia.org/wiki/X_Window_System_protocols_and_architecture

Trying to bring a given X11 setup under control can be frustrating,
e.g., my efforts to get GNOME to be less bloated by autostarting fewer
things was unfruitful for long enough that I decided it wasn't a problem
worth solving, so I moved lateratlly and got rid of GNOME's X11 startup
framework and its bundled window manager (thus eliminating the need to
prune them).

Suffice it to say, one example configuration that is _very_ thrifty of
RAM is:  X boots up into the (antique) "xdm" display manager (the thing
that provides a graphical login screen), which starts IceWM and nothing
else (in particular, no X session manager or "helper apps" of any sort).
Very simple, relatively easy to understand, rock-solid, very low-RAM,
and even pretty attractive, as well.

On recent Debian/Ubuntu builds, I've often found it most expedient to
disable X session management by deleting the symbolic link
/etc/alternatives/x-session-manager .  This fix is unsubtle and there's
probably a better way, but it was simple, worked, and could be easily
un-done if necessary.


[1] Be aware that a distro's installer will tend to have a hard-limit
minimum amount of RAM without which it simply will not run to
completion.  Obviously, you cannot prune down a distro's usage of
resources unless you can first install it, so check distribution
installer requirements before charging in.  (If the news is bad, you may
still find that there's a low-memory mode or alternate installer disk.
Search the Web for it.)

[2] That is, you should get be able to at least roughly guesstimate
whether a process is a hog or not, and how much approximately it's
grabbing.  You don't have to become an expert.

[3] Personally, I like Window Maker, but that's because I have the
rarely-encountered trait of having used and admired NeXTSTep, which
Window Maker intentionally resembles.  





More information about the sf-lug mailing list