Linux Rolling Releases Head to Head Competition One Month Update

About a month ago I decided to try a head to head match up of various Linux rolling release distributions, documented in this blog post. A month in I’ve added a few new distributions and have some initial observations.

NOTE: the continually updated results spreadsheet is hosted on a NextCloud server here and the repository with all of the most recent data, commands, etc. is hosted here .

New Distributions

When I first started this the big fish rolling release distribution that I wanted to have was Arch Linux . Not only was it one of if not the first rolling release distribution but it is widely used and well maintained. As a Linux user that mostly uses graphical installers the idea of spending hours configuring a full environment with desktop didn’t please me. I therefore went with the well known Manjaro Linux since it is based on Arch. As time went on though it seemed the main kernel shipping with Manjaro was slipping further behind Arch. I asked for some more suggestions for other rolling releases. The Arch-based EndeavourOS was suggested to me. So I added that trying to decide if I wanted to just bite the bullet and put together an Arch VM as well. What I didn’t realize until this LearnLinuxTV YouTube video ran across my feed was that Arch added a guided installer script. It wasn’t graphical but it did all the same sorts of autoconfig type steps that the graphical installer could do. It worked as fast as the graphical installers as well. So now there are a total of three Arch Linux based rolling releases in the competition: Arch proper, Manjaro, and EndeavourOS.

The other rolling release I originally wanted to include was a lesser known independent one called Void Linux . When initially setting up the machines I could never get Void to boot after installation. I probably spent two hours trying to get it going. Since I had luck with some new distributions I decided to give Void installation another try. I don’t know what I was doing wrong the last time but this time everything just worked fine. As far as I know I was doing the same steps using the exact same install image. It was probably one of those powering through fatigue causing more problems than it is worth. Either way I have rounded out the rolling releases with Void Linux as well.

One Month Results

So about a month in, with each distribution getting at least one update cycle (albeit Arch and Void only having a few days from installation) there are some noteworthy but not groundbreaking observations.

Update Time and Cadence

I was expecting some differences in the update times and cadences. The distribution maintenance has a lot of manual processes and is relatively labor intensive. They all can’t march in lockstep. However it is surprising to me how varied they are. I’m updating once a week, approximately. So there will be some weeks where a distribution has very few changes, even if some of those changes to a package were already in another distro. Then there will be a huge volume of changes in another week when it catches up. This is most readily apparent with things like when Gnome jumped to Gnome 40 or with kernel updates.

The updates themselves can take drastically different times. While I made sure that each of the installations at least have some of the same standard types of packages: office suites, image editors, etc. they don’t all have exactly the same packaging and some of these out of the box have a lot more packages than others. One of the reasons for looking at trends rather than one absolute time/size value is to see how things change over time within a distribution even more than where their baseline starts. While the dramatic time differences can be heavily a factor of the update system itself for the distribution it is often substantially driven by the network transfer speeds of the server. I’m trying to simulate creating a system with a fire/forget mentality not optimizing each week for different mirrors or configuration settings. These numbers therefore are capturing that.

In terms of quickest update system, of the original set anyway, it seems that Solus is way ahead of the others. OpenSUSE’s zypper seems to be more of a bottleneck to itself, which seems to turn in consistently slower times even with relatively minor updates. Arch, Manjaro, and EndeavourOS all use the same pacman tool but don’t all pull from the same repositories. It is interesting to see how much slower Manjaro has been on some updates, driven substantially by the download speeds but not entirely. Now that there are three Arch-based distributions it’ll be good to see how they run side by side. The big straggler in all of this though is the Gentoo based Redcore. It’s update process except in trivial cases is one of if not the slowest. Gentoo is known for its installation process being download and build everything. Redcore can do this but it actually takes the faster alternative path offered to Gentoo of downloading binaries and installing those. There is still a lot of work to do apparently since the post-download stage seems to move far slower than the rest of the distributions, especially when there is a big update. The worst week was this week, with 500 packages being updated (but not the a major kernel version bump), it took nearly two hours to fully update. I’m not versed in how Gentoo works to know what the integration process is for these pre-built versions. Redcore or Gentoo users may be able to shed some light on that.

Installation Size

I find the disk usage trends across the distributions more interesting than the installation times. Redcore started off with the most disk usage by far even though it seems to have a comparable amount of installed applications as even the most feature laden of these distributions. Yet over time the size has been slowly going down before the big spike this week. I wonder if a similar slow drop off in usage will happen again. OpenSUSE on the other hand which started off as the leanest of the bunch by a little bit has been growing substantially in the early weeks before leveling off at the new second highest disk usage spot, right after Redcore. I originally thought it was the Gnome 40 update or maybe the update to the 5.12 kernel but other distributions have now gone through those transitions and they have seen a much steadier disk usage. Solus seems to have the slowest growth curve of them all so far, but it hasn’t had a major kernel bump yet either. Manjaro has been only slightly faster growing. It’ll be interesting to see how the various Arch distributions compare over time.

Kernel

The most surprising thing to me is the variations in kernel versions. I come from a Linux world where I run LTS versions of distributions which only see major updates every two years. I never worry about running the latest and greatest kernel. Most of my machines are running the 5.4 Linux kernel which date back to 2019, according to this Wikipedia article . Those machines were only recently updated in the second half of last year from kernels dating back into 2017/2018. I’m bringing that up to highlight I’m not a kernel junkie that needs to run the most recent kernel. However I thought that was a big part of why people used rolling releases.

When I started building these machines at the end of March I assumed every rolling release distro would be on the then most recent 5.11 kernel (release February 2021). Yet Manjaro and Redcore were still on 5.10, which is from December 2020. I figured they’d come along soon enough. The release of the 5.12 kernel at the end of April 2021 though would be the test. How fast would the various distributions get that kernel integrated? OpenSUSE was the first on my May 3rd updates. When all of the other distributions stayed pegged I wasn’t exactly surprised. The fact that Manjaro was still on 5.10 though was a bit surprising. I went to the Arch page and saw that it still was on 5.11 as well. That all changed a week later, this week, when Arch and EndeavourOS were both on 5.12 as well. Still Manjaro is stubbornly on 5.10. Solus and Void are still on 5.11. Recode is also still on 5.10.

Manjaro users have been pointing out to me that it is possible to run the 5.12 kernel on Manjaro, you just have to manually select it. That may be true for Solus, Void, and Redcore as well. However the point of the matchup is how these rolling distributions evolve over time automatically. I’m trying to simulate a user who is using the rolling releases to get the latest and greatest in a “it just works” workflow. Just run your updates and what happens over time. Any customization, tweaking etc., is a perfectly reasonable workflow for some users but it doesn’t capture the automatic update process that I’m trying to study. I will be more than a bit disappointed if some of these don’t automatically bump kernel releases by a version rather than just patch an existing kernel.

Reboot Time

Update times is what really brought me to this experiment in the first place. It was more specifically OpenSUSE’s “do you want to update” reboot prompts that actually drove the initial idea. The update and restart time felt way too Windows-like for this mainly Linux user. I wondered if it was normal for rolling releases or not. First, it turns out that much of the perceived time was the actual time of installing the update with the “shutting down” screen and its progress indicator spinning away on OpenSUSE. I’ve learned that now that I separate the update from the reboot process. While there are very large variations between distributions they mostly fall to less than 30 seconds to fully reboot. Most of that process is in the startup process itself. The only distribution which has seen substantial growth in reboot times is OpenSUSE, ironically. It started off the worst at ~40 seconds or so but has grown steadily over the weeks to a new plateau around 50 seconds. I’m not sure why OpenSUSE takes so long to cycle but I hope it doesn’t get worse. Redcore’s update cycle this week also saw a huge bump. Whether this is a permanent new reboot time or just a blip remains to be seen.

Conclusion

At the end of the first month I see this as a sustainable exercise I can continue on for awhile. It will be interesting to see how these evolve over a period of years. It takes less than an hour a week for me to do each of the updates, and probably 20 minutes of actual interactive time when things go off without a hitch. I now have all of the distributions I really care about. The one I’d still love to have but I’m not willing to go through the trouble of building is Gentoo. This coming month will be the first time I have the full suite of rolling releases. I’ll probably do another assessment at that point again. Either way I post the updates to social media as I make them (e.g. here on Twitter or here on Friendica ).