Persona Grata: Robby Workman. A teacher of science and a politically-minded Linux geek
Published: April 14, 2007
The Slack World: Robby, prior to asking the questions, we studied your site, and the first question is: from teaching, through emergency management agency and being a reserve deputy, how did you get interested in computers and become a Linux geek?
Robby Workman: I'm actually a "late bloomer" in the computer world. I'll try to keep it relatively short, as I'm sure very few people are interested in the mundane details... I had an old 350 MHz AMD whitebox that someone gave me back in my old hometown, and after I moved to Tuscaloosa, I decided to get a new one. Rather than buy one from Dell or Gateway or whatever, I decided to try and learn something new, so I did a bit of research and ordered a bunch of parts from NewEgg and built it myself. For what it's worth, it still serves as my primary workhorse box—2.6 GHz P4 with HT, 1.5 GB RAM, and a couple of large SATA drives. Anyway, I had always used Outlook Express as a mail client, and I hated it, so I was looking for something new. I stumbled upon Mozilla Thunderbird (it was still in development—0.4 at the time), so I gave it a try, and both my wife and I really liked it, even at that early stage of development. As I got more familiar with it, I started helping out with user support in the Thunderbird forums, and I saw lots of talk about this "linux" operating system. Curiosity got the best of me... :)
2. When did you stick in Slack? How did this happen?
My initial foray into Linux was with Mandrake and Fedora. I had done some reading about Linux in general, and it supposedly had this reputation for being a "geek" thing. Both Mandrake and Fedora worked out of the box pretty well, and I messed around with them for a few days, but they seemed too "Windows-like." That's not to say that there's anything wrong with being like Windows necessarily—it's just not what I wanted—I was more interested in something to challenge me. I liked the name "CollegeLinux" (which was at that time based on Slackware 9.1), so I installed it and actually kept it for a few weeks. I liked the way everything was laid out on it (as it turns out, they deviated from default Slackware very little), and I had read that it was derived from Slackware, so I did some research on Slackware. Slackware was supposedly the most Unix-like distribution of Linux available, and I had by this point read quite a bit about UNIX in general, so it sounded good to me. This was around August or September of 2004—a couple or three months after that first download of a linux iso.
3. Do you try other distros these days?
No, not very much. I've dabbled in OpenBSD a bit, and I'm a big fan of their stance on lots of issues. I think the open-source community as a whole has probably been a bit too quick to jump on the "pragmatic" bandwagon and accept "solutions" that don't have long-term viability, which is not to say that I think proprietary software is evil (or that those who use it are evil), but I would like to see better open-source drivers especially for the popular graphics cards, and it seems that the widespread community acceptance of the proprietary solutions has hampered that effort—there's no overwhelming user pressure for those vendors to release the necessary hardware specifications for developing open drivers.
Anyway, back to the question: if I ever decide to branch out from the "hobby" aspect of computing and try to make a career out of it, then there's no doubt that I'll need to be familiar with some of the other distributions; however, for the time being, I'm happy with Slackware, so I just don't see the need to look at others most of the time. With that said, I've certainly looked at the sources of some other distros to see how they handled various things, and I'm definitely of the opinion that we can all learn things from each other.
4. What window manager do you use (or are you a CLI guy)?
I'm rather partial to Xfce. That's not to say that it's better or worse than kde, gnome, or some other window manager/desktop environment, but it suits the way I work really well. I've got enough hardware horsepower to run kde or whatever, but I don't really use any of the kde applications (okay, maybe k3b), so I prefer to use that horsepower to do something besides drive my desktop environment.
With that said, I'm not really reliant on X—I find that 'links -g' is more than adequate for most of the browsing I do, and I use both pine and mutt regularly on remote boxes. For general system administration, I strongly prefer a plain bash/ksh interface. :)
5. Ayaz: I use Slackware. I love Slackware. But when asked why, I flounder haplessly, with litte more to say than "because it is simple and puts me in control of the system." Why do you love Slackware (I am assuming you do)?
What more is there to say? ;-) Seriously, the second part is the reason I love Slackware—I am in control of my system. If I want to do something that's possibly braindead, then I am allowed to do it (and of course, I get to pick up the pieces if it actually was braindead). This is an oft-repeated saying that borders on "cliche," but it's true: when you learn Slackware, you learn Linux. In some other distributions, you learn distribution-specific ways of doing things (such as configuring the network, configuring sound, etcetera),whereas in Slackware, you learn the generic (portable) ways of doing those things. The distribution-specific ways might usually work just fine, but you can be guaranteed that the generic ways will work.
I'm going to sound like I'm picking on Debian before this is over, but I promise I'm not—it just so happens that I've actually used a Debian box a little bit, and I know a few people who admin one, so I'm a bit more familiar with it than with some others. One thing that bothers me about Debian is that it basically manages your system for you—for example, if you make changes to syslog.conf and/or logrotate.conf, they will be overwritten when you update/upgrade those packages, so you have to go back and make the changes all over again. It seems to me that Debian is very easy to maintain so long as you leave the default configuration—for some people, that's acceptable, but for me, it's not. Another issue with the automated dependency resolution is when packages list dependencies that are only necessary because the distribution insists on doing things different than the application's upstream maintainers do—for example, the Debian package for squid has (had?) a dependency on the logrotate package, even though squid by default rotates its own logs; basically, the Debian folks configured squid to use logrotate instead. In this particular case, that might not be a bad thing—it depends on what most users want, I suppose; however, this highlights another of Slackware's strong points—with rare exception, Slackware doesn't patch upstream sources [1]; the package you install is exactly what you would get if you compiled it yourself using the instructions from the upstream developers. That might not sound important, but it is a major issue if/when bugs are encountered—I've seen countless examples of finger-pointing: a user reports the bug to the upstream developers, who then blame the distribution's patches, so the user reports it to the distribution, who refer him to upstream, and so on.
[1] In those cases where upstream sources are patched, it is generally to address security issues or to make them compile on whatever toolchain is in use in that Slackware version.
6. It may be an old horse that has been beaten countless times with sticks, but it sprouts up just as often when comparing and contrasting Slackware with other Linux distributions (and, perhaps, non-Linux distributions as well), plus I often find myself short of convincing words when talking about it: Why do you think the lack of dependency checking in Slackware's package management system make it so simple and great?
It's not hard to find examples of automatic dependency resolution causing problems, whether it's the native implementations in some other linux distributions or in the various third-party attempts for Slackware. We've all heard about "rpm hell" on the various RPM-based distributions, and here's one from Debian.
Granted, that's a packaging problem for sure, but the point is that such errors simply aren't possible with Slackware's native tools for package management. That's not to say that there aren't other issues that can cause problems with Slackware's package tools - for example, there's no way to ensure that a package isn't overwriting files that are contained in some other package, and I've been nailed by that before (GNU pth, if built incorrectly, overwrites one of the headers in the glibc package, and then problems occur building some things later—I pulled some hair before I finally figured that one out). That weakness though, is also a strength, because unlike the automated things that try to be "smart" about it, it was easily remedied by reinstalling the glibc package. One could argue that it wouldn't have happened to begin with if Slackware's package tools were "smart" about it, but then, overwriting files in other packages is usually harmless, so the headache associated with having packages refusing to install because some icon or something is present in two packages (and thus being forces to pass some flag to override it) just isn't worth it (IMHO).
7. You've been mentioned in Slackware's ChangeLog quite a few times. Based on your experiences, what is the best way for someone to help out with the Slackware development process?
Well, I'm not sure I have any more insight into the process than anybody else, but I'll throw this out... First of all, keep in mind that Slackware -current is the development version of Slackware—it is not intended for production use, as it's basically just a daily snapshot along the road to a new stable release. That being said, if you are interested in helping Slackware development, using -current is the way to go. I won't go so far as to say that this is the way to do it, but... If I find a "bug" in Slackware, I first check the various IRC channels, the Slackware forum on LinuxQuestions.org, the Slackware related mailing lists, the alt.os.linux.slackware newsgroup, and google in general to see if someone else has run across it and/or fixed it, or at the very least, to see if anyone else can reproduce it—if it's just me having the problem, the the problem is likely ME. :) Regardless of how the above works out, I try to find a solution before I mail Pat. I'm not saying that I always have a solution or patch included in my mails to him, but I try—here's my rationale:
If other people have also found the bug, it's safe to assume that Pat's inbox has already been flooded with reports that lack solutions—there's no need to add one more. If other people have *not* found the bug, then there's no need to get in a rush, as there's time to look for a solution before I send a mail to him.
8. Mikhail: Robby, as far as I know, you are one of the founders of the SlackBuilds.org project, which I think is one of the most useful Slackware-related projects in the Net. How did you come to the idea of the project and what are its basic principles?
First of all, what we've done with this project isn't original at all—a guy named George Georgeakis had a site called "SlackBuild Central" for a while (and he's still got it online for historical reference), but it had long been out of date and unsupported due to his work demands. There were quite a few different people hosting build scripts for various applications, but there was no central place to look and you didn't know what you were getting when you pulled a script from some random corner of the web—as with everything else, the quality was sometimes very good and sometimes very bad. There had often been rumblings in the Slackware channel on freenode's IRC network of trying to start a central repository, but as is often the case, lots of people talk and nobody does anything. I don't remember the exact conversation, but to make a long story short, Erik Hanson (the GWare maintainer) and I were discussing it and one of us said "let's do it." We brought a few others on board and started working behind the scenes on putting together a small group of scripts for initial offering. We went live in July 2006, and the project has been steadily growing since then. It's still somewhat overwhelming to see just how successful it's become, and I think a lot of that success is due to our philosophy; we try to be true to the "Slackware Way"—that is, to keep things as simple as possible without unnecessary complexity.
One of our main ideas at SlackBuilds.org is the KISS principle. We are generally not very fond of trying to emulate the features of a full-blown ports system. That's not to say that a ports-style system is bad, but it's just not something we want to do. Some of those concerns are related to straying from the "Slackware Way," and some are purely time issues. With a small team of volunteers, most of whom have roles in other major projects, we have to be very careful of what we obligate ourselves to do... Did that make any sense at all?? ;-)
While I'm talking about SlackBuilds.org, I'd like to issue a public "THANKS" to everyone in the Slackware community that has contributed scripts to us, used/tested any of our stuff, and/or recommended us to other users. I'm not exaggerating when I say that our success would not have been possible without the community support that we've gotten. As of right now, we have scripts from fifty-one different authors in the repository.
Thank you, Robby! Have the best of luck in all your activities!