Upgrade Reliability of openSUSE Tumbleweed

AspireOne_TumbleweedFor fun… or maybe negligence… I hadn’t updated one of my openSUSE Tumbleweed netbooks. As a rolling distribution of Linux, it is generally considered in bad form to not keep it updated as it will likely break the installation. Not so with Tumbleweed.

The System

Acer Aspire One D255E Netbook

  • Intel Atom CPU N455 @ 1.66GHz
  • 2 GB DDR3 Memory
  • 250 GB HDD
  • Intel GPU with 1024×600 screen resolution
  • Runs openSUSE Tumbleweed with KDE Plasma
  • Last updated 02 May 2018,
  • Kernel 4.16.7
  • KDE Plasma 5.12.4
  • KDE Framework Version 5.45.0
  • QT Version 5.10.0

sudo zypper dup

After updating the repositories and some churning a couple repository switches for two packages, there were a total of 2902 packages to be downloaded and installed. This included:

  • Kernel 4.18.0
  • KDE Plasma version 5.13.4
  • KDE Frameworks Version: 5.48.0
  • Qt Version 5.11.1

After about two hours of that little netbook cranking away, downloading and installing, the upgrade was complete. The machine rebooted without a single incident. Not a bit of strange behavior or fiddling required to use the computer. It just worked.

I was curious to know, how many snapshots were released since the last update. According to this page,  there were 54 snapshots released by the Tumbleweed team. That means there were enough changes to spin up a new ISO of Tumbleweed 54 times!

How does it run?

Upon the system settling, I wanted to check the memory usage. A total of 489 MiB was being used by the system. Since Firefox and Chrome tend to be a bit heavy to use, I installed Falkon Web Browser and started to dink around a little bit. The machine is obviously a bit slow but runs well enough to be useful. Monitoring CPU usage, there were few spikes or periods of the CPU maxing out. I am impressed by how few resources that are actually being used.

As far as how performant this machine is? It’s not. Not at all nor do I expect it to be. I don’t know that this machine is any slower than when it originally Ran Windows 7 Starter but comparatively to other systems, it can be just a bit painful to use outside of casual web browsing but it does play Tux Racer quite well.

Final Thoughts

I am impressed by how well openSUSE Tumbleweed can tolerate not being updated for an extended period of time. Two major kernel revisions, Qt version jump, and a KDE Plasma version jump and not a single things is broken even after missing 54 snapshots. Truly a testament to the hard work of all those involved in building and maintaining openSUSE Tumbleweed.

As far as the hardware goes. I really like the size of this netbook; the keyboard is almost full size and it is preferred over a tablet for most purposes and it stands up on its own without any special case. The battery life is still good after 8 years of use and although it feels a BIT flimsy, the build quality is as such that it has survived more than one drop without any catastrophic damage. When this finally goes, I would strongly consider another of the same form factor and build quality.

As with anything, your mileage may vary. Not everyone has the same successes and failures in their cases. I have pretty ordinary hardware so I seem to have constant success with openSUSE Tumbleweed as a very stable and robust platform to run on my machines.

References

Tumbleweed Changes and ISOs

Acer Aspire One D255E Netbook

Falkon One-Click Install for openSUSE

2 thoughts on “Upgrade Reliability of openSUSE Tumbleweed

  1. Some of this success is due to choices made in Suse to follow Debian style abi library naming policies in their RPM’s. This means during update and after, if you still have binaries tied to older library releases, they aren’t killed, unlike RedHat and Fedora, which cannot easily have multiple library packages installed. This also is why Fedora is only safely updated now, after so many years of failure, with the appropriately named “fed-up”, which downloads and caches and then upgrades during boot. Another important difference is obs, which rebuilds dependent packages automatically when dependencies change. This is different from Debian Testing, and especially Ubuntu and their universe repo, which may have stale binaries that have not been rebuilt against the base system and libraries in a very long time.

    1. I can’t speak with any real authority on the underpinnings of how packages are built. I can tell you, however, based on what I have read from developers and package maintainers is that there is a lot of effort put into ensuring upgradability. I hope this will be the norm for all Linux distributions as things progress.

Leave a Reply