A Taste of Slackware (14.1)

Lately, I’ve been exploring minimalist distributions where they let you
maintain your craft your own environment from the scratch. I don’t blame
distributions for trying their own thing; not at all, I actually promote and
cheer on them to bring a more polished experience. If I’d ever work on a
distribution myself I’ll do my best to bring the best KDE experience on it–as
a KDE user myself.

I like Slackware. I like its philosophy, I like how down to earth it is when
it comes to maintaining your Slackware system.

I’ve been spending a few hours each day getting more and more into Slackware
environment. It’s no different than your typical Debian or Arch Linux setup
when it comes to GNU/Linux. Some things regarding the init scripts changes and
that’s to be expected since they also tell you about it.

I installed Slackware 64-bit, the installation itself was delightful. I only
ran into a few struggles and it all came down to LILO. For some reason it kept
throwing errors and I wasn’t remotely sure on the why. I wasn’t ready to take
on LILO either, mostly because over the years the default boot loader has been

Anyhow, it all worked out. I just followed the main instructions to boot the
root partition from the DVD messages and I was in my Slackware system in mere
of seconds. Truly amazing! I did a rerun of LILO configuration and it managed
to properly reinstall itself. What went wrong? I don’t know.

Immediately after my system booted. I ran *xwmconfig *and as you expected, I
chose KDE. I had the opportunity to try XFCE and some other window managers
like Fluxbox. For some reason if you are out of the QT/GTK environment the
application appearance becomes quite ugly and you have to go the extra mile to
figure out what’s wrong. I kinda knew what was wrong, at least on the GTK
part, but on the QT side I wasn’t that sure.

Slackware is truly an stable distribution, at least from what I’ve managed to
work with. What brought me to “fear” it was that I was in charge of managing
my own multilib.

I’ll try to elaborate:

In the Debian environment, we are used to do apt-get install package:i386
which is at best the most simple thing ever. It’s straightforward and it gets
the job done. In Slackware, for a 64-bit to be multilib-enabled you have
to do certain extra steps.

You need to download “third party” from a long term contributor that goes with
the nickname “Alien Bob”. Note that I don’t mind doing this. I’ve found that
this person has been a strong supporter of Slackware for years and I don’t
want to make it sound like it’s a bad thing itself. After all, Slackware is
nothing without a community–in my humble opinion.

Slackware package manager has no sense of “dependency management”. It means,
you need to brace yourself and do all the library/applications dependency
resolves. I have mixed feelings about this honestly; I have read many of their
reasons on the why, yet to me I don’t really feel convinced on why it
shouldn’t resolve dependencies, at least at best the base ones and leave the
optional ones as optional.

What “troubled’ me was installing 32-bit libraries in my 64bit system. There
wasn’t exactly an easy way to do it. And by easy I mean “take the least time
possible”. I had to do some googling and found out that there are unofficial
tools out there that helps you get 32bit libraries easily.

I did the initial steps of enabling multilib like I said before. However the
tutorial went down to “mirror the Slackware 32bit tree packages” and I
certainly wasn’t fond of that idea. Neither was using *massconvert32 *to get
the packages I want.

I feel like I’ve been introduced to something that takes even more time. It’s
not that I don’t feel like administrating my own system. It’s that the initial
setup would take longer than I expected. To me, these are itself “deal
breakers”. It’s not the fact that I have to track dependencies myself, but the
one that I’ve to jump a few hoops to get the 32bit libraries and convert them
to be compatible.

I’m gonna move on, I think I’ve said plenty on the 32/64bit subject. In terms
of installation and configuration I’ll be frank, it’s just the same thing over
and over. If you have set up MPD and other applications then you will know
where to find the configuration files. System wide configuration files usually
reside in /etc. Like always, things like this never changes. What I mean
is that if you are familiar with GNU/Linux then you won’t have problems.

Stability! It’s such an important word for me. Not stability as in the system
crashing, but stability as in packages receiving their proper updates for
minor point versions.

I might be wrong, but one of the things with Debian stable is that if a
package releases bug fixes and it’s not a major version. It all depends on the
release team to see if it will make it to Debian stable.

I don’t know how Slackware manages the influx of packages myself, this is the
first time I’ve used it in a prolonged manner. What I want is an stable
system, a conservative one, like Slackware. At the same time I also expect
that normal bug fixes releases also remains updated in the stable branch.

An example: I’m using Debian unstable sid. I haven’t had many problems with it
but I did come acoss some problems, most of the time it’s the dependency hell
that occurs. If there are dependency problems sometimes* apt-get dist-
* tries to remove a whole bunch of libraries that shouldn’t be

Obviously, as a person that likes to keep the system stability in-check I’d
just cancel the upgrade and wait for the fixes to come.

What does this have anything to do with stability? Well, there are certain
features in Dolphin file manager that stopped working out of nowhere. It just
happened abruptly and up to this date I haven’t found the cause.

In Slackware, all Dolphin features works. The system is rock solid.

I know I know. *Why are you using Debian unstable? You should know better!
Well, that itself is a fair question! Why use Debian unstable when you want
an stable system. Debian “unstable”, despite its name is not unstable as in
the software will break any time. I’ve yet to see my desktop environment
breaking apart. It hasn’t.

I’m going to wrap this up because I feel like I’ve written a lot already. I’m
willing to give Slackware a decent try as my main distribution if only I
get the answers I need regarding 32/64bit issues and well that’s it. I usually
compile my WINE versions (32bit) and I don’t exactly feel like it’ll be a
challenge to do that in Slackware, minus the dependency tracking which is
itself like an sport.

It was a nice experience. I’m still not a fan of compiling my own stuff
(mostly because it always takes too much time), but if it means to keep my
system in stable conditions and receiving good upgrades of the software I use,
then yea I’m all for Slackware.

If you have any thoughts, input about Slackware or know all the answers to my
doubts. Please feel free to comment!

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.