[TAG] Distro choice for an old laptop (was: ISP email goes down in flames)

[Rick Moen]

Quoting Adam Engel (bartleby.samsa at verizon.net):

> Now that you've brought it up...I'm looking for a new distro, possibly.  
> My nine-year-old Dell Inspiron is no longer inspired or even "on," so  
> I'm looking for a basic no frills desktop for work -- vim, Open Office,  
> Firefox, Thunderbird, Abiword on top of KDE or GNOME or both -- plus  
> WindowMaker, FVWM etc. for mood swings, and "play" -- trying to learn  
> Shell Scripting and Perl, and Networking at the "hobbyist's" level,  
> i.e. just for play, not pay or necessity like the basic word-processing  
> tools and email/web connection.

A vital datum in making this choice is the nature of your hardware.  We
can probably _guess_ how much RAM, CPU power, and disc space is in, or
can be justifiable added to, a 1996 Dell laptop.  Maybe you might have
48-64MB of RAM, a P233, and a 2.1GB hard disk?  And upgrading that would
be somewhere between impractical and economically unjustifiable?

It's a shame to have to _guess_, on that matter.  It would have made
things a lot easier if you'd spilled the beans -- if only bending as far
as including the model number.  ;->

Unless/until you can beef up your 1996 wonder to, oh, 128MB RAM (which
probably doesn't make a bit of sense economically), I'd say
OpenOffice.org is out.  Ditto KDE and GNOME.  And even Firefox will be
tolerable but only barely.  If you skip KDE/GNOME/OO.o, and use the
likes of Window Maker / Blackbox / Fluxbox / Icewm, the rest will work,
though you'll have to be careful about minimum RAM required for some
distros' installer programs.

> For me, the difference between one distro and another is basically 
> the install.  

Wow, that's a depressing thought.  It's sort of like saying that, for
you, the difference between takeout food from Kentucky Fried Chicken and 
takeout food from Sardi's is basically the way their delivery people
dress.  ;->

I don't mean to mock your installation problems.  I'm just saying that
it's depressing to contemplate having such problems, there, that the 
more truly significant and _interesting_ differences aren't even on the
horizon, yet.


> I was using Redhat 6 for a while, then two years ago received SuSE 9.0
> as a xmas gift and was happy not to have spend days with HOWTOSs and
> manuals trying to get everything up and running.  YaST took care if
> the whole deal in a few hours.  But after the initial installation, I
> found the whole package management system a hindrance rather than a
> helper, and prefer to just download the source files when I need an
> upgrade or new application.

To paraphrase Jamie Zawinski, again:  "Occasionally, someone has
difficulty with a package regime and thinks:  'I know!  I'll download
source files from upstream and compile the stuff myself.'  Now, he
has two problems."

Or, to quote the guy I shave
(http://linuxgazette.net/118/weatherwax.html#1):

  While it's useful and worthwhile to know about a program's "upstream"
  development site, where (among other things) the author's latest source
  code can be downloaded, there are a few disadvantages that should be
  noted, (and some alternative locations that should be usually be
  preferred, instead, if such are findable):

  1. Absent extraordinary measures on your part, your Linux distribution's
  package-tracking system won't know about the program's presence on your
  system. Therefore, it won't know to avoid installing conflicting
  programs, removing libraries it depends on, etc.

  2. You won't get any tweaks and enhancements that may be normal (or
  necessary!) for applications on your Linux distribution  unless you
  yourself implement them. You won't get security patches, either, except
  those written by the upstream author.

  3. Along those same lines, the desirable version to compile and run may
  well not be the author's latest release: Sometimes, authors are trying
  out new concepts, and improvements & old bugs fixed are outweighed by
  misfeatures & new bugs introduced.

  4. As a person downloading the upstream author's source code directly,
  you have to personally assume the burden of verifying that the tarball
  really is the author's work, and not that of (e.g.) a network intruder
  who cracked the download ftp site substituted a trojaned version.
  Although this concern applies mostly to software designed to run with
  elevated privilege, it's not a strictly academic risk: Linux-relevant
  codebases that have been (briefly) trojaned in this fashion, in recent
  years, on the upstream author's download sites, include Wietse Venema's
  TCP Wrappers (tcpd/libwrap), the util-linux package, sendmail, OpenSSH,
  and the Linux kernel (CVS gateway's archive, only). Unless you are
  prepared to meaningfully verify the author's cryptographic signature  if
  any  on that tarball, you risk sabotaging your system's security.

  All of the above are problems normally addressed (and the burden of
  solving them, shouldered) by Linux distributions' package maintainers,
  so that you won't have to. It's to your advantage to take advantage of
  that effort, if feasible. The memory of when a thousand Linux sysadmins,
  circa 1993, would need to do all of that work 999-times redundantly, is
  still fresh to us old-timers: We call those the Bad Old Days, given that
  today one expert package maintainer can instead do that task for a
  thousand sysadmins. And yes, sometimes there's nothing like such a
  package available, and you have no reasonable alternative but to grab
  upstream source tarballs  but the disadvantages justify some pains to
  search for suitable packages, instead.

  Depending on your distribution, you may find that there are update
  packages available directly from the distribution's package updating
  utilities, or from ancillary, semi-official package archives (e.g., the
  Fedora Extras and "dag" repositories for Fedora/RH and similar
  distributions), or, failing that, third-party packages maintained by
  reputable outside parties, e.g., some of the Debian-and-compatible
  repositories registered at the apt-get.org and backports.org sites.
  Although those are certainly not unfailingly better than tarballs, I
  would say they're generally so.

  The smaller, less popular, and less dependency-ridden a package is, the
  more you might be tempted to use an upstream source tarball. For
  example, I use locally compiled versions of the Leafnode pre-2.0 betas
  to run my server's local NNTP newsgroups, because release-version
  packages simply lack that functionality altogether. On the other hand,
  that package's one dependency, the Perl PCRE library, I satisfy from my
  distribution's official packages, for all the reasons stated above. 

For more along those lines, see Karsten M. Self's observations:
http://kmself.home.netcom.com/Rants/spyware.html#cultural


>  That said, it seems like the real difference for me between one distro  
> and another would be the package management system for installation and  
> quick jump-start (partition, connectivity etc.) of a new system.

Not really.  The existence and application of an overarching policy 
is much more important, for one:
http://twiki.iwethey.org/Main/WhyDebianRocks

> I was thinking of switching to Debian, which I'm somewbhat familiar  
> with because the Mac OS uses DEB rather than RPM, an earlier TAG  
> discussion regarding Gentoo pointed out some problems I was not aware  
> of.

As discussed at the link above, .deb package format is the _least_
significant aspect of Debian.


> Also, there's the above-mentioned Mandriva, Slackware, etc.   I  
> frequently go to the Debian site for  updates/info etc. which is a plus  
> for them -- I think.  But then, I mostly go to GNU for upgrades or new  
> apps...

Which, for reasons cited above, is bad strategy, generally.

> ...so again, I'm wondering what the real difference is beyond the  
> Deb or RPM package managements systems.

_Oh_, what an excessively large subject that is.  {sigh}

You might want to spend some time reading pages at Distrowatch, to get
the general flavour of various Linux and *BSD systems.

> Sage advice, anyone?

Well, let's be serious:  We're talking about a 1996 laptop.  My 1998
Dell Inspiron 7000 (PII/366, 128MB RAM, 8GB HD) isn't very practical 
anymore because the hardware is so relatively feeble -- and in fact is
currently spending time dead, for about the third time, until I have the
time and nerves to disassemble it and figure out why power isn't
reaching the battery.  Don't forget:  Everything in that beast of yours
is not only small and slow, but also _old_.  It may not have much
service life left.  Hard drives aren't the only parts that just bug 
out, eventually:  Old boxes die the death of a thousand cuts.

Trying to install open-source OSes on i386 laptops can be challenging, 
because of the peculiar chipsets they sometimes use, and the increased
importance of doing difficult subtasks like software suspend.  That's
why the Linux on Laptops site exists, to pool information.  (In fact,
you might want to search down http://www.linux-on-laptops.com/dell.html
to find your model or one like it.)  Trying to install those OSes on
_low-spec_ i386 laptops is super-extra challenging.  I'm thus not at all
sure that you're trying to solve the right problem.

So, my advice is:  Look around for a three-to-five-year-old ThinkPad,
used.  They should be cheap.