It seems like, finally, the pieces are being put in place for the next Slackware release. It has been a long wait, it will be 5 years since the 14.2 release in a few months. Since Salix releases are tied to Slackware releases, there hasn’t been a Salix release for a long while too. Major changes that the next Slackware release will introduce include a switch to PAM, Linux kernel 5.10.x, KDE Plasma 5 and, just last week, Xfce 4.16. I’m guessing there won’t be any other major changes to Slackware current and it will go into beta soon. That’s all just a guess though, as only Patrick Volkerding really knows what he has in mind.

Seeing how Slackware current seems to be stabilizing, I think it’s good time for us to start working on our next release too. Expect things to start getting interesting again. Some have already noticed that 15.0 and slackware-15.0 directories have appeared in our repository mirrors and emailed me asking about them. Obviously, they are no ready yet, especially the Salix 15.0 repository, but they are the groundwork on which our next release will be based.

The first thing we did, as with every new release, is to create a copy of the Slackware current repository and add dependency information to it. This is what constitutes our slackware-15.0 repository. It is currently tracking Slackware current of course, but when Slackware 15.0 is released, we’re going to switch it to tracking that instead. The reason that we’re already naming everything “15.0”, instead of keeping the “current” name, is that we want to have a stable configuration for our package management tools, so that users can follow development from our upcoming 15.0alpha release, throughout the beta and RC releases and up to the final Salix 15.0 release, with as little interruption as possible.

Contrary to what most other distributions are doing these days, we’re going to keep supporting 32-bit systems with our next release. And we’re going to do that for as long as Slackware keeps supporting 32-bit systems. I’m also actually considering another port to Raspberry Pi, but that’s certainly something for later, it’s going to require considerable resources, mostly time.

The installer has already received numerous updates. They are available in the respective git repository for now. The changes haven’t been tested at all with an installation from an actual iso image yet, but I’m confident the issues that will arise are going to be minimal and easily ironed out after our first 15.0alpha release. A noteworthy improvement over 14.2 is going to be the support for installing Salix on systems with NVMe drives.

The new Xfce 4.16 now uses GTK+3 instead of GTK+2. Most other GTK+ applications have been “upgraded” from GTK+2 to GTK+3 as well, with a few exceptions. Salix 14.2 primarily included GTK+2 applications with only a few GTK+3 ones. Salix 15.0 is going to be the opposite, mostly including GTK+3 applications with as few GTK+2 applications as possible. Unfortunately GTK+3 has diverged even further from GTK+2 in terms of looks and functionality, so even if one is using the same theme across the two versions, there are going to be significant differences between how applications look and work. Not much we can do about it, other than picking a default theme that looks as similar as possible across the two versions. I have several issues with how GTK+3 has changed, but perhaps these are for another blog post…

An important part of a Salix system is certainly our system administration tools. Apart from the terminal based tools, which have already received some updates for 15.0, we have a set of graphical system administration tools. Until 14.2, these were written in Python 2 and used the GTK+2 toolkit. For most of them, porting to GTK+3 has already been completed. I actually did that a couple of years ago, but there was no reason to update the packages in 14.2 with the new GTK+3 versions. Moving to 15.0, it seems that some additional issues with Python 2 together with GTK+3 have come up. So, I’m in the process of porting everything to Python 3 as well. I don’t expect this to be too hard.

There are two things that I haven’t ported to GTK+3 yet. The first one, is the salix-update-notifier tool. It’s the one that shows a system tray notification every time there are available package updates. The reason for that is that system tray icons have been deprecated from GTK+3 and is going to be completely removed from GTK4 (yes, they dropped the +" from the project name), as absurd as that sounds. I’m not sure what to do with this. The first option is to keep it as is, a GTK+2 tool. The second is to port to GTK+3 and instead of a tray notification icon, show a notification message instead. But these are definitely not the same thing and a tray icon is more suitable for this task, as notification messages are easy to dismiss. The second tool is Sourcery, which is by far the most complicated tool we have. I had tried porting it to GTK+3 in the past, but came to a stop, because, although the code seemed absolutely fine, it would consume 100% CPU for no reason at all. Maybe it was some bug with the GTK+3 we have in 14.2. I haven’t tried the GTK+3 that is in (what will become) 15.0 yet. If the same behaviour persists, I’ll probably leave it as is.

Packaging itself is going to be more demanding than ever. There has simply been a lot of time between releases and there have been major changes to a lot of software, different build methods, options etc. So, most of our build scripts will have to be reviewed and updated, so that we can create updated packages for everything.

One last thing (but not least), is that there is currently an effort, led by new forum member missTell, to modernize the looks of the next release. There are some interesting ideas floating around and missTell has an eye for detail and seems eager to contribute, so I’m expecting nice things to come out of this.

See you while testing the upcoming 15.0alpha release!