[CentOS] 5.3 on an EeePC??

[Warren Young]

nate wrote:
>> (There are even some things the simpler Red Hattish tools can do that
>> the Debian ones can't, easily.  rpm -qa, for one.)
> 
> rpm -qa typically just lists all of the packages on the system,
> the equivalent in debian is dpkg -l.

Not really equivalent.  The output is only sort of greppable.  I 
frequently say something like "rpm -qa |grep -i mysql-", in that 
particular case because MySQL, Inc. keeps changing the way they name 
their RPMs, so I can never remember the exact package name to query on a 
given system when I'm looking at versions to decide whether to upgrade. 
  If the truncated part of a long package name has what you want to 
grep, you won't find that package.

And yes, I do remember RTFMing dpkg(1) and found that you can change the 
output format of dpkg -l to be more like rpm -qa, but I recall that the 
required command was way too long to type each time.  Sure, I can wrap 
it in a script, but then I'm customizing all my systems to add commands 
to it that should have been in the base distro.

Of such minor things are distro choices made.

> A single unified source for patches,
> security fixes etc.

Yes, that's one of the things I take into account when deciding whether 
I want to use Ubuntu for a particular task: whether I need access to its 
huge repositories, or if I can get by with what CentOS provides, plus 
maybe a few third-party add-ons.  Beyond a certain point, the choice 
becomes clear.

This is not the case for most of my server-class machines, however. 
Basics like LAMP and Samba are all I really need in most cases.

> Also the debian package databases are in plain text format, while
> I'm sure it has happened I have never personally heard of someone
> suffering from package database corruption on debian(assuming they
> were running the 'stable' version). Such corruption reports seem
> somewhat common in the RPM world with the binary databases.

It's been many years since I had to run rpm --rebuilddb.  It never did 
fail on me the few times I did have to run it, and the need to run it 
was *always* due to a kernel panic while manipulating the RPM DB, or 
proximate in time to it.  Kernel panics always were rare on stable Linux 
distros even way back in the mid 90s, increasingly rare now, and RPM DB 
updates are rare in their own right.  Rare squared.

> Add to that the well tested ability to upgrade between minor
> and major version numbers time and time again. I don't have to
> hold my breath when I go from Debian 4.0 to 5.0, I can do it from
> remote without ever losing connectivity, I don't even have to reboot
> at the end I can continue running the older kernel if I want.

I like that feature in principle, though I can't think I'd actually want 
it on any of my servers.  On a desktop, sure, but never on a production 
server.  I'd rather keep something creaking along on CentOS 3, running 
the server's tired old hardware into the ground, building a new CentOS 5 
box to replace it in a swift cut-over, rather than upgrade that old box 
in place.

I do like the way Ubuntu LTS works in this regard, though.  It stays 
locked in the LTS jail, mostly as stable as CentOS with regard to 
updates, as long as you just do apt-get upgrade, but you can break out 
with a dist-upgrade to get onto the bleeding edge releases if you really 
want to.  I still can't see myself ever doing that on a production 
server, but I guess it's nice to know I could.

> I've never really been fond of yum myself, though it is much better
> than what was there before(nothing, before rhn at least).

The only thing I don't like about yum is how hard it is to kill an 
in-progress yum update, while it's still in the package downloading 
phase.  Other than that, I greatly prefer it to the wordy apt-foo commands.

> I currently maintain roughly 100 SRPMS

And does your experience line up with mine, which is that the debian/* 
big-tree-of-assorted-files is a mess, nowhere near as clean as 
package-name.spec?