Interview w/Slackware Developer David Cantrell

keskoy writes: "David Cantrell is a core team member for the Slackware ^[?] Linux Project. In this interview you will learn how David got his start working on Slackware linux, what his role as a Slackware developer is, he will explain to us about his two new applications protopkg and autoslack, plus other various topics of interest are touched on."

What would the "combination" be?

• Perhaps the "best feature" of Red Hat is their tendancy to aggressively pursue the most bleeding edge experimental stuff out there, whether that be ELF, GLIBC2.0, GNOME, or GCC 2.96...
• SuSE's "best feature" is that they have built vast quantities of RPM packages for all sorts of stuff, with considerable numbers of "engineering hours" tweaking the packages.

  Note that these tweaks are to make the packages work with the SuSE "layout," and may not work with other distributions...

• Debian's "best" features are three, namely that they have built vast quantities of DEB packages, with a huge group of package managers (that are people) that tweak those packages, that they have built tools to validate those DEB package to ensure conformance with their standards, and, thirdly, that they have a sophisticated package dependancy manager, APT, which will automatically install the dependancies called for by what you want to install.

  The stable release, as typically released on CDs, takes the conservative approach of only releasing what they know already works well.

• Slackware takes the approach of requiring that packages be managed as "tarballs," with somewhat more limited dependancy checking, and with the expectation that you, the sysadmin, will be installing and configuring the services that you want, as opposed to GUIing it all.

Note that none of this has anything to do with licenses, only with the respective design choices. And some of those choices are downright incompatible.

I would argue that the notion of the "best uberdistribution" is a contradiction in terms and thus an inherent impossibility.

As for the "licensing thing," one part of constructing a distribution is indeed in assessing the respective licenses of the components and how that fits with what you plan to release. If you can't cope with the legalities there, you're probably not legally prepared to release any kind of collection of this sort of thing...

Re:Slackware packages

So what's the alternative? Surely not Debian, Redhat or SuSE. Using common defaults works well for the user who fits those defaults, but screws up everyone else. And throwing a flashy GUI over the adminstration doesn't make it any easier.

I have found, like the other poster, that Slackware is TRULY easier than the other distributions I have tried. The installation is a snap. Administration is easy. That's because Slackware is laid out sensibly. It does require that you be willing to learn, however.

Taking the car analogy, everyone who can drive a stick can drive an auto, but the reverse is not true. Once you know Slackware you know Linux, but once you know Redhat all you know is Redhat.

Slackware Developers

David, Chris, and Logan are three of the friendliest and most helpfull developers I've ever met. They regularly answer questions and post information on the web forums on www.slackware.com [slackware.com]. They can also be found at #slackware on irc.openprojects.net. I've seen them help more people on irc then I can count, from newbies to gurus alike.

All three need to be recognized and applauded for their efforts and commitment to the community.

Slackware packages

If you are a control-freak, Slackware is definitely the way to go. The administration tools are kept to a minimum. If you want to make things fancy, you need to set that up yourself. The result is that you slowly move towards gurudom.

However, if you are making money, slackware packages are fairly primitive. To the best of my knowledge, they don't support dependencies. You don't have a neat dselect type app. But you have the direct power. And that is the price of power - efficiency. I used to compile all my stuff on slackware. However, I must admit that I love apt-get and dselect. It has cut my workload severely.

That being said, I still use slackware on my production server. But my workstation is a debian woody.

Doppelganger

Every time I see this name, I assume people are talking about British Perl Monger David Cantrell, instead of American Linux Hacker David Cantrell. Obviously the open source world needs better naming conventions... :)

Flip-side: BSD Ports

The other interesting alternative would be to take some variation on the BSD Ports [freebsd.org] and build that as the "user space" with Linux as the underlying kernel.

Note that the Debian folk once had the (arguably deranged!) counter-idea of doing the opposite, namely using FreeBSD as kernel for Gnu/Debian/FreeBSD.

I'd contend that neither approach is the least bit "deranged;" I'm actually quite surprised that, with all the BSD connections, Slackware has never headed to using Ports as its package management system...

get slack

wow...1996, and having to reinstall every three or four weeks due to library drift. really brings back memories.

interesting about package management, but it appears apt/dpkg is still the best of breed.

at some point it would be nice to have keywords (something like what "apropos/man -k" is to man pages) for packaging systems. I don't like having to go on the net to find commands/packages to get when I need a program to do "whatever".

some of these news sites ("userlocal.com" in this case) are pretty cool. I prefer the articles that mix some tech background, review, and a bit of getting started all-in-one.