Patrick Volkerding, the founder of Slackware Linux, agreed to an interview with LQ. Here is what he had to say. Some question were contributed by members. Those questions have the member's name in parenthesis after them. Thanks Pat!
--jeremy (LQ Member)
LQ) To get us started, can you give us a little background information about yourself? (LQ)
volkerdi) Sure. I was born in Virginia while my dad was stationed out there as a Navy dentist. We moved to North Dakota when I was very young. As far back as I can remember I was interested in science, the space race, and other typical interests of a kid who wanted to be some kind of scientist someday. I had an erector set, lots of Lego blocks, and a pretty decent chemistry set full of poisons they'd never allow kids to play with today. When I was 7 or 8 years old my class took a field trip to North Dakota State University to see the computer department, and it was there that I got my first taste of UNIX and realized that I wanted to work with computers. I had an Atari 2600 and wanted to get the fairly rare BASIC cartridge for it (but never did), and when personal computers started to appear, I began hanging out at Radio Shacks and electronics stores to get my computer fix. The Radio Shack at the mall had the TRS-80 Model I on display and a nice collection of books on BASIC. I learned to program typing in program listings from one of David Ahl's computer game books and then figuring out how to modify them. The store was happy to have me come in and enter some code, and save the programs to tape so they'd have demos. But alas, they did not make the sale, and my first computer was an Apple ][+, and with it I learned to program Pascal (UCSD p-System), an integer C called Hyper-C, Forth, and other languages. Forth led to appreciation of RPN, and I still use only HP RPN calculators to this day. After high school I entered college as a computer engineering major (kind of a 5 year EEE / CS degree), but after 2 years of that it was clear to me that hardware design really wasn't my calling and that a computer science degree would be better for me. Also, the school I'd chosen was very much focused on VMS. I ended up transferring to Moorhead State University, which had just been given a bunch of AT&T UNIX equipment and was actually connected to the Internet (the other school only had BITNET access, which was fairly useless). It was while finishing my degree at MSU that I first started working with Linux.
LQ) How did you get involved with Linux and Open Source, and what was the path that lead to you starting Slackware? (LQ)
volkerdi) It was 1992 when I first heard that there was this project going on where someone in Finland was trying to build a UNIX clone. At the time I was running OS/2 on a 16MHz 386/sx. It was a good operating system, but what I really wanted was some kind of UNIX. I'd looked at the ads for Coherent in Byte magazine and had considered that, as well as Minix. I'd even gone down to the local computer store and asked about SCO Xenix, which if I recall correctly, they wanted a couple of thousand bucks for a single-user license! I'll pass, thanks. So I was pretty excited to head to the computer lab and start checking out the USENET groups and FTP sites where the development was taking place. It almost seemed too good to be true at the time, but soon I had H. J. Lu's floppies running on my machine (it works!), and checked out MCC Interim Linux next. Yggdrasil was around back then, too, but I didn't try that one until much later since my machine didn't have a CD-ROM drive. I pretty quickly landed (softly) on one of the early releases of Peter MacDonald'sSLS distribution.
I was taking a class on artificial intelligence, and the coding was all done in LISP. We were provided with a DOS based LISP interpreter to use, but the CLISP interpreter that came with SLS turned out to be far, far better. I told my professor about CLISP, and about Linux, and he asked if I could help him install Linux on one of the lab's computers, an AT&T 486 with an S3 video card. We went down there and did the install, and it went pretty well. I took out my notebook ("time to fix the bugs!") and started fixing all the problems that I'd documented in the time I'd been using SLS, and this led to him asking if it would be possible to fix all those bugs on the floppy disks, and make the installer more automated, so that maybe future classes could do their programming on Linux and not have to license a fairly mediocre version of LISP. I was up for the challenge and started figuring out just how things had been put together. SLS had shipped as a mostly binary only release with hardly any source code for anything, and not a lot of clues as to how things were built. There weren't any build scripts for anything, though that was pretty typical for Linux distributions in 1993 (and was a trap I fell into myself early on until I got tired of having to relearn what I'd done every time something needed to be rebuilt). Over the next month or so I corrected all the bugs that I knew about in SLS, upgraded the kernel, and did a major cleanup of the installer. My friend Brett Person was my original beta tester (and contributed a lot to the installer as well), and by April of 1993 was encouraging me to share what I had back with the Internet. I got a few more beta testers around this time by directly emailing people who were posting on comp.os.linux running into problems with SLS and asking if they'd like to help test what we were working on. I got a lot of good feedback, and more encouragement to put the beta up for FTP. So, in July of 1993 I put the first public release of Slackware on an FTP site running on an AT&T 3b2 UNIX box and announced it to comp.os.linux. The response was pretty overwhelming... especially to the UNIX box that was hosting it. I tried to keep things running for a few days, but it wasn't going to cut it, and Linux wasn't yet up to the task yet either (TCP/IP still suffered from random hangs), so I put out a call for help hosting it. Among the responses was one from Rod Grimes of the FreeBSD project offering space on Walnut Creek CDROM's ftp.cdrom.com server, which I gratefully accepted. This led to a long relationship with the folks at Walnut Creek CDROM.
LQ) Which Slackware release to date has been the most demanding/difficult to put together? What about the most rewarding? (solarfields)
volkerdi) Thinking back, there are definitely a few of them that stand out as being particularly challenging, generally due to a major transition of some kind. The move from a.out to ELF was certainly one of them, as was converting from ELF libc5 to glibc when the first stable glibc release came along. I was _really_ glad to see glibc release as stable, because I'd adopted a policy of not shipping beta versions of critical components like the C libraries or compiler, but most other distributions had gone ahead and based on pre-releases of glibc. I was close to violating that policy when the long promised stable glibc finally came along. Probably the most difficult and also the most rewarding release was Slackware 13.0, the first release to support the x86_64 architecture. Eric Hameleers deserves a great deal of credit for his work on porting Slackware to AMD64/x86_64 systems, and for making sure that it would be possible to add multilib support to it fairly easily. I'd been inclined to support 64-bit only, using the same library directories as 32-bit Slackware, and viewed /lib64 as an unnecessary complication that was going to require patching a lot of sources to make it work. It did require a lot of patching initially, and still does in places, but /lib64 was the solution that everyone ended up using.
LQ) Slackware is reported to be the oldest surviving Linux distribution, to what does you attribute this longevity? (ChrisAbela)
volkerdi) I try very hard with Slackware to defer to the wishes of the upstream developers. This isn't the place to be patching in new features, or packaging beta versions (if that can be helped). Lao Tzu said that in order to lead, one must follow. I have my own ideas about how things should work, of course, but I try not to impose them in a selfish manner. The goal is to move forward without abandoning the project's roots. I have nothing against change, but at the same time I try not to let things get juggled around simply for the sake of making them different. People who come back to Slackware after a time tend to be pleasantly surprised that they don't need to relearn how to do everything. This has given us quite a loyal following, for which I am grateful. I guess we're doing something right.
LQ) Did you ever think Slackware would last this long? Do you still have the same enthusiasm for providing Slackware that you had when you started? (jmccue)
volkerdi) No, I didn't think that Slackware would last this long, or at least that I wouldn't still be working on it by this point, but it did reach a sort of a critical mass early on where it was going to continue forward in some form or another whether it was under my guidance or not. I'm still very enthusiastic about Slackware, but it is different than the early days when things were just getting rolling. Those were exciting times for Slackware and for Linux, watching the early adoption. Slackware had the first Linux related booth at COMDEX and we pretty much got mobbed demonstrating a web server running off of a laptop! The first Linux Kongress held in the Netherlands in 1994 was another highlight of the early rise of Linux. It's hard to top things like that. Later on, having Walnut Creek merge with BSDi and try to position ourselves to go public was exciting, and then devastating as the market crashed, the IPO was called off, and the company was sold off when the cash ran out. I'm happy to still be doing what I'm doing though. I love working on Slackware and being a part of the larger Linux community, and continue to believe that it's important work.
LQ) Where do you see Slackware 5 years from now? (smoooth103)
volkerdi) Your guess is probably as good as mine, as far as that's concerned. Five years is a really long time in the computer field. Thinking back over the history of the project, I really couldn't have predicted the course of events, and the majority of it is determined by upstream projects and the ever changing needs of the users. So, I like to stay focused on more immediate goals. As those are accomplished, what
needs to happen next comes into focus. It's been more a process of evolution than directed design. The challenge over the next five years will be to remain true to Slackware's roots in UNIX philosophy as other projects and developers to may have completely different goals contribute to Linux as a whole. The world seems to be moving away from personal computers and towards communication appliances, and applications (especially in business) are moving towards cloud services. How that will impact the direction of Slackware remains to be seen.
LQ) Have you considered a succession plan such as a Slackware Foundation, similar to Mozilla, Libreoffice, etc.? (kingbeowulf)
volkerdi) I'm not sure those examples could really be called "succession plans" -- the Mozilla Foundation is a non-profit organization, while Libreoffice is a fork that resulted from a general unhappiness with the direction that Oracle had taken OpenOffice (or at least a feeling that it was headed the wrong way). In the first case, I have considered something along those lines before. FreeBSD has a not-for-profit corporation that functions to accept donations of hardware and funds to help support the project, and it seems to work for them. I've considered that kind of thing, but wouldn't really know where to begin with it. Setting up any kind of non-profit or not-for-profit is a fairly major undertaking and it's not something that I see as feasible to try to take on without a lot of outside help.
Now to answer what I think you are really getting at -- is there Slackware after Patrick? I'd think that there would be. Back in 2004 when I got ill the team had many discussions about that, we did come to conclusions about how to handle the big "what if". The folks on the team weren't about to let the project drop.
So anyway, we don't have a succession plan, per se, but it's a bridge we would cross when we get there. Meanwhile we try to avoid riding together on the same bus.
LQ) What do you think about the panic that seems to ensue when the main Slackware site goes down? (kristizz)
volkerdi) Panic tends to create more panic, and when I see everyone freaking out I do the same. Especially when the code for the web site is something that was cobbled together long ago by people that have since moved on. Unfortunately, it seems like every time the project hits a bump in the road, there will be people who try to paint this as the tolling of the death knell. And it's been that way for a long time, and not just for our project. I think Netcraft has confirmed the death of just about every open source project that exists at one point or another. That said, it does hurt when the tone of comments tends toward suggesting that the reason there's no immediate solution is because I don't care. Believe me, I care, and when the trolls fire barbs at me I can get pretty discouraged and start thinking nonsense like "I used to be a Linux guru, but then I took an arrow to the knee." I try to come away with a sense of renewed determination, though. And the site is back up, ported to a newer PHP by Mark Post. We're looking at better things for the future, like a decent content management system that would allow us to post news items more frequently. It's been a while since slackware.com was really a hub of activity -- most of our web presence is here on LinuxQuestions, and personally I like that a lot better than thinking about trying to run our own web forum. We did that back around 2000 and found more of our time going into that than into advancing the project. And that's part of why we ended up porting the old site and getting it back online rather than proceeding with building up something from scratch. There was significant progress made towards a completely new website, but that effort should be going into getting -current in shape for a release instead. There's a lot of stuff in the queue.
LQ) Would you say your hard work pays, and the development of Slackware satisfies you economically and personally? (BlackRider)
volkerdi) Well, economically speaking the past few years have been pretty thin. If I hadn't made the strategic decision to head back to Minnesota several years ago there's no way I could have stayed afloat living in the bay area. California is not at all a cheap place to live, and I was always cutting it close out there. Lately I've been cutting it pretty close here, too. I don't even have insurance any more... knock on wood. Personally, absolutely. I've made friends all over the world. I hear from people every day who love Slackware and depend on it for critical tasks, and who don't want to run something else. Working on the project is exciting and fun, and the folks on the team are some of my best friends. It's just not possible to put a dollar value on that.
LQ) Can you describe your typical work day? (slacker77)
volkerdi) I don't follow a standard format, but my day would typically include coffee (very important!), reading my email and LinuxQuestions, and communicating with the rest of the team over IRC. I follow a lot of mailing lists such as BugTraq and oss-security, and many of the other lists run by upstream projects to keep tabs on the changes that are going to affect us. The other team members have areas they are handling, and keep queues of proposed packages, and I go over that to see if it's the right time to start integrating them into -current. There's a lot of compiling and testing of potential updates, and there's more patching involved now than there was in years past, so I do spend a fair amount of time either looking for patches that we need or writing them myself. We all have to do that, really. It seems like upgrades to the toolchain (gcc and glibc in particular) tend to break existing code more often, so what should be a simple version bump turns into porting something to the new compiler (I'm interested to see to what extent llvm/clang are adopted, because I suspect that might be less of a moving target). Of course, updating build scripts, compiling, packaging, and testing are the bread and butter of the project, but those come after a lot of research... I'd rather release well than release often because it's not always that easy to back away from a mistake after it's been merged into -current, much less as part of a stable release.
See: fortune -m "three lines" fortunes2
LQ) Can you describe your personal desktop setup (WM/DE)?
volkerdi) I'm running KDE on my personal desktop pretty much as Slackware ships it, and have used that almost exclusively since it was added. Before that I used FVWM for years. I've tried most of the popular window managers and environments at some point or another, long enough to get to know the ins and outs of them. I'm also a fan of Xfce because it is nice and snappy on my older machines while still providing a complete environment.
LQ) Can you give us some behind-the-scenes report of what hardware you use for testing/development/day-to-day work? (tuxrukes)
volkerdi) The machine I'm using for nearly all of the development here is an AMD Phenom II X6 1100T running at 3.3GHz, with 16GB of RAM. It's got 5 SATA drives in it, 4 of them running as LVM on RAID5, and another set up as a scratch drive for test installs. I'm a computer packrat and have many of my older machines running in some capacity or another, such as signing packages and generating the checksum and manifest files, and syncing out updates to the server we use to hold the not yet public trees. And there are examples of nVidia, Intel, and AMD video hardware so that I can make sure those are working properly. That was especially important leading up to the 13.37 release as everything was transitioning to drivers that use kernel modesetting... there were some tricky issues to overcome with that.
LQ) Slack had always had somewhat closed model of coming to life. What is the best way to contribute to Slackware? Maybe contributing to popular community projects? Or is it best to start Slack related project and see if it catches on? (bobzilla)
volkerdi) If you see something that's missing and that you think has wide enough appeal, you can always submit a SlackBuild for it to slackbuilds.org (if there's not one already... it's quite a large collection). That's also helpful to us if we ever decide to package it in the official tree. Starting a Slackware related project is also a way to go. When we quit packaging GNOME we were happy to see some teams step up to provide it. Testing what's in -current and reporting bugs is also a major help, especially if you've worked out a fix for them. Same goes for likely candidates for upgrades in the development tree. We get quite a bit of help from people who are testing things coming from upstream and find that the existing SlackBuild isn't working to compile them, figure out why, and let us know about it. A lot of this pending development discussion happens on LinuxQuestions, so please share what you know here.
LQ) How do you choose who you work with in your team? How did AlienBOB, Alan_Hicks, rworkman etc. get chosen? (suppy)
volkerdi) First a bit of history is in order -- Slackware core as it stands today is really the second generation team. The first team consisted of David Cantrell, Chris Lumens, and Logan Johnson. David and Logan approached me at a trade show in Chicago. At that time Slackware had never had a website and they volunteered to help build one. When I moved out to California to work for Walnut Creek, they offered them jobs as well, and they worked with me until the dot com bubble burst. David and Chris work for Red Hat now, mostly on the installer, and Logan is working at MOVL. Chris had a bit of fame a couple of years ago as the mastermind behind Fedora's hot dog theme.
The current team began as an unofficial Slackware mirrors system. Erik Jan Tromp (aka alphageek) ran a webpage listing these mirror sites and in addition to his own Slackware mirror there were several other mirror sites and administrators, and they had an IRC channel that they used to discuss what was going on with the mirrors. Eventually they ended up mailing me about it, and lured me into IRC. Initially it was to talk about issues pertaining to distributing the software, but it evolved into talking about development issues. People who have been in the IRC channel longer than I have include mrgoblin, amrit, karlmag, alphageek, and a few others who continue to lurk there but aren't so active any more. After that time, people who got added to core had usually made some kind of major contribution to Slackware in an unofficial sense, and were then invited to join. Robby and Alan were invited due to their work on SlackBuilds.org, and alienBOB through his work on creating a clean port to the x86_64 architecture and all of his extra public packaging work. Fred Emmott of Slamd64 (now working at Facebook) was also invited in and we still see him there. Mark Post was added after porting Slackware to the IBM S/390 mainframe (and feeding back bug fixes discovered along the way). Heinz Wiesinger was invited for performing various miracles, most recently figuring out the issues with mysql and PHP, including how to build PHP in a single pass and have the extensions remain compatible with all the various flavors of PHP in the package and the different Apache Multi-Processing Modules. We had also ended up absorbing a lot of his SlackBuilds from slackbuilds.org, so it seemed a good fit.
Amaze us appropriately and maybe we'll add you, too. But watch out for the terrible hazing rituals.
LQ) Have you considered ways to more consistently communicate with Slackware users (perhaps via a blog or Google+)? What about a more open development model, such as one based on git? (many)
I have considered making more use of social media. I have Google+ and Twitter accounts, and used them to announce or discuss Slackware related issues. I have Facebook, too, but don't use it all that much. I've never really been drawn to the idea of having my own blog (I'm glad alienBOB does, though). I've been trying to put more information into the ChangeLog than simply a list of changed packages though.
As far as a more open development model such as git or other version control, it's probably going to become necessary at some point moving forward, and rworkman in particular is really pushing for something like that to be integrated into our development model. Right now we have several people maintaining their own private trees and I spend an increasing amount of time reconciling differences between updates that were developed in parallel. I've always known that I don't scale, but it's becoming pretty painfully obvious that acting as the commit master for everything going into the -current tree isn't going to be sustainable for very much longer as the number of support packages needed for KDE and other things continues to grow. This is especially true if we ever expect the ARM and other ports of Slackware to all be working off the same source tree. On that note, it might also be time to start thinking about centralizing some parts of the SlackBuild system. While it's nice to have the build script completely self-contained, it's not very convenient when it comes time to support a new architecture. Nothing like deciding to add some new options to the ARCH block in there and having to edit every single SlackBuild in order to pull off what ought to be a simple addition. So these are some of the things to look at once we get this release out and start up another development cycle.
LQ) What do you think of the current trends in desktop environments (Unity, Gnome 3)? Years ago you chose KDE for Slackware; are you happy with the direction (semantic desktop) it has taken? (fgcl2k)
volkerdi) I haven't really had enough personal experience with Unity or GNOME 3 to have formed a strong opinion about them, but my observations of Unity lead me to believe that it's probably an intuitive environment for people that are used to smartphone or tablet interfaces. And my guess it that they're looking ahead to that market. I'm pretty sure I'd be more comfortable with GNOME shell myself. Between GNOME and KDE, I'm happy that it's KDE that's in the main Slackware tree. I like it a lot, and believe it has a more consistent feel to it. Maybe that's because the framework is developed primarily in C++. I tend to prefer C to C++ overall for most things, but I do think that C++ is the better language for GUI development because it's easier to make use of existing components and therefore the temptation to reinvent the wheel and do things outside of the provided framework isn't as strong. The transition from Qt3/KDE3 to Qt4/KDE4 was a bit bumpy (but we waited out the first couple of releases), and I think that most people would agree that KDE4 has evolved into a world class desktop environment. I'm looking forward to a newer Xfce too, but that's going to require absorbing a few of the GNOME dependencies that I was sort of glad to see gone. Not really a big deal though, since Robby's doing much of the heavy lifting there, and the new versions of Xfce look really good so the few additional support packages we'll need to add back will be worth the result.
LQ) Right now, there are a number of potentially intrusive technical changes coming to some of the major distributions. How do you feel some of these will impact Linux in general and Slackware specifically? Are there any you would considering merging into Slackware? (55020 & tuxrules)
volkerdi) Yeah, I see a few things coming down the line that may cause a shakeup to our usual way of doing things, and could force Slackware to become, well, perhaps less UNIX-like. I guess the two big ones that are on the horizon are Wayland and systemd. Whether we end up using them or not remains to be seen. It's quite possible that we won't end up having a choice in the matter depending on how development that's out of our hands goes. It's hard to say whether moving to these technologies would be a good thing for Slackware overall. Concerning systemd, I do like the idea of a faster boot time (obviously), but I also like controlling the startup of the system with shell scripts that are readable, and I'm guessing that's what most Slackware users prefer too. I don't spend all day rebooting my machine, and having looked at systemd config files it seems to me a very foreign way of controlling a system to me, and attempting to control services, sockets, devices, mounts, etc., all within one daemon flies in the face of the UNIX concept of doing one thing and doing it well. To the typical end user, if this results in a faster boot then mission accomplished. With udev being phased out in favor of systemd performing those tasks we'll have to make the decision at some point between whether we want to try to maintain udev ourselves, have systemd replace just udev's functions, or if we want the whole kit and caboodle. Wayland, by comparison, seems fairly innocuous, assuming that they'll be able to implement network transparency either directly or through some kind of add-on compatibility layer. Again, another thing that most desktop users don't have a lot of use for but many users can't do without. I like X11, and would probably stick with it if moving to Wayland meant losing that feature, even if Wayland's rendering method carried with it some benefits like reduced rendering artifacts or increased video performance. I guess we'll just have to see what the overall benefit is when it's far enough along to make such comparisons.
Right now, the big change that has me concerned about the future of not just Slackware but Linux in general is the impending implementation of Secure Boot in all Windows8 client certified hardware, and the total lockdown of ARM hardware with no option to shut this "feature" off. I'm imagining that we'll proceed forward initially requiring that Secure Boot be disabled in order to install Slackware, and was (to say the least) rather surprised that wasn't the path all the Linux distributions were taking. If that makes it impossible to dual boot without making a BIOS setting change, or leaves us without drivers because they are designed to only run against certain signed kernels then we'll have to reconsider that approach, but I can't imagine our users being happy if they suddenly found that they were prohibited from compiling their own kernels and modules. The goal here will be to maximize the end user's freedom to modify their own system, and if that means they'll need to go into the BIOS and flip a switch that doesn't seem like a high bar. Hopefully that won't evolve into needing to flash the BIOS because the switch has gone away when the next generation of machines comes out, if flashing the BIOS would even be possible. All it would take is making that a requirement for the next Windows hardware certification. I'd urge everyone to sign the Free Software Foundation's secure-boot-vs-restricted-boot petition to let the hardware manufacturers know where you stand on this issue. I'm especially disappointed to hear that the ARM based systems designed for Windows will be locked down out of the gate, but maybe it's possible that Google or some other company will come through for us. And maybe Alan Hicks was ahead of the curve when he bought an Apple laptop to do Linux development on. Interesting times we live in, indeed.
LQ) What do you think about Fedora and Solaris 'simplifying' the filesystem by doing stuff like merging /usr/bin and /bin? Something you would ever consider? (ruario)
volkerdi) Sure, I could see doing that, but we'll see how it goes elsewhere and to what extent things start to expect it to be that way. On Slackware (and other systems) a lot of the binaries that would otherwise install to /usr/bin have to be moved to /bin because they are needed before /usr is available, if /usr is on a separate partition. Likewise, libraries have also had to move. This has led to a lot of symlinks pointing from /usr/bin to /bin, or from /usr/sbin to /sbin, and elsewhere around the system. Now, I'm not sure that I consider this to be a bad enough situation that it's worth the pain of changing it, but it's certainly under consideration. Really, the most painful requirement about /usr was the rule that it had to be possible to mount it as a network volume. That might have been a good idea at the time when hard drives were expensive and small, but it probably isn't done a whole lot today. If we do make a change like that it would be a major change (and would warrant a major version number bump for sure), and I'm not sure how (or if) upgrading from an earlier version would work. Perhaps with a tool on the installer that would transform the system to the new layout? Dancing that dance on a running machine would be a difficult trick with the package utilities based on shell scripts that are using binaries at the same time that they'd have to be moved around.
On a related note, we're looking into how to best handle a top-level /run directory. This does make sense, if not to merge /var/run with it, at least to have it available in early boot.
As far as these kinds of changes are concerned, we have to be certain that they actually solve important issues and leave us better off than we were before, and without new problems that we didn't previously have. Sure, the way things are now until /usr comes online we may be dealing with a limited set of utilities, but we've been able to make due with them in early boot so far. If, for example, the changes make it a requirement to use an initramfs on every system, I wouldn't necessarily consider that to be simplifying things.
LQ) Given the success of some much younger distros, do you have any regrets with the direction he has taken Slackware in, and does he have any aspirations to get his creation more readily accepted by the masses? (vdemuth)
volkerdi) Heh... that's a tough one. Of course, with the power of hindsight I can look back and see a bunch of what might be considered "Gary Kildall moments" where doing things differently would have led to fame and fortune. Would that have been good for me, or for Slackware? It's very hard to say. Look at what happens to some of those lottery winners. The reason I didn't go along with some of those early offers that might
have followed that path was because the people with the cash didn't really want Slackware. They wanted Slackware's market share at the time. I wasn't even sure they wanted me -- I could have been quickly marginalized out of the business. I knew nothing of startups and venture capital, and early on was reluctant to accept payment for what I was doing at all because I felt like I was taking advantage of all the unpaid developers creating the components that I was putting together. Of course, since then an entire industry has grown around Linux, and I wouldn't mind having a bigger piece of that, but if my goal had been to make as much money as possible I'm really not sure that it would have happened anyway, and it's quite likely that Slackware would either have been a flash in the pan or turned into something completely different. In many ways, Slackware has evolved into a learning tool. There's a learning curve, and then the reward of understanding. Slackware's not going to fight you if you want to replace or recompile part of it. Somehow I think that's never going to be what the masses want, and I'm OK with that.
LQ) What tools do you use to keep track of all the packages in Slackware and how do you decide what gets updated and when? (trxdraxon)
volkerdi) Actually, it doesn't really require a lot of custom tools to track the number of packages that we currently have. I keep lftp bookmarks so that it's easy to find an upstream FTP site using "lftp ", and leave some hints in the tree (package.url). Otherwise, a lot of the TODO list and tracking here is in the form of a couple of notebooks. I know some of you might be laughing at the idea of tracking things on paper, but it's an efficient enough way to figure out what to do next. What is more difficult than finding stale packages is considering the impact that upgrading any given package is going to have on the system. Some of that is just guesswork, and some of it is based on past experience. After you've been doing this for a long time, you start to get a feel for which packages are going to be safe upgrades, and which ones you should be wary of (in spite of promises of ABI/API compatibility). Plus, we've all got our own favorite projects that we follow development and announcements for. User requests are also incredibly important in determining what gets updated, especially if an update is needed as a dependency for something that we don't ship. We do have a couple of tools that were written by Stuart Winter that we use to find packages that link against a given library, or binaries that need to be recompiled because libraries that they were linked against have gone missing. Those come in handy when shared libraries bump their major version numbers. I guess I wouldn't mind having a script that would search for newer upstream versions of all the Slackware packages and generate a report about what's available, but we do tend to find these things out anyway. Updates that are not libraries or dependencies for other packages can be done whenever there's time to do them. Packages that are dependencies for other things have to be done more carefully, and if it's going to cause a lot of rebuilds I might wait until there are updates available for some of the larger things that are going to have to be rebuilt (e.g. KDE). If bumping a dependency is going to cause other packages to need a rebuild, I'll do them all at once in the same batch. Even in -current, I don't like to see anything broken for very long, and leaving dangling dependencies is a definite no-no. Maintenance of older Slackware versions is mostly done for security reasons and there I prefer upgrading packages over patching them if the compatibility can be trusted (sometimes this will fix other problems as well), but if an upgrade might mean breaking compatibility then we'll patch the problems rather than possibly throwing a wrench in the works on production systems.
LQ) How does Slackware's reputation make you, personally, feel? Is it a point of pride that your distro is considered difficult to install/use and expert level, or do you view that negatively because it keeps new users from wanting to try Slack? (trademark91)
volkerdi) Hopefully that's not all of Slackware's reputation! And to the extent that it is, it's not something that I agree with. The goal back when the project was started was to make it easy, and to keep things simple. But to paraphrase Einstein, you want to make things as simple as possible, but not simpler. There's a point of diminishing return when adding additional layers and interfaces, especially when it comes to system configuration. I've seen automated configuration do things like strip out all the comments in a config file, or worse just completely rewrite the thing because you had the nerve to try editing it outside of the approved system. And I do feel like Slackware has been shafted in some of the reviews over the years, largely because there's a tendency to review only the installer and not the system itself. There is certainly a learning curve, but that's true for all versions of Linux. We've never tried to make things hard, but perhaps we also haven't tried to prevent people from shooting themselves in the foot. Things like aliasing rm to 'rm -i' don't help the user learn to be careful.
LQ) Slackware's passionate userbase is infamous. Do you have any words for them? (dugan)
volkerdi) Slackware may not have a huge userbase, but it is an extremely dedicated and loyal one. There are some really great folks in the Slackware community. Thanks for keeping me in line!
LQ) By default, Slackware installs an unusually large selection of text editors. Which one do you actually use? (dugan)
volkerdi) I actually use elvis most of the time (out of habit, and because it gets the job done), but I'm also a fan of vim. The vim color syntax highlighting has definitely saved me a lot of time debugging shell scripts.
When I was at Southeast Linux Fest last year, Andrew Psaltis gave a talk on Emacs that impressed the hell out of me, though. I was telling some of the people there that I was going to try switching to Emacs. I did try using it for a while, but not long enough to really got the hang of it (though I remained impressed). But, I drifted back to my vi comfort zone pretty quickly.
LQ) How are things going in general? Is there anything slackware fans can do to help with any inconveniences? (H_TeXMeX_H )
volkderi) Send lawyers, guns, and money! I've seen things better before, but I've also seen them worse, and I'm glad that we moved back to Minnesota before the economic downturn... it would have been a lot worse for us on the west coast, financially speaking. I am really grateful for the donations that have kept things afloat. If I had any ideas about how else Slackware fans could help out, I'd let you folks know. Frankly, a business model that's based mostly around selling physical media doesn't make a lot of sense in this era of widespread high-speed net access -- just look at what the record companies claim it has done to them. How to generate sustainable funding for the project is a looming question. Maybe have periodic fund drives similar to what public radio does?
LQ) Back in an old 1994 interview you stated that you were a homebrewer. Do you still have time for that these days? Related to that what is your favourite beer? Is beer your drink of choice? (ruario)
volkerdi) Yes, I did indeed brew beer, but it's been years now. I never did brew again after moving to California, but I kept most of my equipment, and have recently had the itch to try it again. So, I picked up some German pale malt and Spalt hops and will be brewing some Altbier one of these days. I've missed the cool season but the furnace room stays pretty chilly in the summertime when the air conditioning is running (it's also a good spot to keep the servers).
If I'm going to be drinking alcohol, yes, I'd say beer is my usual drink (otherwise coffee... and soda, but trying to cut back on that). Guinness is one of my favorites (especially the Foreign Extra). For cheap beer, I'll take a Pabst Blue Ribbon.
LQ) I caught your interview in Hacker Public Radio. Besides the Grateful Dead and incense, what other musical genres do you enjoy? When you're not working on Slackware, what other hobbies/activities do you enjoy? (kingbeowulf)
volkerdi) I also enjoy jazz, classic stuff from greats like Miles Davis and John Coltrane. I also like J.S. Bach, especially the harpsichord partitas. Gotta credit Hofstader and _Go:del, Escher, Bach: An Eternal Golden Braid_ for getting me interested in those (and Bach's "Musical Offering"), which are very interesting both musically and mathematically. Earl Scruggs and John Hartford are my favorite banjo players. Back in the mid 90s I went to see Jorma Kaukonen (who used to play lead guitar for the Jefferson Airplane) play a show not far from where I'm living now in Minnesota. John Hartford was also on the bill, but I wasn't yet all that aware of his music, which was an old time style banjo with lots of songs about steamboats and the Mississippi River. I ended up collecting a lot of his CDs over the years and picked up the 5-string banjo myself probably as a result of that one show. Other music -- blues, dixieland, big band, trance/glitch (like Oval), "found sound" mashups like Negativland, old country music. There's a great country AM radio station in Fallon, Nevada that I'd tune in when traveling through when all I had was a radio in my car. Now I've got satellite radio in my car... lately it's been tuned in to the 1940's station.
I like old cars, and have a 1967 Firebird that I've been driving for more than half my life. My wife acquired a 1950 Chevy last summer. It's got a 6 cylinder Stovebolt 230 in it, and only 53,000 miles. That one's going to take some work though... it needs almost full choke to run and seems to starve out once it's warmed up. I have a rebuild kit for the Rochester B carburetor on it which should help (it's got gas leaking from the gaskets), and might also be looking at vacuum leaks, or maybe the heat riser that's stuck is cooking the carb. Ah, great gearhead entertainment!
I'm also passionate about photography. I used to shoot black and white (Kodak Tri-X) and develop it myself. Now all my cameras are digital, and I don't own an SLR, but I still like to see if I can get good results from relatively cheap equipment. I use a Canon S90 point and shoot that's got the CHDK enhanced firmware on it that allows a lot of the advanced features that you normally only see in SLRs. The S90 can save RAW images natively, but even cheaper Canons can as well when using CHDK. I've taken a ton of bracketed photos, which is where you shoot a sequence of photos at different exposures that can be combined to make High Dynamic Range (HDR) photos. I've also done Kite Aerial Photography using CHDK's timer features, setting the camera to snap a picture every 15 seconds and sending it up on a kite. So far so good on getting the camera back in one piece, and I've gotten some really great shots that way.
LQ) Over the years, you must have done quite a few interviews. Is there any question you always wish an interviewer would ask but never has? (jeremy)
volkerdi) Do you want to come back to my place, bouncy-bouncy?
No, just kidding, but I couldn't resist having a Monty Python reference in here. :-) And to answer the question, not that I can think of.
Thanks folks, it has been fun! Let's do this on Reddit someday.
Take care,
Pat
|
