[vox-tech] Installing a desktop upon my laptop

[Rick Moen]

Quoting Ken Bloom (kabloom at ucdavis.edu):

> I don't know anything about this. I haven't needed to Debian hardware
> detection in a while.

The matter came up previously on vox-tech two years ago -- leading
directly to a broader discussion among the Linux Gazette "Answer Gang".
I've archived my part of it, here:

"Hardware Detection" in http://linuxmafia.com/kb/Debian/ 

Essentially, the Official Debian installer (yes, there most certainly
_are_ others[1]) through 3.0/woody deliberately did _not_ do a great deal
of hardware autoprobing, in order to ensure that it's installable on a
huge range of hardware, including hardware that tends to freeze up
installers when poked by autoprobers.

I guess it's expected that, if people _want_ autoprobing, they'll
install the numerous optional autoprobing-code packages -- and only then
carry out final setup steps such as configuring sound and X11.  Here are
the ones I know of:

o  discover: hardware identification system (thank you, Progeny Systems, Inc.)
o  mdetect: mouse device autodetection tool
o  read-edid: hardware information-gathering tool for VESA PnP monitors
o  sndconfig: sound configuration (thank you, Red Hat Software, Inc.)
o  hotplug: USB/PCI device hotplugging support, and network autoconfig
o  nictools-nopci: Diagnostic tools for many non-PCI ethernet cards
o  nictools-pci: Diagnostic tools for many PCI ethernet cards
o  mii-diag: A little tool to manipulate network cards

The read-edid and (if I remember correctly) discover packages will make
X11 setup "smarter".  Of couse, it's also possible that some of these
packages' code can (in rare cases) seize up your machine if they poke
option ROMs (etc.) the wrong way -- but I think the attitude is that
you'll know what you were getting into.

The late-beta-stage 3.1/sarge Official Debian installer relaxes this
attitude a bit, and does a fair amount of autoprobing by default.

Note that "sndconfig" doesn't do ALSA, only the old oss-free kernel
drivers.  I don't know if there's a hardware-autoprobing package for
ALSA.  ALSA has always been a pain in the rear for me, so far.

> > 3) Its kinda slow.  I'm running a 1Ghz pentium III, 384 MB ram, 5400
> > rpm drive.  It takes something like 10 seconds after I enter my
> > userid into GDM before I get my desktop

Causes for this fall into two categories.  One is easily under your
control, the other less so.

1.  Prune what gets started at boot time.  Did you really _want_ all
that stuff loaded into RAM just because you turned on the machine?
Among other things, Debian tends to assume that, if you install a
network daemon, you want it running by default.  (I wish it wouldn't do
that.)  Best way to fix this is to install package "rcconf", fire up the
binary of the same name, and start unchecking checkboxes for services
you do _not_ want running, even if they are present on the system.

2.  The fact that Debian, by default, does _not_ do prelinking of
binaries, stripping of debugging symbols from binaries, and tweaking of
most binaries' compilation options for the exact CPU architecture,
omitting frame pointers, etc.  Let's take those one at a time:

a) Prelinking.  This ensures that shared libs get loaded early, and can 
lead to quicker load times.  On the downside, any time you upgrade any
package that links to a particular shared libs, you have to go through a
relinking process.  Any time you upgrade the lib, you have to relink all
of the apps that call it.   This maintenance shuffle gets wearying,
fast.

b) Stripping.  Stripped binaries are smaller, hence faster to load.  
They're also completely impossible to get debugging information from,
if/when a bug blows them out of memory.  People who try to actually
_maintain_ a distribution tend to think that running stripped binaries
is a bad tradeoff.

c) CPU optimisation, and other compiler options:  Fabulous claims 
abound concerning improvements available from this-or-that CFLAGS
settings prior to compilation.  Those of us who've been around the block
a few times tend to take those with a big grain of salt, because we've
found out for ourselves that few binaries benefit much, for lots of
reasons, and you mostly end up spending colossal amounts of time fooling
with compiler options and waiting for compiles to run.

Yoper is a very nice desktop distribution, making use of all three of
the above techniques.

Although Debian isn't ideally designed for recompiling packages from
source with tweaked build options, but the facilities are there.  For
starters, install package pentium-builder, which lets you set
system-wide CFLAGS for subsequent package recompilation.  There are more
tips in my old, disorganised http://linuxmafia.com/debian/tips file.


Oh, I forgot to mention:  Many if not most people who install Debian
using one of the official installers completely forget to install a
kernel-image-* package suitable for their architecture, and thus end up,
by default, using a really fairly awful and generic kernel image copied 
(for lack of a selected kernel) from the installer media.  If "dpkg -l |
grep kernel-image" returns null, then you too have made this mistake.

> > Can anyone suggest a route for installing on my laptop that will
> > help me detect/identify all the components on my laptop (network
> > card, wireless card, ir port, monitor, sound card...), give me a
> > nice slim install, and ideally use APT for software administration

Some people like Xandros Desktop OS Open Circulation Edition for that.
Me, I just use any old netinst installer for Debian sufficient to
bootstrap the distribution minimally, install the hardware-recognition 
packages, and build up from there.

> G'mar Chatima Tova

May you, too, be written and sealed for a good year (but I'm just a
goyish ex-kibbutznik, mind you).

[1] "Installers" on http://linuxmafia.com/kb/Debian/