The Linux kernel has recently had an unusually large number of ‘minor’ releases.

Given the warnings and media hype that accompanies some of these releases, people quite reasonably wonder how many of them contain significant security bugfixes. The kernel developers’ formal position seems to be: ‘all of them’. They understand that almost any bug has the potential to become an exploitable vulnerability.

Slackware seems to be more pragmatic. If the risk to a naive user’s system from messing up a kernel upgrade is greater than the real-world risk from a vulnerability, Slackware does not produce a new kernel. Official kernel updates are very unusual. At the same time, more sophisticated users are empowered to use their own judgment and build their own kernels: first, because the configuration and building procedure is well documented; and secondly, because there is a very strong preference for Slackware to use unpatched ‘vanilla’ kernels.

This situation is generally accepted in the community, but it leaves some Slackware users – specifically, the naive ones that are receptive to security hype but can’t build their own kernels – in a state of anxiety.

So, in an attempt to alleviate this anxiety, from now on I’m going to have each 4.4 series release automatically built and packaged and available here, starting right now.

But of course, the big problem is trust. Why should you trust an unofficial set of kernel packages from me?

To solve that problem, these kernel packages are reproducibly built. If you want to, you can clone the ‘dusk’ project from my Gitlab, and build your own packages, and your packages should be absolutely identical to my packages (if you build on Slackware 14.2). And so you can be assured that I haven’t added something evil.

Nevertheless, I recommend that you should continue to use the official kernel packages unless you are worried about a particular security or hardware bug.

Reproducible building and packaging is an ongoing project of research and development, with a homepage at I’ll write some more about that in a future post.