Slackware - Control

When people ask why I used Slackware back in the day, my answer is simple: I needed an operating system, not a babysitter. It is 2008. The internet has stopped being a toy for geeks, Linux is becoming fashionable, Ubuntu CDs arrive free in the post, and crowds of former Windows users are installing fancy themes and Compiz so their windows burst into flames and spin around a cube.

That was when I finally understood something: the more “friendly” a distribution becomes, the less its users understand what is going on inside it. Slackware was the opposite. Linux for the paranoid, for people who want to know which daemon starts, why it starts, where its configuration comes from, who opened a port, and which damn process ate all the memory.

It hid nothing. No magic, no magic buttons, no shamanic utilities that overwrite half the configuration files and then shrug: “It just happened.” You are responsible for the system yourself. That is why Slackware teaches Linux so well.

init as an operating table

Most modern distributions resemble a hospital where the patient is hooked up to a hundred machines, half of which nobody understands anymore. Slackware is more like an anatomy theatre.

Here are rc.M, rc.inet1, rc.modules, and rc.local. Read them, edit them, understand them.

Want to disable a service?

chmod -x /etc/rc.d/rc.httpd

This command disables httpd startup through Slackware’s standard boot scripts. It does not stop an already running server; use /etc/rc.d/rc.httpd stop for that. Both commands require root privileges.

Done. No layers of abstraction and no daemons managing other daemons that launch yet more daemons. Simple, understandable behaviour. It is like surgery. If a doctor does not know where an artery runs, the patient dies. If an administrator does not know which script brings up the network, the system will eventually fail to boot. Slackware forces you to understand these things.

A package manager without drugs

Slackware has no automatic dependency resolution, and I think that is wonderful. Yes, it sounds strange today. But having to manage dependencies yourself makes you an engineer, because you have to understand:

• why you need a library;
• what depends on it;
• what will happen after an update;
• why this particular version is built with these particular flags.

In other systems, the package manager resembles a nurse who injects twenty drugs into a patient without asking any questions. Slackware makes you read the instructions. Suddenly, you discover that you do not need half the libraries at all.

Compilation as a way of learning

People often complain:

“Why build anything by hand?”

I have always asked a different question:

“Why do you trust a binary built by someone you know nothing about?”

Compilation makes you understand the system. You begin to learn:

• how Autotools works;
• what CFLAGS are for;
• why x86 and x86_64 behave differently;
• where ABI problems come from;
• how dynamic linking works;
• what ld.so is and why ldconfig exists.

Build KDE or Xorg by hand once, and you understand more about Linux than you do after a year of using Ubuntu. It is like a dissection. While a medical student reads textbooks, a surgeon is already holding organs and seeing how everything really works.

The system becomes predictable

Predictability is Slackware's main advantage. If something breaks, you almost always know where to look. There is no black magic, no hidden configuration generators, no dozens of automation layers.

If the network fails, look in rc.inet1. If a daemon does not start, inspect its rc script. If X11 will not start, read the log.

Linux becomes an engineering system again, rather than a collection of incantations.

Paranoia as a way of thinking

Slackware gives you a thoroughly troublesome habit. After a few years, you start looking suspiciously at every piece of software. Why does this service start? Why is this daemon exposed to the outside world? Why does this binary have SUID set? Why does this program need twenty dependencies? Why is the system doing something without my permission?

You begin to understand that security comes from knowing what is happening, not merely from installing patches. Most break-ins happen because people do not know what is running on their machines, not because they are stupid. Slackware cures that disease quickly and brutally.

Minimalism as therapy

Modern systems resemble a patient in intensive care:

• five hundred processes;
• hundreds of megabytes of logs;
• dozens of services;
• gigabytes of dependencies.

Slackware looks more like a healthy organism. Everything is simple, visible, and explainable. If you cannot explain why a component exists, you do not understand your own infrastructure well enough.

Why I used Slackware

I wanted complete control of the machine. I wanted to understand Linux, rather than merely use it. I wanted to know what happened in memory, which daemons listened on ports, how the system started, and why it worked at all.

Slackware does not make you a compliant user. It makes you a little paranoid. That paranoia later saves servers, infrastructure, and nerves. Many people consider Slackware obsolete today. Perhaps it is. But it gave an enormous number of people a fundamental understanding of Unix.

When the latest fashionable distribution suddenly breaks after an update and its user searches forums for a magical fix, an old Slackware hand opens the log, examines the problem, and quietly repairs it. They know the system's anatomy.

A doctor who knows anatomy always has an advantage over someone who only knows how to press pretty buttons.