Slackware 16 Alpha 1: What's New and How to Test It

🚧 Pre-release: Slackware 16 Alpha 1 — not for production use. Based on the official changelog · Last updated: September 2026

Slackware just shipped its first alpha since Slackware 15 came out in 2021 — four and a half years of -current development landing in a testable release. If you've used Slackware before, the headline is a full toolchain rebuild: GCC, Glibc and Binutils all jumped at once, and Patrick Volkerding rebuilt the entire package tree against them. If you haven't used Slackware before, this guide explains what makes it worth testing (or skipping) before you commit a machine to it.

Curious to try it yourself before committing to bare metal? A cloud VPS is the fastest way to test-drive a new release — see our comparison of the best Linux VPS hosting providers.

What's Actually New in Slackware 16 Alpha 1

The core of this release is a toolchain upgrade, not new desktop features. Volkerding's own changelog entry from September 5, 2026 sums it up:

"Upgraded to binutils-2.47, gcc-16.2.0, and glibc-2.44, and compiled everything with them. There might be a light at the end of the tunnel, eh?"

That "compiled everything with them" is the part that matters — this isn't a handful of packages bumped in isolation, it's the whole distro rebuilt against a new C library and compiler. That's the kind of change that surfaces build breakage and ABI issues project-wide, which is exactly why it needed 4.5 years of -current churn before an alpha felt ready.

Firefox and Thunderbird were also updated for this release, and Zenwalk — a Slackware derivative — pushed its own update around the same time, which is a reasonable signal that the toolchain rebuild is stable enough for downstream projects to build against.

The -current Branch Keeps Moving — What Landed Right After Alpha 1

Alpha 1 isn't a snapshot frozen in time — Slackware's -current changelog keeps shipping fixes on top of it daily. Two days after the alpha, on September 7, 2026, a batch of security-relevant updates landed:

• util-linux 2.42.3 — fixes five CVEs, including CVE-2026-76642, CVE-2026-78410, CVE-2026-78409 and CVE-2026-78408.
• libpcap 1.10.7 — fixes seven CVEs (CVE-2026-0799, CVE-2026-31912, CVE-2026-31911, CVE-2026-6244, CVE-2026-6554, CVE-2026-18313, CVE-2026-18238) — worth knowing if you use tcpdump or anything linked against libpcap for packet capture.
• python-numpy 2.5.3, taglib 2.3.2, rust-bindgen 0.73.1 and pkgconf 3.0.7 — routine version bumps.

If you're already tracking -current, run slackpkg update && slackpkg upgrade-all regularly rather than treating Alpha 1 as a fixed target — the branch is moving fast right now.

Slackware Still Isn't Like Other Distros — What That Means for 16

If your Linux experience is mostly Ubuntu, Fedora or Arch, three things about Slackware are worth knowing before you decide whether to test this alpha:

• No automatic dependency resolution. Slackware's package tool doesn't resolve dependencies for you the way apt, dnf or pacman do — see our comparison of apt, dnf, pacman and zypper for what that actually means day to day. On Slackware you either track dependencies yourself or lean on a third-party tool like sbopkg for SlackBuilds.
• LILO, not GRUB, is still the default bootloader. Most major distros moved to GRUB years ago; Slackware 16 Alpha 1 still boots with LILO. It works, but the configuration syntax and recovery process are different enough from GRUB that it's worth reading up on before you're troubleshooting a broken boot at 2am.
• Minimal by design, closer in spirit to Arch than to Ubuntu. There's no installer GUI wizard, no automatic configuration layer smoothing things over. If you've done a manual Arch Linux install, the mental model transfers — you're expected to configure the system yourself, not have it configured for you.

Who Should Test Alpha 1 Now — and Who Should Wait

Test it now if:

• You maintain SlackBuilds, third-party packages, or anything that needs to be verified against the new GCC 16 / Glibc 2.44 toolchain before Slackware 16 goes stable.
• You already run -current and have a disposable test machine or VM you update regularly.
• You want to report build failures or regressions early, while Volkerding is still actively rebuilding the tree.

Wait for beta or a release candidate if:

• You need a daily-driver or production system — this is Alpha 1 of a release that's already 4.5 years in the making; treat "alpha" literally.
• You're new to Slackware. There's no dependency resolver and no installer hand-holding, and testing that combination for the first time on pre-release software doubles the number of things that can go wrong at once.
• You depend on third-party SlackBuilds that haven't been confirmed to build against GCC 16.2.0 / Glibc 2.44 yet — a lot of them haven't been touched since the last stable toolchain.

How to Test Slackware 16 Alpha 1 Safely

If you haven't installed Slackware before, our Slackware 15 installation guide covers the stable-release process — worth reading before you attempt an alpha, since the installer flow itself doesn't change.

None of this belongs on a machine you rely on. Alpha software with a rebuilt toolchain is exactly the combination most likely to break in unpredictable ways.

1. Use a VM or a spare partition, never your main install. A fresh VM (QEMU/KVM, VirtualBox) is the safest option — snapshot it before every slackpkg upgrade-all so you can roll back instantly.
2. Pull from -current, not a static ISO. Slackware's development branch updates daily; grab the latest packages via the official changelog rather than assuming a downloaded ISO is current by the time you install it.
3. Read the changelog before every update. Volkerding documents breaking changes and rebuild notes directly in the changelog entries — that's the closest thing Slackware has to release notes during an alpha cycle, and skipping it is how people get surprised.
4. Rebuild your SlackBuilds against the new toolchain before trusting them. Anything compiled against the old GCC/Glibc should be treated as untested until you've rebuilt and verified it under 16.2.0 / 2.44.
5. Keep a known-good Slackware 15 install around. If you're testing for compatibility work, you need a stable baseline to compare against, not just the alpha in isolation.

What Comes Next on the Way to Stable

Slackware doesn't run on a fixed release calendar, and Volkerding doesn't publish target dates — the project has historically shipped "when it's ready" rather than against a deadline, which is part of why there was a 4.5-year gap since 15.0. Expect the usual pattern from prior cycles: more alpha builds as remaining packages get rebuilt and tested against the new toolchain, then a beta once the package tree is largely stable, followed by one or more release candidates before a final 16.0. Watching the -current changelog is the only reliable way to track progress — there's no public roadmap or milestone tracker.

Frequently Asked Questions

Is Slackware 16 stable yet?

No. Alpha 1 was released September 5, 2026, and Slackware doesn't publish target dates for beta or stable — based on the 4.5-year gap since 15.0, expect the alpha/beta/RC cycle to take a meaningful amount of time before a final release.

Can I upgrade from Slackware 15 to 16 Alpha 1?

Slackware doesn't officially support in-place upgrades across major versions during the alpha phase. Test on a separate install or VM — don't upgrade a working Slackware 15 system in place.

Why did Slackware wait 4.5 years between major releases?

Slackware doesn't work to a release schedule. This cycle specifically needed a full toolchain rebuild — GCC 16.2.0, Glibc 2.44 and Binutils 2.47 all upgraded together, with the entire package tree recompiled against them — which is a slower, higher-risk process than a typical point release.

Does Slackware 16 use GRUB or LILO?

LILO is still the default bootloader in Alpha 1. Slackware hasn't switched to GRUB by default the way most other major distros have.

Will my SlackBuilds still work on Slackware 16?

Not guaranteed. Anything built against the previous GCC/Glibc toolchain should be treated as unverified until it's been rebuilt and tested against GCC 16.2.0 and Glibc 2.44 specifically.