Linux OSBN/Ubuntuusers Planet XING / LinkedIn

Linux year in review 2021 – my highlights

As the year draws to a close, there has once again been a lot going on in the Linux world. In the recently published episode of the Focus on DevOps podcast, we spent two whole hours discussing all the news in detail.

Time to take a slightly deeper look at my personal top 5.

Probably the biggest highlight for most people was the 30th anniversary of Linux – I already reported on this in another article. I was also able to contribute to two special episodes of the Focus on DevOps podcast:

E22 – 30 Jahre Linux

Rocky Linux und AlmaLinux

AlmaLinux 8 installer

The promising CentOS forks Rocky Linux and AlmaLinux have been reported on repeatedly throughout the year. After the discontinuation of the conventional CentOS distribution by Red Hat and CentOS in December 2020, the expectations in the community were high. People were eager to see who would deliver first – and AlmaLinux decided this race in its favor:

Release Date
RHEL AlmaLinux Rocky Linux CentOS
8.3 29.10.2020 30.03.2021 (+147) 30.04.2021 (+183) RC 07.12.2020 (+39)
8.4 18.05.2021 26.05.2021 (+8) 21.06.2021 (+34) 03.06.2021 (+16)
8.5 09.11.2021 11.11.2021 (+2) 18.11.2021 (+7) 26.11.2021 (+15)

In general, you can say that the community was split. One part did not want a fork that was created by a company – for fear that the drama that had just happened would repeat itself. The other part was enthusiastic about CloudLinux engagement, the company behind AlmaLinux, and saw a lot of potential.

I myself belonged to the first part for a long time and was skeptical – but I have to admit that AlmaLinux actually does an excellent job and is very committed to a transparent community. The US hoster and distributor claims to invest 1 million dollars annually in development and founded a community including a foundation and a foundation board. CloudLinux CEO Igor Seletskiy recently withdrew from this board, as he no longer saw the need for it. Currently the board consists of 5 people, 2 of them from the own ranks. The connection to the community via its own forum, Reddit and Twitter is short – you can reach the project easily and get feedback on ideas quickly.

With great interest I have also observed the developments in the Rocky Linux project. This project also founded a community including a charter and a non-profit organization financed by donations – according to the Linux Foundation, Rocky Linux may also officially bear the name Linux. However, the project took longer until the first stable release, because infrastructure and processes had to be built up first. AlmaLinux had an advantage here because it already has experience in maintaining RHEL forks – with CloudLinuxOS, a commercial fork is already offered to its own hosting customers.

Both distributions do a good job. They are stable and wonderfully boring to install and use – just like RHEL itself. Since version 8.5 Rocky Linux also offers Secure Boot support. Differences between the distributions are mainly in the speed of patches.

Here we should briefly repeat what is understood as a patch in the RHEL context. In principle, the package management updates installed RPM packages in order to fix security vulnerabilities and program errors. Which package version fixes which bugs defines additional meta-information collected in the software repository. This information is necessary so that administrators can make a meaningful patch selection. RHEL and the forks also make this vulnerability information available online via web frontends. I compared these frontends for 6 months (01.06.2021 – 09.12.2021) and visualized the deviations in a graph:

Speed and continuity of released security patches

This showed that AlmaLinux needs an average of about 2 days to rebuild and deliver RHEL patches. Rocky Linux takes 17 days and had problems delivering patches in a timely manner, especially up to and including July. Also the pipeline for the maintenance of the patch information does not seem to function reliably. Some patch information is missing, although the packages were properly rebuilt and published – also recognizable by the tearing lines in the graph. Thus my comparison is not completely accurate, since I limit myself here exclusively to patch information. To make a more accurate statement on a per-package basis, I would have to monitor the projects’ individual mirrors to compare new files in terms of versions. Nevertheless, I consider the continuous maintenance of patch meta-information to be important.

More background and details can be found in my updated talk “CentOS ist tot, lang lebe CentOS”.


In the Uyuni project, which is the upstream for the commercial SUSE Manager, there have been some changes that I very much welcome. For example, aarch64 support in general has been greatly improved, as well as support for many new distributions:

  • AlmaLinux und Rocky Linux 8
  • Alibaba Linux 2
  • SLE Micro und openSUSE MicroOS 5.0

The operating system has been updated to openSUSE Leap 15.3, numerous CVEs – especially related to Salt – have been fixed. Redfish is now supported as power management, numerous discontinued API calls as well as support for EL6 have been removed. The rarely used feature for central upload of ABRT reports after program crashes has been removed. Support for older systems without Salt agents has been discontinued and will be removed in the future. New Grafana dashboards help to monitor the system landscape in an automated way and to visualize the health status in an appealing way.

More details about monitoring with Uyuni can be found in the following arcticle and YouTube video.

A new addition is the central maintenance of maintenance windows. This allows systems to be assigned maintenance times, and tasks executed outside the window are not executed by mistake. With a calendar export, administrators can conveniently communicate maintenance times to their team. Also, information about registered SLES systems can now be forwarded to the SCC (SUSE Customer Center) – for example to visualize the correct licensing.

I find the preview of a functional Ansible integration very nice. Many users would prefer to use Ansible instead of Salt because it is much easier to use and understand. The project has listened to the request and now offers to run Ansible playbooks and roles through a dedicated proxy system. Ansible code can then be conveniently assigned to the system and executed via a graphical interface. In the future, it is planned to simplify the use and to add further functionalities.

Katello 4

The competition has also seen a long-awaited change – Katello is now available in a major version 4. This version cuts old ties and no longer requires MongoDB installation. Katello is mainly used together with Foreman, which uses a PostgreSQL database, to fully manage Linux systems. The two projects form the basis for the commercial Red Hat Satellite server.

Running two databases in parallel on one system is always suboptimal – even after numerous optimizations, system performance always lagged far behind the original Spacewalk project (now Uyuni). It took some time to complete the rebuilds. In the meantime, numerous subsequent versions have been released – the next release 4.3 should be out soon, the Release Candidate was published a few days ago:

Katello Foreman Date
4.0 2.4 22.04.2021
4.1 2.5 22.06.2021
4.2 3.0 19.10.2021
4.3 RC4 3.1 14.12.2021

Red Hat Satellite 7.0 is scheduled for release in May of next year – maybe based on Katello 4.2? This version will ship without integrated Puppet and will replace the long obsolete katello-agent with Remote Execution.

Further (preliminary) details of the roadmap can be found in the following blog.

Currently there are efforts to simplify the well-known organization/location setup – contributions in the community are explicitly welcome. It is also currently being discussed whether new versions should be developed and tested against RHEL or CentOS Stream.

RHEL 9 Beta and CentOS Stream 9

SSH option in the CentOS Stream 9 installer

On 03.11.2021, Red Hat released the beta of the upcoming RHEL 9 version. The beta is based on the CentOS Stream 9 beta, which in turn is based on Fedora 34. The final versions of the operating systems should be released in May 2022 if Red Hat maintains the previous schedules.

Not much technical news is known yet – that should change over the next few months. The Linux kernel is updated from 4.18 to 5.14, GNOME jumps from 3.32 to 40. The installer currently brings hardly any visible news – the only noticeable change is that the default SSH configuration now blocks access for root.

Asahi Linux

Debian Bullseye on a Apple Mac Mini with M1 SoC

Last year, Apple surprised with its first processor of the M family: the M1. It is primarily intended for use in MacBooks, Mac Minis and iMacs – the MacPro will probably follow later. This year in October, two more advanced processors with significantly higher performance followed with the M1 Pro and M1 Max. The original M1 already offered excellent performance with low power consumption, low heat development and extremely long battery runtimes – a combination not found in Intel and AMD.

It is all the more impressive that it is now possible to run the devices with Linux. While Apple, as expected, keeps a low profile when it comes to supporting alternative operating systems, clever developers have managed to create the necessary drivers via reverse engineering. Some of these drivers are already included in Linux 5.13, further developments will be included in 5.16 and 5.17. There is still a lot to do here – but considering the short development time, it is remarkable how advanced the support already is. For example, it is already possible to get a full Linux desktop running with a few tricks, as developer Alyssa Rosenzweig shows. Currently, hardware-accelerated 3D support is still missing, among other things – but even in the very inefficient software acceleration, Apple Silicon beats powerful and hardware-accelerated ARM SoCs supported by Linux.

During the X Developers Conference, Rosenzweig provided interesting insights into the Linux development around the M1:

Personally, I find Apple’s developments of the M family as well as the efforts of the Asahi project impressive. Apple has managed to build a solid, powerful and extremely efficient hardware platform. However, I do not want to use macOS for various reasons – mainly because of the lock-in. If it should actually be possible at some point to simply install Linux via a USB stick without hacks like on other platforms and to be able to use all hardware stably, I could become weak. A MacBook Pro with M1 Pro and a working GNOME desktop would be an absolute dream for me.

Wishes for 2022

After one year, a lot has happened in the CentOS environment; most cloud providers now offer Rocky Linux or AlmaLinux images – but unfortunately not all. I would like to see Hetzner in particular offer AlmaLinux as well as Rocky Linux. With Rocky Linux I would be happy if errata information were provided more reliably. In general I am curious what changes RHEL 9 and CentOS Stream 9 will introduce next year.

In the hardware market, I would be happy to see more ARM devices. Apple has proven that the ARM platform is also suitable for normal end users:inside and has long left the tinkering stage. My hope is that other large manufacturers will jump on the bandwagon and produce comparable devices. With Concept Luna, Dell has shown a very interesting concept for low-cost, sustainable and modular notebooks – similar to the Framework Laptop now also available in Germany. I am curious what will happen here and whether Dell will continue to think about Linux here. So far, Dell had attracted attention with a good commitment – e.g. in the fwupd project.

Sharing is caring

Leave a Reply

Your email address will not be published.