Slackware 15 — 1
Slackware 15.0 was released February 2, 2022 22:22 UTC — more than five years after releasing 14.2. The long release cycle tested the patience of many Slackware users and probably tested the patience of all developers and contributors too.
Historically I have been slow to update from one Slackware release to another. I used 12.2 until reaching end-of-life support (December 9, 2013). I tinkered with but skipped 13.0, 13.1, and 13.37 and instead updated to 14.0 (September 26, 2012) and then to 14.1 (November 4, 2013). I waited about a year after the 14.2 release before updating from 14.1. Part of that latter delay was migrating from 32-bit to 64-bit.
I do not recall updating a computer operating system major release in a blind or trusting manner. I always tested thoroughly before proceeding to update systems.
Updating from 14.1 to 14.2 was filled with many bumps and required some months to complete.
I repeated my practice of detailed testing when I thought the 15.0 release might be imminent. In the spring of 2021 I tested the development branch of 15.0. I discovered hiccups and challenges for my usage. From that testing I created a check list for updating my systems and a shell script to automate updating a 14.2 system. For the past several Slackware releases I have written a shell script to automate the update consistently across multiple systems.
After my 2021 spring testing I concluded 15.0 was not close to being released. Life priorities required me to forsake testing. I monitored the change log but that is all.
Nine months elapsed before the official release. I waited several weeks until packages were released at slackbuilds.org.
Not being in hurry to update, in spring 2022 I tried my first pokes at the official 15.0 release.
As is the common Slackware ritual I reviewed the release notes and documentation. I updated my shell script and check list.
Next was synchronizing the /etc/rc.d scripts. I started modifying the default rc.d scripts about 20 years ago when I began using Slackware. My changes are not dramatic or traumatic. I like stdout color in the rc.d scripts, I add additional stdout verbosity, I shorten the time used with some sleep commands, I massage the scripts as much as practical to be consistent, and I modify how some of the scripts function. Comparing and updating the scripts always takes time.
I prepared testing partitions. These testing partitions create a dual boot environment but is an optimal way to test the actual hardware. In addition to a test partition on the laptop and office system, I have two Slackware test systems with internal hard disks. I test the office system in this dual boot manner, but I prefer to mangle the other systems before testing my primary production system. This approach allows me to limit taking down the office system that also is the house network file server.
Unlike previous Slackware releases when I lacked appropriate hardware, this time around I created a virtual machine (VM) for testing. I dislike the “Rinse and Repeat” game — updating in a test partition, evaluating the results, restoring the test partition to baseline, and repeating until satisfied. This is a slow process on a physical system. A VM cannot replicate actual hardware and does not avoid the repeat game but allows me to create snapshots to test more rapidly. A couple of mouse clicks in the VM configuration and the baseline snapshot is restored. With a VM I am not burning measurable electricity.
The “Rinse and Repeat” game means tweaking the update script and check list after each test run. Typically this “Rinse and Repeat” game requires many passes until I am satisfied.
The first update in the VM went well. Unsettling was the update required about an hour.
The script was in automatic mode with no user action required. The one-hour period included removing non stock packages, not installing KDE packages, and updating patches since release. I did not test but I presume installing KDE packages would add another 10 minutes or more.
The T400 laptop with a SATA II SSD took about 90 minutes. On one physical test system with an AMD dual core and SATA II disk, the update required about 2 hours and 25 minutes. The computer from Hell took 2 hours and 42 minutes.
These update times are awful. I am using a network connection to source packages from a local repo. Using an optical disk or USB stick would be slower. A fresh install would be much faster but that loses all configurations and customizing. Seems the days of lean and mean operating systems are long gone. A distro on a single CD or small hard disk? Not anymore. The long times made me feel as though I was updating Windows.
Posted: Category: Usability Tagged: Slackware
Next: Slackware 15 — 2
Previous: Newer is Not Always Better