After celebrating the release of Slackware 15.0, it was time to migrate LinuxGalaxy.org. Since the new OS includes a working python3 stack by default, getting my CMS and other tools up and running was much easier.

Previously, this site was using a custom compiled python3 installation with various python modules installed using pip and venv. This made it difficult to track what versions of these modules were installed using the tools I'm accustomed to. It also presented problems with reproducible builds. Using pip (and various other web-based package managers) make it difficult to maintain consistent versions of a given module across multiple machines.

To work around that issue, you either need to tell pip which versions you want installed, or build your own custom packages. Since 15.0 includes several of the most common python modules, the latter option requires significantly less effort on my part.

Other than that, the migration from 14.2 -> 15.0 is no different than it has been for any previous version. While there are a lot of new packages and systems the standard Slackware experience is no different than it was 10 years ago.

On Linux, all of the layered subsystems required to play sound from your speakers are exposed to the user. For those interested in trying out Pipewire, the latest user-space daemon in audio device management, here's a short guide.

From the official pipewire website (https://pipewire.org): PipeWire is a project that aims to greatly improve handling of audio and video under Linux.

"It provides a low-latency, graph based processing engine on top of audio and video devices that can be used to support the use cases currently handled by both pulseaudio and JACK. PipeWire was designed with a powerful security model that makes interacting with audio and video devices from containerized applications easy, with supporting Flatpak applications being the primary goal. Alongside Wayland and Flatpak we expect PipeWire to provide a core building block for the future of Linux application development."

Pipewire is installed by default in Slackware for all versions after 14.2. To use it we need to disable pulseaudio and add pipewire-pulse to our autostart script.

first we need to disable pulseaudio. This is a bit more complicated than you would expect because we cannot simply remove the libraries. Applications still link to the shared libraries and will use it to communicate with pipewire. What we need to do is disable the daemon auto-start feature that causes the pulseaudio service to start everytime an application launches. We make this change in /etc/pulse/client.conf

Make sure autospawn = no is in this file. Now the daemon will not be started by applications that play audio.

Pipewire config files are stored in /etc/pipewire/

Open /etc/pipewire/pipewire.conf and look for the exec = option. This controls how the pipewire daemon process is started and may look like this:

Make sure the line for /usr/bin/pipewire-pulse is uncommented. This provides a pulse-compatible daemon that allows applications expecting pulseaudio to communicate with the pipewire daemon. Think of PipeWire as a drop in replacement for Pulseaudio!

Pipewire doesn't need to run as root. Simply add the process to your autostart script as defined by your desktop of choice. In KDE you can add this in the system settings or for simpler window managers just add the command "pipewire" to your startup script so that it gets started every time you log in.

All pulseaudio aware applications should see the pipewire-pulse daemon as a suitable replacement. Pavucontrol and apps like Firefox should be able to play sound without any further changes!

Keep in mind that Pipewire is still unfinished, so you may encounter minor problems such as popping audio. As things are improved over time Pipewire will likely become a more standard part of the Linux desktop.

Weekly update statistics are here for January 30, 2021! This is where Official updates in the Slackware changelog are retrieved, summarized, and presented for YOUR viewing pleasure.

Enjoy and be sure to visit the Official Slackware Changelog for full details!

http://www.slackware.com/changelog/

Activity this week has revolved around upgrading existing packages to their newer versions. This week also saw the removal of several noteworthy packages:

• l/gst-plugins-base0-0.10.36-x86_64-4.txz
• l/gst-plugins-good0-0.10.31-x86_64-4.txz
• l/gstreamer0-0.10.36-x86_64-3.txz
• n/openssl10-1.0.2u-x86_64-2.txz

These were obsolete versions of gstreamer and openssl that are unlikely to be used in any currently maintained applications. Note that these packages are still available in stable releases (14.0, 14.1, 14.2).

January 2021 saw a mass rebuild for the entire slackware package tree. More than 3000 packages were recompiled against the new toolchain. This recompile only applies to -current and is the biggest update in Slackware history, beating the previous record set in 2018 when 2460 packages were recompiled.

In addition to changes made across all versions, the latest stable release (14.2) saw a trickle of updates to keep up with upstream. 14 security updates were released for 14.2.

That's it for the week of January 30, 2021. The plan is to continue this every Saturday, with minor tweaks to improve the usefulness of the data.

Also want to give a big shout out to Patrick Volkerding and the rest of The Slackware Team. Slackware 15 looks like it's going to be awesome.

Thanks for keeping the project going all these years!

As a Slackware user, I often run into situations where I find myself having to prove that Slackware is in fact a current and up-to-date Linux Distribution. Since we now live in an era of "data driven" decision making here are some statistics that showcase the pace of Slackware development.

If you've ever told a Slackware user that you don't see any activity on Slackware.com, you were probably asked that question. Slackware has no marketing team, no social media influencers, or the support of a user-facing foundation. Development is handled by a small team and all official communication with users occurs within the changelog itself. To help illustrate the activity level of the Slackware project, I have been working on parsing the changelog data in python in order to present in a more human-friendly format. Changelogs are parsed using python, and charts are generated by gnuplot on Slackware -current.

Updates in the Slackware have followed the same pattern since version 12.0, back in 2007. Take the update from January 20, 2021 as an example:

Every update to the changelog as a timestamp, the package name, and what was done to the package. This means that on 1/20/2021 the Linux kernel was upgraded to version 5.10.9. Because the Slackware team is so consistent in how they announce changes, we can parse this and visualize the data going back an arbitrary number of years.

This is count of all slackware updates, organized by type. I'm also comparing it to the number of packages total in the distribution on release. This shows that Slackware has grown significantly over time and that the time between releases has also increased.

It is important to note that"rebuilds" are situtations where a package is recompiled with no version changes. This is usually due to upgrades in the tool-chain or other core dependencies. The large spike in 2018 was due to a mass rebuild in which the entire OS was recompiled.

Slackware is old! Has anything changed recently?

Yes it has! 2020 saw the addition of KDE Plasma into the official Slackware distribution. Many Slackware users have been running KDE using an unofficial "ktown" repository but now the desktop has officially been added. The spike in added packages at the end of 2020 is largely due to that. As we approach the release of 15.0 you will also see a lot of packages being rebuilt against the newer GCC and other core libraries.

This is part of an ongoing project. As I work on the tools used to digest the slackware changelog I'll release more detailed information. Hopefully someone out there finds this stuff interesting because I know I do :-)

Jumping into 2021 with a new blog and other online tools.

Its finally time to broadcast myself to the internet! Due to Trust issues with common web platforms, I decided to put together my own CMS system utilizing some python web frameworks to fill in the boilerplate code. linuxgalaxy.org also provides a basic file storage area so any software packages or other things worth sharing will have a secure place to live.

I plan on releasing updates for the various software projects in the works here as well as other fun tidbits as they come to mind. There are no Like, Share, or Subscribe buttons and if you were looking for a comments section to spew random opinions on, well sucks to be you!