Intro
I've been using Slackware Linux since around 2010-2011, moving from Debian mainly because I got tired of the package churn and following the internal politics of DDs. Initially I tried it as a way of getting a close to BSD experience on Linux, since I was already using OpenBSD at the time (more on that on a later post.) Turns out that having a prior BSD experience helps a lot, especially as Slackware is as "upstream" as upstream gets (very minimal, if any, distro-specific changes, as a matter of policy.)
Since it was Slackware's birthday just sometime ago, let me share some tips and tricks I've learned over the years.
Use slacktrack as a next choice after SlackBuilds
Both SlackBuilds.org and alienBOB's repo have a large cache of additional software packages to get from, but there are few cases where sometimes you'd need to install software without a SlackBuild. In those cases, one might just go straight to doing ./configure && make && make install for those software that claim to be well-behaved and install only into /usr/local and nowhere else. For more complex software, something like GNU stow may be required to track the file changes and try to make sense out of the install.
On Slackware though, there's already a GNU stow alike in the form of slacktrack, which not only provides a way to track file changes, but can optionally make a full Slackware package that can be installed using pkgtools. This is a nice alternative when you don't want to write out a full SlackBuild setup for that package (yet); instead, you write a .build file that is a very thin wrapper for your software's build/install system.
As an example, I use the acpi_call Linux kernel module and tpacpi-bat software on my ThinkPad X220, which are not on those two repos above, but on GitHub. For my case, all I need to do is to fork those GitHub repos, add a .build and slack-desc file for each (and a doinst.sh for the kernel module so I can run depmod upon install/upgrade,) then invoke slacktrack, like so for tpacpi-bat:
# cd tpacpi-bat
# slacktrack -Qp tpacpi-bat_3.0-x86_64-1zakame.tgz '/bin/sh -x tpacpi-bat.build'
This produces a Slackware package in /tmp, so while tpacpi-bat is already installed and tracked by a dummy record in /var/log/packages, I can still do something like
# installpkg /tmp/tpacpi-bat_3.0-x86_64-1zakame.tgz
To install the package with a proper slack-desc (and in the case of acpi_call, an actual package post-install script.)
Generate initrds after slackpkg upgrade-all
This one is something I picked up quite recently. What I used to do is that after a slackpkg upgrade-all with a kernel update, I'd fire up a separate root shell to run /usr/share/mkinitrd/mkinitrd_command_generator.sh --run /boot/vmlinuz-generic | sh so I can have a new /boot/initrd.gz once slackpkg prompts me to run LILO.
It turns out that slackpkg has a simple mechanism of customizing package post-installation work, since slackpkg is after all a wrapper around the standard pkgtools. In this case, what I needed to customize is the lookkernel() function in /usr/libexec/slackpkg/functions.d/post-functions.sh. Copy that function over to a new file (say, /usr/libexec/slackpkg/functions.d/z-lookkernel.sh) and edit so it becomes something like this:
lookkernel() {
NEWKERNELMD5=$(md5sum /boot/vmlinuz 2>/dev/null)
if [ "$KERNELMD5" != "$NEWKERNELMD5" ]; then
if [ -x /usr/share/mkinitrd/mkinitrd_command_generator.sh ]; then
echo -e "\n
Your kernel image was updated.
Do you want slackpkg to run mkinitrd now? (Y/n)"
answer
if [ "$ANSWER" != "n" ] && [ "$ANSWER" != "N" ]; then
( /usr/share/mkinitrd/mkinitrd_command_generator.sh --run /boot/vmlinuz-generic | sh )
fi
fi
if [ -x /sbin/lilo ]; then
echo -e "\n
Your kernel image was updated. We highly recommend you run: lilo
Do you want slackpkg to run lilo now? (Y/n)"
answer
if [ "$ANSWER" != "n" ] && [ "$ANSWER" != "N" ]; then
/sbin/lilo
fi
else
echo -e "\n
Your kernel image was updated and lilo is not found on your system.
You may need to adjust your boot manager(like GRUB) to boot appropriate
kernel."
fi
fi
}
This customization will now let slackpkg upgrade-all prompt me about updating my initrd upon a kernel upgrade, along with a subsequent prompt to update LILO.
Prefer startx over display managers
For some, this might very obvious, but this one is something I learned early on, even when on Debian or OpenBSD. I can't count how many times I've read questions from people asking about what to do next after upgrading their display driver and/or kernel, rebooting, and getting a blank screen instead, with some of them not even able to switch virtual consoles back to tty1. Or, it boots up fine to presenting the display manager, only to break upon logging in because of somesuch.
On a default install, Slackware would drop you to runlevel 3, which will not run a display manager. This is a good default, since this means you have startx as an option to run X11, and even more, you have some option to check if your configuration is ok, by looking at your /var/log/dmesg or /var/log/Xorg.0.log. Moreover, logging in to console shell lets you have a chance to set up your environment the way you want it, especially if you need some X11 tweaks. Which leads to next item...
Know your login shell's init (and maybe your X11 init too)
I know most people have a simple login shell configuration, e.g. on bash, just having a .bashrc and maybe even a .profile. But there's more to that than just those two files. For example, if you're on a Slackware64 with multilib enabled, you can source /etc/profile.d/32dev.sh to get additional environment tweaks for compiling software under 32-bit mode.
For bash, I recommend reading up the INVOCATION section of the manpage. For zsh, there's a corresponding STARTUP/SHUTDOWN FILES section in its manpage as well. Other shells definitely have their own style of setup, so be sure to check out their docs.
If you're going to use X11 via startx, it is often helpful to look around /etc/X11/xinit and peek at the various xinitrc* files. Reading startx's manpage should also give a clearer idea about configuring it so you can run your preferred apps and window manager/desktop environment.
Outro
These last couple of tips are pretty much something that can be applied to just about any Linux/BSD system, not just Slackware. However, these are often overlooked so I think it best to tell here, and moreover, I think this shows how well and generic Slackware is.
Kudos once more to Patrick Volkerding and and the Slackware team!