Tumbleweed for the server

Tumbleweed is a little different than the average rolling distro. Like in Debian, there is library naming policies that make it possible to have side-by-side abi versions of runtime libraries installed, which does help make it, much like debian (testing, even sid), so operationally reliable to update in place.

More so, I have come to appreciate that some key server packages are also “versioned”. Hence, there is, for example, postgresql13-server. When you have postgres, and you suddenly upgrade major versions, you have to backup and then reload tables. In a distro like arch, this can happen at any time, so you might find yourself suddenly updating by ambush. In Tumbleweed, I should be able to pin to a specific version, like say postgres13-server, for example, and keep that even when tumbleweed migrates to postgres14 or 15 by default. This means I am in control of and can choose when I update key services that can be messy, and can define what my “baseline” services environment looks like, rather than upgrading by ambush. This also applies to language runtimes, hence ruby2.7 and ruby2.7-rubygem…, for example. This would make tumbleweed so much more interesting and sustainably deployable to me.

I had been considering migrating from leap to tumbleweed on my main system. I did update a laptop to tumbleweed very late last year, and was very pleased with how clean the update to xfce 4.16 went on it, too.

The main issue I see is what is defined as a “server”. If “server” means deploying web pages, managing small office file serving, etc., my experience has been the TW has been quite stable.

If “server” means high availability, then TW is probably the wrong solution. To take advantage of the rolling distribution you will need to perform reboots quite often, sometimes daily. Of course, it you don’t follow the rolling updates then you won’t have to reboot as often, but then the Leap distribution would seem to be more suitable.

Indeed, I am thinking most about replacing my development server, and devops type systems. So yes, it is about those kinds of things to me. The only sad thing to me is leap seems to be abandoning arm32, which is still so useful for low end IoT device endpoints. Most of my own server needs are not truly high availability, but my device needs often are.

“Throw-away” docker instances already seemed a very good potential choice for tumbleweed, and given this even more so since one can establish a baseline for testing even if no instance is perfectly “identical”, such as around ruby 2.7, a specific postgres series, etc.

On TW for the server: a big yes from me. These days running old stuff on servers for the sake of LTS is a bad way to go IMHO. New tech, new threats need an up to date system.

That said, in my current job we work with TW on the servers, VM and cloud instances. The issues we’re meeting are almost never related to TW itself. And … it’s fully dockerized and salted.

Honestly I have a very confused opinion about this. I only started using TW early last year and so far for me, it’s been more stable than LEAP 15.1 or 15.2 on my laptops anyways.

The only thing that worries me is the number of packages that lose support and get “dropped”, for example a big chunk of python packages on a release a few weeks ago which ended up crippling scipy, then again I can manage python package with pip instead, but I am afraid of something like that happening for other packages with very short notice. Right now, they are discussing about dropping Chromium.

Indeed, this is one of my classic fears about using rolling distros in general and had kept me away from doing so before. What I liked about Tumbleweed is the versioning of critical packages (postgres, ruby runtime, etc) which can give kind of a cushion against surprise / ambush upgrades to incompatible releases. I did notice python is also versioned in Tumbleweed (python38-… for example), so I think if you used the versioned packages rather than the “master” package which selects “latest”, you might not have ran into that problem. On the other hand there seems to only be one version of python actively maintained in tumbleweed (there is both ruby 2.7 and 3.0 active by comparison), so it may be harder to stay on a version. Postgres has versions from 9.5 to 13 all actively maintained, and maybe more can be done to actively maintain older python series packages. There also might already be a separate dev repository on obs that has older python packages built for tw currently. obs is also what makes tw seem much more sustainable to me as a rolling release.

This has been documented on the Mailing list, so not an unknown, renaming of python, it’s just the fallout until the broken packages get tweaked with the new naming convention…

Suggest you install something like feedbro reader in your browser, then link to the rss feed? <https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/feed/mailinglist.rss&gt;