If you are familiar with Linux you have probably heard of Slackware.
It's the oldest surviving Linux distribution,
and over the years it has earned a reputation as an ultra conservative stable and crude simple system.
Rumors of its demise are greatly exaggerated:
The current branch of Slackware has seen continuous daily updates in its
changelog
for years,
it's just that a stable release hasn't been pushed in a while.
Finally though,
on February 2 2022 Slackware 15.0 was released after nearly 6 years of development.
We will take a closer look at this recent edition of Slackware,
and I think you'll be pleasantly surprised.
We will not cover all the generic aspects of using a Linux desktop however,
since that is covered all over the place on the web,
instead our focus will be on basic system administration,
and package management in particular,
which is quite different in Slackware then what you might be used to.
PS: This is a long and tedious article, if you want the quick version just read the Installation and Desktop section and the Package Management section. Have Fun!
Well, yes and no. Take this 2 second test to see if you have what it takes to become a Slacker: To enable sudo access uncomment the %wheel line in /etc/sudoers. Do you understand what that means? Would you be able to do it? If so you have what it takes, if not you may be in for a rough ride...
Despite it's reputation installing Slackware and firing up a desktop is done in a matter of minutes. In recent years binary repos and user friendly package managers with dependency resolution have also become available, so you can choose to use Slackware much like a run of the mill desktop distro (and this will be our focus here), even though the defaults assume a much more manual approach. Although it's certainly a loosing uphill battle, Slackware strives to follow the KISS principle/UNIX philosophy, so upstream applications are altered as little as possible, and the distro tries very hard to stay out of your way. This may seem crude, even unwelcoming to users who are accustomed to more user-friendly distros, that include layers upon layers of patches, custom configurations and assorted helper utilities woven deeply into the mesh of things, all in a valiant, but ultimately futile, attempt to hide the fact that Linux is inconsistent, ugly and difficult. Slackware makes no such attempt whatsoever. It may seem counter intuitive at first, but in the long run this approach is easier.
For one "user-friendliness" is often at the surface level only. Like throwing a blanket over a pile of garbage it doesn't actually solve the underlying problem (looking at you Systemd). When things break the sysadmin needs to understand how the underlying system works. Kelly Johnson, the lead engineer at the Lockheed Skunk Works who coined the acronym KISS (Keep it simple stupid), famously handed a team of design engineers a handful of tools, with the challenge that the jet aircraft they were designing must be repairable by an average mechanic in the field under combat conditions with only these tools. Seasoned sysadmins, whether they are Slackers or not, understand what he was talking about. Because every major distro has their own custom tooling, learning the ropes in one of them, will not necessarily help you out in another. Finally, since most big distros patch upstream applications liberally, it can be very hard to debug problems. Does the bug originate from upstream, from the distro patch or is it some local customization that are screwing things up? The fun really begins when a forum suggests one solution, the distro documents another, and the upstream developers agree with neither.
So even if Slackware lacks makeup and has a somewhat steep learning curve at the onset,
once you fix problems that arise,
they tend to remain solved.
The problems you encounter in Slackware will also be Linux problems,
and the tools you use to solve them are Linux tools.
So once you have become comfortable with the warts and smells in's and out's of this old distribution,
you have essentially become a distro agnostic Linux expert.
Why even
BSD
will not throw you any big surprises!
Like
LFS,
Slackware provides a fascinating learning experience,
but unlike LFS,
it gives you a fully functional desktop and server to start with.
PS: We will not talk about how you can use Slackware as a server (or "in the cloud" if you prefer), but if you're interested in that topic, I might suggest some fine reading material for you: Alien Bob recently wrote a 7 part blog about cloud services in Slackware, here is part 1: Episode 1: Managing your Docker infrastructure.
Because Slackware avoids making custom changes to upstream software you often don't need distro specific documentation. Are you having trouble with Firefox? Go to the Firefox website. Are you having trouble with VLC? Go to the VLC website. Are you having issues with LibreOffice? Go to the LibreOffice website. The point is: If you are having trouble with a program in Slackware, talk to the developers of that program. The version shipped with this distro is delivered as the authors intended.
A pro tip when googling a Slackware problem: search for "Linux my problem..." or even "BSD my problem...",* not "Slackware my problem...", since Slackware users are few but application problems are often similar across distros. The semi official Slackware forum is LinuxQuestions.org, many of the Slackware developers hang out there and will answer your questions to the best of their ability. An excellent Linux resource is the Arch Linux Wiki. Of course the information here is specific to that distro, but many of the pointers will be relevant on other distros as well. There are Slackware mailing lists, but they are not much used.
Yet another channel for support is IRC (Yes, the Linux folks still use IRC!). IRC is an informal, noisy and rude place, but it will sometimes give you a quick solution to a quick problem. On libera, you can usually find a channel that's specific to your needs. For instance if you were having trouble with the above programs you could go to: #firefox, #videolan, or #libreoffice. Other channels of interest are #linux and ##slackware (the Slackware channel is called ##slackware, not #slackware, for historic reasons, but #slackware will just redirect you to the right ##slackware channel). If you are unfamiliar with IRC, go to the Hexchat website, and follow the instructions. If you want to use the command line, irssi is one alternative:
$ irssi
[(status)] /network add <mynickname>
[(status)] /server add -ssl -auto -network libera irc.libera.chat 6697
[(status)] /connect libera
# if your nickname is already taken, you need another one:
[(status)] /nick <mynewnick>
[(status)] /msg nickserv register <mynewnick> <myemail@example.com>
# read your email and follow the instructions,
# afterwards you can auto authenticate your user:
[(status)] /server add -autosendcmd "/^msg nickserv ident <mypassword> libera
# restart irssi:
[(status)] /quit
$ irssi
[(status)] /join ##slackware
[##slackware] Hi folks!
As a last resort you could pull up your sleeves and get a book. Scary I know, but its the only way to really learn! There is a Slackware book, but it's very dated. The FreeBSD Handbook is another excellent source of information, even though many of the details do not apply directly to Linux. There are also a number of commercial books for Linux. A good starting point would be the Linux Bible from Wiley. O'Reilly has also a huge range of books on any number of Linux topics. You can buy these books at Amazon and other places.
I am not going to walk you through every single detail of the Slackware installation, just read the text carefully and go with the defaults unless you have a good reason not to. But I will give you a few hints: You need to partition your hard drive before you run the setup installer program, I recommend using cfdisk to do this (or you can partition your hard disk from another operating systems first). A single Linux partition will often suffice these days, but you can also add a swap partition if you want to (4-8 Gb should be ample). If you do not understand what "partition" means, do yourself a favor and choose a different Linux distribution. During the network configuration stage of the installer, choose Network Manager. When asked which desktop to use I recommend KDE if you have the horsepower, Xfce if you don't. Lastly, if you want to boot the system using grub, skip lilo/elilo during installation. Once setup is done, choose shell, not reboot, upon exit. chroot into your fresh installation and install grub manually. How the heck do I do that?!? Find out (or just use lilo).
Booting into your new system will disappoint you, it's all text! Don't Panic! Just run startx and you will be greeted by a friendly desktop. Clicking around should get you internet access. You will find all kinds of useful, and not so useful, applications in the menu. However, the only user on this system seems to be root. And lot's of nifty programs, such as LibreOffice, VLC, Steam and whatnot, are missing, but there's no package manager! What gives!?!
It's time for some configurations. And lets be honest, this is where Slackware becomes challenging. But with a little bit of know-how you should do fine.
PS: It should be noted that you already have a very complete and capable operating system at this point! Probably because Slackware do not have an official software repository, the default installation is specifically designed to be as complete as possible. Complete however is a relative term. Some might feel that a Linux box without Lynx is incomplete, some that a desktop without Chrome is missing something, the Slackware developers belong to the first group of people.
KDE has graphical tools for managing users and groups, but we will walk you through the command line approach. Add a regular user to your system with the adduser command. Go with the defaults, but when asked about "Additional UNIX groups" hit the up arrow key, it will fill in some recommended groups, and type wheel (it should read: : audio cdrom floppy input lp netdev plugdev power scanner video wheel). Once the user setup is done, give him sudo privileges by running visudo, type /# %wheel/, then hit x (to uncomment the line, it should read: %wheel ALL=(ALL:ALL) ALL), and type :wq to save and exit. Any user in the wheel group should now be authorized to do anything with sudo. If you forgot to add your user to the wheel group, you can do so later with: usermod -a -G wheel <myuser>
During installation you were asked to set up your keyboard layout. However, this only applies to the console (the text-based interface), if you start a graphical interface (ei. "desktop") it uses the default us layout. You can click around in KDE or Xfce to set a different keyboard layout, but that will not adjust the X defaults (so the login manager will still use a us keyboard). To change the X defaults to a us keyboard with dvorak layout and a right Alt compose key for instance, you need to write an X config file, (eg. nano /etc/X11/xorg.conf.d/20-keyboard.conf) with the following content:
Section "InputClass"
Identifier "system-keyboard"
Option "XkbLayout" "us"
Option "XkbVariant" "dvorak"
Option "XkbOptions" "compose:ralt"
EndSection
If you have multiple monitors, you may run into a similar issue. KDE/Xfce will let you set up your monitors however you want of course, but these settings do not apply to the default X configuration (the login manager may have a wrong layout). For instance, on my setup I have two screens, LVDS-1 and VGA-1 (check with xrandr from within a desktop). I want LVDS-1 to be my primary monitor, to the left of VGA-1, and I want both screens to have the maximum available resolution. To specify that as the X defaults, I need to write another file, nano /etc/X11/xorg.conf.d/10-screen.conf:
Section "Monitor"
Identifier "HDMI-1"
Option "LeftOf" "VGA-1"
Option "Primary" "true"
Option "PreferredMode" "auto"
EndSection
Section "Monitor"
Identifier "VGA-1"
Option "PreferredMode" "auto"
EndSection
Why all of this mess, can't KDE/Xfce do this for me?!? No, they can't. User programs, such as desktops, are not allowed to fiddle with system files. As for X, it knows nothing about KDE/Xfce. It is possible to write tools that integrate these things smoothly, and many distros do, but this isn't really how "Linux" works. It is ugly yes, but at least Slackware teaches you to deal with reality.
PS: Slackware 15.0 does come with Wayland if you prefer that over X (as far as inconsistencies are concerned it adds nicely to the mess).
You may also have noticed that while the shell in your text based environment is quite nice, it highlights directories and links with different colors, it prints a humorous welcome message and has a decent prompt, but when you open up a terminal in your graphical desktop it has none of these things... why? The systems default shell settings is in /etc/profile, and this file is read when you log in to a text based environment. A graphical terminal however does not read this file, instead it reads $HOME/.bashrc.
The solution? Simple: Add source /etc/profile to your $HOME/.bashrc. But why do you need separate shell configurations for the graphical interface and the text-based interface?!? This is one of those ugly Linux (actually UNIX) inconsistencies that Slackware makes no effort to hide. It may be annoying at first when you encounter such difficulties, but trust me, you will be glad later when a colleague messes around in his bashrc on the companies Ubuntu server and nothing happens after he reloads his ssh connection... Poor sod didn't realize that he should have put those instructions in ~/.profile. With experience you realize that Pat wasn't being a dope when he just stood there idly with a smug smile and watched you struggle without lifting a finger to help, he was actually being a very wise instructor, teaching you how to fish instead of handing you one.
By default the lilo boot loader waits patiently for 2 minutes before booting the first choice. This is a bit excessive and you may want to reduce the timeout in /etc/lilo.conf. If you are only running Slackware on this system its probably better to simply comment out the prompt line, this will make the boot loader run the first entry directly. When you are done editing this file, run the lilo command (as root) to install the new boot loader.
The init system in Slackware is blissfully simple. All the available services are just shell scripts located in /etc/rc.d, the files that have executable permission will be run at startup, those that don't won't. So enable a service by chmod +x /etc/rc.d/rc.some_service and disable by chmod -x. This takes effect after a reboot. If you need to start/stop/restart a daemon without rebooting run the corresponding script with that argument, eg. /etc/rc.d/rc.some_service stop. Go ahead and read some of these scripts if you're curious, most of them are short and simple enough to understand. Lastly if you need to add custom commands to your startup, then add them to /etc/rc.local (fun fact: this last step is not Slackware specific).
As you can see Slackware boots into a textual interface by default. You can manually start a graphical interface with the startx command. The desktop used is the default you choose during installation, you can change this later with xwmconfig. Probably you want to boot into a graphical interface by default, you can do so by editing /etc/inittab and changing the line id:3:initdefault: to id:4:initdefault:
Rumors would have you believe that Slackware doesn't have a package manager. It does, it just hasn't got a graphical package manager, or dependency resolution, or a repo... See the distinction? Don't worry though, unofficially it has all of that. The semi-official 3rd party repository of community packages for Slackware is SlackBuilds.org. This repo is in source form, but in recent years a binary repo of it has been made available from SlackOnly.com. This repository contains nearly 8000 packages, which is small compared to the likes of Debian or Arch, but not totally insignificant (note that this number would be closer to ~16.000 packages in Debian terms, since such distos tend to split sources into multiple packages). You can manage both official and 3rd party repos for Slackware with the user-friendly slpkg package manager. It too is unofficial, but very stable and practical, and it does automatic dependency resolution. Just go to the link above and download the package, then do the following as root:
# tar xvf slpkg-*.tar.gz
# cd slpkg-*
# ./install.sh
# slpkg repo-enable # eg. slack, slonly, alien
# slpkg update # refresh package lists
# slpkg upgrade # upgrade EVERYTHING (official and 3rd party)
# slpkg -F libreoffice # find "libreoffice"
# slpkg -s alien libreoffice-7 vlc chromium # "sync" packages from alien repo
# slpkg -s slonly wine dosbox scummvm # install packages from slonly
# slpkg -r libreoffice # remove package
As you can see, there exists multiple unofficial Slackware repositories. This can be a bit confusing, and you might be tempted to just enable them all; Don't! Many of these repos are overlapping and somewhat incompatible (they may have different versions of a package with different dependencies). Basically you want to enable as few repos as possible, slack and slonly at least (the official Slackware packages and the SlackBuilds.org binary repo). Alien Bob, a Slackware developer, also maintains a repo of very popular packages that you might want to add. In addition to alien, he also maintains restricted, multi and ktown repos (for dubious multimedia codecs, multilib support and bleeding edge KDE). There is also a csb and msb repo for the Cinnamon and Mate desktops if you need that, but like I said, try to add as few repositories as possible.
slpkg makes it almost shamelessly easy to use Slackware, but it is possible to work with packages more manually (in fact that's the default), and it is helpful to understand the underlying technologies that slpkg automates. The next sections discusses these topics, but if you're bored, you can go ahead and skip to the end.
A Slackware package (usually a .txz file) is actually just a tar archive which unpacks its contents into the root filetree. It also includes an install directory that contains a slack-desc file of meta information, and a doinst.sh file containing scripts to run after the installation completes. You can manually manage these files with commands such as pkgtool, installpkg, removepkg, upgradepkg which are fairly self explanatory. Meta information for these packages are plain text files located in /var/lib/pkgtools/packages. If the package also includes a post-install script, it is stored in /var/lib/pkgtools/scripts, and can be rerun later at will if needed. These tools do not do dependency checking, so in the grand tradition of UNIX they allow you to shoot yourself squarely in the foot.
No doubt the concept of no dependency resolution will seem bat crazy, but this isn't so bad in Slackware as you may think. For instance LibreOffice, Skype and Wine can be installed directly with no extra dependencies. Contrast that to other Linux distros! There are a number of reasons why dependency management is so simple in Slackware. First of all the base install is quite large (~16Gb) and it tries to include all the basic libraries and tools you will likely need in order to compile extra software. Secondly Slackware tries very hard to be as patch-free and vanilla as possible. In contrast, most Linux distros tend to split sources into multiple packages. That is great for the conservation of disk space, but terrible for dependency resolution! Finally, many package managers in such distros will often install packages with every optional add on for good measure even though it's not actually required.
In theory you can freely download 3rd party Slackware binaries and manage them much like a Windows system with the tools described above. pkgs.org is a quick way to find binary packages for Slackware, and many other distros, for instance. But I do not recommend managing your packages in this way! It isn't a good idea to install random binaries from the web willy nilly (there is a reason why Windows is so insecure). But if your favorite opensource project provides a Slackware package on their website, it is perfectly safe to install it. Some projects that do provide such packages are wine, vlc and chrome (the last two will just link to Alien Bob's repository).
By the way, the installation DVD contains some useful extra packages that are not installed by default either for licensing issues or other considerations (You can also get these files from one of the many Slackware mirrors). To install Oracle Java form the DVD for instance, do the following:
# mkdir /usr/src/dvd
# mount /dev/sr0 /mnt/dvd
# cp -r /mnt/dvd/* /usr/src/dvd
# Or use ftp (see above link for alternative mirrors):
# cd /usr/src/dvd
# lftp -c 'open https://mirror.wheel.sk/slackware/slackware64-15.0; mirror'
Grab Java from Oracle's web sites and place it in /usr/src/dvd/extra/java, then we can make a Slackware package and install it:
# cd /usr/src/dvd/extra/java
# ./java.SlackBuild jdk-*.tar.gz
# installpkg /tmp/jdk-*.txz
You have some other options for manual binary management as well: Slackware includes rpm2txz which in theory will convert rpm's to Slackware packages, but in practice this will only work for very simple applications with few dependencies. SlackBuilds.org also provide packages for flatpak and docker.
The official "repo" of Slackware is the 1590 packages provided by the installation DVD (plus 214 packages in the extra directory). And Slackware does ship with a tool that lets you manage official packages quite easily; slackpkg (slpkg will use this when managing packages from the slack repo (and technically, slackpkg only grabs stuff from network mirrors, it uses pkgtool(8) and related commands to actually manage your packages locally)). Generally I recommend using slpkg to manage your system, but if you don't need to use many packages beyond what Slackware already provides, slackpkg is a convenient alternative for keeping your system up to date. It is also a very useful tool for managing packages on minimal installations (see below). To use slackpkg, first edit /etc/slackpkg/mirrors and uncomment a mirror near you. Pay attention: There are two lists of mirrors in this file, one for the stable Slackware release and one for the current branch. I recommend going with the stable release. In any case, you must uncomment only one of these mirrors. After fiddling with the mirror list, you want to run slackpkg update gpg to update the gpg keys for your mirror (unless something odd happens to your mirror, you only need to run that command once). You can then issue commands such as slackpkg install/remove/search/info package and so on. For instance, if you somehow managed to completely break Firefox, you can reinstall it like so:
# slackpkg reinstall firefox
If you want to update your system you can do it like this:
# slackpkg update
# slackpkg install-new
# slackpkg upgrade-all
# slackpkg clean-system
If you find this cumbersome like I do, you can write a little script in /root/bin/upgrade with the following content:
#!/bin/sh
for action in update install-new upgrade-all clean-system; do
slackpkg -dialog=off -batch=on -default_answer=y $action
done
After you have made this script executable (ei. chmod +x /root/bin/upgrade), you can simply upgrade your system with this new command. This will not update 3rd party addons however, and slackpkg clean-system will even remove any unofficial extras! We will discuss ways around that later, but for now it's enough to know that slackpkg works well if you don't need to manage much more then the official packages, if you need a lot of extras go with slpkg.
You can also use slackpkg to upgrade to a new Slackware release by first updating /etc/slackpkg/mirror to point to the new release repo, and then run the above commands.
PS: Note however that upgrading from one Slackware release to the next is rarely just a question of upgrading a set of packages. Often you need to run a few manual commands to clean things up as well. The details are described in the UPGRADE.TXT file in the root of the install media. You can either read this from the DVD/ISO or online (eg. http://ftp.slackware.com/pub/slackware/slackware64-15.0/UPGRADE.TXT for instructions on upgrading from version 14.2 to 15.0).
As mentioned, by default slackpkg will only manage official Slackware packages, and even try to remove unofficial ones if you run clean-system. But there is a 3rd party extension to it, appropriately named slackpkg+, that will allow you to add 3rd party repos or otherwise tweak slackpkg to ignore such addons. The difference between slackpkg+ and slpkg, is that slackpkg+ is just a superset of the default slackpkg command, enabling the native Slackware command to handle 3rd party repos. slpkg however is a package manager all on its own, and has certain features lacking in the default slackpkg, notably automatic dependency resolution. But if you only need to add a handful of Alien Bob and other custom packages to a vanilla installation, slackpkg+ can be a good alternative. To install VLC, LibreOffice and Chrome for instance, download the slackpkg+ binary and run:
$ su -
# installpkg slackpkg+-1.7.0-noarch-5mt.txz
# nano /etc/slackpkg/slackpkgplus.conf
Enable the alienbob and restricted repositories, and add restricted to PKGS_PRIORITY. Once its configured to your liking, update slackpkg and use the new repos:
# slackpkg update gpg # you only need to run this once after adding a repo
# slackpkg update
# slackpkg install libreoffice-7 vlc chromium
You can also create templates of installed packages with slackpkg and then automatically install these on other Slackware machines (provided they too have the necessary repositories enabled). This is especially handy when managing minimal Slackware installations, but be aware that you must sort out dependencies yourself - note though that neither VLC, LibreOffice, or Chrome from Alien Bob require any extra dependencies! (that said, 3rd party software will assume you have a full standard installation of Slackware). Suppose you had just installed the above packages on a machine, and you wanted to install the exact same packages on another Slackware machine, you could do so like this:
# slackpkg generate-template myprogs
# scp /etc/slackpkg/template/myprogs.template myothermachine.com:/etc/slackpkg/template
# ssh myothermachine.com
# slackpkg install-template myprogs
PS: If you want to add Alien Bob's multilib repo and enable Slackware to run 32-bit software on a 64-bit system, you should first read the instructions here.
Finally, it is possible to edit /etc/slackpkg/mirrors and enable a current repo. You can then do the upgrade routine to always run the development version of Slackware, essentially turning it into a rolling release. But beware! You need to stay on top of things if you do this. Subscribe to the mailing lists and familiarize yourself with the forums. Also note that the SlackBuilds.org community repo assumes a stable release. Installing such extras on a rolling release may require some jerry rigging.
During the long hiatus between Slackware 14.2 and 15.0, the fact that SlackBuilds.org was out of sync with Slackware current became quite critical. many users downloaded the unofficial current branch of SlackBuilds.org and configured sbopkg (prior to SlackOnly.com a Slackware user would typically use slackpkg to update the core system and perhaps a few select extras, and sbopkg to compile packages from SlackBuilds.org, but I recommend slpkg nowadays) to install packages from their local snapshot. It's a bit hackish, but then again, you're kinda expected to be a bit hackish if you're running current.
For new users I strongly recommend that you do a full installation of Slackware. The installer does allow you to choose what categories of software you want to install, and even cherry pick which packages, but if you do this you are on your own! The installer will not protest if you set up a system with no kernel, or KDE with no Qt. In true UNIX fashion, Slackware gives you just enough rope to hang yourself, then adds some more for good measure. Not only is a custom installation perilous, but usually quite pointless. If you want to reduce memory footprint or create a snappier system, choice of application habits is a better way to go. Removing packages during installation will only reduce how much disk space Slackware will use, but nowadays you'd be hard pressed to even find a disk with size labeled in "Gb" rather then "Tb". These stats are all taken from a default installation of Slackware for instance:
| Environment | Memory | Startup |
| KDE+SDDM | 500Mb | 2m 45s |
| Xfce | 400Mb | 50s |
| Fluxbox | 100Mb | 30s |
| TTY | 100Mb | 25s |
Having that said, if disk space is critical, you can do some minor tweaks during installation without too much danger. For example, E, F, K, KDE, T, TCL, XFCE and Y can all be safely unchecked, if you aren't planing on using Emacs, reading obsolete docs, recompiling your kernel, using KDE, LaTex, Tcl, Xfce or playing NetHack. (keep either KDE or Xfce if you need a desktop environment!). If you are planning on running a server only, you can also safely uncheck X and XAP. Let's see how much we save by doing so:
| Installation | Time | Disk | Packages |
| Full Installation | 20m | 16Gb | 1590 |
| Xfce Desktop | 12m | 11Gb | 1208 |
| Server | 8m | 8Gb | 810 |
We can go much lighter then this, but be careful! Linuxquestions.org has a good, but somewhat dated Slackware-Minimal Install guide. My recommendation to start with though, is to install everything in A except grub, kernel-generic, kernel-modules and kernel-firmware. With that setup we'll be using lilo and kernel-huge to boot. It may seem counter intuitive, but as far as conserving disk space is concerned, it is much lighter to use the huge static kernel, rather then a generic kernel + dynamic modules. We also need diffutils and slackpkg in AP, glibc and libunistring in L and dhcpcd, gnupg, iputils, net-tools, network-scripts, openssh and wget in N. With that in place we have a very bare bones Slackware system that can connect to the network and download extra packages with slackpkg. Let's compare our minimal Slackware installation with other light operating systems:
| Installation | Time | Disk | Packages | Memory | Startup |
| Minimal Slackware | 10m | 0.3Gb | 132 | 55Mb | 20s |
| Debian Xfce | 30m | 3.1Gb | n/a | 300Mb | 25s |
| Debian Base | 12m | 1.2Gb | n/a | 50Mb | 20s |
| Alpine Base | 4m | 0.8Gb | n/a | 50Mb | 25s |
| OpenBSD FVWM | 3m 30s | 1.7Gb | n/a | 90Mb | 30s |
| OpenBSD Base | 3m 30s | 0.9Gb | n/a | 30Mb | 30s |
As you can see, Slackware is able to compete with the best of them. The long 10 minute install time includes the tedious work of unchecking nearly all of the packages in the AP, L and N categories. If we wrote a tagfile for this, it would only take a couple of minutes. But I reiterate: Beginners really should go with a default installation. If you mess with the installer like this, you need to stay on top of things and know what you are doing!
Every so often you may find that you want to install a weird application that is not included in the repo, this is especially true for Slackware. In such cases you may need to compile the software manually. This usually involved the following steps:
These will usually be something like:
$ ./configure
$ make
$ sudo make install
You will probably note the number of conditionals in the above instructions, usually, or similar, something like... This is because there are a vast number of ways to make and install software on Linux. The quality of the program in question and the install instructions that are provided vary greatly. Additionally sorting out dependency issues by hand and ironing out edge case compatibility problems, is tedious to say the least. The main purpose of a package manager is to take care of all this mess, and lull the casual user into a false sense of security.
In spite of the pain however, knowing how to compile software is a useful skill set to have. This process is not easy in any distro, but it is significantly easier in Slackware then most. For one, distros with large binary repositories, such as Debian, will usually split a package into a default version for users and a -dev version for developers. So if you want to compile something that depends on ncurses for instance, having ncurses-base in Debian is not enough. You need to install the libcunit1-ncurses-dev package, and probably a few others as well. Needless to say this naming convention is entirely different in Red Hat, and God forbid that you need to adjust one of these packages a with non-standard compile option!
In Slackware the packages are straight from upstream, including everything you need for compilation. Whereas the Debian repo has some 30 plus ncurses packages, Slackware has only one. It is remarkably easy to create custom Slackware binaries or adjust existing ones. Lets illustrate how with a couple of examples:
Since there is finally a modern Slackware release out after so many years, let's celebrate by installing a modern desktop; CDE. A quick search on SlackBuilds.org however reveals no CDE package. So it looks like we'll need to build it ourselves:
$ cd $HOME/src
$ git clone git://git.code.sf.net/p/cdesktopenv/code cdesktopenv-code
$ cd cdesktopenv-code/cde
$ less README.md # README says to look at the wiki:
$ firefox https://sourceforge.net/p/cdesktopenv/wiki/Slackware
# Follow the wiki suggestions:
$ su -
# cd /usr/lib64/locale
# ln -s de_DE de_DE.ISO-8859-1
# ln -s es_ES es_ES.ISO-8859-1
# ln -s fr_FR fr_FR.ISO-8859-1
# ln -s it_IT it_IT.ISO-8859-1
# ln -s /bin/gawk /bin/nawk
# chmod +x /etc/rc.d/rc.nfsd # wiki says rc.rpc, that's wrong!
# We can now install CDE:
$ ./autogen.sh
$ ./configure
$ make
# su -
# mkdir /tmp/cde
# cd /home/<myuser>/src/cdesktopenv-code/cde
# make install DESTDIR=/tmp/cde
# cd /tmp/cde
# makepkg -l y -c n /tmp/cde.tgz
# installpkg /tmp/cde.tgz
# The CDE config files should be edited in /etc:
# mkdir /etc/dt
# cp -r /usr/dt/app-defaults /usr/dt/appconfig /usr/dt/config /etc/dt
# Lets add the launcher to standard locations:
# cp /usr/dt/bin/Xsession /etc/X11/xinit/xinitrc.cde
# cat <<eof > /usr/share/xsessions/cde.desktop
[Desktop Entry]
Version=1.0
Name=CDE
Comment=Use this session to run CDE as your desktop environment
Exec=/etc/X11/xinit/xinitrc.cde
Icon=
Type=Application
DesktopNames=CDE
eof
# Finally, we may want to boot directly into the CDE login manager,
# change these lines in /etc/inittab:
id:3:initdefault:
x1:4:respawn:/etc/rc.d/rc.4
# to:
id:4:initdefault:
x1:4:respawn:/usr/dt/bin/dtlogin
If we had dropped the four underscored lines, and just run sudo make install, the program would have been compiled and installed in the normal way. But by doing the underlined steps here, we have instead create a Slackware package in /tmp/cde.tgz. With such a file in place, root can:
The advantage of installing CDE as a package is that the Slackware package manager is now aware of it. It is easy to remove or upgrade it (especially if we have a build script that automates this job - keep reading), and it is very easy to share this package with other machines. You'll note that CDE has zero dependencies on a standard Slackware installation. For other packages you may have to hunt for dependencies on SlackBuilds.org, and of course you will probably run into a few issues along the way. In fact our CDE installation did not work entirely smoothly; the desktop calendar requires the rpc.cmsd background daemon. We can start that up manually simply by running /usr/dt/bin/rpc.cmsd & as root, but we really should write a proper init script for that. Getting the Mail and Printer apps to work however is a lost cause. Also, we should tweak /etc/inetd.conf and /etc/hosts to conform to some CDE expectations, and enable the inetd daemon (ei. chmod +x /etc/rc.d/rc.inetd && /etc/rc.d/rc.inetd start). But there configurations are not strictly necessary, and so we have just ignored them for the sake of simplicity.
PS: Not all source packages have a DESTDIR option in their Makefiles. Let's look at one such example, the colorful Brogue roguelike, which also is not available in the community repo:
$ cd $HOME/src
$ git clone https://github.com/tmewett/BrogueCE
$ cd BrogueCE
$ less README.md
$ make bin/brogue
$ mkdir -p /tmp/brogue/home/<myuser>/games/brogue
$ mkdir -p /tmp/brogue/home/<myuser>/bin
$ cp -r bin/* /tmp/brogue/home/<myuser>/games/brogue
$ cat <<\eof > /tmp/brogue/home/<myuser>/bin/brogue
#!/bin/sh
cd $HOME/games/brogue
exec ./brogue $*
eof
$ chmod +x /tmp/brogue/home/<myuser>/bin/brogue
$ cd /tmp/brogue
$ sudo /sbin/makepkg -l y -c n /tmp/brogue.tgz
$ sudo /sbin/installpkg /tmp/brogue.tgz
Our roguelike game is very easy to install, so much so that it causes certain problems for us. By default it assumes that your user, and only your user, wants to install the executable along with support files in the bin directory of the source tree. Clearly we need to wrestle a bit with the sources here if we need to make a proper Slackware package, but we can make a really sloppy package easily enough. The above "package" will just install the brogue game in ~/games/brogue, and a convenient launch script in ~/bin/brogue (assuming naturally that $HOME/bin is in your $PATH). It probably isn't worth the bother of making a personal package like this, unless you happen to have many Slackware boxes that only you use. Still, I hope this hackish example illustrates how flexible and easy package management can be in Slackware. For example, it's easy enough to make a personal package that installs your user to a Slackware system with all your essential dotfiles and other necessities.
The above examples are quick and dirty ways to make Slackware binaries, the official binaries are generated by a shell script that basically follows these steps, but needs to take care of some further details such as figuring out what architecture you are running and which version you are building. It also has a few conventions, all packages are built in /tmp/package-name and the resulting binaries are placed in /tmp, and so on. If you want to submit a build script to SlackBuilds.org, or if you want to make adjustments to packages that come with Slackware you should familiarize yourself on how to write SlackBuild scripts.
Now suppose you need to adjust an application in Slackware. For instance the cacaview image viewer that comes with Slackware has been compiled with the --disable-imlib2 option. This makes sense since Slackware does not include imlib2 by default. I however, always install this library since it's a dependency for some other programs I need, and without imlib2 support cacaview cannot open popular image formats such as PNG and JPEG. Well, how do I change this application?
First we need to find out which package cacaview was installed from. A quick grep cacaview /var/lib/pkgtool/packages/* reveals that it was installed with the libcaca package. You can get the source code for this package from one of the Slackware mirrors (eg. mirrors.slackware.com/slackware/slackware64-15.0/source/l/libcaca), and put the files in $HOME/src/libcaca. Now to customize and install the application:
$ su -
# cd /home/<myuser>/src/libcaca
# nano libcaca.SlackBuild
# change --disable-imlib2 to --enable-imlib2
# PS: remember to install imlib2 first!
# BUILD=12 ./libcaca.SlackBuild
# upgradepkg /tmp/libcaca*
That's it, you now have imlib2 support in your caca applications! Note the BUILD=12 statement, you can adjust the VERSION or BUILD variables manually. The version of libcaca that I was altering was version 0.99.beta19, build 11. If I downloaded a later version of the source code, say 1.0, I could run VERSION=1.0 BUILD=1 ./libcaca.SlackBuild, if this worked I could then edit the SlackBuild and set these values permanently. However we were just rebuilding with different compile options, so we only incremented the BUILD number.
PS: If you make a habit of customizing the standard packages, or if you make a lot of packages yourself, you should probably have a fixed place to put your files. I will not dictate how you should organize yourself, but you might find the following suggestions helpful: I usually place temporary source code that I am compiling in $HOME/src/name, my SlackBuilds in $HOME/pkg/mysbo/name, any source code archives in $HOME/pkg/mysbo/archive, and my binary packages in $HOME/pkg/myrepo. I have installed slackpkg+, and in my /etc/slackpkg/slackpkgplus.conf configuration I have enabled a local repository: MIRRORPLUS['myrepo']=dir://home/<myuser>/pkg/myrepo, so that slackpkg will not remove stuff I have installed manually. This local repository is also added to PKGS_PRIORITY so that my custom packages will always take precedence over the official ones. (naturally I have also commented out [0-9]+_SBo in /etc/slackpkg/blacklist so that slackpkg doesn't try to fiddle with anything from SlackBuilds.org).
The above CDE package worked quite well, so I would like to write a proper SlackBuild for it, maybe even submit it to SlackBuilds.org. But first, we must write it as a real SlackBuild. Don't worry though, the hardest part is getting a package compiled in the first place, once that's done the rest is mere housekeeping. The first order of business is to get a proper version of CDE, and here we hit our first snag. Surprisingly, the last official 2.4.0 version of CDE from sourceforge does not include the resources nor the documentation needed to actually build the code. As far as I can tell from a cursory look at things, compiling from a git dump is the only way to make this work. This is very sloppy release engineering that is all too common nowadays.* We can write a SlackBuild that builds directly from GitHub sources of course, but this is not ideal, since it's hard to track versions and verify checksums. Anyway, the first thing we need to write is a plain text README file, which should contain a quick summary of the package, important instructions and dependency issues, as needed. SlackBuilds.org also requires an info file with important meta information, such as program name, version, homepage, download link, md5sum, required dependencies, and your contact information. We'll also add an xsession file for CDE and an init script for the rpc.cmsd service (and here we meet our second snag, more on that later):
$ mkdir -p ~/pkg/mysbo/cde
$ cd ~/pkg/mysbo/cde
$ cat <<eof > README
The Common Desktop Environment was created by a collaboration of Sun, HP,
IBM, DEC, SCO, Fujitsu and Hitachi. It was developed during the 90's and
was the de facto standard UNIX desktop on commercial systems until the
early 2000's. Originally CDE was proprietary software, but it was finally
licensed under LGPL in 2012.
This SlackBuild uses the latest GitHub sources of CDE.
PS: The rc.nfsd, rc.initd and rc.cmsd daemons in /etc/rc.d should be
running for CDE to work right (rc.nfsd is REQUIRED).
PPS: There is a bug in rc.cmsd that prevents it from starting up during
boot, so you'll need to manually start it.
Your /etc/hosts file should also contain the following lines:
127.0.0.1 <myname> <myname>.<mydomain>
::1 <myname> <myname>.<mydomain>
and /etc/inetd.conf should contain these lines:
cmsd/2-5 dgram rpc/udp4 wait root /usr/dt/bin/rpc.cmsd rpc.cmsd
ttdbserver/1 stream rpc/tcp4 wait root /usr/dt/bin/rpc.ttdbserver \
rpc.ttdbserver
If you want to use the CDE login manager, change
x1:4:respawn:/etc/rc.d/rc.4
in /etc/inittab to
x1:4:respawn:/usr/dt/bin/dtlogin
eof
$ cat <<eof > cde.info
PRGNAM="cde"
VERSION="2.4.0"
HOMEPAGE="https://sourceforge.net/projects/cdesktopenv/"
DOWNLOAD="" # missing since we're cloning from git
MD5SUM="" # missing since we're cloning from git
DOWNLOAD_x86_64=""
MD5SUM_x86_64=""
REQUIRES=""
MAINTAINER="Dan-Simon Myrland"
EMAIL="dansimon@radiotube.org"
eof
$ cat <<eof > cde.desktop
[Desktop Entry]
Version=1.0
Name=CDE
Comment=Use this session to run CDE as your desktop environment
Exec=/etc/X11/xinit/xinitrc.cde
Icon=
Type=Application
DesktopNames=CDE
eof
$ cat <<\eof > rc.cmsd # eof is escaped, to make $1 etc literal
#!/bin/sh
#
# This runs the rpc.cmsd background process needed by CDE.
#
# To enable this service automatically at boot, make this file
# executable: chmod 755 /etc/rc.d/rc.cmsd
#
# BUG: For some unknown reason this fails to start during boot.
#
cmsd_start() {
/usr/dt/bin/rpc.cmsd &
}
cmsd_stop() {
killall rpc.cmsd
}
cmsd_restart() {
cmsd_stop
sleep 2
cmsd_start
}
case "$1" in
'start')
cmsd_start
;;
'stop')
cmsd_stop
;;
'restart')
cmsd_restart
;;
*)
# Default is "start", for backwards compatibility with previous
# Slackware versions. This may change to a 'usage' error someday.
cmsd_start
esac
Now, let's add some commands to run in doinst.sh:
$ cat <<eof > doinst.sh
ln -s /usr/lib64/locale/de_DE /usr/lib64/locale/de_DE.ISO-8859-1
ln -s /usr/lib64/locale/es_ES /usr/lib64/locale/es_ES.ISO-8859-1
ln -s /usr/lib64/locale/fr_FR /usr/lib64/locale/fr_FR.ISO-8859-1
ln -s /usr/lib64/locale/it_IT /usr/lib64/locale/it_IT.ISO-8859-1
ln -s /bin/gawk /bin/nawk
These commands will be executed after the files have been installed on the system. The README file is included for the benefit of SlackBuilds.org users, the Slackware package manager itself (pkgtool(8), and related commands) needs to have the description in a painfully formatted way, the easiest method of writing that is to download slackdesc (you can install the tgz file with installpkg), and let it help you generate a proper slack-desc (you don't need to add sysadmin/dependency issues here, just a short description):
$ slackdesc "cde" "2.4.0" "CDE common desktop environment" "The Common \
Desktop Environment was created by a collaboration of Sun, HP, IBM, DEC, \
SCO, Fujitsu and Hitachi. It was developed during the 90's and was the de \
facto standard UNIX desktop on commercial systems until the early 2000's. \
Originally CDE was proprietary software, but it was finally licensed \
under LGPL in 2012." "https://sourceforge.net/projects/cdesktopenv" \
> slack-desc
$ cat slack-desc
cde: cde 2.4.0 CDE common desktop environment
cde:
cde: The Common Desktop Environment was created by a collaboration of Sun, HP,
cde: IBM, DEC, SCO, Fujitsu and Hitachi. It was developed during the 90's and
cde: was the de facto standard UNIX desktop on commercial systems until the
cde: early 2000's. Originally CDE was proprietary software, but it was finally
cde: licensed under LGPL in 2012.
cde:
cde:
cde:
cde: https://sourceforge.net/projects/cdesktopenv
Now that all our files are in order lets write the actual build script, open cde.SlackBuild in your favorite editor and write:
#!/bin/sh
# We'll fist add a standard header and a simple BSD Zero Clause License
# Slackware build script for CDE
#
# Copyright (C) 2022 by Dan-Simon Myrland <dansimon@radiotube.org>
#
# Permission to use, copy, modify and/or distribute this software for any
# purpose with or without fee is hereby granted.
#
# THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL
# WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED
# WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR
# BE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY
# DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER
# IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTUOUS ACTION, ARISING
# OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
# Next we want to define some common defaults, program name, version,
# architecture and compiler flags and so on.
PRGNAM=cde
VERSION=${VERSION:-2.4.0}
GITURI=${GITURI:-https://git.code.sf.net/p/cdesktopenv/code}
BRANCH=${BRANCH:-cdesktopenv-code}
GITTAG=${GITTAG:-2.4.0-636-g75c377065}
BUILD=${BUILD:-1}
TAG=${TAG:-_SBo}
if [ -z "$ARCH" ]; then
case "$( uname -m )" in
i?86) ARCH=i486 ;;
arm*) ARCH=arm ;;
*) ARCH=$( uname -m ) ;;
esac
fi
CWD=$(pwd)
TMP=${TMP:-/tmp/SBo}
PKG=$TMP/package-$PRGNAM
OUTPUT=${OUTPUT:-/tmp}
if [ "$ARCH" = "i486" ]; then
SLKCFLAGS="-O2 -march=i486 -mtune=i686"
LIBDIRSUFFIX=""
elif [ "$ARCH" = "i686" ]; then
SLKCFLAGS="-O2 -march=i686 -mtune=i686"
LIBDIRSUFFIX=""
elif [ "$ARCH" = "x86_64" ]; then
SLKCFLAGS="-O2 -fPIC"
LIBDIRSUFFIX="64"
else
SLKCFLAGS="-O2"
LIBDIRSUFFIX=""
fi
# Let's be paranoid and exit if anything goes wrong
set -e
# OK, we're ready to actually build the package now. Clean out old
# files and create build directories if necessary, also make sure file
# permissions are correct.
rm -rf $PKG
mkdir -p $TMP $PKG $OUTPUT
cd $TMP
rm -rf ${BRANCH}
# Normally we want to download a tarball with a proper release version,
# but in this case we will just checkout the source from GitHub.
git clone ${GITURI} ${BRANCH} \
&& cd ${BRANCH} \
&& git checkout ${GITTAG} \
&& chown -R root:root . \
&& chmod -R u+w,go+r-w,a-s . \
&& cd $PRGNAM
./autogen.sh
CFLAGS="$SLKCFLAGS" \
CXXFLAGS="$SLKCFLAGS" \
./configure
make
make install DESTDIR=$PKG
# Lets try to conserve space if we can
find $PKG -print0 | xargs -0 file | grep -e "executable" \
-e "shared object" | grep ELF | cut -f 1 -d : | \
xargs strip --strip-unneeded 2> /dev/null || true
# Normally in a SlackBuild, you move any manpages to $PKG/usr/man, and
# gzip them to conserve space, but in this case, I will leave the CDE
# manpages in $PKG/usr/dt/man alone. It makes sense that this big
# desktop from the past resides safely in its own private den. But we
# do want to create some extra system files:
mkdir -p $PKG/etc/rc.d
cat $CWD/rc.cmsd > $PKG/etc/rc.d/rc.cmsd
chmod 644 $PKG/etc/rc.d/rc.cmsd
mkdir -p $PKG/etc/dt
cp -r $PKG/usr/dt/app-defaults $PKG/usr/dt/appconfig $PKG/usr/dt/config \
$PKG/etc/dt
mkdir -p $PKG/etc/X11/xinit
cp $PKG/usr/dt/bin/Xsession $PKG/etc/X11/xinit/xinitrc.cde
mkdir -p $PKG/usr/share/xsession
cat $CWD/cde.desktop > $PKG/usr/share/xsession/cde.desktop
# Copy over any relevant documentation
mkdir -p $PKG/usr/doc/$PRGNAM-$VERSION
cp -a \
CONTRIBUTORS COPYING HISTORY README.md copyright \
$PKG/usr/doc/$PRGNAM-$VERSION
cat $CWD/$PRGNAM.SlackBuild > $PKG/usr/doc/$PRGNAM-$VERSION/$PRGNAM.SlackBuild
# Add the meta files
mkdir -p $PKG/install
cat $CWD/slack-desc > $PKG/install/slack-desc
cat $CWD/doinst.sh > $PKG/install/doinst.sh
# And then finally we can create the Slackware binary
cd $PKG
/sbin/makepkg -l y -c n $OUTPUT/$PRGNAM-$VERSION-$ARCH-$BUILD$TAG.${PKGTYPE:-tgz}
With this file in place, we can now create and install this package like so:
$ su -
# cd /home/<myuser>/pkg/mysbo/cde
# chmod +x cde.SlackBuild
# ./cde.SlackBuild
# installpkg /tmp/cde-*.tgz
# Or, if we have configured slackpkg+ with a custom repo:
# mv /tmp/cde-*.tgz /home/<myuser>/pkg/myrepo
# slackpkg install cde
Our CDE SlackBuild is not ideal. There are a few nagging issues with CDE itself; For some inexplicable reason rpc.cmsd simply refuses to start during boot. This is not a Slackware specific issue, as I have seen the exact same CDE problem in other operating systems. And there are other problems besides. Hopefully the CDE devs will manage to fix some of this in the future, but for now there isn't much we can do about it. Another serious shortcoming is that we don't use a proper version, but just build it straight from GitHub. What we should do in this case is join the CDE mailing list/forum, and pester the developers about good release engineering, and see if we can help them out in any way. Personally I don't have the time and energy for that, but feel free to take this demo SlackBuild and see if you can make a proper SlackBuilds.org submission (go ahead and change the license/author too if you want, you have my permission). In any event, I do hope that it was educational to go through this process, we even learned a thing or two about the Slackware init system!
PS: Getting a 30 year old desktop to work in the modern world is quite a challenge! It is possible to go in the other direction though; Making a modern desktop look like CDE. That is what the NsCDE developers have done. NsCDE (Not so Common Desktop Environment) is basically FVWM on steroids, and it's quite mind blowing to see what these people have managed to do with it!
If you're new to Linux though you can be forgiven for thinking that the above script is anything but easy, but most of the commands here are just boiler plate. Templates such as this one only need minor tweaking to build something radically different. Also note that there is nothing inherently special about a SlackBuild, it is just a shell script, in fact the only Slackware specific part of our script is makepkg (our init script conforms to Slackware idioms, but it too is just a shell script with no distro specific commands).
Prior to slpkg a Slackware user would typically use slackpkg to update the base system, and possibly a few addons from external binary repositories, such as Alien Bob's packages, with the aid of slackpkg+. But by and large, package management consisted of compiling 3rd party software from SlackBuilds.org, usually using the sbopkg front end (it doesn't do dependency resolution by default). You can still manage your Slackware system in this way, and I am sure a few old timers, myself included, will prefer this approach (or for the really hardcore, you can always manually download and compile packages from SlackBuilds.org by hand), but for beginners I recommend going with slpkg.
What if you're on board with all the stability and simplicity and stuff, but you find the default Breeze Plasma theme for KDE boring. The Dr460nized edition of Garuda Linux looks much cooler, who cares about stability anyway! Is it time for a distro hop..? Well, if you want Slackware to look exactly like Garuda, it will take some doing, but setting a Sweet theme and candy icons in Settings -> System Settings -> Appearance will make your KDE look somewhat reminiscent of that gorgeous Arch spinoff (you may also want to tweak System Settings -> Workspace Behavior -> Desktop Effects). Admittedly, it is a bit clunky to tweak KDE themes like this, but it took me only about 5 minutes to set up each of the following screenshots, despite being a KDE amateur. To illustrate the theming flexibility of KDE, the second screenshot is purposely made to look as retro as possible, using the Irixium theme and NsCDE icons (SE98 icons are a good alternative). I'm sure you can make nicer/fouler themes yourself, or tweak KDE to look and behave like a Windows/Mac clone, if that's your thing.
Slackware will give you software in its default form, but as this example shows it usually takes a minimum of effort to change things up if you prefer. You may of course want something other then KDE. The SlackBuilds.org repo contain quite a few window managers and desktops that you can install with slpkg (or sbopkg if you prefer). For larger more complex desktops more work might be required. Enable the csb and msb repos in slpkg (or slackpkg+ if you prefer) if you want to install the Cinnamon or Mate desktops, for instance.
It is also possible to install GNOME 3 (aka Shell), this too is provided by a 3rd party repository. GNOME 3 is a complex piece of software, and as always complex pieces of software can cause all kinds of problems. So it is highly recommended that you install GNOME 3 on a fresh, and default, installation of Slackware! After downloading the PackageKit installer from the dropline project, do the following:
$ su -
# installpkg PackageKit-*.txz
# pkcon refresh force
# pkcon install dropline
KDE Plasma, and what not, is all Kool and dandy, but as we all know, Tom's Window Manager (or TWM), is the standard X11 desktop. The problem though, is that TWM is crude and ugly! Is it possible to make this ancient relic functional and cool? Well, let's try to make it look a bit more like the ENCOM OS-12 desktop from TRON: Legacy (a documentary about the Linux command line). We start by copying the default config file to our home directory; cat /usr/share/X11/twm/system.twmrc > ~/.twmrc. We can read the twm(1) manpage and tweak this file to our liking. TWM is a bit too customizable for it's own good (it later inspired FVWM, which took this insanity a lot further), but after a while of trial and error, our config file may look something like this:
# default behavior
RandomPlacement
WarpCursor
NoRaiseOnResize
NoTitle
# fonts and colors
MenuFont "-adobe-helvetica-bold-r-normal--*-120-*-*-*-*-*-*"
IconFont "-adobe-helvetica-bold-r-normal--*-100-*-*-*-*-*-*"
Color
{
BorderColor "cyan"
DefaultBackground "black"
DefaultForeground "cyan"
BorderTileBackground "cyan"
MenuBackground "black"
MenuForeground "cyan"
MenuBorderColor "cyan"
IconBackground "black"
IconForeground "cyan"
IconBorderColor "cyan"
}
# mouse and keybindings
Function "move-or-raise" { f.move f.deltastop f.raise }
Function "resize-or-lower" { f.resize f.deltastop f.lower }
Button1 = : root : f.menu "main"
Button1 = m : window|icon : f.function "move-or-raise"
Button2 = m : window|icon : f.iconify
Button3 = m : window|icon : f.function "resize-or-lower"
"F1" = : all : f.zoom
"F2" = : all : f.delete
# menus
menu "main"
{
"Xterm" f.exec "exec xterm &"
"Apps" f.menu "apps"
"" f.nop
"Delete" f.delete
"Exit" f.quit
}
menu "apps"
{
"Firefox" f.exec "exec firefox &"
"Thunderbird" f.exec "exec thunderbird &"
"VLC" f.exec "exec vlc &"
"LibreOffice" f.exec "exec soffice &"
}
Besides setting a cyan theme and app menus, we also configure our TWM window manager to move windows with Alt + left click (Button1 = m), and resize it with Alt + right click (Button3 = m). To bring up the TWM menu, just left click anywhere where there isn't a window (on the root). Next, we need to set a cyan theme for our various applications. For Qt apps, just fire up systemsettings5 and look for a suitable Tron theme (if installation of a theme fails, you can always manually extract the /tmp download in ~/.local/share/plasma/look-and-feel). GTK apps is a bit more messy, you can hunt for themes at Gnome-Look.org, and unpack them in ~/.themes. You can then edit ~/.config/gtk-3.0/settings.ini (or ~/.config/gtk-4.0/settings.ini, maybe even ~/.gtkrc-2.0, depending on what version of GTK the theme is designed for - you can also install lxappearance for a more graphical approach). For our basic X11 apps though, we need to add some values in ~/.Xresources (search the manpages to get clues on what values can be set):
! Default X settings
*background: black
*foreground: cyan
*BorderColor: cyan
! XClock settings
XClock*hourColor: cyan
XClock*minuteColor: cyan
XClock*majorColor: cyan
!XClock*hands: cyan ! replace 3 lines above with this on some XClock versions
! XEyes settings
XEyes*outline: cyan
XEyes*center: black
! XTerm settings
XTerm*faceName: Monospace:pixelsize=18
To set TWM as your window manager, either run xwmconfig and choose xinitrc.twm, or manually edit ~/.xinitrc and set exec twm towards the end. You'll also note the /usr/bin/xrdb -merge $sysresources line in this file; you need to run that command (ei. xrdb -merge ~/.Xresources) for your new X settings to take effect. If you need to adjust the background color, you can do so with xsetroot (eg. xsetroot -solid black), or feh (eg. feh --bg-fill wallpaper.png). The example instructions for setting the right keyboard and screen layout, mentioned in the Xorg Configuration section, can also be done with the following commands: setxkbmap us -variant dvorak -option compose:ralt and xrandr --output HDMI-1 --primary --left-of VGA-1 --auto --output VGA-1 --auto. You can add all of this to ~/.xinitrc to make the desktop behave as you want. Of course this all assumes that you login to a text based environment (by setting id:3:initdefault: in /etc/inittab), if you don't, you may need to write an Xsession file for TWM in /usr/share/xsessions/twm.desktop (see Compiling Packages for a hint on how to do this). For some simple login managers (eg. XDM) it will suffice to just ln ~/.xinitrc ~/.xsession however, and it doesn't hurt to run ln ~/.Xresources ~/.Xdefaults either as some X programs expects to find such values there (the good thing about standards is that there are so many choices).
But if you are the type of person who would like a Tron-like Window Manager, I assume you want to start it from the TTY. Speaking of which, how do we make the TTY use a cyan theme? Well, a simple way would be to add echo -en "\e]P700FFFF" && clear to our ~/.profile ("\e]P700FF00" if you want a green font), it's also a good idea to add source ~/.profile to your ~/.bashrc, so that this theme takes effect in your xterm's too. We could also add the echo line above early in /etc/rc.d/rc.M to make the system use a cyan theme early on in the boot process. To ensure a comprehensive Tron-like terminal theme though, you probably don't want applications to spew out their own colors. Unfortunately, such settings are very application specific. Here are just a few examples you might want to add to your ~/.profile (CDE users might find this useful too):
alias alsamixer='alsamixer -g'
alias ls='ls --color=never'
alias grep='grep --color=never'
alias emacs='emacs --color=never'
alias vim='vim "+syntax off"'
alias lynx='lynx -nocolor'
alias mc='mc -b'
Other programs may require some config tweaking, you can add set-option -ag status-style "bg=cyan" and set-option -ag pane-active-border-style "fg=cyan" to ~/.tmux.conf, and change use_shadow and use_colors in /etc/dialogrc from ON to OFF, in order to make tmux and the various dialog based package management tools in Slackware (eg. pkgtool, sbopkg, slpkg) conform to our Tron theme.
TWM is limited though, it has no virtual workspaces for instance, so how do we multitask in our Tron-like environment? For one, we can run multiple instances of TWM; Log in to TTY2 with Ctrl + F2, then run startx -- :2. Running more then 12 desktops from the TTY is impractical, but we can run TWM from within TWM: Eg. run (Xephyr :3 -screen 1920x1080 &); sleep 1; DISPLAY=:3 twm. (it doesn't matter what ID number you give it as long as it's unique). You can even Alt + middle click this desktop to iconify it (ei. minimize it) to your first TWM desktop, and we can run TWM from within TWM from within TWM, and so on. In practice however, nesting identical window managers like this isn't a good idea, since it causes mouse/key binding conflicts* (running KDE from ratpoison works like a charm though). You can end such nested desktops with pkill Xephyr. You can also enable more TTY's by editing /etc/inittab (more then 24 is possible, but impractical); Find the line that says c6:12345:respawn:/sbin/agetty 38400 tty6 linux. Copy this line and change c6 and tty6 to c8 and tty8 (certain login managers will assume that TTY7 is reserved for the graphical environment so we'll leave it alone). You can repeat this procedure for TTY9-24. To move between TTY13-24, use AltGr + Fn (eg. AltGr + F1), instead of the left Alt button.
Our crude Tron-like Window Manager isn't nearly as cool as the Holywood ENCOM OS-12;* Not all applications and X11 elements work well with our theme, and we don't have the slick fonts, glow effect or curved window borders seen in the movie. It is possible to create a more convincing illusion in KDE/GNOME of course, but if you want a system wide immersive Tron-like experience from start to finish, it would require massive hacking of the init system, the kernel and a plethora of other applications. As always, following the UNIX principal of worse is better is the wisest course of action. And really, It would probably be best to go with a dull gray theme here. It is more restful for the eyes, and works better with X defaults and colorful terminal apps. Still, I hope this imperfect example might inspire you to make some customizations of your own, and perhaps illustrate that boring old cruft in Linuxland might provide more fun then first impressions suggest.
Pro tip: Even if you refuse to mess with basic X11 apps out of sheer principal, just setting *background: gray in your ~/.Xresources, is usually enough to make such horrid eyesores look merely plain.
To illustrate what you can do with Slackware I played around with a few window managers and included their screenshots. I have not included all available desktops, in particular there is a near unlimited amount of lightweight stacking and tiling window managers available for Linux, but I have tried to include a selection that will illustrate the breadth of choices. Of course there is no end to the limit of customizations you can do on most desktops, the examples shown here are just the result of a few minutes of tinkering. I am sure you can produce prettier (or uglier) setups yourself with modest efforts.
Some might choose a distro simply because of the way it looks, but does that really make sense when it takes 5 minutes to change a desktop theme? How much fun is a cool looking wallpaper on an unreliable system? At the end of the day a Linux distribution is just a collection of software. Firefox 91.5.1esr on Fedora or Gentoo does not have mystical superpowers that Firefox 91.5.1esr on Slackware or Debian lacks.
At the end of the day the Slackware desktop experience is what you make of it. True, it does not have a huge and well tested repository compared to the likes of Debian, but it likely has what you need. There are certainly more slick and smooth distros out there (Void Linux and FreeBSD are two strong competitors if you like the KISS approach), but it's precisely the rough edges in Slackware that makes it interesting; Using it you gradually realize that there isn't a distro there, it's quite literally just a handful of shell scripts that automates the installation, package compilation and background processes. It drives you to dig deep into the applications themselves and really learn how a Linux system ticks, including all of its ungainly aspects. That said, it's much easier to install and use Slackware then most seem to think. We may have gone a bit overboard with whimsically convoluted examples in this article, but as the Initial Configurations section says, 10 minutes after installation you have a fully functional modern desktop, everything after that is optional tinkering.
Have fun :^)