Linux Distributions

[Mike Bilow]

Jerry Feldman wrote in a message to Mike Bilow:

 JF> I have been using Red Hat for the past few years. I would
 JF> like to start a  thread on distribuitons, likes, dislikes,
 JF> religious opinions, etc. 

 JF> Recently, I had to install Debian. IMHO, Debian is a more
 JF> complete  distribution than Red Hat, it takes forever to
 JF> install, and lacks some of  the nice system admin  tools
 JF> that Red Hat supplies.

 JF> I currently have Red Hat installed on my Alpha and my Intel,
 JF> but I will be  installing Debian on my Intel system today. 

I've used both fairly extensively, but I prefer Debian.  I agree that the
"dselect" tool takes forever to run, but that is because of its architecture. 
In fact, deselect is just a front-end for the real "dpkg" tool, which is quite
quick.  I'm sure that dselect could be enormously improved, but it is not
actually necessary except for initial installation or wholesale upgrades. 
Also, dselect is usually run unattended once it is started on its work of
resolving dependencies and installing packages.

Debian is the obvious choice if your main uses involve specialized work where
most of the active developers are themselves using Debian, such as amateur
radio.  Debian also has the "alien" tool which allows installing Red Hat "rpm"
packages, which is very useful.  Debian has more varied installation options,
such as 1.2 MB floppies, and these may be critically important if they happen
to affect you.  Otherwise, Debian and Red Hat are closely matched.

Red Hat is better supported commercially.  If you need that level of support,
then you are not going to get it from Debain at any price.  The idea is that
many companies have policies against using "free" software, so it helps to be
able to point to an invoice for $50 and a nice box on the shelf.  Finally, if
something goes wrong, the Red Hat people will "take the bullet," as they say.

Ironically, given the emphasis placed by Red Hat on commercial situations,
Debian tends to be more stable while Red Hat tends to be more bleeding edge, in
my opinion.  For example, Red Hat was the first major distribution to make the
jump to libc6/glibc for its own binaries, and there were a lot of problems
reported in connection with that early adoption.  Debian only moved to libc6
months after Red Hat had already done so, and had a fairly long period of
testing and bug-fixing in preparation for the release.  This by no means
implies that Red Hat left bugs unfixed, and its second libc6-based release
(5.1) was an enormous improvement over its first (5.0), but you have to be
careful to understand that Red Hat releases may be uneven in quality and tend
to follow that old saw about "x.0" releases never being any good.

On the other hand, Debian tends to lag hardware support.  This can be extremely
annoying, as I found out recently with the Adaptec SCSI drivers that have been
in flux recently.  This was especially embarrassing, as I have long been active
in the development work on these drivers, and I was dead in the water trying to
install Debian.  There are ways around this, of course, but all of them involve
working around the official Debian stuff and building custom installation
disks.  Because Debian is a volunteer effort, sometimes things happen that
would never be tolerated on a commercial project, such as taking a week or two
for someone to get around to moving package updates posted by their maintainers
into publicly accessible areas.

On security, both Red Hat and Debian are pretty agressive about keeping up.  I
consider the default Debian installation to be a more secure configuration than
the default Red Hat installation, but that could be argued.  Certainly, both
are very good about doing all of the basics, such as supporting shadow
passwords, and good security demands going through the configuration and
adjusting to the particular needs of the situation, such as not running servers
through inetd that are unneeded.  But I think I would give a slight edge on
security to Debian, mainly because there is an extensive bug tracking process
that is open and public.
 
-- Mike


***
Subcription/unsubscription/info requests: send e-mail with subject of
"subscribe", "unsubscribe", or "info" to discuss-request at blu.org