[conspire] I7000

[Rick Moen]

Quoting Edmund J. Biow (biow at sbcglobal.net):

> Yes, I've been bit by the lack of 686 extensions by the Cyrix CPU
> before, lots of Linux CDs just reboot as soon as they get to the grub
> screen, particularly the Fedora/Redhat/CentOS line.  Luckily, Debian
> and Ubuntu still retain i386 kernels (actually, a bit of a misnomer,
> since the i386 Debian Linux kernel requires at least a 486, IIRC).

It used to be a standard workaround to cobble together a custom boot floppy
-- back in floppy days - to modify a distro installer to use a custom
installation kernel.  These days, most distros aren't all that difficult
to remaster, i.e., unpack the boot ISO, replace the kernel, re-do the
image's bootloader, and put the image back together to re-burn to disc.
Of course, that's not a really great way to do it, and you have to
remember to put in a real, runtime kernel at the end of installation.

Searching on distro names plus "remaster" is often enlightening, e.g.:

http://news.softpedia.com/news/How-to-Create-a-Fedora-10-Linux-Distribution-101164.shtml
http://wiki.debian.org/DebianLive/Howto/ISO_(multimedia)
http://wiki.mandriva.com/en/Development/Howto/Remaster_ISO
http://blog.mypapit.net/2006/12/remaster-and-customize-ubuntu-cd-with-reconstructor.html

> Well, I'll give it a shot with my back porch Via Ubuntu LXDE machine
> and report back.  What other programs besides rcconf/sysv-rc-conf and
> removing extra programs should I be looking at?  I don't need more
> than 2 TTYs.  Maybe using sysctl to reduce swappiness would help.  I
> actually have plenty of RAM on that rig but I think that install still
> tries to use the swap partition.
> http://lifehacker.com/software/feature/slim-down-and-speed-up-linux-333798.php

I'd really just go down through the process list -- "ps auxw | grep more" 
-- and make sure I understood each and made a conscious decision that I
had a compelling reason to run each.

It's an instructive exercise:  It teaches you quite a bit about your
system.  

Do take the trouble to (at least temporarily) strip down your X11
startup and see what the process table looks like with, say, just the X
server and a simple window manager running.

The easiest way to do _that_, in turn, is to temporarily disable startup
of your X display manager (gdm, kdm, xdm, or whatever) and reboot.  Your
system will now boot up to a non-X11 runtime state, where you can login
to the console and (whenever you like) start an X session by running
"startx" from the command line.  Exiting or doing Ctrl-Alt-Bkspc will
end the X session and take you back to the command line.

If you create an ~/.Xclients file specifying one or more X11 program,
"startx" will run those and those only (other than the X server).  So,
back when I did this experiment, I started out with /home/rick/.Xclients
saying only:

xterm 

...Then, do "startx".  What results is startup of the X server with
exactly one client applications, xterm, with no controls or
decorations, and with pointer focus (such that you can type in it). 

The first thing you'll want to type in that xterm is "ps axuw | more",
so you can see what the process table for bare-bones X11 looks like.
Note1:  It is strongly in your interest to figure out how to best
interpret the "RSS" (Resident Set Size) and "VSZ" (virtual size)
columns, just as it's very useful to learn to interpret the RES, SHR,
and VIRT columns in "top" output.   Note2:  It's easy to misinterpret
the figures for RAM usage of the X server process, because reported RAM
for _that_ specific process includes video memory it uses (so, reported
RAM usage is significantly overreported).

That's an approximate way of stating the matter.  Here's a more-exact one:
http://www.xfree86.org/pipermail/forum/2003-April/003370.html

Anyway, you might think that a control-less xterm window sitting in the
middle of a featureless, mottled X11 display is pretty useless, but you
get quite intriguing results by typing things like this in the xterm:

wmaker &

(That assumes that you have the binary for the Window Maker window
manager installed and in the execution path, e.g., /usr/local/bin.)

Suddenly, you see Window Maker decorations, and Window Maker controls on
the sides of the xterm, and have access to Window Maker menus and
similar things.  Re-running "ps auxw | more" and "top" for comparison's
sake is interesting, too.  (The "&" puts the wmaker process into
background, ensuring that you get your command prompt back without
killing the wmaker process.)

Typing 

killall wmaker

...brings you back to the situation of running just an unadorned xterm
(and X server).  You can then compare what you get by running different
window managers, e.g., fluxbox, blackbox, icewm, and so on.  See which
tend to launch subsidiary processes, and which are modest in RAM
requirements, etc.

And, yes, by all means prune back the number of getty processes for
virtual consoles.  Back to one, if you're really trying to save RAM.


> Depends on your needs. I have a friend who scrambled Windows 2000 by
> installing a defective stick of RAM.  I sent him a 200 MB Slax
> (Slackware based KDE) CD so he could get his data off of it and
> reinstall Windows. 

Slax is very small, but I hear that it is _not_ limited in its design, 
but rather scales up nicely as needed.  

Of course, since it's a variant of Slackware, it's not like there's a
lot of distro scaffolding to _omit_.  ;->  

But, anyway, I was specifcally _not_ talking about utility uses such as
copying data off a damanged MS-Windows installation, or bulk-copying
partitions, or data recovery, or security forensics, or anything like
that where you aren't creating an installed Linux system that you intend
to live with.  I was talking very explicitly about discs from which one
aspires to create an installed, run-from-HD Linux system on a
non-pathetic (4 GB or larger) hard drive.
 
> The Seamonkey version of Puppy is quite a nice environment for light
> web surfing & multimedia.  There is even a version called Mediapup
> that will load in to RAM on systems with 512+ that is designed for
> video editing and DVD authoring. kino, avidemux, k9copy, GIMP, etc.,
> though I doubt it compares favorably to ArtistX if you have modern
> hardware.

That's nice -- but the point is that you can do better with something
actually designed to be a real, non-micro Linux distribution, by simply
picking and choosing what you actually run, instead of resorting to
an incredibly tiny distro strictly so that the _default_ runtime process
set doesn't overtax low-spec hardware.

> Puppy's repository is very limited, but I understood that DSL is
> actually  a very stripped down Debian based on the 2.4 kernel.  I've
> seen references to people even upgrading it to use the big windows
> managers, though I wouldn't recommend it.

No, you really don't want to.  Going by my experience with several micro
distributions, you really do start running into problems when you try to
scale up and converge towards a mainstream distro

[Linuxcare BBC:]

> I still have one of those.

As an ex-Linuxcare guy, glad you liked it.  (Nick and Deirdre were
Linuxcare staff, too.)

Both it and released versions of the subsequent LNX-BBC disc are
unfortunately lagging behind newer hardware.  (Ditto the ILUG fork.)

And yes, these days, I'd rather just put a distro on a flash drive.