[ Note: this is an unfinished draft, patches welcome ;) ]


The Debian project maintains a great Linux distribution.

Why create yet another Debian derrivative? Because we can.

Ok, seriously: Because we think that in some details the Debian project does not do the best possible thing.

The Details that matter...

The following is an attempt to break the details that matter to us into three categories: the distribution part, the backports part, and the live part.

Please note that the examples below are highly subjective, incomplete, in no particular order, and they might hopefully not even be a problem anymore. However, they were randomly choosen out of all the changes we have done. Most importantly they are intended to illustrate categories of problems we experience and not to blame individual persons.

A complete list with all changes can be found in the respective distribution changes lists for stable, stable-backports, and unstable.

1. The Distribution

Decision Taking

Sometimes because of political reasons within the Debian project, sometimes because of being bound to build an universal operating system, the Debian project is not able to make some decisions where we believe it is important.

Feature Fixes

The Debian Release team mostly allows strict bug fixes only to a stable release. In general this certainly is the right policy. However, there are some non-intrusive features that would be very nice to have but which can not be managed to get into a released Debian stable release.

License Interpretation

The Debian project has a long tradition of dealing with software licenses. In some cases, the Debian projects chooses to follow a distinct minor opinion in an interpretation of a license where we choose to follow the majority opinion instead.

Maintainer Inertia

The Debian distribution is developed by volunteers. Sometimes it can be very hard to make certain goals happen, especially when requiring changes to more than one package at the same time.

Maintainer Mercy

In the Debian project some improvements are entirely at the mercy of individual package maintainers and can not be integrated without their consent (overruling maintainer via the CTTE is theoretically possible but is not always the right thing to do).

Package Defaults

The Debian distribution has most of the time sane defaults. However, in some cases we disagree with the defaults choosen.

2. The Backports

User Friendlyness

The Debian Backports team has made a few unfortunate decisions that makes the Debian Backports archive not as user friendly as it could be.


Some of the high interest packages in the Debian Backports archive are not well maintained.

Some of the backports of high interest in the backports.debian.org archive are not maintained as predictable and well as it should be (such as the kernel packages) that are not well synchronised for end-users (they often lack either the linux-latest-2.6 or the linux-kbuild-2.6 tree, or simply takes the contributors too long to upgrade to a newer version making users voulnerable for kernel exploits).


Backports in the Debian Backports archive are "incomplete" in the sense of that when using a certain backport, another important package needs to be updated too in order to not provide feature regressions between the Debian stable release and the matching backports suite.

Also a backports suite should be treated like a normal suite, located between Debian stable and testing. This should include debian-installer images that offer to install the backports suite directly.


When using the Debian Backports archive, there is no guarantee that one backport is not breaking another one. While we can not guarantee that either, we at least make sure we test this. All of our backports can be used together.

3. The Live Media

Due to nature of live systems, the toolchain around them improves very much over time even for older releases. It would be desirable to use the latest released toolchain to build and run the stable images.


Summary: Debian first, always.. almost.

Even with the Debian project not being always perfect for everything, we constantly work with and work on improving Debian. We do not believe in "competitive advantage" of one distribution over another. In an ideal world, Progress Linux would be non-existent and Debian would have no outstanding bugs.

In the meanwhile we try to make any changes in Debian first, always. Only where necessary, we take the shortcut and distribute the changes ourselfs after submission to Debian to circumvent above illustrated shortcomings and eliminate useless waiting periods.



Example 1: debian-installer default frontend

The debian-installer has two frontends, a default text-based one and an optional graphical GTK+-based one.

The graphical frontend provides a better look and feel for users. It specifically provides better features for people needing accessibility features during installation. It supports more languages (e.g. for those languages that write from right-to-left) and other nice features (the ability to take screenshots). Therefore, it is desirable to have the graphical frontend be the default frontend for the installer and use the text-frontend only as a fallback and on users explicit choice.

During the Debian Squeeze release cycle, it became clear that the graphical frontend was mature enough to be the default. Eventhough there was consent in the debian-installer team to switch the default, it was not possible to make this happen as early as 8 months before the release (References: 2010-08, FIXME: list the older references too).

Example 2: C.UTF-8 locales in eglibc

The newly introduced C.UTF-8 locales in Debian Wheezy is a very nice thing to have on servers and small systems. Together with unsetting AcceptedEnv from sshd_config this eliminates the tedious need for locales or locales-all packages to be installed and configured.

Backporting C.UTF-8 to the eglibc of Debian Squeeze consist of two very small patches only, is non-intrusive and provides no source for regressions.

Example 3: libreadline support in postgresql

PostgreSQL is linked against libedit instead of libreadline to solve an alleged license conflict (GPL versus OpenSSL). This however has been discussed by other people with a legal backround and is considered to be majority opinion on the subject. See LWN.net for a summary.

Example 4: lxc support in squeeze

LXC is the technology of choice for linux-on-linux virtualization. To make Debian Squeeze work as an container, only two simple and uncontroversial patches need to be applied. Eventhough they were filled in time, it was not possible to get them applied as early as 3 months before the release (References: #473202, #607713).

Example 5: lzip support in dpkg

Lzip is the supposed successor of Gzip. It is an implementation of the LZMA compression algorithm offering superior compression ratio at shorter compression time. The dpkg maintainers prefere to not accept patches to use Lzip as an alternative and are sticking with XZ (References: #556960, #600094).

Example 6: sysvinit integration in git-daemon

The Git package in Debian has a long history of enforcing people to use runit if they want to use git-daemon. The principal Debian maintainer of the Git package prefers runit and does not like sysvinit, he therefore vetoed all attempts to add sysvinit integration as additionally supported alongside of runit.

We maintained a sysvinit patch for Git and after several re-iterations, we finally could get this accepted for Debian Wheezy. During the whole time (about 6 months), we distribute Git packages for Squeeze with the exact same patch applied so that users do not need to wait.

Example 7: recommends in apt

Starting with Debian Lenny, apt automatically installs recommended packages by default. We believe that this clutters too much our users systems and opt for educating users about the package management instead.

Example 8: ext3 in debian-installer

Debian Squeeze still uses ext3 as the default filesystem. We believe that ext4 is the better choice for Squeeze based systems.

Example 9: architecture independent backports

The Debian Backports team decided after the Debian Sarge release that architecture independent backports should not be uploaded to the Debian Backports archive.

While this is understandable from a backports point of view in order to reduce the potential amount of unmaintained backports, it is user unfriendly to need to use apt pinning to get the packages from Debian testing instead. It leaves all upcoming problems with testing for that package to the user.

Example 10: kernel backports

The kernel backports in the Debian Backports archive are not maintained well. Most of the time, either the linux-latest-2.6 or linux-kbuild-2.6 packages are missing. The backports do lagg considerably back to Debians main archive leaving users unnecessarily exposed to security problems.

Example 11: libreoffice backports

In order to use libreoffice from the Debian Backports archive, a few additional packages need to kept in sync (e.g. cliparts, dictionaries, extensions, etc.). While the Debian Backports archite does not provide these backports, we do.