Slackware is the oldest Linux distribution still in active development. It predates Debian and Red Hat, it has had the same lead maintainer throughout, and it has changed remarkably little — not through neglect, but because its design was settled early and its maintainer has never been persuaded that the alternatives are improvements.
It is also the distribution most often assumed to be dead, for a reason that turns out to be a misreading.
The release that looks like abandonment
The current stable release is Slackware 15.0, from February 2022. There is no 15.1 and no 16.0. On the face of it, that is a distribution that stopped four and a half years ago.
It is not. The development branch is updated almost daily. Slackware’s real activity happens in slackware-current, which is a rolling tree that receives package upgrades continuously — checking while writing this, the most recent changelog entries were from yesterday, upgrading half a dozen packages. Meanwhile 15.0 continues to receive security patches, the most recent at the time of writing being August 2026. The project’s stated policy is “release when ready and not before”, with no timetable, so the gap between stable releases says nothing at all about whether work is happening. Judge Slackware by its changelog, not by its version number.
Patrick Volkerding remains the lead maintainer, working on it full time, with a small group of long-standing contributors. Funding comes from merchandise sales and a Patreon that currently carries several hundred paying supporters — not lavish, but not the picture of a project running on fumes either.
No dependency resolution, on purpose
This is the design decision everything else follows from. Slackware’s package tools — installpkg, removepkg, upgradepkg and the menu-driven pkgtool — do not check dependencies. A package is a compressed tarball with a script; installing it unpacks the files and runs the script. That is the whole mechanism.
The reasoning, which the project states plainly, is that the distribution is meant to work as a cohesive whole: if you install everything, the dependencies are present, and tracking them individually solves a problem you do not have. Hence the official advice, which sounds odd until you understand it:
Do a full installation. Not a minimal one. Slackware is designed around it, the documentation assumes it, and a partial install is how people end up with the missing-library problems they then blame on the package manager.
installpkg package-1.2-x86_64-1.txz
upgradepkg package-1.3-x86_64-1.txz
removepkg package
pkgtool # the menu-driven front endslackpkg is official — it lives in the distribution’s own ap series and is installed by default. It handles fetching updates and patches over the network, searching, and blacklisting, sitting on top of the pkgtools. What it does not do is resolve dependencies, because that is not a thing Slackware does.
slackpkg update # refresh the package lists
slackpkg upgrade-all # apply everything available
slackpkg install-new # packages added since your release
slackpkg search opensslFor software outside the distribution, SlackBuilds.org is where the community keeps build scripts — currently targeting 15.0 and actively maintained. A SlackBuild is a shell script that fetches upstream source, compiles it and produces a package you then install with installpkg. Unofficial helpers such as sbopkg and slpkg automate that loop, and slpkg will follow the dependency lists that SlackBuilds declare.
What the system looks like
| Area | Slackware | Almost everywhere else |
|---|---|---|
| Init | BSD-style scripts in /etc/rc.d | systemd |
| Runlevel for a desktop | 4 (3 and 5 are both console) | Graphical target |
| Dependencies | Yours to know | Resolved automatically |
| Configuration | Edit the file | Edit the file, usually |
| Release cadence | When it is ready | Scheduled |
| Architectures | x86, x86_64, plus official ARM and AArch64 ports | 64-bit, increasingly only |
No systemd, and no announced plan to adopt it. Services are shell scripts in /etc/rc.d/ that you make executable to enable and edit to configure. Whether that is a feature depends entirely on you; what is true either way is that the scripts are short, readable, and do exactly what they appear to do.
The runlevel detail catches everyone: in Slackware, runlevel 4 is the graphical one. Runlevel 5 is identical to 3, which is console. Set id:4:initdefault: in /etc/inittab if you want a graphical login.
And a detail worth noting in 2026: 32-bit x86 is still shipped and still updated, in both 15.0 and -current. There is also an official ARM port — 32-bit ARM for 15.0 and AArch64 in -current — covering Raspberry Pi and similar boards. Very few distributions still do the first of those.
Stable or current?
This is the real decision, and it is not the one the version number implies.
15.0 is genuinely stable and genuinely old. It is patched for security, but its desktop environments and toolchains are from early 2022. For a server doing one job, that is fine and arguably ideal. For a workstation, it will feel its age immediately.
slackware-current is the rolling development tree and is what most people actually running Slackware today are on. It carries current packages and receives updates constantly. It is also, formally, a development branch — it can break, and there is no promise otherwise. In practice it has a reputation for being far steadier than that description suggests, but the reputation is not a guarantee, and you should be reading the changelog before you upgrade rather than after.
Treat ChangeLog.txt as required reading. It is the project’s real communication channel, it explains what changed and why, and on -current it is what stands between you and a surprise.
What it is like to use
Fewer layers than you are used to. There is no configuration abstraction sitting on top of the service files, no tool generating /etc from templates, and nothing that will undo your edit on the next upgrade. When something is wrong, the thing that is wrong is in a file you can read.
The cost is that you do the work. Installing something not in the distribution means finding a SlackBuild or compiling it, knowing what it needs, and installing those too. Nothing tells you what is missing until a program fails to start and you read the error. Being comfortable with ldd stops being a nice-to-have.
People who like Slackware describe the same thing every time: they know what is on the machine, because they put it there.
Who should run Slackware
You should, if you want to understand a Linux system rather than operate one — Slackware teaches more per hour than any other distribution here, because nothing is hidden and nothing is automatic. You should, if you administer a machine that does one well-defined job and you would rather it did not change underneath you. And you should, if you have a working 32-bit machine you still care about, because the list of distributions that will still take it seriously is now very short.
You should not, if you want to install software without thinking about what it depends on. That is not a limitation to work around — it is the design, and fighting it means fighting the distribution. Try Debian, which is similarly conservative and resolves dependencies for you.
You should also not, if you want current software with a stability promise attached. Slackware offers old-and-supported or current-and-formally-a-development-branch, with nothing in between. If what you actually want is a rolling system that is nonetheless meant for daily use, Void is the closer fit — independent, not systemd, and rolling by design rather than by default. And if the appeal is specifically the absence of systemd rather than Slackware itself, say so out loud before choosing, because that narrows the field in a much more manageable way.
Related reading
- Void Linux — independent, no systemd, rolling on purpose
- Debian — the conservative choice with dependency resolution
- Gentoo — the other distribution that expects you to build things
- How packages and dependencies work — what Slackware deliberately does not do
- systemd explained — the thing it does not use