Debian — troubling signs; can Slackware teach us anything?

This article will try to provide a contrast between ‘the Debian way’ and ‘the Slackware way’ when it comes to distribution management. The idea is to really attempt to illuminate people on why Debian, and many other distributions may not be ideal, and why a classic approach such as Slackware still has merit in this world of modern feature-crazy distributions.

I start this article knowing full well that it will offend people, even so, I think this needs to be said.

Now, for some background, I started using Linux sometime in 2000, my first distribution was Mandrake 7.0, and I eventually switched to Slackware 7.1 in order to try and accelerate my learning curve by forcing myself to use a more ‘pure’ environment, this worked fairly well. In the first year, my knowledge of the various modular components and how they fit together grew rapidly. At some point in 2004 I believe, I started using Gentoo on my laptop, and it quickly became one of my favorites. Several months ago, I realized I no longer wanted to spend valuable time waiting for various software packages to compile, I also grew very frustrated with their masking ‘feature’, and decided it would be time to look elsewhere.

And here finally, is the crux (no pun intended) of the story. Out of all the options out there, I figured my best bet would be Debian; after all, if there is one distribution that could be considered a ‘flagship’ of the Linux community, it would have to be Debian. Furthermore I liked the idea that like Gentoo, the base system came in a minimal configuration, and you added packages as you need them. Of course, because of various factors, I didn’t get the chance to do my migration right away, and it ended up being put off for a few months.

Then one day, while googling around for some info on XULRunner, I stumbled upon Mike Hearn’s blog, where he was discussing Debian’s controversial method of forking software; it is old news, but still important to evaluate I believe. I have to say that this shocked me immensely. Despite not using the distribution yet, and therefore not being a ‘fan’ per se, I held a lot of respect for the project and it’s leaders, for fighting the good fight and standing strong when it came to software freedom. The notion that Debian could do any evil was alien to even a non-user like me. I read on and I found myself agreeing with Mike on pretty much all his points. I googled for more details on this controversy and discovered this which explains some more details about the whole incident. As near as I can see, the Debian maintainers feel that Mozilla’s linking strategy is not ‘unixy’ enough, and have decided to ‘correct’ that by changing the way the software functions on their distribution. This has the potential of breaking compatibility as noted by both Mike and Benjamin. And I would add that this is just a total slap in the face to the hard work of the Mozilla developers. Bottom line is, if you want to get all patch-happy on some piece of software, then change the name; the upstream developers do not deserve to suffer all sorts of support headaches simply because you decided to do your own thing.

The fun doesn’t stop there however. On May 13th, one of the most severe and critical security problems in years was discovered in Debian’s version of OpenSSL, and this problem affects Debian forks as well such as Ubuntu, Mint, DreamLinux (unconfirmed) and MEPIS. All of those are in the top 10 of DistroWatch as I write this (with Ubuntu in 1st place), except for MEPIS which is #12. The issue arose because once again, one of the Debian package maintainers decided to go their own way without including upstream developers in the process. The short of it is that Valgrind, a well known memory debugger, was coming up with “uninitialized data” warnings in code linked to OpenSSL. This apparently is a well known issue, and there have been discussions about why the issue comes up and what to do about it. It is related to the fact that Valgrind and IBM’s Rational Purify usually view “uninitialized data” as a bad thing, when in the case of a random number generator, it is actually necessary.

The Debian ‘patch’ essentially removes the ability for OpenSSL to generate random numbers properly, the result of which causes keys generated with OpenSSL on Debian (and it’s derivatives) to be extremely easy to guess in a short amount of time using an amateurish brute-force attack. Worse yet, this Debian ‘maintainer’ didn’t alert upstream developers to his ‘patch’ and therefore the problem went uncaught for years and has now put many unsuspecting users at risk.

I may not be a developer, but even I can see the absolute stupidity behind the OpenSSL debacle. And it is all because of their absolute refusal to respect the wishes of upstream developers regarding their software. This is nothing new of course; distributions have been doing this sort of bullshit for years. I recall back in the day when Red Hat ended up shipping a CVS version of GCC known as “GCC 2.96″, which broke compilation with many packages, the official stable GCC release at the time was 2.95.3, and this newer 2.96 version was actually a development snapshot for the upcoming 3.x releases. Then there was the whole controversy with various distributions shipping broken copies of MPlayer due to patent fears; SuSE and Debian (yep, them again) were two notable offenders as I recall.

Essentially, for whatever reason, some distributors seem to think that their Linux distribution is a proper place to dump all their dirty hacks and patches, and to completely spit at the hard work that upstream developers put into their stable releases. It is heartbreaking to see the community in this sort of uncooperative state.

Many years ago I read an opinion article titled “Does Slackware still matter?“, I remember being pretty miffed about the whole thing, but at the same time I couldn’t really produce a comeback. Over the years of course I’ve gained more insight into these matters, and I can now definitively say that, YES, it matters perhaps more than any distribution currently out there.

Patrick Volkerding started Slackware back in 1993, and the first release came on July 16th of that year. Originally not intended to be a serious project, it eventually grew, and exists to this day as the longest living Linux distribution ever. The philosophy behind the project very much obeys the “Keep It Simple, Stupid” philosophy, or KISS for short. The idea is that the system should shy away from over-reaching complexity and abstraction layers, and instead keep things clean. In following this philosophy, most of Slackware’s packages are often sparsely modified compared to their upstream counterparts, and given that this is a one-man project, it would be pretty difficult to go around patching everything and then having even more testing to deal with. There are some exceptions I would imagine, perhaps some security issues and so on; also, back when the Gnome environment came standard, Patrick would often have to clean up after the upstream Gnome, and make sure it doesn’t essentially ‘take over’ the system.

I truly believe that the Slackware way of distributing, is the right way, with minimal changes from upstream, and very few abstraction layers for configuration (bash scripts like netconfig are all that come to mind), as well as an easy to work with BSD init script set up, it is easy to see that Slackware does not ‘hide’ the system from you like many others do.

I mean let’s be clear, when you use Gentoo, with it’s bizarre init and config system, you don’t learn Linux so much as you learn ‘Gentoo’, and when you use SUSE, you don’t learn Linux so much as you’re just learning ‘SUSE’, and so on with every distribution. Now of course I may be exaggerating; after all there are more similarities than differences, and truly, experienced Linux users can easily pick up another distro and understand what’s going on. Besides, often many of the ‘default’ usual configuration files will point you in the right direction, like when editing resolv.conf on Gentoo, a note will mention how you have to add your DNS servers in /etc/conf.d/net instead. Even so, it does mean that there are serious challenges in administering many boxes with different distributions.

Of course, the first natural riposte to my article will probably be “are you against freedom of choice or something?”, and the answer to that question is no, I am not. I fully understand that everyone has the freedom to do things their own way, and of course, to the “Windows user” that joins the Linux community through Ubuntu, they probably don’t care whether resolv.conf is edited directly or whether there is some abstraction layer; but to people who want to learn system administration, it can be a pain in the ass to move between distributions if you haven’t learned how the system really works behind all the abstraction. And of course, it is a slippery slope; there are configuration hacks/abstractions, and then there are actual source code patches that change the behavior of the program in question; and we can see that this patch-happy attitude can often have some serious repercussions, like in the Debian OpenSSL case. If anything, I am not suggesting we all become robots and obey one standard ‘method’ of doing things, however I think there needs to be a more conservative attitude when it comes to breaking consistency with upstream. Let us remember that upstream projects develop the applications, and distributions are supposed to distribute.

To conclude and sum this up, when I download a package from a distribution’s repository, I think it is not unreasonable to expect the package to be the same as the one I would download from the upstream maintainer’s website. If it isn’t, then there isn’t really much of a point to pitching the idea of online package repositories as an alternative to traditional methods of software distribution. I think Mike Hearn’s example of a distribution mirror altering a package is a very good example, because in such a scenario, many individuals would be outraged and angry, and yet Linux distributions get away with this kind of thing all the time.

And that is pretty much all I have to say about that.

P.S.: As I said when starting out, I know some folks will be offended by this, and I know how articles and posts like this can easily cause flame wars, I hope there are no hard feelings. Also, it seems that one of the first instincts when reading an article like this is for people to question the author’s competency and so on, I hope you can manage to keep it civilized despite any disagreements you may have with my opinion.