Is Slackware a Binary or Source-Based Linux Distribution?
This question (and we get asked this an awful lot), or the exclamation that it is (or isn't), is often bantered about in blogs, forums, and mailing lists.
It seems that there are different perceptions of just exactly what a source-based distribution is, and what constitutes a binary Linux distribution.
Before we begin, I think a couple of qualifiers to lay down some groundwork are in order.
First of all, NorthTech's technical articles, tutorials, and How-Tos are for the most part, focused on two of the oldest, most stable, and longest standing maintained distributions of Linux (when we're talking about Linux anyway).
Sorcerer Linux, as the name of the distributions phonetic implications suggest, is completely source-based, meaning you begin the installation from a rather small .iso image and once a basic installation has been accomplished, it totally and completely goes out (all by itself) and gathers up all of the latest sources from the actual repositories maintained by the software authors, downloads it, compiles it, and installs it all over again.
This is performed with an eye to the particular, singular machine's architecture that you are installing it on. It also yields what is arguably the most completely integrated, stable, and optimal UNIX system possible for each and every particular machine it is running on (and we agree).
Once Sorcerer Linux has completed its initial self-reinstall by downloading and compiling everything all over again using the latest stable "sources from the sources", you then may begin to decide what you would like to have installed beyond that which is merely a basic system.
For example, let's say you want the KDE desktop. Well, in order for you to have KDE, you also must have X, and in order to have X there are other dependencies which in some cases might seem to go on and on and on.
But Sorcerer knows (we won't go into how dependencies are met) what is needed before KDE can be downloaded, compiled, and installed. So it goes out and gets those things, then compiles and installs them, and when you come back in the morning your machine is waiting for you - except that now you have a bright and shiny KDE desktop waiting for you!
The next thing we should probably cover are how some of the other distributions out there deal with package management - such as the Redhat Package Management System, used by RPM-based Linux distros.
These distributions use a package (that means binary) manager that in a perfect world, resolves dependencies (or at least warns about those dependencies. They are certainly not as slick as Sorcerer - you can't just say say rpm -ivh KDE-version.rpm and expect X to be installed, and even with the newer YUM, which is supposed to go out and install those prerequisites for you as part of the process, an odyssey like the example we're using here just can't be met with a simple package manager.
Slackware is so much more elegant than this. Why? Because it doesn't even bother with worrying about source dependencies.
um... Huh? So, if I want to install the KDE desktop, how do I know what each and every dependency is? The answer should be rather obvious - KDE will tell you, when you peruse the docs and read about how to install it.
Okay that's a bit of a cop-out, but seriously, and in short order, When you install Slackware Linux you are installing a complete operating system that probes for the necessary kernel modules required to support your machinery, and with regards to the things you want (or do not want) installed, you choose them at installation time (or after the install).
The selection process is simple. you decide what you want, and the "Packages" are installed. Most people just install everything, but if you don't want games, then don't install them. If you don't want X, KDE, XFCE, etc., then don't install it. If you don't want networking, then don't install it.
Okay, so is Slackware source-based?
The packages are pre-compiled binaries, ready to be installed and run on your system. Like RPMs, they install virtually instantly (but the Slackware Package Management System doesn't bother to inform you of dependencies).
There are many reasons for this, but one of the most common ones sited is the fact that most competent System Administrators don't want to hand control of their system over to someone they don't know. The next most popular reason is probably the possibility that someone who wrote an RPM will place files in a location that you either don't want, or worse still, a place where mission critical files are going to be overwritten.
In an RPM-based distro, you can write your own RPMs. That's great! But by the same token, you don't know anything about the RPMs that you are about to install, that were written by someone else - now do you? By the way, Slackware does actually support RPMs - if you must.
Slackware forces the responsibility upon the Systems Administrator by requiring them to decide which (often optional) dependencies to meet prior to installation of a Slackware package.
By convention, the standard method of installing a package is to get the source, use a script called a "SlackBuild", and then run that SlackBuild, which compiles the source and creates the binary package.
In the SlackBuild script, you have complete control of where you want the package to be located, where you want all of the binary files of the package installed, where in the menu (if you're running say, KDE) you would like the application to appear on your desktop, and any/all configuration flags to be set during the compile process.
Now you're saying, "Um... Okay then, so is Slackware a source or binary based distribution?"
As with any UNIX system, you can simply download, configure, compile, and install software for that platform, but when we speak of 'packages', we're usually talking about binary files that are ready to run (We're not going to visit Sorcerer here again, and Sorcerer doesn't really use 'packages' anyway).
Okay now for a bit of history. Slackware is THE OLDEST Linux distribution still actively maintained! It also maintains its clean and pure UNIX roots.
In the olden days... Don't you just love when someone says that? ...we used to have to drive uphill backwards in our Fords - wait, wrong millennium, wrong story! Start over...
In the olden days, we would install Slackware and then, if we wanted a particular application, we would go and fetch it ourselves, untar it, ./Configure ; make ; make install (compile and install from source).
That still doesn't make the distro a source-based distro, however. The distribution was installed with pre-compiled binaries, as a series of packages. You didn't replace the entire installed OS with pure source that you re-compiled from scratch.
Nowadays, we don't often do it that way. We use a SlackBuild script (You don't have to - there are many alternative choices for Slackware). We manipulate this 'script' which, once we have downloaded the sources from the sources, configures, compiles, and then "Packages" the resulting binaries for us.
Note the omission of the word, "INSTALL". There is no installation of these compiled sources at this point, yet it is at this point that we have a Slackware Package in binary form, ready to be installed with the Slackware Package Management System ;)
Provided all of the dependencies have been met (a discussion which is beyond the scope of this article), we can now install this binary package on our (or most any other) Slackware box simply by invoking the package management utility of our choice (No, we're not covering how to use Slackware Package Management in this article either).
Installing a Slackware package is kind of a tricky thing - kind of like photographing lightning - if you blink, you missed it. It's that fast (and simple).
There are a few well respected Slackware package repositories out there, but even so, most seasoned administrators still prefer to go through the process of compiling from source in order to create their own (binary) packages.
As you stand there scratching your head, I know what you're saying now, "So is Slackware a binary or source-based distribution?".
In this article, we haven't actually come right out provided you with an answer to the question - we have, however, thoroughly explained the topic. That means you now have command of the answer, and can argue it. Once again, you have been put in charge of things - the Slackware way.
Probably the best way to make everything clear to you at this point, with regards to the internal mechanics of what all is involved, is to simply refer you to http://SlackBuilds.org and have you read up on installing all the kewl software you would like for your Slackware machines.
We recommend you install a few of your favs from existing SlackBuilds, and then make a couple of your own SlackBuild scripts.
Once you've done that, you'll be completely prepared to chime in with your own take on things life, the Universe, and 42.