Your editor is not always known for the display of large amounts of good
sense. Arguably, this poor judgment is best displayed by the habit of
running leading-edge development distributions on systems which are needed
for everyday work. Development distributions are where distributors create
their next releases; they tend to contain packages fresh from their
upstream sources which are not, always, quite ready for prime time.
As a result of running these systems, episodes like the following are
- Two hours prior to leaving to catch a plane to yet another conference,
your editor decided to do a "quick" update on the laptop system, which
was running the Ubuntu development repository. What followed was two
highly focused hours with a rescue CD bringing the system back to a
point where it would boot and run a presentation.
- Your editor's desktop, running Fedora's Rawhide, started to exhibit an
interesting interaction between Gnash and the X server, with the
result that, at random times, random X clients would be abruptly
disconnected. The old lesson about frequently saving one's work was
well reinforced over the few days it took to track down the problem.
Given that this kind of occurrence is not particularly rare, one might well
wonder why your editor continues to run development distributions on
mission-critical systems. Natural cranial density may well play into this
situation, of course. There are also clear advantages for somebody in your
editor's line of work in seeing where distributions - and the applications
they ship - are headed before they get the "stable" stamp applied to them.
But that does not explain why so many others run these distributions; there
is more to it than that.
When one runs a development distribution, one is immersed in the heart of
the process that makes Linux happen. There are opportunities to help
improve the system (by reporting bugs if nothing else) and to influence
the directions that development takes. The only way to effectively test such a
complex collection of software is to use it in real-world situations; this
testing is a crucial part of the process as a whole. And the truth of the
matter is that software which is under ongoing development is alive in ways
that occasional, stabilized releases are not. It's sort of like having a small
child in the house: development distributions will surprise you every day
with some new ability, a new look, or something totally off the wall and
Of course, again like a child, these distributions will also bring surprises
in the form of an occasional, unpleasant mess to clean up, usually at highly
inopportune times. It's part of the deal.
LWN tends not to run a lot of distribution reviews, mostly because doing a
review which goes beyond commenting on the installer requires using the
distribution for real work over a substantial period of time. Your editor
has, however, been using these two distributions for long enough to get a
sense for the differences between them. So what follows is a review of
Rawhide and Ubuntu (through the Edgy, Feisty, and Gutsy development
periods - your editor has not, yet, had the courage to jump onto the Hardy
train) as development distributions. Needless to say, your editor
will not be making comments on the installation process.
So what does matter to users of development distributions? Clearly, an
issue which will always be at the top of the list is stability. One
expects to get bitten on occasion, but it would be nice if "on occasion"
were as occasional as possible. Getting real metrics on stability of
development distributions would not be easy to do, but your editor can say
this: Ubuntu seems to break more often than Rawhide does, and in more
severe ways. Your editor's Rawhide system has never required
reinstallation from scratch - something which cannot be said of the
laptop. The sad fact is that Ubuntu, for all its qualities, does have a
bit of tendency to ship buggy software; the official releases, too, sometimes
have surprises, especially with the more obscure packages. Don Marti's recent
experience in this regard is not exceptional.
Tracking a development distribution is hard work; one must, to the extent
possible, keep an eye on what is changing and try to figure out when the
most auspicious times for an update might be. Rawhide publishes a single
message daily with a list of updated packages and known dependency problems
(example). Ubuntu, instead, sends out a
separate message for every updated package (example). Either way, trying to follow
everything that changes from one day to the next is an impossible task for
all but the most dedicated reader - the volume is simply too high. So one
ends up starting an update, looking at the list of packages to upgrade, and
trying to decide whether, given the day's requirements, an update is a
sensible thing to do or not. As noted above, your editor occasionally gets
this decision wrong.
Coding coding coding
Tho the desktops blowing
Keeps on near exploding
Brains, wit and pleasure
Wishing our code was not to blame
All the things that we're missing
Typecasts, NULLs and phishing
Are waiting at the end of the day
-- Alan Cox
The Fedora community has a most helpful resource in the form of the
fedora-test mailing list. When something goes badly wrong, somebody will
usually post some sort of anguished cry, allowing everybody who is further
back in the pack of lemmings to decide to skip the update for that day.
Thanks to this list, your editor was happily able to avoid the inadvertent
breaking of the X window system which recently burned a number of Rawhide
users. Even better, Rawhide developers will occasionally post warnings
that a difficult transition is about to happen; for example, Rawhide users
are well advised
evasive action if they care about graphical displays over the next few
weeks. Occasional bad poetry (see sidebar) is a special bonus.
As far as your editor can tell, the Ubuntu community lacks an analogous
list; there is no public forum specifically for users of the development
Package management and updates
Another aspect of tracking a development distribution is package
management. Rawhide's tool for this task is yum. Your editor has
expressed his opinion on this tool before; it is not, shall we say, the
yummiest part of the distribution. That said, yum has improved
considerably in recent times. Some basic caching means that, at least some
of the time, operations like "yum search" no longer allow the consumption
of more than one cup of coffee before they complete.
The under-publicized skip-broken plugin allows a system
to be updated even if an obscure package is uninstallable because of a
dependency problem (and Rawhide frequently has dependency problems). Your
editor no longer remembers when it was last necessary to remove rpm's cache
files by hand. Most of the time, the yum/rpm combination works well enough
these days - at least for those of us who are not in a hurry and have a lot
Ubuntu, of course, uses apt and dpkg. These tools, in many ways, remain
nicer than their rpm-based equivalents. Apt is faster and seems to be
smarter about complicated updates - though one must still watch closely
when doing a dist-upgrade (often necessary with development distributions)
to ensure that apt does not stealthily remove crucial packages. Tools like
dpkg-reconfigure are most nice to have when an update causes, say, one's
mail configuration to take a strange turn. All told, Ubuntu's Debian-based
package management tools still are nicer to work with, though the gap is
One interesting difference is in the handling of configuration file
updates. RPM-based distributions will, when faced with an updated
configuration file, put the new version in the target directory with a
.rpmnew extension. Except when they, instead, replace the file
and leave the old one with a .rpmsave extension. Except when they
use .rpmorig instead. Your editor's system currently has 106
.rpmnew files, 41 .rpmsave files, and 103
.rpmorig files under /etc; your editor has no clue about
what changes might be indicated by any of them. A diligent user will, of
course, read the update log and carefully look to see what has changed
whenever one of these files is created. The rest of us just never notice
until something breaks, at which point we go in to try to figure out, say,
why printing no longer works.
Ubuntu, true to its Debian roots, halts the update process and asks the
administrator what to do. Except, on occasion, where it just silently
replaces some vital configuration file with a non-working version.
Fortunately, that does not happen very often, but there is a much more
frequent problem which afflicts all Debian-based distributions: it will
often stop and ask what to do about configuration files which have never
been changed by anybody. In cases where the file has never required
intervention, it would sure be nice not to have to tell the system
explicitly that the replacement does not require intervention either.
But it must be said that it is better to err on the side of asking what to
do than to silently install (or drop) configuration file updates.
In general, Debian-based systems have traditionally been seen as being easier to update -
especially from remote repositories - than RPM-based systems. Your editor
has not really found that to be the case here, though. The desktop Rawhide
system started at Fedora Core 2 and has never seen an installation CD
since. As mentioned above, the Ubuntu system has required a couple of
reinstallations. Ubuntu has, unfortunately, earned a bit of a reputation for
upgrade-related problems; somewhere in the process of civilizing Debian,
that distribution's robust upgradability has suffered.
Of course, Rawhide is not perfect in this regard. Your editor still has
not had the time to figure out why the PulseAudio transition has left sound
in a problematic state, for example. Gracefully replacing core
infrastructure on a running distribution is simply not an easy thing to do.
With regard to the variety of packages available, Ubuntu used to have a
huge lead. When the full set of universe repositories is used, this
Debian-based distribution still offers more packages than Rawhide does. In
the recent past, Rawhide was, to a great extent, limited to the set of
packages offered by Fedora Core. The separate-but-unequal "Extras"
repository filled in some of the gaps, but, for the development
distribution, Core and Extras were often inconsistent with each other and a
system using Extras packages tended to be hard to update. Now there is
only one repository and life is better. Your editor has always made a
point of having something Debian-based around just because almost any
package of interest was only an apt-get away. But now it is rare that a
desired tool cannot be found in Rawhide.
Whether one can get the current version of a given program from
either of these repositories tends to be a hit-or-miss proposition. Both
distributions freeze updates as their release dates approach, with the
result that, near the end of the cycle, the packages on offer tend to lag behind what is
available upstream. Ubuntu is rather more aggressive than Rawhide, though,
in shoveling quite-new software versions in shortly before its release
dates. It's worth noting that the Fedora project appears to be planning to
change how Rawhide works starting with the Fedora 9 cycle; the
stabilized distribution and Rawhide will fork much sooner, allowing Rawhide
to blast on ahead during the later stages of the distribution cycle.
Both distributions, sometimes, seem to be a bit over-zealous in
churning packages; your editor has never understood why large packages like
dejavu-fonts or the OpenOffice.org language packages (or just
OpenOffice.org) seem to require daily, bandwidth-sapping updates.
For people who want easy access to packages containing patent-encumbered or
non-free software, Ubuntu will clearly work better. Repositories with that
kind of stuff are configured from the outset and the pieces fit together
nicely. Rawhide users must go to third-party repositories - a move which
is likely to introduce dependency problems and make updates harder to do.
Meanwhile, this aspect of Ubuntu is, for better or for worse, likely to
make life easier for those who want to run a development distribution on a
Your editor tries to make a point of changing distributions on occasion,
just to have a good feel for what is out there. The two development
distributions discussed here are far from the only ones out there. Others
worth of consideration for any willing victim include:
- Debian sid,
which has long been the definitive development distribution. Many
developers have been running sid for many years and have never looked
for anything else.
- Gentoo. The last time your editor
attempted to install Gentoo was some years ago on a very slow system.
A few days later, it was still building packages. There is, however,
a large group of users (with faster machines) who swear by this
- Mandriva's Cooker appears to
have an active and growing user community.
When looking at the major distributions and their associated development
versions, one is struck by one significant absence: there is no development
repository available for SUSE Linux. There is an occasional openSUSE
development release, but no access to the current development repository.
As a result, SUSE misses out on the sort of active user and testing
community that these other distributions have. Update: some
commenters have pointed out the openSUSE Factory distribution,
which your editor obviously missed.
Your editor does not wish to choose a winner among the two development
distributions here, much less try to compare them with the other available
distributions. One can certainly have a fun, useful, occasionally
thrilling ride with any of them. The best thing for anybody with the
requisite interest, technical skills (especially in the disaster recovery
area), and calm disposition is to pick one and jump into the game. There's
no better way to get into the process that creates Linux.
to post comments)