As you might have guessed my screen name says I am a slacker, but I bet it
means something different to me than it suggest to you.
You see slacker is a shortened form of Slackware User, not somebody who does
not do much. It is one of those terms that has changed since the "invention"
of the Internet, just like hacker, in the popular press) means what cracker
used to.
So what is Slackware?
Well the short answer can be found at the official Slackware site,
www.slackware.com.
The long answers is Slackware is oldest, most versatile and easiest to
manipulate distribution of Linux in the world. It was originally derived via a
distribution called SLS that was put together in Manchester UK. When the
person who ran that got bored/made an unpopular decision/moved on (you
choose) Slackware was born, and I have been with it all the way from version1.
Now there are literally hundreds of different distributions around today,
some you may have heard off such as RedHat, Debian, Ubuntu, SuSe and
loads you will not know exists. A distribution can be very specific covering
one specialist area like music production (ArtistX) or a general one like the
ones more commonly known.
One interesting fact that most people do not know is that almost all the
distributions you see today owe their existence to Slackware. Look back far
enough in RedHat, SuSe or many others past and you will find their first
version were based on Slackware.
The one major difference between Slackware and almost every other distribution
around today is something called package management. Most of the common
distributions use a package manager to allow a user to add or remove software
from a computer with just a few mouse click or keystrokes, but not Slackware.
That is not to say you can not have that with Slackware, it is just it is not
mandatory as it is with most of the others. Slackware gives you a choice in
this as in everything else; you do not want it, rip it out! Of course if you
go and rip out the wrong bit then things will go wrong. Others do not want
this so put safeguards around things by having a tool that will make sure you
understand that by continuing with your actions you will break something. The
trouble is those safeguards come at a price, more software, more overhead and
more disk space. Now for a desktop system these days that is just not an issue
which is why any distribution is fine as long as you like it. But in the
embedded world it is just the opposite. Memory is tight, processing limited
and each installation tends to have very special needs. Slackware is one of
the few operating systems on the planet that lets you rip out any part of it
without getting in the way. Sure if you rip out the wrong bit everything goes
down the drain, but even that can be recovered from (usually). In my
experience this makes it ideal for those with tight memory budgets and limited
on board processing capabilities. To give you an example I managed to get a
working custom Slackware install in less than 1MB of flash. Yes a multi-user,
multi tasking operating system with real time capabilities, networking and a
GUI (of sorts) in one megabyte of space, and that was using no compression.
I am sure I might have shrunk it further, but I had what I wanted.
The other thing I like about Slackware is it is limited in its native support.
Now that may sound the wrong way around, but let me explain.
Most people would say that having a starting block that supports just about
any hardware ever made would be ideal. If you want that then go check out the
Debian project. It is a Linux based pure open source distribution that runs
out the box on over 14 different CPU architectures (probably more by now), but
so what? Are you developing on an embedded system or using a PC?
The one reason I use Slackware on both my PC and my target systems is it makes
things easy. I just get down/write/borrow the code I need and
compile/cross-compile it as needed and I am away. Heck I even run a copy of my
embedded environment in a virtual machine on my desktop so I can debug down at
the hardware level with no worries. Of course it will not help when sorting
out those timing problems, but for building a kernel that runs first time it
is installed on the target it is great. Well I like it :)