Stuart Winter: I learnt more about Linux in two weeks of using Slackware than in two years of using Red Hat
Published: July 2, 2010
Dear fellow Slackers! We are happy to publish an interview with Stuart Winter, a Slackware developer and maintainer of the ARMedslack project, he has kindly given us on the occasion of the Slackware ARM 13.1 release. Enjoy!
Dear Stuart,
We are glad to congratulate you with the next release of
ARMedslack and we would be immensely grateful if you could take out
some time from your busy schedules to answer a few questions that
we believe can be interesting both for Slackers and other Linux users.
Thanks. Slackware ARM v13.1 was a lot of hard work especially in the last month prior to release. There were lots of package upgrades and some new devices to support. I think Slackware 13.1 is a great release (one of the best yet!).
1. Stuart, you are known to the Slackware community as the author of slacktrack, adduser (which is also employed by Gentoo) and a number of other tools as well as updates to linuxdoc-tools, helpful posts on the alt.os.linux.slackware news group. You have also become famous recently "for all kinds of fixes throughout the [Slackware] installer and system" and even finding bugs made by Patrick Volkerding [check here] :-) Could you please introduce yourself for a wider audience?
Heh. I'm not sure I'd describe myself as being "famous". If I was to be famous, I think I'd rather be known for walking over a tight rope in a high wind, over a shark infested sea, whilst juggling biscuits, or something crazy like that; fixing bugs and working on a few projects is almost too pedestrian ;-)
I started using Red Hat Linux in 1996 for a few years, but had a shell account on a friend's Slackware box. I started reading the config files and the rc scripts and saw how well they were commented and how clean the system looked. All of my systems were ARM desktops back then, apart from the one PC with Red Hat on it. So I got hold of a 486 and installed Slackware v3.5. I learnt more about Linux in two weeks of using Slackware than two years of using Red Hat—purely because everything had to be done by hand.
Now the primary thing I do in Slackware is maintain linuxdoc-tools and find bugs in build scripts ;-) I have recently tended to encounter new bugs in the installer too (the installer is rebuilt using the latest binaries/libraries from the current tree—some of which need cajoling into a good mood to work in the installer image because unexpected results occasionally occur with new versions). This is because I upgrade kernels much more frequently for Slackware ARM, thus have to rebuild the installer to include the new kernel modules. This has allowed us to fix such problems before they appear on x86.
I live with my girlfriend and 2 month old daughter in Surrey, UK and work in London. I'm 30 years old this year, and my star sign is … ;-)
2. Besides the projects mentioned in the first question, you also maintain Slackware ARM aka ARMedslack. We believe many of the rank and file PC users hardly even know what ARM processors are. How did you get interested in porting Slackware to ARM architecture and how do you use ARM devices (equipped with Slack) in the everyday life?
At school I was introduced to BBC Micro computers (which were made by a company called "Acorn") and got programming in BBC BASIC. These machines had a 6502 CPU. Later Acorn created a new range of machines which had an OS called "RISC OS" which was a WIMP system and far superior to many similar systems on the market at the time. These machines had ARM CPUs (ARM at that point stood for Acorn RISC Machines) which were specifically designed by Acorn for these machines.
My main desktop machine was a StrongARM RiscPC running RISC OS. When I eventually started using Linux full time on the desktop, I wanted to make use of the RiscPC still (primarily because I had spent so much money on it). Since I knew Slackware quite well by this point, I knew I'd be able to make any changes necessary to the system in order to make it ARM compatible. So I just visualised seeing the Slackware installer running on the machine, and started work. One of the things that particularly motivated me to continue was that there were so many undocumented things in Slackware, and I found this much more interesting, and learnt a lot about how the distribution was put together—both by experiment and reading, and also talking to Patrick Volkerding about it when I really couldn't figure out how stuff was done. I also created slacktrack to build packages of the older style build scripts that were quite prevelent back then. If everyting was documented and perfect, I'd probably have stopped years ago because there'd not have been much for me to create and explore. This was almost ten years ago though and Slackware's documentation has evolved a lot since then, mostly by the crew.
My intention for ARMedslack was and still is, to use it as my primary desktop. I achieved this briefly with the RiscPC, and was close with another ARM desktop machine "The Iyonix". But unfortunately the Linux 2.6 port for this machine was never completed, so it is now of no use :-( but it did serve as the main work horse for ARMedslack 11.0. Most people only know that ARM CPUs are in embedded devices such as phones. However, to really make use of these devices, you typically need a highly customised distribution with specific packages. Slackware is a general purpose OS for servers and desktops which suits the ARM systems I am personally interested in.
3. ARMedslack includes almost all packages present in Slackware, including KDE and tetex, which are hardly needed on devices like SheevaPlug. Does this mean ARMedslack can be used on ARM netbooks (that are expected to be widely used by 2012)?
Yes that is the plan. My aim also is to provide a complete port. Even if you can't run KDE (most ARM hardware couldn't until the SheevaPlug was released—just because the CPU was too slow; but I have run KDE on my SheevaPlug and OpenRD client), some apps might want to link against libraries. So the only time I don't provide packages is either because it's x86 specific or it's binary only—eg JDK.
I had an older ARMedslack running on the Psion Netbook Pro a few years ago, but Psion stopped the project and the Linux support for it never went upstream. I'm still waiting for an ARM netbook. I am a patient man ;-)
4. According to the source tree, many of the build scripts are "heavily based on the original Slackware build scripts". A closer look reveals though that your approach differs pretty much from that of Slackware. One can even find dependency checks, prohibited in Slack ;-) How does the development of ARMedslack differ from that of Slackware, not mentioning tweaks of the kernel and special compilation flags?
Once I got started with ARMedslack, I decided that since I had access to a range of architectures, that I would port Slackware to everything (as you can tell, I was excited at the progress I was making ;-) ). I planned to port to the HPPA too, because there was a system at work I could use. I'm glad I didn't do anything other than ARM though—it takes a lot of work and a lot of time!
Since I didn't have access to write to the official Slackware tree, I had to maintain my own scripts anyway. I sat down with Darren Austin (who's on the GNOME SlackBuilds team and runs a Slackware mirror) and figured out some initial time-efficient methods to keep up to date with the real Slackware scripts, whilst being able to make the necessary modifications to add in patches and package build changes for various architectures.
One of the key things I have done for ARMedslack is to automate as much as possible. This includes even simple things such as placing the new package into the tree after building and wiping the previous version (rather than into /tmp where I'd have to manually move it—consuming more time (I have backups to recover from if the package is broken, which has happened on a few occasions)).
The dependency checks you mentioned are build dependency checks to ensure that the correct packages are installed prior to building the new package. This is because before I build packages, my build scripts remove the existing installation of the package you're building (apart from stuff like zlib, glibc et al.—I do still need the system to run ;-) ). This is because I found some applications would generate data using the system versions of (now older) binaries which sometimes was incompatible with the newer version of the software. Removing the packages prevents this and forces the software to use the newly compiled version. So after a build has finished, the package is no longer installed. When building a chain of packages, I use my scripts' build dependency checks to automatically install the newer version of the packages further up the chain (should they not be present on the system)—otherwise the build either fails, or doesn't build with a particular bit of functionality that Slackware has. When Patrick builds Slackware, he typically does not remove the existing version unless absolutely necessary, but instead builds it a few times.
The dependency stuff also comes from when I used to cross compile ARMedslack in a sandbox called "Scratchbox".
Also, I have a Slackware package called "slackkit" which contains a big shell script library of common functions such as stripping binaries, compressing man pages and so on. Instead of having to make changes in all scripts (eg when we stopped chowning binaries root:bin), I just change it in script library.
The biggest noticable difference is that ARMedslack is chiefly a skeleton source tree. I quickly learnt that hours could be spent in making sure the source archives and patches were in sync with slackware and armedslack. ARMedslack builds "against" a Slackware tree: you configure the slackkit config file to point to your Slackware x86_64 tree (because 32-bit x86 doesn't have sources for Mozilla Firefox, for example), and ARMedslack's build scripts reference it for the sources, patches and slack-desc (basically anything that the build scripts look for in the common $CWD variable). This significantly reduces the time taken to keep up to date with Slackware's development.
The long term plan is to have the Slackware build scripts build for all supported architectures, and you can see that from v13.0 onwards, there is some movement towards that already.
5. Developing and maintaining ARMedslack seems to be a huge work. What kind of hardware do you use for building ARMedslack?
I started off with two StrongARM RiscPCs, and "Scratchbox" on an x86 PC with QEMU, then got the Castle Iyonix. Now I have two SheevaPlugs and an OpenRD Client in active use. One runs the last stable release of ARMedslack, one runs the bleeding edge "-current" and the other the stable "-current" (incase it all goes wrong, which has happened a couple of times by making broken builds of critical packages).
Everything is built natively, but I use distcc to farm out compiles to six X86 and x86_64 machines which run an identical toolchain (but a cross compiler) as ARMedslack. This speeds up compiling immensely.
6. Is there anything in Slackware and/or ARMedslack you would like to change significantly? If yes, what is this and why do you want this?
When I was working as a system administrator and running Slackware in a data centre and building my own custom packages, I really wanted post-remove scripts that would be run by removepkg. This way I could tidy up residue from the package's installation, or adjust config files once a package was removed. However, I found ways to work around that, and I no longer do that job so I haven't thought about that since then.
Things like Kerberos and PAM would have been useful in my last job where I used Slackware as my desktop in a corporate environment. This was because the systems I was logging into used Kerberos/GSSAPI so I wouldn't have to keep authenticating to commit changes to a git repo, or SSH into a system or login to a web site; but again I'm no longer there, so I don't have a personal need for those anymore.
I also have a few speed ups for pkgtools that I'd like to get into there. I have patched pkgtools in a few areas to increase speed (the speed increase of not forking so many utilities is very noticable on slow ARM hardware). Pat knows about these but I forgot to remind him.
Eric Hameleers and I started working on some ideas to create a scriptable installer, similar to how you can script a totally automated installation of RHEL with "kickstart". This was a few years ago now though, and neither of us has time to do it. If I remember correctly, the initial thoughts were to create a shell script library of all of the major functions the installer did, and then modify the existing scripts to use them; you could then write a shell script to call them with pre-defined values. I think that the installer as it is has all of the necessary utilities included to accomplish this. Given how many times we reinstall Slackware during development, I think this would be valuable when done right.
7. Do you ever try any distributions based on Slackware, e.g., Salix, Woolvix or Zenwalk? Do you like any of the ideas implemented there (for example, automated package management)?
I have heard of two of these but never used any of them.
8. In reviews that appear after any new release of Slackware, one can often find complaints about missing dependency hell in the existing system of package management in Slack. Just of curiosity, have you ever discussed a possibility of implementing an optional check of package dependencies with the other developers of Slack?
The official recommendation is to perform a full installation, so this would help prevent many of the initial dependency problems. This is something I actually do on my desktop machines, but for servers I, like many others, are very particular about what gets installed.
Yes we have briefly discussed dependencies on a few occasions in the past. Apart from the huge adjustments that'd be required to pkgtools, there's also the significant effort required to determine a) firstly, what the dependencies are and then b) maintain that list.
Whilst this may seem obvious and easy, in fact it's seriously time consuming. I know for a fact because I maintain the build dependencies, as you noticed, for ARMedslack's build system. I have a script that does it for me, but it only does it by using ldd and the MANIFEST file; anything else such as "this actually needs some funny xml tool to make the docs" is added by hand. Keeping track of this takes much more time than I believe any of us has. For this reason alone I think we'd be doing a disservice by adding it, since it'd take valuable time away from working on things that the regular Slackware users enjoy about using Slackware.
And secondly, if we were to do it, we may as well just use a package manager that already takes care of dependencies and makes us more aligned with the other distributions, and use RPM. Who wants that? ;-)
Having been a system administrator in various guises for most of my career, I know full well how useful dependency resolution can be (in particular the automated online resolution that yum and apt have)—especially when you just need something done and trust the vendor to have it act together and "just work".
However, in my personal opinion, I consider looking after my Slackware systems analogous to caring for a classic car. You have to learn a lot about how it all fits together, spend time enjoying doing it, and then you know exactly what is going on with your systems; rather than allowing a dependency system to install an additional package because an errata of an existing package now depends on something new (which has happened a lot in my time of administring Red Hat systems).
Although not directly related to the question, but following on from making prevalent and time consuming changes, I think it's worth mentioning: In my conversations with Patrick over the years, it's quite clear that he always considers continuity and stability whilst thinking about the future for Slackware. This thinking shows in a number of ways—chiefly that he adopts a conservative approach when considering a revolutionary patch to an existing Slackware utility, or a new tool from an unknown or relatively new contributor. This is because if the change becomes married to the core of the OS, and that contributor disappears, then who will maintain it? This is not something that is unique to Slackware—you can find this in Fedora and Debian too, when a package maintainer orphans their package for whatever reason. It's very hard to remove functionality once users have got used to it. As the core Slackware team has grown larger over the years, and individuals have proven to be reliable and continue their interest, this helps add more features and packages to the system, knowing that these can be maintained into the future. I think this is a very sensible approach and is appreciated by the Slackware user base.
In summary, if you have an attitude geared towards being interesting in what your OS is doing and you can set aside time for it, then Slackware can be a great OS for you.
9. Do you personally use Slackware on laptops? Do you think Slackware is suited well for running on laptops? The major issues we are aware of seem to revolve around WiFi and resume/suspend/hibernate support. How well do you think Slackware fares with regards to these and other overall challenges that any Linux distribution faces when run on a laptop?
I have an IBM T60 laptop that I use as my main development machine. I can't comment on hibernation and so on because my laptop has the lid permanently closed and I only use external monitors, so I really use it just like a desktop (only it doesn't have huge fans making it too noisy).
10. What do you think about the way Linux in general is evolving? Is there anything you miss or are not satisfied with?
One of the things I have always loved about Linux is that for the most part (at least in my experience) if you have some hardware, you know that in 99% of the cases, you'll be able to use it in a few years' time. Where as if you were using Windows, there's a good chance that the software would have been dropped by the vendor since the hardware is obsolete. This goes for both the kernel level drivers and user space stuff.
There are some issues with certain packages which seem to change the way their rules/configuration files are done in almost every release; and I think that you have to have sucked on the laughing gas before starting to produce a stable collection of X.org packages—you wouldn't need any tear gas, at any rate… ;-)
I have used some of the other main stream Linux distributions recently and one of the key things that struck me is just how dumbed down they are, particularly that they are geared towards users who do not know what to do with the root account. Ubuntu in particular wouldn't let me 'su -' to root! Having to reconfigure the OS to let me do what I want and know how to do, drives me nuts. I'm so glad with Slackware all you have to do is build it up, not tear it down first then build it up.
But all in all, I like the direction Linux is going in, and as long as there is choice, I think most people can be happy once they find a combination of OS and software that works for them.
A couple of personal questions:
11. How did you become "MoZes"? :-)
I chose the name in the early 90s. Originally it was "MoZes The Polystyrene Policeman", but when I got onto the Internet in '94, I found that my user names and email addresses had to be shorter, so I just took the first bit. I liked the sound of the name "Moses" (the Biblical character), but preferred the spelling with a Z. The Z spelling is how the biblical character is spelt in the Netherlands, but I didn't know that at the time.
12. Is there still any place for biscuits in your life? :-)
Biscuits are an integral part of my life. Whilst I don't eat as many as I used to, when I do eat them I really savour every moment as if it were my last.
Actually, I'm off to the super market this morning and I'm going to pick up a bag of bourbon creams. Hmmmm.
13. And, in the end, is there anything you'd like to tell Slackers about that we didn't dare ask?
Before I'd finished replying to these questions, I had sacrificed one and a half lemons. [Compare with the answer given by Robby Workman :-)—Editors]
I know I've over answered most questions, but I hope these answers have been useful and interesting for the Slackware community.
Thanks a lot for finding time to (over)answer the questions, Stuart! :-) All the best for you and THE girls!
http://slackworld.berlios.de/2010/stuart-winter-on-armedslack-13.1.html