Slackware 14.2

31 December 2016
Most Linux distributions operate on a 6-12 month support cycle, which for a somewhat conservative user like myself, is simply unacceptable. I've generally been happy with Ubuntu's LTS (long-term support) releases, although in practice I've found that aside from core packages of security-critical libraries and internet software, things get stale quickly. My current desktop I built using Ubuntu 12.04 just before going to New Zealand, and with 12.04 “support” ending mid-2017 I need to do a rebuild sooner or later. The obvious choice is the latest Ubuntu LTS 16.04, but given my dislike of having to do rebuilds, I wanted to look at alternatives.

Since I was seconded abroad the last few months, which is long enough to need my primary desktop with me but not quite long enough to justify air-freighting my actual desktop system, I decided to see what it would be like having a Slackware64 (64-bit Slackware) install on my laptop as a substitute. This seemed a fair test to decide whether to rebuild my actual desktop with Slackware or Ububtu 16.04 LTS. Below is a collection of notes and opinions gathered as a result of this trial period.

Background

For servers I've long favoured Slackware because it has remained simple and consistent for about a decade, whereas other distributions seem to adopt increasingly elaborate configuration schemes that are intended to be used via tools. More importantly from the perspective of this trial period is Slackware's habit of making minimal changes to upstream packages. I'm convinced Slackware expects you to compile your own kernel from upstream tarballs, given how easy it seems to be compared to every other distribution I've tried, and worst-comes-to-the-worst patching up any part of a Slackware system from tarball is much less of an ordeal compared to other distributions. This seemed a good deal given that I will have to resort to tarballs somewhere along the line, particularly if I wanted rebuild to last multiple years.

Looking back at why I tried Slackware 14.1 three years ago, I see much the same theme as what made me try out Slackware 14.2: Not having to hit a learning curve (or some nasty gotcha) every time I do the occasional bit of system administration. SysV init uses symlinks such as /etc/rc.3/S90http where rc.3 is the directory for scripts relevant to runlevel 3 and S90 is information on when (startup vs. shutdown & priority) the script should be run. Of course these are not supposed to be wired up manually, which means choosing one of many tools to do this for you, each of which has its own set of idiosyncrasies. Slackware's BSD-style init system is basically a pile of shell scripts, and from a quick read it is fairly easy to work out how to hack them to add a new service to system boot. If startup priority actually matters, put the higher priority ones earlier in /etc/rc.d/rc.inet2. Job done, move on. Incidentally, in the time since I wrote the Slackware 14.1 article, several distributions have moved over to systemd, which seems to prefer systemctl stop http.service to service http start.

System bootstrapping

Fdisk and partition alignment

Slackware uses fdisk (part of util-linux-ng) as one of its preferred partitioning tools, but by default fdisk uses a now-depreciated DOS compatibility mode that results in inappropriate partition alignment for modern hard drives that typically use 4-kilobyte block sizes. Unlike hard drives that simply write new data over old in a single pass, SSDs also have to erase any existing data first, and the erase block size used for this erasing process is a relatively large 128 kilobytes. As a result the recommended alignment is 1 megabyte rather than 512 bytes. For versions of fdisk prior to 2.17.1 (which I think was circa 2010) you need to use the -S 32 and -H 64 flags and make sure the first partition starts on cluster 2 (not 1), whereas later version of disk need the -c and -u flags. Fuller details can be found on this detailed article, and alignment can be cross-checked using parted (align-check optimal <partition>), which is on the Slackware install DVD.

Disk-sets to install

Slackware has a very broad interpretation of what is an optional package, and since it doesn't do any dependency tracking, you have to be rather careful about what packages not to install. Below shows the size of the disk-sets in Slackware 14.2, although these have to be taken with a pinch of salt as they are compressed package sizes rather than installed size:

652M KDE (K Desktop Enviornment)
386M KDEI (KDE Internationalisation)
240M D (development tools)
222M XAP (X applications)
219M L (libraries)
127M A (base system)
102M AP (Non X-Windows applications)
100M X (X-Windows)
87M K (Linux kernel source)
85M N (Networking tools)
82M T (Tex)
39M E (Emacs)
11M XFCE (Xfce window manager)
6.6M F (FAQ & HOWTO documentation)
5.5M TCL
1.7M Y (games)

With the exception of KDE & KDEI best thing is to simply install everything, because with modern storage capacities the space saved is simply not worth any possible resulting hassle. For instance I don't do any kernel hacking, but you get the occasional out-of-tree driver release (e.g. Nvidia & Virtualbox) that need them around in order to build & install. A full install (sans KDE/KDEI) is about 8GB.

Keeping up to date

In this day and age, automatic updates of at least network-exposed software packages is a tick-list item, and Slackware is aware of this. I have used the third-party slapt-get for quite a long time, and the following source list should be suitable for a multilib system (caveat emptor):

SOURCE=http://slackware.uk/people/alien/sbrepos/14.2/x86_64/:DEFAULT SOURCE=https://www.mirrorservice.org/sites/ftp.slackware.com/pub/slackware/slackware64-14.2/:OFFICIAL SOURCE=http://slackware.uk/people/alien/multilib/14.2/:PREFERRED SOURCE=file:///tmp/:CUSTOM

In ascending order of priority is the alienbob repository, Slackware 14.2, multilib, and finally locally-built SlackBuilds. For the latter you need a script such as the ones from the slapt-get FAQ to generate a PACKAGES.txt file. Although slapt-get is still third-party, these days Slackware includes SlackPkg as a package manager. Personally I much prefer slapt-get, but SlackPkg is the official package manager, and it might take account of some gotchas that slapt-get doesn't. You'll need to install the slackpkg+ extension if you want to use SlackPkg to keep a multilib install up to date. In this case the following /etc/slackpkg/slackpkgplus.conf (with commented-out and empty lines stripped) is the equivalent of the above slapt-get config:

SLACKPKGPLUS=on VERBOSE=1 ALLOW32BIT=off USEBL=1 WGETOPTS="--timeout=20 --tries=2" SEARCH_CLOG_INPARENT=on CACHEUPDATE=off GREYLIST=on SENSITIVE_SEARCH=on WW_FILE_SEARCH=on SHOWORDER=package DETAILED_INFO=basic STRICTGPG=on PKGS_PRIORITY=( multilib alienbob ) TAG_PRIORITY=off REPOPLUS=( slackpkgplus ) MIRRORPLUS['multilib']=http://slackware.uk/people/alien/multilib/14.2/ MIRRORPLUS['alienbob']=http://slackware.uk/people/alien/sbrepos/14.2/x86_64/ MIRRORPLUS['slackpkgplus']=http://slakfinder.org/slackpkg+/

Both package managers will overwrite a SlackBuild-installed package if there is a more up-to-date one in the repository, and you have not explicitly excluded such packages from updates. To my knowledge the only big difference between the two is that slackpkg will install new multilib compatibility packages, rather than just upgrading ones that are already installed.

Multilib (32-bit compatibility) support

Slackware64 is multilib-ready, which means that it can have both 32-bit and 64-bit software installed in parallel. The official documentation on enabling 32-bit support is concise, in short involving replacing the 64-bit versions of glib and gcc with multilib-enabled ones, and installing the 32-bit versions of system libraries. It is surprisingly quick, but is probably best not done through a graphical login..

Graphical logins

My previous article on installing SDDM details how to get a sane login manager (assuming you didn't install KDE) working with Slackware, along with a few other window manager & X11 details. Keyboard layout selection and importing Windows fonts are covered. Note that this article was written before I found out about the AlienBob repository, from which downloading the pre-built binary will be faster.

Wireless setup

The easiest way to setup wireless networking is to install Wicd, which is a lightweight wired & wireless network manager. You'll have to clear out all entries in /etc/rc.d/rc.inet1.conf as it expects full control of all network interfaces, but for something like a laptop where you will likely be switching between interfaces and networks, this is not major problem. Only thing to note is that Wifi passwords will typically require the WPA 1/2 (Passphrase) encryption option, rather than any of the hex key options.

Sources of software

AlienBob binary packages

A surprisingly large amount of software is available as binary packages from AlienBob's third-party SlackBuild collection, for which there is a UK-based mirror and UK-based repository suitable for package tools. Although third-party to the Slackware project, AlienBob himself is a Slackware developer/maintainer, so should be trustworthy enough to regard as de-facto official. In support terms this means if you have difficulty with any of his software packages, you should consider a different Linux distribution.

Slackware DVD /extra

On the Slackware DVD (not sure which CD it is on for the CD collection) there is an /extra directory that includes various bits that for various reasons are deemed important enough to ship with Slackware, but nevertheless are not installed by the Slackware installer. Three of these items are (SlackBuild) scripts that take binary packages and turn then into Slackware packages for installing. They are:

flashplayer-plugin: Adobe Flash plugin (auto-downloads from Adobe website)
google-chrome: Google Chrome 32-bit or 64-bit .deb (Debian/Ubuntu) packake.
java: Oracle Java tarball

It is understandable why such repackaging scripts are not part of the standard install. The other packages (source code included) are various packages, some of which I'm guessing are here for political reasons:

aspell-word-lists: Aspell dictionaries (non-English)
bash-completion: Programmable Bash command completion
bittornado & bittorrent: BitTorrent clients
brltty: Braille display software
fltk: FLTK GUI tooklit
emacspeak: Emacs speech interface
mplayerplug-in: Play embedded videos in web browsers using MPlayer
recordmydesktop: Desktop recording (audio & video)
tigervnc: VNC remote desktop client
wicd: Lightweight network manager (wired & wireless)
xf86-video-fbdev: X.Org framebuffer video driver
xf86-video-nouveau-blacklist: Nouveau blacklist file (stops conflicts with nVidia driver)

The directory has PACKAGES and CHECKSUM files, so it can be pointed to as a repository by package managers.

SlackBuilds

If you've not come across SlackBuilds, it is roughly the Slackware equivalent of FreeBSD's ports collection. In summary a SlackBuild is the upstream source tarballs together with patches/scripts needed to build it for Slackware, and when run you end up with the binary package ready to install. Although SlackBuilds is not part of Slackware itself, it is officially endorsed by the Slackware project, and it wouldn't surprise me if SlackBuild-related tools eventually become part of the official distribution.

Dependency information: Like Slackware itself SlackBuild scripts don't do dependency resolution, but SlackBuild meta-data does includes dependency information. The dependency meta-data is limited to a list of other required (and sometimes optional) SlackBuild packages, but in practice this is sufficient as SlackBuilds assume a full Slackware install. There is a special %README% dependency tag for awkward cases such as ffmpeg, but only 20 of ~6000 SlackBuilds use it.
SlackBuild Package Manager (SBoPkg): The third party tool SBoPkg acts as a package manager for SlackBuilds, and it goes a long way in making Slackware comparable to other distributions in terms of maintainability. Although I am not fond of its ncurses-based interface, it does a good job of working out which SlackBuild-built packages have updates available, and if desired will update them. SBoPkg has limited support for dependency resolution in the form of queue files, which are built from SlackBuild dependency meta-data.
The down-sides: Some of the times I've used SBoPkg it has felt hit-and-miss, but in the vast majority of cases it gets the job done. The one exception was the somewhat pathological experience with ffmpeg, but video software tends to have unique difficulties. The one big problem with SlackBuilds is the time and space requirements of having to do compilation from source code, which can run into Gigabytes and hours, but mercifully these instances are ones such as LibreOffice that you'll most likely only have to do once.

Notes on specific software packages

For software not part of Slackware itself the next port of call will usually be SlackBuilds, but a surprisingly large amount of software is available as binary packages from the third-party AlienBob repository discussed above. Below is some notes on software packages I consider of interest:-

Abobe Flash

Personally Flash is something I would prefer to see the back of. On Linux it is a repackaged closed-source program, and Slackware has multiple options depending on which browser will use it. I think it has to be installed separately for Firefox and Chromium. Firefox itself specifically checks for outdated Flash versions.

Adobe Acrobat

Adobe has stopped distributing a Linux version of Acrobat Reader, which was a bit of a surprise for me, but this is not really an issue these days as other PDF viewers are now quite good.

Doom 3

Doom3 Linux v1.3.11304, available from the id software FTP site, will run on multilib-enabed Slackware64 out of the box with default configuration options. The latest demo version (v1.1.1286) is broken and you will most likley have to killall doom3.x86 and then Ctrl-Alt-Backspace to restart your X-server (I hope you saved all documents first..).

Eyes of Gnome (image viewer)

The best substitute for EoG (Eyes of Gnome) I found was Viewnior. Linux image viewers are a dime-a-dozen, but I was looking for one that (like EoG) supported zooming using the mouse wheel.

Google Chrome (& Chromium)

Google Chrome is not officially supported on Slackware, so you have two choices:

Use a script that converts the Debian/Ubuntu package (see above)
Install the upstream open-source Chromium browser

Apart from being in a different location (~/.config/google-chrome/ vs. ~/.config/chromium/), configuration files are fully compatible. Chromium is the upstream open-source project from which Google Chrome is derived, and for Slackware a pre-built package is available. There is an extension that checks for updates, but since this extension only supports updating on MacOS, easiest thing to do is to add AlienBob's repository to your package manager config.

LibreOffice

If built via SlackBuilds it will take a while, but it is also straightforward due to having only a few dependencies. If spellchecking does not seem to be working, odds are that the dictionary is missing. Just grab it from the LibreOffice extension repository and install using Extension Manager.. under the Tools menu.

VLC Media Player

Best bet is the AlienBob package as it is self-contained. Building VLC via SlackBuilds is a bit of an ordeal, so it is best avoided unless the AlienBob build doesn't support a codec you need.

VirtualBox

Virtualbox's SlackBuild doesn't list acpica as a dependency (optional or otherwise), but once this was installed Virtualbox had no problems building/installing. VirtualBox drivers such as vboxsf (gives Slackware Linux guests access to shared folders) & vboxdrv (needed to run VirtualBox on a host system) do not automatically load, which although is not blocking issue as they can be loaded using modprobe, is nevertheless an annoyance as having to manually load kernel modules is something I last did in 2002 on hardware acquired in 1996. VirtualBox mentions running sudo /sbin/rcvboxdrv setup when it cannot detect the VirtualBox drivers, which is a binary that does not exist on a SlackBuild VirtualBox install. However SBoPkg does a good job of getting the relevant driver recompiled should you do something like upgrade the kernel.

Wine

Building Wine on Slackware64 is a bit tricky as it has to be built as a 32-bit application but not quite follow the usual 32-bit package cross-compiling instructions. In short sourcing /etc/profile.d/32dev.sh but passing ARCH=x86_64 to the SlackBuild script. Easier to just go for the AlienBob Wine package as it seems to be more up to date than the SlackBuilds offering.

Doing without Gnome

Even though the Slackware installer lists a GNOME disk-set, it does not include Gnome any more - it only includes a few Gnome-related programs that have standalone uses. Why it does this I'm not sure, but it is apparently to do with the downstream effort required to build & package up Gnome. There is the third-party Dropline Gnome, and some of the individual Gnome tools I might be interested in all seems to be on SlackBuilds.

Personally I'm glad because for various reasons I've never liked Gnome. It doesn't seem to have the reliability problems I remember from university lab days, but I think the Gnome 3 Unity interface is an abomination comparable to Windows 8. And I am far from alone in hating it. They both fall into the same trap of trying to cater for tablet & touch-screen PCs, whereas people trying to do actual work use a mouse & keyboard with an external display.

Doing without Gnome has meant doing without system configuration GUI tools, especially with my preference for IceWM, but on the whole I found this a price worth paying. Gnome is a full-blown desktop manager, and I suspect it has conflicts with underlying X11 configuration tools. For instance I suspect some screensaver module was constantly smashing my xset screen settings. Expunging Gnome completely gets rid of a lot of out-of-band configuration channels when it is not used as a window manager.

Touchpad issues

I've never really liked laptop touchpads, and I find things like tap-click and scrolling particularly troublesome. For some reason in Slackware the touchpad is very sensitive to even slight brushes, which caused a whole host of irritations while typing, mostly the caret suddenly jumping around. I eventually found that the touchpad can be configured using the synclient command and the following sorted out my problems:

$ synclient -l | grep Tap TapButton1 = 1 TapButton2 = 2 TapButton3 = 3 $ synclient TapButton1=0 $ synclient TapButton2=0 $ synclient TapButton3=0

Slackware seems to have a problem with unpolished defaults, but more often than not issues are easy to figure out once you've found out the name of the command that controls whatever needs fixing.

Building FFmpeg via SlackBuilds

The FFmpeg package is a particular pain because it has a load of optional dependencies that are not auto-detected, and even if they were there are legal issues with some combinations of build options. For instance including faac & libfdk-aac will means an inability to distribute the resulting FFmpeg package. Nevertheless below will build FFmpeg with just about all options enabled:

Building FFmpeg's dependencies

sbopkg -i "lua libquvi-scripts" export TMP_PKG_LST = "libass libbluray libdc1394 decklink-sdk \ faac libfdk-aac flite frei0r libgme gsm libiec61883 \ libavc1394 libilbc ladspa_sdk lame libmodplug OpenAL \ opencore-amr opencv libquvi opus rtmpdump schroedinger \ snappy speex twolame vid.stab libwebp x264 x265 xvidcore \ zeromq zvbi" sbopkg -d "${TMP_PKG_LST}" sbopkg -b "${TMP_PKG_LST}" for pkg in ${TMP_PKG_LST}; do ls /tmp/${pkg}*.tgz done

The lua and libquvi-script packages are sub-dependencies so they need to be built & installed first. The other packages are independenct so they can be downloaded/built/installed as seperate passes. Testing in a VM, building ${TMP_PKG_LST} took just under an hour, with opencv (an image processing library) accounting for about two-thirds of that time. I left out celt as building it resulted in the following error:

/usr/lib/libogg.so: error adding symbols: File in wrong format

This looks like celt is trying to link to the 32-bit OGG Vorbes library rather than the 64bit one. This is likely a fault in the SlackBuild script, which although probably easy to fix, I am leaving out for clarity's sake.

Building FFmpeg

groupadd -g 214 avahi useradd -u 214 -g 214 -c Avahi -d /dev/null -s sbopkg -b ffmpeg:ASS=yes:BLURAY=yes:DC1394=yes:DECKLINK=yes:\ FAAC=yes:FDK_AAC=yes:FLITE=yes:FREI0R=yes:GME=yes:GSM=yes:\ IEC61883=yes:ILBC=yes:LADSPA=yes:LAME=yes:MODPLUG=yes:\ OPENAL=yes:OPENCORE=yes:OPENCV=yes:OPUS=yes:QUVI=yes:\ RTMP=yes:SCHROEDINGER=yes:SNAPPY=yes:SPEEX=yes:TWOLAME=yes:\ VIDSTAB=yes:WEBP=yes:X264=yes:X265=yes:XVID=yes:ZMQ=yes:ZVBI=yes

Building FFmpeg itself requires all the options to be included colon-seperated without any spaces, hence lack of indents.

General feeling about Slackware

Slackware is not an out-of-the-box Linux distribution in the same way that Fedora and Ubuntu are, where you have apt-get/yum/dnf as a one-stop shop for software. Coming from Ubuntu it is a bit of a leap of faith to be relying on notionally third-party software sources, but it seems to have some commonality with FreeBSD's packages & ports system. With Slackware I found myself using four different sources:

Officially packaged software
Software shipped alongside Slackware
AlienBob third-party repository
SlackBuilds build-it-yourself scripts

Had I known all four of these from the outset I would have saved myself a lot of time & effort, and it all leaves a feeling of a rather fragmented software eco-system that easily leads to frustration. Upfront gotchas like this make Slackware a hard sell, and my feelings at times were not that far off the gotcha-fest FreeBSD 6.2 felt like. My other main thoughts are as follows:-

AlienBob vs. SlackBuilds: It was only after doing many SlackBuilds that I found out that AlienBob was actually quite a large collection of pre-built software, and both slapt-get & slackpkg will overwrite a SlackBuilds-built package if a more up-to-date version of the software is available as an AlienBob package. This is particularly annoying as AlienBob packages tend to be those that take a long time to build. In many cases I've chosen to keep the SlackBuild by adding those packages to my package manager exclude list, although from what I've seen so far AlienBob has tended to be more up to date than the respective SlackBuilds authors. The one piece of software I would by choice build via SlackBuilds is video playback, as they tend to have a lot of optional dependencies, and pre-built packages often choose such options conservatively.
Dependency resolution: Comprehensive dependency resolution is hard, so by and large Slackware avoids it. Just about the only thing that has a form of dependency tracking is SlackBuids. AlienBob's approach to dependencies is to include a copy of the relevant libraries within the package, although in most cases the extra space usage itself is not a big concern these days. In practice lack of dependency resolution didn't cause any problems, but I'm not the type who installs a lot of software.
DVD playback: If there was one thing that was going to test my tolerance of Slackware, it was going to be video-related. The AlienBob VLC build doesn't include DVD support, so at some point I will have to bite the bullet and build it myself. Or so I thought, as it seems there is a “restricted” (read: non-US mirrored) AlienBob build that does include DVD decryption.
Keeping up to date: Slackware's offerings for automated updating are far from polished, but they nevertheless seem to do a good job. Main worry is complications from having a multilib system, as I am not entirely sure how solid the upgrading procedure is for such systems. The kernel update in response to Dirty COW also took a bit longer than it really should have.
Getting things working: Most of the problems with getting things working was due to instructions assuming a Ubuntu or Fedora system, and hence things were given in terms of Ubuntu/Fedora commands rather than actually explaining what needed to be done. In most cases this was the use of things like systemd service control commands rather than the more generic daemon parameters. A notable exception is Arch Linux documentation, which often applies to Slackware very well.

Even though many things did not work out-of-the-box so hence a lot of wondering around about what to do, things were pretty simple once instructions were found, in large part because problems with instructions being for a previous version were practically non-existent. More importantly when stuff has been installed & configured, things pretty much always worked first time. Wicd picked up my wireless network. Doom3 on Ubuntu 12.04 64-bit needed a lot of messing around, but on multilib-enabled Slackware64 default options were enough. I was never lost for long trying to work out why something was not working.