Debconf23 talk mentioning Slackware in passing

[Mike Small]

Hi,

For anyone who likes to check out any mention of Slackware in the wider
world here is one:

https://debconf23.debconf.org/talks/15-why-debian/

Now, to prepare you, he's very much a hardcore Debian user and developer
who used Slackware as his first distro but moved quite early to Debian
from not liking his upgrading experience. If it's any consolation he
seemed to like Redhat less well than either.

But it's a nice talk nonetheless, I thought, in that he shares his
personal experiences in school in the 90s and onwards and how his
preferences formed. I related to a lot of it except I kind of went the
opposite way, starting with Debian but now for the most part preferring
Slackware between those two, for the usual reasons.

[John McCue]

Post by Mike Small
Hi,
For anyone who likes to check out any mention of Slackware in the wider
https://debconf23.debconf.org/talks/15-why-debian/
Now, to prepare you, he's very much a hardcore Debian user and
developer who used Slackware as his first distro but moved quite
early to Debian from not liking his upgrading experience. If it's
any consolation he seemed to like Redhat less well than either.

<snip>

I remember posts on USENET about how people wanted a
kind of easy upgrade for new releases. That was the
big selling point of Debian and Red Hat at the time.

Now that Slackware does not have a release every few
months, I use it as a opportunity to do a full reinstall,
cleaning out the SBo's and other items I have no need for.
I have scripts that creates users, groups and identifies
/etc files that need to be modified. So to me, my
"upgrades" are not that hard.

[Sam]

Post by John McCue
I remember posts on USENET about how people wanted a
kind of easy upgrade for new releases. That was the
big selling point of Debian and Red Hat at the time.
Now that Slackware does not have a release every few
months, I use it as a opportunity to do a full reinstall,
cleaning out the SBo's and other items I have no need for.
I have scripts that creates users, groups and identifies
/etc files that need to be modified. So to me, my
"upgrades" are not that hard.

Ubuntu releases are once every two years (for LTS releases), so they are not
that frequent either.

I am, though, quite shocked to see that do-release-upgrade just plows
through, just like that, on a live system, even with an X session going. But
it does apparently work. At least, I don't see huge crowds complaining about
the whole thing crashing down halfway through, because half the system is
upgraded, live.

[Henrik Carlqvist]

Post by Sam
I am, though, quite shocked to see that do-release-upgrade just plows
through, just like that, on a live system, even with an X session going.
But it does apparently work. At least, I don't see huge crowds
complaining about the whole thing crashing down halfway through, because
half the system is upgraded, live.

The same thing kind of applies also to Slackware when it comes to
security updates. I do
"upgradepkg --install-new --reinstall"
in a cron job on all new security updates from the patches directory and
it mostly worsk fine including when X packages are being updated. When
firefox has been updated firefox might say that firefox needs to be
restarted and of course the entire machine has to be restarted if the
kernel has been updated. However, I have customized my kernel packages to
also update the boot loader.

But yes, the recomended way to upgrade from a previous release is to do a
full reinstall from scratch. For me, this has never been a big problem. I
have multiple machines in networks running different versions of
Slackware. Some of those networks share home directories on NFS servers,
some setups have local home directories on separate partitions.

All those people out there out there finding it hard to to a total
reinstall from scratch probably lack a plan for doing a bare metal
recovery. One day such a plan might be needed in case of a disk crash,
fire or other disaster. It is better to have such a plan in place before
that happens.

regards Henrik

[Sam]

Post by Henrik Carlqvist
But yes, the recomended way to upgrade from a previous release is to do a
full reinstall from scratch. For me, this has never been a big problem. I
have multiple machines in networks running different versions of
Slackware. Some of those networks share home directories on NFS servers,
some setups have local home directories on separate partitions.

For someone who's running a strock distribution, out of the box, a reinstall
wouldn't be a big deal.

It becomes more of a deal for someone who actually has to set up and
configure the server.

If you have to fiddle with Apache's configuration, in /etc/httpd, good news!
You have to do it all over again. Pretty much every Apache seat is heavily
customized. Apache's configuration files are its main feature, heavily
documented, and are heavily used.

Are you running a MySQL/MariaDB instance? Well, time to start from scratch.
Not only does updating to a new major release will often involve a DB
rebuild, now one will need to manually restore the entire MySQL
configuration. In most cases it's just one file, but still, a needless PITA.

And if someone's running OpenLDAP, well, I'll just say a quiet prayer for
them.

Post by Henrik Carlqvist
All those people out there out there finding it hard to to a total
reinstall from scratch probably lack a plan for doing a bare metal
recovery. One day such a plan might be needed in case of a disk crash,
fire or other disaster. It is better to have such a plan in place before
that happens.

I sort of have a plan for my main servers, I track all of their
configuration files and stash them in a git repo.

This allows me to get an exact count of how many configuration files, of
sorts, will need to be restored after a full reinstall. Currently it is 110
configuration files, for one server.

Certainly: tracking them this way would be a major timesaver. This will save
a great deal of time if I have to reinstall. But there'll still be a huge
amount of work still left to do.

Fortunately, the 110 configuration files are for a distro with a well-
established, hardened upgrade procedure. Last upgrade to a new release took
only thirty minutes of downtime, and a failover to a backup server. There
was no need to restore anything. That's a lot, a lot quicker than what it
would've taken to do a fresh reinstall, from scratch.

[Henrik Carlqvist]

Post by Sam
I sort of have a plan for my main servers, I track all of their
configuration files and stash them in a git repo.

My plan for configuration files as well as custom software is to keep
them in custom Slackware packages. However, this is for those
configuration files intended to be shared among all, or at least several
machines. Examples of such files are ntpd.conf, sshd_config, snmpd.conf,
sendmail.cf and resolv.conf. For those few servers with a specific
purpose I store backups of their configuration file in a separate backed
up place, one directory for each server. Exemples of such files are
httpd.conf, exports, named.conf and slapd.conf.

By having those settings in custom Slackware packages I can quickly and
easily install an ordinary machine from scratch. Those specific servers
also have a backup plan for their configuration files. And when updating
ot a newer version of Slackware, I know exactly what configuration files
I have customized. I will most likely not be able to reuse all old
configuration files as is, but the tool kdiff3 or meld is great for those
situations as it with a quick glance show the differences between the new
stock configuration file, the old stock configuration file and my old
customized configuration file.

The biggest amount of time when upgrading to a newer version of Slackware
is to compile (ofter newer versions) of all those extra added software.
These days with slackbuilds.org and tools like slpkg that work is a lot
easier.

regards Henrik