Slackware is the oldest surviving Linux distribution, founded by Patrick Volkerding in July of 1993. From the onset, the operating system has maintaineslackwared a minimalist approach to computing.
It is renowned for its speed and stability, due in part to the fundamental principle of keeping packages as vanilla as possible. Aside from essential patching, each package in Slackware is exactly as the developers intended.
After all this time it is still a one man show, although Patrick has a team of loyal volunteers around him. Perhaps this has something to do with its continued success.
The popular distribution has just announced the availability of version 13.0, its latest release. There are many improvements in this release, including the major upgrade from KDE 3.x to 4.x, however perhaps the biggest is an official port to 64-bit. That’s right, Slackware, one of the very first Linux distributions, is one of the last to go 64-bit. What has taken so long to do so?
Linux Magazine spoke with Eric Hameleers (known as Alien BOB) about the 64-bit port and why users should consider switching to Slackware. As Eric discusses, this 64-bit release came from a ground up approach which has even managed to benefit the 32-bit build in the process.
Christopher Smart: Eric, could you please introduce yourself and tell us about what you have contributed to Slackware thus far?
Eric Hameleers: I am Eric Hameleers, 48 years of age (yeah, shocking), born and still living in the Netherlands. I came into contact with the exciting world of high-end UNIX workstations when I started a night-time job to earn some extra money during my Physics study. I never really considered a career in Physics ever since. I had a series of jobs ranging from technical sales support to systems manager and finally networking consultant. At IBM where I ended up I have worked on a variety of Linux based projects and currently oversee helpdesk operations. I am married to my wife Ine and have a son, Daan.
Slackware has been a hobby that has gotten out of hand I guess. It consumes a huge part of my free time but in my opinion it is worth it. Working on Slackware gives me tremendous satisfaction.
I bumped into Slackware when the UNIX developers in the company I worked for as a sysadmin started using it (with a 0.9.x kernel at the time!) as a cheap cross-compilation platform with Solaris as the target. Gradually, Slackware found its way onto the servers of our emerging company Intranet, project fileservers and firewalls.
I was a happy user, but I only started meddling with Slackware’s internals after we were acquired by IBM and our ethernet network was re-wired to tokenring. I finally became fed up with patching rc.inet1 after every install to add support for my ‘tr0′ tokenring interface (Slackware only understood ‘eth0′) and contacted the Slackware maintainer Pat Volkerding. He and I got along pretty well (even though it took a long time for him to accept my network patches) and as time passed by, more of my ideas found their way into Slackware.
With Slackware becoming more and more my desktop platform of choice, I started writing SlackBuild scripts for the software I installed regularly as a means of bringing structure to my work and to overcome the endless frustration of not remembering how I built a package the time before. I had a habit of publishing these packages as well as the accompanying scripts on my home server behind a DSL line. Consider that a give-back to Slackware users because at the time I did not buy every Slackware release, instead downloaded them for free. I guess I felt compelled to compensate for my freeloading.
At one time, I asked Pat if I could get some space on the Slackware server for my package repository because my DSL line could no longer handle the demand. To my surprise, he actually went ahead and created an account for me. From then onwards it all progressed much faster because using “slackware.com/~alien” works pretty well for one’s credibility.
CS: You were instrumental in creating the new 64-bit release, what was your motivation and how did you go about achieving this?
EH: There were a few unofficial 64-bit derivatives already, of course. Fred Emmott created the original 64-bit derivative, Slamd64, and that effort was copied by Bluewhite64. During those years, there was no real pressure to develop an official Slackware port – suitable hardware was not yet a commodity, and a lot of software needed to be moderately to heavily patched in order to compile on a x86_64 platform. That was a sign to me that it was worth waiting for things to mature a bit more.
When it became clear that efforts were underway to port high-profile binary software products like Adobe’s Flashplayer and Sun’s Java Runtime to 64-bit Linux, I started feeling an itch. Pat was still not convinced about the necessity for an official 64-bit port, so I decided that I should just go ahead and let him judge based on what I could produce. Getting that project on the rails took me a bit longer than I had anticipated though. I was invited (along with Robby Workman and Alan Hicks, two of my fellow Slackware team members) to visit Sao Paulo, Brazil in August 2008 and deliver a couple of presentations at the annual ‘SlackShow’ there. This kept my mind off the 64-bit port, because I needed time to optimize my Slackware laptop for demonstrating virtualization techniques and showing off our brand new KDE4 desktop.
But right after my return, I was scheduled for surgery to get rid of an annoying pain and found myself at home for a few weeks of recovery. This was in early September 2008, and I decided to start the 64-bit port as a diversion from the pain (which was actually a lot worse in the weeks after surgery then it was before).
Pat was never quite outspoken about my pet project, I guess he was curious about what I would produce. Then he installed the first semi-finished version somewhere in December 2008 – about the time Slackware 12.2 was released. He ran several computational benchmarks on Slackware64 and was instantly hooked when he saw speed increases between 20 and 40 percent for some of the benchmarks, compared to 32bit Slackware. That marked the moment when it became a team project – the others installed it too, and some switched entirely to
Slackware64.
From there on to the go-live in May 2009 I used the team’s feedback and ironed out the obvious bugs, at the same time trying to stay synchronized to the public development of slackware-current. People who used to inspect Slackware’s build scripts since early 2009 could see where we were heading because gradually more clues about x86_64 started appearing. But we kept our mouths shut tight, in order to make a spectacular landing.
CS: What were the biggest challenges you faced in porting Slackware to 64-bit?
EH: Quite rapidly, it became clear that if Slackware was going to develop two architectures (x86 and x86_64) in parallel, it would double the effort required by Pat, unless I did something smart. So I changed priorities. The new priority was, to give all build scripts a facelift. We decided on a “template” for the scripts and then I began adapting them one by one with the goal of unifying the scripts for x86 and x86_64 architectures. Pat was sceptical about this at first, but in the course of the 13.0 development cycle he got sold on the concept because indeed, it pays off in the end when you can build both your ports from the same set of sources. We intend to carry it further even, because our two other ports (for S/390 and ARM platforms) are converging to the same source tree as well.
Another issue I faced was the installer. Historically, Slackware’s installation environment has been hand-crafted by Pat with contributions from others. This meant there was nothing available that would allow me to create an installer from scratch. With the help of Stuart Winter (who wrote an installer for his ARMedslack port earlier on) and Pat himself, the three of us managed to work out a method for creating indentical installers for the x86, x86_64 and ARM platforms. This was crucial because it allowed us to keep the installer stable while we added a whole lot of both small and big improvements.
Thanks to the new unified SlackBuild scripts and installer, our parallel Slackware development carried on without major issues. In hindsight, I would say that the biggest hurdles were at the start. For instance, I needed to make my mind up about how to handle support for multilib (the ability to run 32bit software on a 64-bit environment), which was a design decision potentially affecting the build scripts for a lot of packages. Furthermore, I needed to learn how to create a Slackware Linux system from scratch – but for a different architecture. This in itself was quite an interesting endeavour. In the end, I used a combination of QEMU – which is Fabrice Bellard’s fast, open source virtual machine software – and the information I found in the ‘Cross Linux From Scratch’ book to create an initial 64-bit bootstrap environment.
I stayed away from the available ‘unofficial’ 64-bit ports and turned my project into a clean-room implementation. Had I used an unofficial port as the bootstrap, there are no doubts that we would see a clash of opinions and egos later on. It made my work harder (compilation in a virtual machine is slow!), but I think we ended up with a solid and well-engineered Slackware port, with it’s own unique flavour that sets it apart from it’s unofficial predecessors.
CS: What issues are there with the current 64-bit version of Slackware? What is still to be finalised?
EH: To be honest, it looks like there are no issues specific to the 64-bit port left. The development cycle for 13.0 has been extremely intensive (if not completely exhausting) in order to get everything working the way Pat and the team wanted. What is left to comment upon is not platform specific I guess. Making the switch to KDE4 and getting the new X.Org in were scary moments, because these products have a big impact on the overall Slackware experience. Stabilizing X.Org took us much longer than anticipated and moving to KDE4 has caused some popular applications such as K3b and KOffice to be reduced in functionality and stability due to the impact of porting to Qt4 – the foundation of KDE4. These are issues beyond our control but I expect to see further stabilization and more maturity in this area before the next Slackware release.
There is one other thing worth mentioning about Slackware64. Out of the box, this is a pure 64-bit operating system – it is not capable of running or compiling 32bit binaries. This sets it apart from slamd64, for instance, which has full multilib support. This was a conscious decision, partially based on the viewpoint that there is a 32bit Slackware for those who need it, but at the same time we strived to make Slackware64 ‘multilib-ready’. Only a few easy steps are required for adding full multilib capability to Slackware64. The procedure is documented in an article I wrote for my Wiki. It is possible that a future release of Slackware64 will be multilib. That is Pat’s call however.
CS: Slackware is the oldest surviving Linux distribution, what took so long to get an official 64-bit port?
EH: In my opinion, 64-bit operating systems have been a bit over-hyped in the past. Of course there are definite advantages such as access to more than 4GB or RAM, although PAE (physical address extension) kernels can overcome the 4GB memory limit of a 32bit Linux OS. There is of course a speed increase for computational applications. For the majority of users however, a 64-bit OS will not make a huge difference in their experience of Linux. When you offset this to the fact that Slackware is essentially a one-man operation (albeit with the help of a small team of volunteers) it makes sense not to spread the available resources too thin. I have experienced myself that maintaining Slackware has become an increasingly complex task. I guess that if I hadn’t had my surgery, there would not be an official 64-bit port today. As I see it, the port’s streamlining effect has been beneficial because it made it easier for Pat to keep maintaining Slackware for the two platforms.
CS: What makes Slackware different and what has contributed to its success? Why should Linux lovers use Slackware over other distros?
EH: Let’s take the opportunity to tell why I prefer Slackware over other Linux distributions. It goes without saying that I am biased, but I have used RedHat, SUSE and Ubuntu extensively and I will try to pinpoint the differences. In my opinion, the big three all have their merits, with their focus on user-friendliness and full auto-configuration. They also, all of them, show a definite eagerness to be accepted in and certified for the corporate environment, and in fact that is where I use them. None of them find their way into my home, or any server that I control. That is the domain of Slackware.
To me, Slackware’s philosophy has a different angle that sets it apart from all the others. To this day, Slackware has an extremely lean design, intended to make you experience Linux the way the software authors intended. This is accomplished by applying patches as little as possible – preferably for stability or compatibility reasons only. Slackware’s package manager (yes, it has one, pkgtools!) stays out of your way by not forcing dependency resolution. And the clean, well-documented system scripts (written in bash instead of ruby) allow for a large degree of control over how your system functions. Slackware does not try to assume or anticipate. The installer is still console-based, but it uses dialogs, menus and buttons nevertheless. Not depending on X during installation, Slackware’s installer is rock-solid, a statement which I can not repeat for the other distros I use. When you login for the first time after a fresh install you will end in the console instead of X. No assumptions are being made about what your intended use for Slackware is. This comes as a shock to many unsuspecting users, but it is the start of a learning experience.
I am well aware that the above statements are often perceived as negative, but in fact they make Slackware into a versatile tool that is adaptable to many needs. And yet, like any modern-day Linux distro, it fully recognizes and utilizes your hardware by virtue of the same kernel, Hal, D-Bus, X.Org and a truckload of other applications that the big distros ship as well. Slackware does not live in the stone age of computing. It is strong and thrives. It is lean and speedy.
The testimonials of ‘converted’ Slackware users at LinuxQuestions.org and other forums show that Slackware’s philosophy of giving full trust to the system admin is an eye-opener to people who struggled with the other distros before. This continuous influx of ‘converts’ is one of the reasons that Slackware has not disappeared into oblivion. Slackware assumes you are smart! This appeals to people.
And there is always the helpful community in case you have questions – for instance the Slackware forum at and the Slackware IRC channels on the Freenode and OFTC networks.
I highly recommend you to give Slackware a try and experience the difference. If Slackware is for you, you will know it soon.
CS: How can users of Slackware help in the future?
EH: Earlier this year we had major issues with X.Org in slackware-current, our development version. Owners of hardware with Intel graphics got a pretty bad experience out of it. Then, Robby Workman called out to the community at LinuxQuestions.org to test a variety of package versions and combinations and feed us their results. The high quality of the responses we received allowed us to ship Slackware 13.0 with a solid X.Org. This example shows why it is so important to have people willing to test our stuff, fully realizing that it can render your computer temporarily useless. It’s the reason why the ’slackware-current’ development tree exists. Even though Slackware is the brainchild of one man, it could never have become what it currently is without the feedback of it’s users.
There is another consideration to be made, and that is the fact that Slackware sales are Pat’s only source of income. Slackware is essentially free software – you can download it all over the internet without a fee – but in my opinion, people who really like Slackware should make a judgement call and buy a copy at the Slackware Store if they can afford it. Their action will be a small contribution to the continuation of this oldest surviving Linux distribution. I can safely say this, because none of the team apart from Pat get paid for their work. In fact, I have a Slackware subscription myself and so have the others. I want Slackware to have a future, if only because it has become an island of focused effort in a sea where everybody wants to storm the ‘enterprise’. To me, Slackware remains the Swiss army knife of Linux.
CS: It’s very exciting to see. Thank you again for your time and for all your hard work!
EH: It’s all my pleasure, Chris.
Christopher Smart has been using Linux since 1999. In 2005 he created Kororaa Linux, which delivered the world’s first Live CD showcasing 3D desktop effects. He also founded the MakeTheMove website, which introduces users to free software and encourages them to switch. In his spare time he enjoys writing articles on free software.
Eric Hameleers is a Linux user since the 0.99 kernel releases and ran into Slackware Linux around 1995. The first need to make modifications to Slackware occurred when Eric joined IBM and was doomed to use Token Ring for which there was no support in the network scripts. Rather than applying his patches again after every new Slackware installation, Eric decided it would be better to convince Pat Volkerding about adding them to Slackware.
From Linux Magazine: “Interview with Eric Hameleers: Why You Should Try Slackware”