Why I Use Slackware
I have been using Slackware since 10.0. That would be about 12 years. Three years ago everything in the house only ran Slackware. Then I installed Linux Mint Debian Edition (LMDE) on my laptop to support people migrating to Linux. Two summers ago I began using Fedora as my primary distro on the laptop. I installed CentOS 7. That gave way to a short stint with Xubuntu. Then a longer stretch with Ubuntu MATE. Partly I wanted to find a common desktop for all computers, but more importantly I wanted to gain exposure to other distros.
All along Slackware remained on my office desktop, server, and laptop. When I built a dedicated server I remained with Slackware.
In some ways Slackware is a peculiar distro. Often touted as the oldest surviving Linux distro, Slackware was one of the top dogs for many years. At one time a popular adage was, “Learn Red Hat and learn Red Hat. Learn Slackware and learn Linux.” Those days are long gone. Slackware now is the outsider. At best Slackware now is an after thought for many people.
Slackware is designed as a general purpose distro. No additional design help is provided by the BDFL or development team. While some Slackers are content with the generic design, anybody wanting more will invest various amounts of sweat equity. This is one reason Slackware is not a serious candidate for non technical users.
The generic design of Slackware provides me something I embrace. The design stays out of my way. There is something to be said about simplicity.
While all computer operating systems require some design presumptions and considerations, generally Slackware is not designed to guess how users will use the computer. Slackware is not designed with a lot of bling.
Starting in the 1980s I was already deep into customizing my computers to function the way I want. I admit my addiction. I seem incapable of using a default operating system as is.
Slackware allows me to customize the system. Minimal presumptions about my usage.
Other distros may be customized too. Yet often I find that distros designed for non technical users do not provide the same degree of flexibility. Certain design presumptions and considerations prevail. I find that these design presumptions often cause breakage in one form or another with respect to my expectations and work flow.
Through the years I have tweaked Slackware. A lot. I mean really a lot. So much that on my to-do list is to start documenting everything in a notebook. I tend to forget how I tweaked things and then consume time refreshing my memory before I can debug or add new tweaks.
I do not deny the sweat equity. Slackware can be fun but generally, is not for the faint of heart. Twenty or thirty years ago anybody using a computer was already a full fledged geek. Tweaking was the norm. These days most folks only know tablets and smart phones. Swipe and tap. Preinstalled laptops. Point and click. They know nothing about anything underneath. Slackware is not for such users.
Slackware could be massaged for such users. The Salix developers have done much work in that area, although officially they target “lazy Slackers.” I think with additional polish Salix could be molded into a friendly desktop for non technical users.
Slackware does not support pam.d, systemd, selinux, or apparmor. For my usage I find those missing elements meaningless. I am aware that pam.d is useful to some users and without that layer Slackware is unlikely to be used in certain environments. I have had my own challenges with systemd and hope that Slackware thrives many years without systemd. Likewise with selinux and apparmor. These additional layers only increase complexity of an already complex tool.
For the past two and half years I have purposely exposed myself to other distros. My primary reason was improving employment options. Yet after this period I find I prefer Slackware. Not that I actually ever left.
The lack of systemd is one reason. I do not care for the idea of parallel booting, rebooting, and halting. I prefer a known order for booting, rebooting, and halting.
I like the straightforward BSD-like init script approach. I never was warm towards the more complicated System V init scripting, let alone systemd.
I like that Slackware packages are not split into user and developer packages. Or that some packages such as OpenSSH, are split into server and client packages. Just one package, one install, and everything works.
I am not a developer but I like that most software development support is installed. No wasting time installing build-essentials or anything like that.
Slackware provides more than a few duplicate packages. This allows users to retain their knowledge and skills with older packages. A classic example is net-tools. The iproute2 package is provided in Slackware, but curmudgeons like me still have access to the tried and true net-tools collection.
Slackware is developed with a release-when-ready approach. No fixed or bleeding edge schedules. While Slackware is released with recent versions of software — and by recent I do not mean 9 to 12 months stale like Debian — the basic structure and design changes incrementally. The development team does adapt and add new technologies. Yet seldom are there big whopping changes with each release. Slackware does not depend on a development strategy that everything has to be l33t or shiny.
Generally packages are not patched for esoteric reasons or to satisfy developer whims. Patches are limited only to produce a working package. Yes, on occasion I have rebuilt a stock Slackware package to include a feature I wanted. Only on occasion.
While the BDFL does release critical kernel patches, generally the reasons have to be severe. That is, Slackware is not a card carrying member of the fatiguing kernel-of-the week club.
Slackware is stable because the overall design remains similar. Paper cut issues and bugs arise but more easily resolved. When such issues appear, debugging is more straightforward because there is less overhead.
Slackware does not provide a large repository system. Additional repos exist, but generally Slackers expect to compile additional packages. This was daunting when I first started, but I have been doing this for many years. At times the drudgery and lack of convenience irritates me, but in the end I know I get the package I want. When testing other distros I get frustrated by the additional dependencies a packager incorporates into packages. Otherwise known as bloat.
Slackware is designed with a sane way to manage package removals. Despite any dependencies needed for installation, removing a package does not remove those dependencies too.
I have an opinion that all operating systems suck. Each person should find the operating system that sucks the least for that person’s needs and work flows. The operating system will still suck but the pain points will be fewer. For me Slackware seems to suck the least. For other people that is not the case. And should not be.
I intend to keep tinkering with other distros. My professional needs require staying abreast with CentOS and Debian. Supporting people who want to migrate from Windows likely means something in the Ubuntu family. I accept that working as a system administrator means working with Red Hat, CentOS, SUSE, or Ubuntu systems rather than Slackware.
I spend much time advocating improvements for non technical users and Slackware seems an odd choice. Yet I am not advocating Slackware for those users. I am choosing Slackware for me. For my personal daily use, Slackware remains my foundation.
Posted: Category: Commentary, Usability Tagged: Slackware
Next: How I Use Linux
Previous: Slackware As My Desktop