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

[jim]

excellent pointers! 

seems to me there are three "times" of which to be aware: 
* pre-install time 
* install time 
* post-install time 

Pre-install Time 
   pre-install time is research time. choose your distro. 
my advice is to weight heavily the distro used by people 
you know or to whom you have access. ubuntu seems the 
likely choice for sf-luggers these days. 
   try to get to a machine that's got your chosen distro 
on it and see what's there: 
- in a terminal window use 
$ ps auwx | less  # jim uses more, but he's an antique \
  # you'll get output where the first line looks like this 
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
in the subsequent lines, look at the fourth field to 
see what percentage of memory each process is taking. 

- use the internet and the list and all friends 
to identify low-ram alternatives to the piggiest 
processes. 

- do other research, like what will be the purpose 
of the old machine? 

Install Time 
   Install time is when you put the CD or DVD in 
the old machine and start the installation process. 
   be attentive to partitioning. is the hard drive 
greater than 20GB? if so, you have enough room for 
most purposes. if not, you might need to partition 
defensively (put /var/logs/ in its own partition 
and maybe put /home/ in its own partition and put 
/boot/ in its own partition and ensure that the 
partition for /boot/ is the first partition). 
   choose packages individually. don't make blanket 
choices such as All or Minimal. do you need X 
windows? if so, what window manager will you want 
and is that on the installation media or will you 
have to download it later? what servers do you need: 
sshd might be handy, but other servers? 

Post-install Time 
   Post-install time is after the installation and 
things are running. 
   immediately after you've got your distro installed, 
you might have to download other software, such as a 
light-weight window manager. 
   also you should take a close look at the process 
table to see how many processes are running and how 
much memory each takes for this installation (don't 
take the word of the other, pre-install box). 
   my ubuntu machine has an /etc/init.d directory 
with /etc/rc?.d script directories. i'm new to 
ubuntu, so i'm gonna have to learn what's in them 
and where in the ubuntu /etc/ directory is the 
file that sets the gettys running: i'll want to 
reduce their number. 
   i'll regularly want to watch the /var/logs/ 
directory, inspect the /proc/ directory, and monitor 
memory and overall disk usage. crikey, that's a lot: 
i'm gonna be a system administrator if i actually do 
all that. or a linux power user. or a competent QA 
technician. 

   now that i've exposed my ignorance and wrong 
headedness, i'm sure others will come in blasting: 
i hope so, as i find that behavior entertaining 
and informative. 



On Sun, 2008-06-08 at 23:51 -0700, Rick Moen wrote:
> 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.
> 
> 
> 
> _______________________________________________
> sf-lug mailing list
> sf-lug at linuxmafia.com
> http://linuxmafia.com/mailman/listinfo/sf-lug
>