Celebrating 30 years of Linux - is 2021 finally the year of the Linux desktop?

My favorite Linux insider joke is that “The year of the Linux desktop is always next year”. Each year there is a new technology which is expected to achieve breakthroughs. I was asked almost a decade ago to give a talk about this topic. I proved to my audience that the year of the Linux desktop is already here, just not the way most Linux users expect it. Hopefully it will be even easier now!

Linux was born 30 years ago.

I started to use Linux just three years later. The first machine where I installed Linux was an i486 box with 8 MB (not GB!) of RAM. I brought Linux home on floppy disks and did not install a graphical user interface (GUI). Next I installed Linux on an i386 box with 16 MB of RAM, an unbelievably large RAM size at that time. I made my first steps with a GUI on Linux there. I used the FVWM2 window manager on top of X11 and ran Netscape Navigator to browse the web.

Read the rest of my blog at https://www.mndwrk.com/blog/celebrating-30-years-of-linux-is-2021-finally-the-year-of-the-linux-desktop

As part of my school internship at TEM Messtechnik I got the oppertunity to work on the Enclustra Mars MA3, a FPGA SoC with two ARMv7 cores. This post describes the process of getting Linux (more precisely, openSUSE Tumbleweed) to work on this SoC.

Requirements

In order to build and install all the needed files, you’re gonna need the following:

• 1x Enclustra Mars MA3
• 1x Enclustra Mars EB1
• A computer capable of running Linux, in this case openSUSE Tumbleweed
• A computer running Windows (we need it for the flash tool)
• 1x MicroSD Card.

Setting up the build environmentee

Setting up the build environment is not difficult, but it is not a “clean” way of using a Linux system. We’re gonna need some packages that are not maintained anymore and are therefore not avaliable in the openSUSE Tumbleweed repositories. Installing packages from unofficial repositorys can be dangerous for your system though, so the first thing we’re gonna do is create a filesystem snapshot:

snapper create --description "Snapshot before installing Enclustra build environment"

This will create a Btrfs snapshot so that we can rollback (snapper rollback)to the state of the system before installing the build environment. Because no --cleanup-algorithm is specified this snapshot will not get removed after a certain period of time.

First, we need to add some repositorys:

sudo zypper ar https://download.opensuse.org/repositories/Kernel:/tools/openSUSE_Factory/Kernel:tools.repo
sudo zypper ref 

Now we can install all the dependencies we need:

sudo zypper install gcc48 gcc48-c++ git autoconf bc curl glibc-32bit mercurial unzip wget make patch openssl-devel python3-termcolor

In addition, we need a really old version of python-dialog, which is not avaliable for Tumbleweed, so we need to install it manually from an unsupported repository:

sudo zypper in https://download.opensuse.org/repositories/openSUSE:/Leap:/42.3/standard/noarch/python-dialog-3.3.0-8.1.noarch.rpm

Under normal circumstances, you should never ever install a package from Leap in Tumbleweed! The only reason we can do this here is that Leap 42.3 won’t change anymore (since it is discontinued) and I tested that everything works. Never do this regularly!!! You have been warned.

We need to set the default compiler:

sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-4.8 50
sudo update-alternatives --install /usr/bin/g++ g++ /usr/bin/g++-4.8 50
sudo update-alternatives --install /usr/bin/cc cc /usr/bin/gcc-4.8 50

Now, we can finally install the buildtool:

git clone https://github.com/enclustra-bsp/bsp-altera.git && cd bsp-altera

Since we want to get openSUSE Tumbleweed running instead of the default (bare bones) Linux Enclustra provides, we do not need to build the root filesystem. We do need to build however a bootloader (U-Boot) and a Linux Kernel. Both these parts are part of the openSUSE distribution, but the versions in the repositorys are not compatible with the Mars MA3, so we need to build the versions provided by Enclustra. The version of the Linux kernel provided is not up to date though, but I won’t go into detail on how to build an upstream Linux kernel in this post.

To start the build process, run

./build.sh -d Mars_MA3/Mars_EB1/MMC -x Linux -x U-Boot

The process is going to take some time, so go grab some tea (or coffee, if you prefer that for whatever reason…). After the build succeeds, you can find the build results in a folder named out_<timestamp>_<module>_<board>_<bootmode>. In my case that is out_20211105094426_Mars_MA3_Mars_EB1_MMC.

Partitionizing the SD Card

The SoC expects a specific partitionizing on our SD card, which we need to create manually using fdisk (replace /dev/mmcblk0 with the block name of the SD card):

sudo fdisk /dev/mmcblk0

Use fdisk as the following:

Welcome to fdisk (util-linux 2.36.2).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

Device does not contain a recognized partition table.
Created a new DOS disklabel with disk identifier 0x99faaaa1.

Command (m for help): o
Created a new DOS disklabel with disk identifier 0x8c918d1b.

Command (m for help): n
Partition type
   p   primary (0 primary, 0 extended, 4 free)
   e   extended (container for logical partitions)
Select (default p): p
Partition number (1-4, default 1): 2
First sector (2048-16777215, default 2048): 
Last sector, +/-sectors or +/-size{K,M,G,T,P} (2048-16777215, default 16777215): +2M

Created a new partition 2 of type 'Linux' and of size 2 MiB.

Command (m for help): a2
Selected partition 2
The bootable flag on partition 2 is enabled now.

Command (m for help): n
Partition type
   p   primary (1 primary, 0 extended, 3 free)
   e   extended (container for logical partitions)
Select (default p): p
Partition number (1,3,4, default 1): 1
First sector (6144-16777215, default 6144): 
Last sector, +/-sectors or +/-size{K,M,G,T,P} (6144-16777215, default 16777215): +200M

Created a new partition 1 of type 'Linux' and of size 200 MiB.

Command (m for help): t
Partition number (1,2, default 2): 1
Hex code or alias (type L to list all): c

Changed type of partition 'Linux' to 'W95 FAT32 (LBA)'.

Command (m for help): n
Partition type
   p   primary (2 primary, 0 extended, 2 free)
   e   extended (container for logical partitions)
Select (default p): p
Partition number (3,4, default 3): 3
First sector (415744-16777215, default 415744): 
Last sector, +/-sectors or +/-size{K,M,G,T,P} (415744-16777215, default 16777215): 

Created a new partition 3 of type 'Linux' and of size 7.8 GiB.

Command (m for help): w
The partition table has been altered.
Syncing disks.

After the partitioning is done, we can download the Tumbleweed root filesystem, which gets built by the openSUSE Build Service. Our SoC has an armv7 architecture, so we need the rootfs for that specific architecture. Download the image wget:

wget http://download.opensuse.org/ports/armv7hl/tumbleweed/appliances/openSUSE-Tumbleweed-ARM-JeOS.armv7-rootfs.armv7l.tar.xz

You’re also gonna need my deploy script, which makes flashing everything to a MicroSD card really simple. Download it and make it executable:

wget https://code.opensuse.org/KaratekHD/MA3/raw/main/f/deploy.py
chmod +x deploy.py 

Usage of the deploy script is really simple:

usage: deploy.py [-h] -r ROOTFS -d DEVICE -i INPUT_DIR

Deploy openSUSE Tumbleweed to the Mars MA3.

optional arguments:
  -h, --help            show this help message and exit
  -r ROOTFS, --rootfs ROOTFS
                        Path to rottfs.tar
  -d DEVICE, --device DEVICE
                        Deviceprefix to deploy to (e.g. /dev/mmcblk0p)
  -i INPUT_DIR, --input_dir INPUT_DIR
                        Build files generated by build.sh

An example of using the deploy script:

./deploy.py \\
-d /dev/sdb \\
-r /home/jens/bsp-altera/openSUSE-Tumbleweed-ARM-JeOS.armv7-rootfs.armv7l.tar.xz \\
-i out_Mars_MA3_Mars_EB1_MMC/

Replace the paths with the ones matching for your situation. Warning: If your SD-Card is the block device /dev/sdb, use dev/sdb as the parameter for -d. If your block device is e.g. /dev/mmcblk0 , you’ll need to use /dev/mmvblk0p as the parameter for -d. Also, it is important that you use an absolut path for the rootfs, even if it is located in the same directory.

The script will ask for your root password and then

1. Format the partitions of the SD card with the required file systems
2. Flash the preloader and the Linux Kernel
3. Extract the rootfs to the SD card

An example output would be:

Formatting partition 1 with fat32...
mkfs.fat 4.2 (2021-01-31)
Formatted partition 1
Formatting partition 3 with ext2...
mke2fs 1.46.4 (18-Aug-2021)
/dev/sdb3 contains a ext2 file system labelled 'rootfs'
	last mounted on / on Thu Jan  1 01:00:01 1970
Proceed anyway? (y,N) y
Creating filesystem with 15539968 4k blocks and 3891200 inodes
Filesystem UUID: b229ef5a-d94a-4851-bd70-c8c00c52fadb
Superblock backups stored on blocks: 
	32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
	4096000, 7962624, 11239424

Allocating group tables: done                            
Writing inode tables: done                            
Writing superblocks and filesystem accounting information: done   

Formatted partition 3
Flashing preloader...
512+0 records in
512+0 records out
262144 bytes (262 kB, 256 KiB) copied, 0.0645477 s, 4.1 MB/s
Preloader flashed!
Syncing...
Synced!
Mounting /mnt/rootfs
Mounting /mnt/boot
Copying files to /mnt/boot
- uImage
- devicetree.dtb
- fpga.rbf
- u-boot.img
- uboot.scr
Removing everything from /mnt/rootfs...
Extracting rootfs from /home/jens/bsp-altera/openSUSE-Tumbleweed-ARM-JeOS.armv7-rootfs.armv7l.tar.xz to /mnt/rootfs...
Extracted /home/jens/bsp-altera/openSUSE-Tumbleweed-ARM-JeOS.armv7-rootfs.armv7l.tar.xz to /mnt/rootfs
Syncing...
Umounting devices...
Done

After the script did its magic, it’s time to move on.

Building U-Boot

In our experiences, we couldn’t get the SoC to use the U-Boot image deployed to the SD Card. U-Boot is, however, required to boot the Linux kernel, so we need some other way to get U-Boot to run, which, in this case, is to flash it to the QSPI Flash of the SoC itself.

In order to do this, we need to build a version of U-Boot that works from QSPI. To do this, navigate to the build directory and run

./build.sh -d Mars_MA3/Mars_EB1/QSPI -x U-Boot

Now, navigate into the output folder (e.g. ./out_Mars_MA3_Mars_EB1_QSPI) and transfer u-boot.img and preloader-mkimage.bin to the Windows PC.

Setting up the board

In order to get the board to boot from the QSPI Flash (and aafter that from the SD card) and to give us a seral output, we need to set up the dipswitches (see above) as following:

Now you can connect a Micro-USB cable to USBUB (see the image above) and use it to flash to the QSPI and use a serial console as described below.

Flashing the bootloader

Connect the Board to the Windows PC via USB, power it using the dc input on the evaluation board and click on “Enumerate” in MCT. Make sure no other serial devices are connected to your PC. For example a USB-Jtagger can cause problems. The board should show up in the list.

In the “Operation” drop-down menu, select “Erase”, select “Full chip” and click on the “Erase” button:

In the next step, select “Program” from the “Operation” drop-down menu. Set the Start address to 0, enable “Preserve boundary data” and disable “Boot after programming”. Now select the preloader-mkimage.bin file as the Bitstream file and click on “Program”. Once the preloader has been flashed, set the Start address to 6000 and select the U-boot.img file as the bitstream file. Keep the rest of the settings as descibed above and click “Program” again.

Connecting to a serial console

Now connect the Board to a PC via USB (TODO @Phillip: Switches für Serielle Konsole?). Use Putty, Minicom, Picocom or whatever tool you prefer to use to connect via serial to the Board, just make sure to set the Baudrate to 115200.

Configuring U-Boot

With a serial console connected, power on the Board. You’ll see some output, but wait until you see a little arrow (=>) in the line at the bottom. Now, type

setenv bootcmd "run mmcboot"
saveenv

Now your board will boot from the SD card by default. Now it’s time to actually boot Linux, so power off the board. U-Boot does not have a shutdown command, so just pull the power plug.

Booting the Linux operating system

Insert the MicroSD card into the slot on the Board. and power on the board. This time you should get a lot more output then before, because this time it actually boots into Linux. There are gonna be a lot of lines starting with [OK] in green, but also a few starting with a red [FAILED]. That’s fine though, everything works even with these minor failures.

Once it’s done booting, you should see something like this on the serial console:

Welcome to openSUSE Tumbleweed 20211107 - Kernel 4.15.0-g506369939 (ttyS0).

eth0:

localhost login:

That’s it! You succesfully installed openSUSE Tumbleweed on your Mars MA3, sou you can now use it like every regular Tumbleweed machine. The default credentials are root:linux, so make sure to change them using passwd before doing anything else. I also recommend to do a quick zypper dup before starting to work on the SoC.

Further reading

• Enclustra Build Environment documentation
• openSUSE on your ARM board
• Source code for the deploy script

Tumbleweed pulled back from the frequency of snapshots released last week, but still had a good amount of releases this week.

After continuous daily releases from Oct. 27 to Nov. 2, openSUSE Tumbleweed put together another three consecutive snapshots.

Snapshot 20211106 was an extremely large snapshot and brought software updates from GNOME, KDE, Mozilla and more. An update of gnome-software 41.1 brought various minor User Interface tweaks and fixes. The package improved metadata support for snaps and added the new GNOME Circle apps to the featured carousel. The 41.1 version of gnome-shell fixed some crashes and some erratic scrolling in GTK apps. KDE Gear 21.08.3 brought several fixes for Kdenlive. The video editor fixed the muting of audio, some resize and alignment issues and the behavior of incorrect wipe and slide transitions while resizing. KDE’s document viewer Okular fixed bookmark menu actions that were missing after switching tabs and Konqi fans who like to book travel have support for German Eurowings booking confirmation in the KItinerary package. Mozilla Thunderbird 91.3.0 fixed eight Common Vulnerabilities and Exposures. One of the CVE fixes for the email client involved disabling the Opportunistic Encryption feature because a network attacker could forward a connection from the browser to port 443 to port 8443. The disabled feature could cause the email browser to treat the content of port 8443 as the same-origin with HTTP. The Application Programming Interfaces with the gawk 5.1.1 update now handles Multiple Precision Floating-Point Reliable Library and GNU Multiple Precision Arithmetic Library values slightly differently, which requires different memory management for those values. The 1.2.4 update of PackageKit improved the thread safety of an operation cancellation and added a specific error code when a user declines an interaction. There were a few updates for YaST packages like yast2-network 4.4.29, which fixed a crash when checking if a virtual interface is connected. Other packages to update in the snapshot were evolution-ews 3.42.1, glib2 2.70.1, libvirt 7.9.0 and many other packages.

Just four packages arrived in snapshot 20211105 snapshot. The first of the 41.1 GNOME packages arrived in the snapshot. gnome-chess and gnome-remote-desktop. The latter had some adjustments for frame PipeWire data. There was some clean up with the network configuration package wicked in the 0.6.67 version along with changes in the dbus configuration. The aws-cli 1.21.6 package had multiple API changes and relaxed a version dependency for python-docutils.

Snapshot 20211104 brought more than a dozen updated packages. The removal of duplicated config entries and the construct of the snippets based on the main config were made with busybox 1.34.1. ClamAV 0.103.4 added virus-name suffixes to the alerts, which trigger when a scan limit has been exceeded, and the anti-virus package fixed some issues related to email parsing. The Chinese manual pages were updated with the man-pages-zh_CN 1.6.3.6 update and several pypi packages where updated including python-Pillow 8.4.0, python-boto3 1.19.6 and major version python-pyOpenSSL 21.0.0.

The openSUSE Project has posted results from a recent survey that ran between Oct. 7 and Oct. 29.

The aim was to gather more information from open-source developers, development teams, packagers and maintainers. The survey also aimed to determine the satisfaction level of contributors and better understand the complexities and challenges they encounter with the project’s development. The survey provided an area to comment and provide suggestions to improve relevant aspects of the project and its tools.

An email to the factory mailing list about the results has provided fun discussions. The highest majority of people submitting the survey were between the ages of 35 and 49. Almost 90 percent were from the northern hemisphere and almost 60 percent had a university degree. A vast majority had or are working in the Information Technology field. On average, maintainers and packagers interact with 11.34 people for their development projects.

More information about the results can be found on the openSUSE wiki.

Sequence – making PatternDB creation for syslog-ng easier

We are well into the 21st century, but most of the log messages still arrive in an unstructured format. For well over a decade, syslog-ng had a solution to turn unstructured messages into name-value pairs, called PatternDB. However, creating a pattern database for PatternDB from scratch is a source of major pain. Or rather, it was: sequence-rtg – a fork of the sequence log analyzer – provides a new hope! It can easily create ready-to-use patterns for your most frequent log messages.

Sequence-rtg is still in beta phase, and therefore is a bit rough around the edges. However, once you deal with the initial struggles of creating the database, it works just fine. Especially if you have lots of log messages. My experience was that the more log messages and larger batch sizes I had, the better quality patterns were generated.

Read my blog at https://www.syslog-ng.com/community/b/blog/posts/sequence-making-patterndb-creation-for-syslog-ng-easier

The openSUSE Project is seeking nominations and applications for openSUSE Board candidacy. The projecct also looks to gain more members leading up to the elections.

A notice was sent by the election committee informing project members of the timeline for the election process.

There are two seats open for this election cycle. The call for nominations and applications will continue until Monday, Nov. 22. If you would like to nominate a member from the openSUSE community or declare yourself as a candidate, please send an email to the election committee at election-officials@opensuse.org.

The process is scheduled to take place in three phases. Phase 0, which is the current phase, announces the election schedule, seeks candidates to run for the board and has membership drive for people who want to become members of the project. Phase 1 continues with the membership drive to gain new members and declared candidates, who will be announced in this phase, can begin campaigning. Moving to the final Phase 2, members can begin casting votes for the candidates while the candidates can continue to campaign for votes. Phase 2 is scheduled to begin on Dec. 13 and the results are expected on the last day of 2021.

Only openSUSE members are eligible to run for openSUSE Board openings.

Introduction

During 2021 we have been starting to focus more in security for MicroOS. By default MicroOS is a fairly secure distribution: during the development all the changes are publicly reviewed, fixes (including CVEs) are integrated first (or at the same time) in Tumbleweed, we have read-only root system and a tool to recover old snapshots, and periodically the security team audit some of the new components. Also, the move from AppArmor to SELinux should help to standardize the security management.

But we really want to rise the bar when it is possible. For example, we are starting to think on how to enable IMA/EVM properly in the distribution, or what alternatives we have for full disk encryption supported by a TPM. There are some evaluation on dm-verity inside the new Transactional Image Update installer.

Another area where we make progress in MicroOS is how to measure the health of our systems, detect remotely when an unauthorized change has been made (remote attestation), and actuate over it globally and as fast as possible.

TPM as a root of trust

Today all our devices (laptops, desktops, servers, phone or tablets) includes a cryptoprocessor known as TPM (from the initials Trusted Platform Module). Sometimes is inside the CPU, but can also be found soldered in the motherboard or implemented as a software in our firmware. Those co-processors are really cheap (and sadly slow), but very useful when we want to design software that requires a hardware based root of trust.

For example, imagine that we want to encrypt the disk but we do not want to be asked for the password at the beginning of the boot. We should need some trusted component that can provide the password very early in the boot process, and that the system can - somehow - validate that it is the real deal and not some other agent trying to impersonate it. A TPM provides mechanisms to do this validation, and if every this goes OK to unseal the password to the kernel so it can decrypt the disk.

This same role is required for many other operations, like accessing to a VPN that requires the validation of the combination machine / user. Because of how the TPMs are designed, they can generate keys that we can check that comes from this specific TPM and no other. This property is valuable to open the access to the internal network, for example.

Another activity where a root of trust is require is when we need to validate the health of our systems via measured boot.

Measured Boot and remote attestation

The general mechanism goes like this: during the boot process, a very early piece of the firmware takes care of initializing some hardware components and setting some clocks, and when is done, before delegating the execution to the next stage (maybe some early stage in the UEFI firmware), it will load in memory this next stage and will calculate a hash of it (like SHA256), and will communicate this information to some piece of hardware that we trust (the TPM in this case). This component can now delegate the boot process to this second stage, that will do the same operation when needs to move to the third stage (load, measure and communicate the measurement to the TPM), and this goes on until Grub2 enter in action and load the kernel.

If we do this we effectively have a measurement of every step in the bootloader chain, from the most early stage deep in the firmware until (and included) the kernel. This process is known “measured boot”. And the TPM have a record of all those measurements!

Actually I am lying (well, sort off, as we will see a bit later).

TPMs are cheap and do not have a lot of space inside, so the TPM by itself cannot have the full record of measurement. Inside the TPM we have some registers known as platform configuration registers (PCR) that have one feature: we can read them, but we cannot directly write on them. To change the value of a register we have an operation known as extension, that can be viewed as taking the current value of the register, attaching at the end the value of the hash that we want to extend with (in this case the measurement done), and calculating the hash of the full string (again, like SHA256). This new value calculated is the one that will be stored in the PCR instead.

This extend operation makes that the current value of the PCR depends on all the previous values of it and the values (measurements) used before. So in order to replicate a value we need to know the correct measurement of each stage of the boot chain (including the initial value of the PCR after the reset, that is usually 0x00..0).

The goal here is that once all is booted, the user can ask for those PCR values to the TPM via another operation named quote. This operation returns a report signed by a key that only the TPM knows, and that I can validate to see if, indeed, comes from my TPM or not. I can later compare the PCR values with the ones that I expect for my current version of UEFI, Grub2 and kernel. If they match I know for sure that the boot chain has not been tampered, and if do not match … well … we have been hacked (or we have an unauthorized updated somewhere that we need to check).

To be honest, comparing raw PCR values is hard. If we do not know all the measurements of our boot chain, they are impossible to predict.

This is why for each measurement, from the UEFI until the kernel, besides extending a PCR register in the TPM we are also storing in memory a log of all those measurements. We register (in the normal memory) some bits extra of information used during the measurement, like the PCR number and the value used for the extension. We can also see in the log some signatures found (and expected if we are using secure boot), text data (for example the kernel command line used in Grub2), etc.

This log will be passed between stages until it reaches the kernel, that will make is available to the user space via the security file system. This log is known as the event log.

Another point here is that we can now ask, remotely from a different machine, the current values of the PCRs via a quote to the TPM, and the full content of the event log. With this information we can attest remotely that the system has not been compromised during the boot process. Of course, this is known as remote attestation.

Keylime

If we have a device with a TPM we can go to the BIOS / UEFI boot menu and activate it. After that, every boot of this system will be measured as described here, and we can do the attestation ourselves requesting a quote to TPM (via the tpm2.0-tool package in MicroOS) and comparing the values with the event log.

But this is cannot scale properly, we need a tool to help us doing this automatically.

Keylime is an open source project designed to do exactly what we need: do remote attestation of our devices, using a TPM as a root of trust of all the measurements.

In Keylime we have some services available. The agent is the service that needs to be installed in all of the nodes that we want to monitor. This service is responsible of collecting some data (TPM quotes, event log, IMA logs, etc) under demand.

This information is requested by another service known as verifier, that will validate this data based on some user provide information.

For example, it will check that the PCR values are the expected ones. It can also inspect the event log using an user provided policy (as a Python code) that will search for some signatures, will see the Grub menu used for booting and will compare some of the measurements that known of (like the kernel one, for example).

Also, if IMA is enabled in the remote node, it can validate the hashes of all the programs and services that we are running!

With Keylime we can deploy secrets to our nodes (like certificates or keys), and we can execute user-defined actions when we detect an unauthorized change in our nodes.

For example, if Keylime detect the execution of a program with a different IMA hash that the one expected, we can execute a program that will try to isolate this node from their peers, and will revoke any access to the shared resources in the network, like databases.

The good news is that Keylime has been integrated in MicroOS via two new system roles in YaST. During the installation we can see know two new roles, one should be used for the nodes that we want to monitor (agent role), and the other for the node that will take care of collecting the information of the agents, doing the verification and triggering the revocation actions when required (verifier role).

Those roles make very easy to start doing remote attestation in MicroOS today and the process is fully documented.

More information!

We documented all this information (and more) in the MicroOS portal. There you can find a more technical description, including how to configure the agent services in order that they can find the verifier, how to enable IMA in the nodes and prepare a white list of hashes, and how to write programs that can acts when an intrusion has been detected.

There is also some more details about the TPM and how to check if they are present in the system and recognized by MicroOS.

Also recently we had the SUSE Labs 2021 conference, and all the videos has been published recently, including a talk about Keylime and TPM in the context of MicroOS that you can check. In the proceedings of this conference there is also a paper that can be useful to complement this topic!

Dear Tumbleweed users and hackers,

The weather is getting colder, days shorter, motivation to go outside is shrinking. Which leaves more time in front of the computer, helping Tumbleweed roll. And roll it did during the last week! We have published 6 snapshots (number 7 needed to be discarded due to vi installation issues). The snapshots released were numbered 1028, 1029, 1030, 1031, 1101, and 1102.

The most relevant updates shipped as part of those snapshots were:

• pcre2 10.38 (I wish we could get rid of the old pcre 8.x version at least in the bootstrap cycle)
• KDE Plasma 5.23.2
• pipewire 0.3.39
• Mesa 21.2.5
• Bison 3.8.2
• GDB 11.1
• Meson 0.59.3

Staging projects are almost all filled up, you can expect changes like these in the near (for most parts) future:

• Mozilla Thunderbird 91.3.0
• Mozilla Firefox 94.0
• KDE Gear 21.08.3
• More improvements to rpmlint 2: next up: Fix “no-library-dependency-for” errors
• Bash: moving away from update-alternatives to handle /bin/sh; To allow busybox to step in as ‘sh’ provider, we are switching to a package replacement model (e.g. bash-sh, bysybox-sh). Those packages will install the relevant /bin/sh symlinks
• Meson 0.59.4 (followed by the stricter 0.60 branch)
• Linux kernel 5.15
• tbb 2021.4: breaks opencv3
• gc 8.2.0: breaks texlive and guile
• X.org server 21.1: causes some havon on openQA as font rendering changed due to DPI reporting changes
• Coreutils 9.0
• openSSL 3.0