$Home|Elec|Tech|Misc|Pics

Slackware 14.1

30 November 2013
As much as I like Ubuntu from a convenience perspective, I am not the type who reinstalls their main desktop all the time, and the only real reason I upgraded from 10.04 to 12.04 was the need to switch to a physically smaller machine before moving to New Zealand. The long-term support editions of Ubuntu tends to get a little stale, which is why I have had to occasionally build stuff from tarballs. As it happened Slackware version 14.1 had just been released, and while I do not foresee switching over to it entirely, I nevertheless felt it was worth loading it up into VirtualBox, much like I have with Windows 7 Ultimate.

Why? And Why Slack?

The thing I like about Slackware is that it is very conservative, which is in stark contrast to most other Linux distributions that tend to have a lot of idiosyncrasies, and even worse tend to change them a bit too frequently. I only found out recently that Ubuntu has effectively deprecated /etc/resolv.conf in favour of NetworkManager, whereas Slackware still honours the former. A lot of these "modern" configuration systems are designed for use with user interface front-ends, which is a royal pain if you want to administrate a server over a high-latency SSH connection. This is why most of my overseas servers are Slackware-based. Try compiling a kernel using the sources off kernel.org you you will experience the full pain package manager inflict when you try to bypass them.

My motive here, in contrast, is Slackware's packaging policy. Most Slackware packages are basically what a vanilla configure-make-install would give, so if something is getting a little stale then all that needs to be done is to grab the upstream sources and compile it manually. In this case it is trying out MonoDevelop (update: forward link added), which in Ubtuntu 12.04 is horrendously out of date. Although I don't intend to replace Ubuntu as my desktop host OS, it would allow me to at least experiment with doing so.

Sorting guest additions

Even though it seems to try and build new modules form source, the guest additions included with VirtualBox does not seem to work with Slackware. This might be due to the version of them included with Ubuntu being outdated, but thankfully SlackBuilds has versions that do work. SlackBuilds is a bit confusing to use at first, as you need to download both the SlackBuild tarball and the linked-to source tarball. You need virtualbox-kernel-addons and virtualbox-addons, and if you are not after v14.1 it should not take long to guess how to find alternative versions.

Getting the VM full-screened

My preference is to run virtual machines full-screen, with the Virtual Box mini toolbar at the top as IceWM running on the host system tends to display its own taskbar if the cursor hit the very bottom of the screen. This latter setting is on the General page under the Advanced tab, and is listed as Show At Top Of Screen. For some reason auto-resizing does not work properly with Slackware, so I simply force full-screen resolution using /etc/X11/xorg.conf. The snippit below seems to be the close to the minimalist config to do this:

Section "Screen" Identifier "Default Screen" Monitor "Configured Monitor" Device "Configured Video Device" DefaultDepth 24 SubSection "Display" Depth 24 Modes "1680x1080" EndSubSection EndSection

Apt-get?

The apt-get package manager to me is the only really good thing with Debian, and it is pretty much the main reason I have stuck with Ubuntu for my desktop system. Slackware has its own variants, the one I use being slapt-get.

What about dependency support

While slapt-get supports dependency resolution, the official Slackware repositories do not include the information. There are repositories out there that do, the one I historically used seems broken these days. This is more important for bare-bones systems such as off-the-shelf virtual private servers, but for desktop systems it is easier just to install all the disk-sets.

Shutdown buttons in XDM

XDM (X Display Manager) is the program that put up a login screen when you boot up Slackware in graphical mode rather than text mode. The problem is that it harks back to the days when shutting down a Unix system was considered a privileged operation, and hence does not allow a non-logged-in user to do such a thing. I found one simple-ish solution, but the resulting buttons not only look ugly, they also appear as a window in IceWM. In the end a bit the bullet and decided to just do a full install and use KDE's KDM instead.

The joy of SlackBuilds..

Even though Slackware makes it relatively easy to install stuff via tarballs, the earlier-mentioned SlackBuilds makes it even easier by providing scripts that have all the required flags, with the bonus that someone out there has actually tested it with the relevant version of Slackware. In particular, with the scripts on SlackBuilds, someone has also gone to the effort of checking the dependencies. I think a lot of the scripts there have minimal if any changes when a new upstream source tarball is released, and in this context is is understandable why they link to the upstream tarball rather than including it (cf. Source RPMs).

In this case, as stated above, my aim was getting a working install of version 4.something of MonoDevelop. To cut a long story short, it still meant chasing manual dependencies, but the 18-month-old guide I was using as a base-line was still pretty accurate in terms of dependencies. With SlackBuilds you can be confident that any breakage is not due to platform oddities, so bouncing around a bit of not a hassle, even if it is time-consuming (4-6 hours). For the impatient, the outcome is below:

In the source collection, all you need to do is run the build script in each sub-directory, although it is only really included here the completeness. The binary collection is all the package .tgz that pop out and it should be possible to pass these to a single installpkg call. As per usual USE AT YOUR OWN RISK. Should be OK, but I am not liable for any damage. I subsequently found out there is a tool that automates the building of packages off SlackBuild, but have yet to try it myself.

Missing window decoration in IceWM

I use the SilverXP theme with IceWM, although I suspect there are other themes that are affected, and I have seen the same problem on RedHat-based systems. In more recent times I have noticed problems with the rendering of the tops and bottoms of window decoration as shown:
Can't remember which website forum put me on to the right track, but it seems to be a problem with more recent versions of the Xorg X-Windows server, rather than IceWM itself. Some display adapter drivers have problems with one-pixel-wide bitmaps that are stretched, so the solution is to stretch them with something like ImageMagick's convert so they are instead two pixels wide. The following Bash script should do the trick with minimal alteration:

#!/bin/bash for img in *.xpm; do WIDTH=`identify -format "%[fx:w]" $img` if [ $WIDTH -eq 1 ]; then HEIGHT=`identify -format "%[fx:h]" $img` echo Scaling $img.. convert $img -resize 2x${HEIGHT}! out/${img} fi done;

Note that the exclamation mark in “2x${HEIGHT}!” is deliberate..

Errors about Dbus

I got these while loading up Gimp, but at the time for some reason did not think to record the error message. It was caused because during installation where you choose which services to activate on startup, I disabled rc.messagebus, which oddly enough is actually used quite extensively. To reactive all you need to do is set the execute bits on the /etc/rc.d/rc.messagebus script.