A Red Hat user's introduction to Debian

> Why have you switched to Debian? What is the main advantage of Debian
> over RedHat? Or in other words "why do you like it so much?"

First, lets talk technical details. For example lets take the dependencies engines of RPM and dpkg. An RPM package can "require" another package. For example any program will require libc6. A Debian package, in addition to "requiring" a package, can "suggest" or "recommend" one. For example, the apache package suggests you the apache-doc package. This means that when you select the apache package a window appears, telling you that there are related packages you might want to install. This is very useful.

Another feature is the "alternatives" idea. Here's an example. There are many clones of the vi editor. When you type "vi", one of them should be launched. If you have several installed, which one will it be? In Red Hat there's no standard way to specify it. Some vi clones will install a binary with a different name than "vi", and make a symlink from that to "vi". Others will just install a binary named "vi".

In Debian, however, mess is not accepted. /usr/bin/vi is a symlink to /etc/alternatives/vi. That, in turn, is a symlink to your actual preferred vi binary (say /usr/bin/vim). When you install a new vi clone, it redirects the /etc/alternatives/vi symlink to its binary. When you uninstall it, it redirects it back to another vi clone you have installed (if you do). The same mechanism is used for man pages as well (so that when you type "man vi" you actually get the man page of the vi clone you're currently using).

Yet another feature is menu-methods. It is a mechanism for programs to add themselves to your window manager menus, similar to the way it is done in Windows. I vaguely remember a similar thing in Red Hat (wmconfig?), but I never saw it working. In Debian I never saw it not working. The reason for that will be explained further on.

There are other issues, such as better naming conventions for libraries (the name of the package contains the major version number of the library - this way you can easily have multiple versions of the same library installed, a very useful thing), and many other features, but I want to move on to the more important stuff.

There are subtle differences between the organizational models of packaging software in Red Hat and in in Debian, and IMHO they are very important. Lets look at a typical Red Hat installation.

First, there is the core Red Hat system that you get on the CD. These are RPMs that are created by the Red Hat employees and include all the most important software (base utilities, compilers, the X Window System). The CD also includes a lot of other software. But most of the time, if you do all your work in your Red Hat system, you need other programs that do not come with Red Hat. If you want a window manager that is not included (say Window Maker or Enlightenment) you have to get it separately. There is a lot of other software you'd want to get. So what you do is go to the nearest Red Hat "contrib" mirror and download the needed packages. The "contrib" is the place where people that create RPMs for their favorite programs upload them.

There are several problems with this approach:

1. New versions of programs that come with the distribution are released very rarely. If you want to use the latest version of the compiler, you have to wait until the next release of Red Hat. Even then they do not always include the latest version of the software.

   This is partially solved by Red Hat's new RawHide distribution. It's similar to Debian's "unstable" tree, which means that new packages that are to go into a future release of the distribution are placed here for testing. However I noticed that even RawHide isn't always updated as well. (For example version 1.0.2 of egcs stayed there for a very long time after 1.0.3 was released.)

2. If you take the latest versions of basic utilities (such as the compiler, util-linux, libraries and so on) from the contrib, expect to get broken RPMs. Outside people don't know to build RPMs as well as the Red Hat people do. I myself got burnt by this once, and that was enough for me to learn the lesson.

3. Programs that do not come with the distribution have to be downloaded separately. Red Hat omitted very important software from the distribution such as XEmacs, probably in order to lower support costs. (This is one of the points where Red Hat being a commercial company whose bottom line is to bring a revenue actually disturbs.)

   Here we're back to problem 2: software that you download from contrib is often broken. This is not to say that anything you download from there will wreak havoc in your system, there are many good RPMs, but the fact that amateur people from the outside create them, without any obligation to make them right, is very well felt. There are a few packages there that are packaged twice, under different names. You may also find out when you're about to upgrade a contrib package, that the new package was not packaged by the same person that packaged your old version. This often means that the upgrade will not be easy and clean.

   In other words, the disorder prevails.

Debian's model of packaging software is substantially different. Since Debian is a voluntary organization, there's no limit to the number of possible Debian developers, because they are not paid. Therefore, there's no "contrib" in the sense of Red Hat.

In Debian, anyone who packages software is a "Debian developer", and his packages go into the distribution. Becoming a Debian developer is not just a matter of creating a package and uploading it to Debian (like with Red Hat's contrib). You have to sign up and be approved. After you are approved, you take the task of maintaining a particular software package. (You can take more than one of course.) This means that noone else packages it, and you are responsible for creating packages for this program and supporting them (that is - receiving bug reports about the packaging via the central Debian bug database, and fixing them). This package then becomes part of the distribution.

When you create the package, you have to follow the strict packaging guidelines, which make sure that your package works well with the rest of the system. (Noone holds a knife to your throat on this, and "the boss" doesn't come at night to check that, it's assumed that people who signed up and were approved are responsible enough - and the experience says this scheme works.)

This system has many advantages. Lets go back to the problems I outlined with Red Hat's way of packaging.

1. Since the developers that make the packages are also using them themselves, new packages of software appear very soon after the software is released. This of course depends on the developer, but from my experience it is very quick on the average.

2. Not relevant due to 1.

3. Since there are enough developers to pack most of the software that is out there, there are almost no "rogue" packages, or packages that come from outsiders. I know for myself that almost any software I wanted to download was already packaged by Debian. If you find a piece of software that is not packaged, you can either suggest the developers to package it (via the debian-devel mailing list), or become a Debian developer and package it yourself. This implies coordination and cooperation between the people that create packages. That's what allows for things like menu-methods to work. Since all the window managers are packaged by Debian developers, and not by "just" people out there, they all make sure to include a menu-method for their window manager in their package.

This creates a distribution that has all its parts working well with each other. Since there are a lot of developers and a lot of software packaged, the distribution becomes very big. Debian 2.0 includes over 1500 software packages, and the binaries alone take a whole CD. Debian 2.1 is said to be so big that even its binary packages don't fit on a single CD anymore. IMHO this is an advantage: CD media is very cheap, certainly much cheaper than downloading from the Net.

Finally, to summarize: while Red Hat has its advantages as a small distribution with a simple-to-understand packaging system, its disadvantages that include poor management of contributed efforts, slow updates, and that same simple packaging system, make Debian a much more attractive system for myself, and hopefully for you too.

Resources:

Red Hat	http://www.redhat.com
Red Hat's contrib packages	ftp://contrib.redhat.com
Debian	http://www.debian.org
Packages in Debian	http://www.debian.org/distrib/packages