A Mind Lost

Anything and everything.

Behind Slackware

Immersing myself in Slackware again lately, I came across a journal/blog “Human Readable” written by one Darrell Anderson. Mr. Anderson bemoans the features he thinks Slackware is lacking, so much so that one is left wondering if, in spite of his professed dedication to Slackware, he actually gets Slackware.  What follows are retorts to his long-winded rant about Slackware’s supposed deficiencies:

I am not wedded or bonded to Slackware. Most of the time I find the operating system useful for the way I like to maintain my computers. I discussed elsewhere why I would migrate away from Slackware. My reasons focus primarily on supporting other people who use a free/libre software operating system. Slackware is good enough for me and tends to stay out of my way. Slackware is not a good choice for “mom and pop” and non-technical users.

Perhaps this lack of bonding is the reason for his lack of “getting it”.  And by it’s very nature Slackware is not a good choice for “mom and pop”… or “grandad and gramma”, or “crazy aunt Bertha and her twelve cats”…

Although my journey with Slackware is much less bumpy these days, one ongoing beef I have with Slackware is wanting to see better support to help end-users render Slackware more usable to “mom and pop” and non-technical users. That target audience is dear to me. Most of the distros allegedly focused on such users are bloated and never will run on old hardware, which many “mom and pop” and non-technical users still use. Slackware or a derivative has the chance of cornering that audience, but some serious usability tweaking is needed.

The various open and free source movements have answered this sort of demand repeatedly over the years.  If you want something done, and no one else is doing it, roll up your sleeves and do it yourself.  Slackware has no need of “cornering that audience”, because that is not Slackware’s target audience in the first place.  No usability tweaking required at all, thank you very much.

Some of the derivative maintainers have tried to smooth those edges. Yet working with the Slackware derivatives is frustrating. Those maintainers have their own vision and that vision does not match mine. I find that the derivative people are geeks and do not include usability testing with “mom and pop” and non-technical users. Testing on old hardware is rare. These maintainers tend to treat their derivative like the stock Slackware — geeks designing software for geeks. Free/libre software remains predominately a geek culture even when “improved.”

“Wah, I am not happy with stock Slackware, and double wah because the people who have modified it to suit their own goals (one of the driving reasons behind the GPL) aren’t modifying it to suit my goals.”  That’s about what I got out of that.  Calling them geeks certainly doesn’t help, either.  Sure, it’s cool to be a geek these days, but in this context it’s mildly insulting.

I agree that a good solution for me would be to manage a new derivative project. Working in such a project at the code level is beyond my skills, but I have the vision and management skills. As a project manager I could have Slackware working for me the way I want. I could design a derivative system to work for “mom and pop” and non-technical users the way I think such a system should function for those people. Somehow use the best ideas of the derivatives and merge them all.

Agree with whom exactly?  I disagree that you should manage any project where the number of contributors to said project is > 1, with that 1 being yourself.  Not with this attitude, anyway.  Here we go: If you want Slackware working for you the way you want, then change it so that it works for you the way you want. How bloody lazy are you that you expect someone else to do the work?  If something is beyond your skills, then learn some new skills instead of bitching about it.

Here is my punch list as I previously described:

And here is my counter punch list, complete with a snap kick to the groin and an elbow to the face:

  • No graphical installation. A graphical installation is not a critical priority. If I provided other people support they would receive a pre-installed system. A graphical installation is not a priority for my own usage but is nice eye candy for demos.

Slackware uses a curses based installer that performs the job adequately and is guaranteed to work flawlessly on any display device capable of displaying text in 80×25.  You can even get in to 80×50 mode if you want when booting the kernel.  Slackware, in case you haven’t guessed, is not about eye candy.  A text-mode installer works just as well as a graphical one.  It runs when you install, and then you never have to see it again. There’s nothing to “demo” in Slackware. It installs, you configure it, it works.

  • No boot splash. A boot splash is important to “mom and pop” and non-technical users. I prefer a classical stdout boot output, but my experience is “mom and pop” and non-technical users recoil at anything but a boot splash screen.

A boot splash!? What the hell?  Who cares about something you’re going to see for all of 20 seconds while the computer boots.  Just turn the frelling monitor off until you’re sure your login manager is ready if it bothers you that much.  Or roll your own bootsplash when the system is up and running.  Make a package out of it for ease of installation on multiple systems.  This is how Slackware is meant to be used!

  • No graphical administration tools. Graphical administration tools are a must for “mom and pop” and non-technical users. End of discussion. Some of the derivative maintainers have tried to fill that void.
  • No graphical package manager. The only graphical package manager for a stock Slackware I know about is gslapt. Some of the derivative versions have their own. I think gslapt and the others fall into the “good enough” category. Not as polished as some more well known graphical package managers, but probably good enough to keep “mom and pop” and non-technical users away from the command line.

Slackware’s origins, and hence its design goals, predate the era of graphical administration tools. While I would agree that an “official” graphical frontend for pkgtools would certainly be nice on occasion, there’s nothing that you cannot do with a text editor and some thinking.

  • A lack of a large central package repository. A lack of a large central package repository can be worked around — somewhat. There are several package repositories that can be used in a graphical package manager to provide the illusion of one large repository. Yet these multiple repositories remain no match against the large package repositories provided by Debian, PCLinuxOS, Red Hat, etc.

The design of Slackware is such that Pat and co. provide a base system that gets you up and running in a fully functioning environment without layers of crap in between. What you do with the system from there is your domain. If you want a program on your computer, then it is your responsibility to see it makes its way there.

  • A lack of full multimedia support out-of-the-box. A lack of full multimedia support out-of-the-box is easily worked around with pre-installed systems.

I don’t understand the complaint about multimedia. Almost all audio media I use plays just fine, while video media hasn’t caused any problems in years. Alien BOB‘s VLC package is the easiest, but it’s not particularly hard to build VLC from source either. MPlayer also functions quite well.

  • A hodge-podge collection of documentation scattered around the web.
  • /usr/share/doc has tons of documentation. Most software also has its own documentation on their website. Searching for the homepage of the software in question is hardly difficult. A comprehensive and up to date wiki for Slackware would certainly be nice, but again – if no one’s done it, what’s stopping you?

  • The lack of a current user’s manual.
  • User’s manual? Really? Put disc in drive, install operating system, DO WHAT YOU WANT WITH IT.

  • Comparatively small community.
  • There’s nothing that can be done about the community.  Slackware’s greatest strength is also its greatest weakness.  It is an advanced distribution intended for people who know, or want to know, how all the little pieces come together to make a whole.

    A hodge-podge collection of documentation scattered around the web and the lack of a current user’s manual is a sore spot. Several times I have considered starting a Slackware documentation project. As a technical writer for three decades I probably have a clue about such a project. My documentation would focus first on desktop usability. I would relegate the typical Slackware administration information to an appendix or secondary manual. Slackware documentation, as well as the documentation provided by the derivative maintainers, remains focused on the geek user and not the “mom and pop” and non-technical users.

    Considering something is not the same as doing something… and by the way SLACKWARE HAS NEVER TARGETED “MOM AND POP” OR NON-TECHNICAL USERS.  And that’s the way we like it.  There’s a certain amount of pride when we say use Slackware.

    Anyway, after a few more mentions of poor old “mom and pop”, and some rambling about desktop environments and not upgrading, we get to this:

    I wish Slackware users provided more attention to “mom and pop” and non-technical users. I wish they provided more usability testing with such users. I wish they provided more testing on old hardware. I wish KDE 3.5.10 could be patched more easily.

    Probably not going to happen any time soon.

    I might as well wish for world peace too.

    The suggestion to wish for world peace is probably the most meaningful part of this nonsense.  Slackware is not a big project, does not have massive corporate financial backing, and simply doesn’t have the manpower to do more usability testing.  Which is moot anyway because Slackware does as little as possible to alter the software installed.  If you want usability testing, take it to the software authors, not the distribution maintainers.

    And there’s nothing stopping you from forking KDE 3.5 as far as I know.  Start a project somewhere with a bug tracker, announce it anywhere and everywhere, see if you can’t lure some developers in, then start fixing and improving things.  Just don’t go in to it with the attitude that you are the supreme overlord and have final say on everything.  That attitude doesn’t get you far.

    His other entries contain just as much inane nonsense…

    Every time I read about an app that might be useful to me I have to find a SlackBuild build script. As there is no officially sanctioned Slackware repository, downloading pre-compiled packages can be risky. If there is no SlackBuild build script, then pretty much I have to do without the app. I’m tired of that game. The problem is not finding a way to build packages (there is a tool called src2pkg that avoids the build script problem). The problem is simply the inconvenience of not being able to download pre-compiled packages from a reliable source. An RPM or Debian based system solves that problem. Those operating systems support large central repositories and finding a package is straightforward. Like millions of other computer users these days, with those systems all I need do is download a package and I’m done.

    This one is really easy.

    cd $HOME/src
    tar xf $HOME/archive.tar.bz2
    cd archive/
    ./configure --help | less
    ./configure --whatever-you-want
    make && make install

    To the inexperienced this may look like some crazy voodoo command-line stuff, but really after you do it a few times you start to get the hang of it. Eventually you might even learn what exactly is going on when you enter those cryptic commands.  That’s right, you might learn something! *GASP*

    Why are people still creating Live CDs rather than Live DVDs? If people insist upon creating Live CDs then they should sacrifice some other package to allow room for pre-compiled VirtualBox guest addition packages. Testing and using an operating system in a virtual machine is status quo these days. Additional packages can be downloaded later. Usability from the beginning is a must.

    Downloading a 700MB image is a lot faster, and bandwidth friendly, than a 4.7GB image, especially when a minimal yet functional Linux system can operate in much less than a gigabyte of data. And why waste space including a package that will never see any use on a “real” computer, which is the expected use of a live CD.

    I will admit I do take a bit of offense to nonsense like this stuff.  Slackware was among the first handful of distributions I tried in the mid-90’s, and it’s the one distro I’ve stuck with in all that time.  In spite of any flaws and difficulties I have had with it over the years, it is without a doubt the best distribution for learning the insides of Linux.


    Leave a Reply

    Please log in using one of these methods to post your comment:

    WordPress.com Logo

    You are commenting using your WordPress.com account. Log Out /  Change )

    Google+ photo

    You are commenting using your Google+ account. Log Out /  Change )

    Twitter picture

    You are commenting using your Twitter account. Log Out /  Change )

    Facebook photo

    You are commenting using your Facebook account. Log Out /  Change )


    Connecting to %s

    %d bloggers like this: