Linux Weekly News

Two Google engineers came to Open Source Summit North America 2021 to talk about a project to change the way the company creates and maintains the kernel it runs in its data centers on its production systems. Andrew Delgadillo and Dylan Hatch described the current production kernel (Prodkernel) and the problems that occur because it is so far from the mainline. Project Icebreaker is an effort to change that and to provide a near-mainline kernel for development and testing within Google; the talk looked at the project, its risks, its current status, and its plans.

The Asahi Linux project has a progress report on its goal of running Linux on Mac M1 hardware. Earlier this year we saw the absolute lowest level drivers being merged into the kernel. Those are important for bring-up, but to get a usable system we need many more. Over September we’ve seen a lot of action on this front, with many important drivers now in review or even already merged for Linux 5.16. The goal of the Asahi Linux project is to upstream everything into the Linux kernel, so all our drivers are eventually headed for upstream review.

The AlmaLinux Foundation has opened membership to everyone. The AlmaLinux Foundation [...] was created as a 501(c)(6) non-profit (the same as the Linux Foundation) in order to put OWNERSHIP of the OS, the Intellectual Property and the direction of the project into the hands of the community. By joining as a member (100% free for community members) you have the right and the ability to vote on board members and the direction of the project and other decisions as they will come up in the future.

Firefox 93.0 has been released. With this version Firefox supports the new AVIF image format, which is based on the modern and royalty free AV1 video codec. The PDF viewer supports filling more forms, such as XFA-based forms used by multiple governments and banks. Downloads that rely on insecure connections are blocked, protecting against potentially malicious or unsafe downloads. Details on these features and more can be found in the release notes.

Version 13.0.0 of the LLVM compiler suite is out. There is a long list of changes, as always; see the numerous sets of release notes below for details.

Security updates have been issued by Fedora (cryptopp), Mageia (kernel, kernel-linus, and sqlite), openSUSE (rabbitmq-server), Red Hat (kernel and samba), SUSE (glibc and webkit2gtk3), and Ubuntu (containerd, docker.io, imlib2, ledgersmb, mercurial, mongodb, and node-bl).

Version 3.10.0 of the Python language has been released. There are a lot of significant changes in this release, including the much-discussed structural pattern-matching feature. See this article for an overview of what's in 3.10.

Julia is an open-source programming language and ecosystem for high-performance scientific computing; its development team has made the first release candidate for version 1.7 available for testing on Linux, BSD, macOS, and Windows. Back in May, we looked at the increased performance that arrived with Julia 1.6, its last major release. In this article we describe some of the changes and new features in the language and its libraries that are coming in 1.7.

Developers working in languages like C or C++ have access to two competing compilers — GCC and LLVM — either of which can usually get the job done. Rust developers, though, are currently limited to the LLVM-based rustc compiler. While rustc works well, there are legitimate reasons for developers to wish for an alternative. As it turns out, there are two different ways to compile Rust using GCC under development, though neither is ready at the moment. Developers of both approaches came to the 2021 Linux Plumbers Conference to present the status of their work.

Security updates have been issued by Debian (apache2, fig2dev, mediawiki, plib, and qemu), Fedora (chromium, curl, kernel, kernel-headers, kernel-tools, openssh, rust-addr2line, rust-backtrace, rust-cranelift-bforest, rust-cranelift-codegen, rust-cranelift-codegen-meta, rust-cranelift-codegen-shared, rust-cranelift-entity, rust-cranelift-frontend, rust-cranelift-native, rust-cranelift-wasm, rust-gimli, rust-object, rust-wasmparser, rust-wasmtime-cache, rust-wasmtime-environ, rust-wasmtime-fiber, rust-wasmtime-types, rust-wast, rust-wat, and webkit2gtk3), Mageia (apache-mod_auth_openidc, c-ares, chromium-browser-stable, icu, libspf2, perl-DBI, python, and python-rsa), openSUSE (haproxy and opera), Oracle (kernel), SUSE (firefox and libvirt), and Ubuntu (python3.8).

The 5.15-rc4 kernel prepatch is out for testing.

One thing standing out in the diffs might be the m68k 'set_fs()' removal - not really a regression fix, but it has been pending for a while, and it turned out that the problems attributed to it were due to an entirely unrelated m68k signal handling issue. So with that fixed, we could get rid of set_fs from another architecture.

See this article for information on set_fs() and its removal.

Paul McKenney has started a blog series on Rust for the Linux kernel. He has posted six of a planned 11 articles, though several are labeled as "under construction". This series focuses mostly on use cases and opportunities, rather than on any non-trivial solutions. Please note that I am not in any way attempting to dictate or limit Rust's level of ambition. I am instead noting the memory-model consequences of a few potential levels of ambition, ranging from "portions of a few drivers", "a few drivers", "some core code" and up to and including "the entire kernel". Greater levels of ambition will require greater willingness to accommodate a wider variety of LKMM [Linux-kernel memory model] requirements.

[...] These blog posts will therefore present approaches ranging upwards from trivial workarounds. But be warned that some of the high-quality approaches require profound reworking of compiler backends that have thus far failed to spark joy in the hearts of compiler writers. In addition, Rust enjoys considerable use outside of the Linux kernel, for example, as something into which to rewrite inefficient Python scripts. (A megawatt here, a megawatt there, and pretty soon you are talking about real power consumption!) Therefore, there are probably sharp limits beyond which the core Rust developers are unwilling to go.

Much of the free-software development world has adopted Git forges (such as GitHub, GitLab, or sourcehut) with enthusiasm. The kernel community has not. Reasons for that reticence vary, but one that is often heard is that these forges simply don't work well at the scale needed for the kernel project. At a Kernel-Summit session during the 2021 Linux Plumbers conference, Donald Zickus and Prarit Bhargava sought to show how Red Hat has put GitLab to good use to support its kernel team. Not only can these forges work for kernel development, they said, but moving to a forge can bring a number of advantages.

Security updates have been issued by Debian (curl, krb5, openssl1.0, and taglib), Fedora (cifs-utils), SUSE (libqt5-qtbase and rubygem-activerecord-4_2), and Ubuntu (linux-raspi, linux-raspi-5.4 and linux-raspi2).

Adrian Ratiu writes on the Collabora blog about the challenges that face developers trying to build the GNU C Library with the LLVM compiler.

Is it worth it to fix glibc (and other projects which support only GCC) to build with LLVM? Is it better to just replace them with alternatives already supporting LLVM? Is it best to use both GCC and LLVM, each for their respective supported projects?

This post is an exploration starting from these questions but does not attempt to give any definite answers. The intent here is to not be divisive and controversial, but to raise awareness by describing parts of the current status-quo and to encourage collaboration.

James Bottomley explains how the integration of Matrix and BigBlueButton was done for the just-concluded Linux Plumbers Conference.

One thing that emerged from our initial disaster with Matrix on the first day is that we failed to learn from the experiences of other open source conferences (i.e. FOSDEM, which used Matrix and ran into the same problems). So, an object of this post is to document for posterity what we did and how to repeat it.

The term "interrupt" brings to mind a signal that originates in the hardware and which is handled in the kernel; even software interrupts are a kernel concept. But there is, it seems, a use case for enabling user-space processes to send interrupts directly to each other. An upcoming Intel processor generation includes support for this capability; at the 2021 Linux Plumbers Conference, Sohil Mehta ran a Kernel-Summit session on how Linux might support that feature.

Stable kernels 5.14.9, 5.10.70, and 5.4.150 have been released with the usual set of important fixes. Users of those series should upgrade.

Security updates have been issued by Debian (libxstream-java, uwsgi, and weechat), Fedora (libspf2, libvirt, mingw-python3, mono-tools, python-flask-restx, and sharpziplib), Mageia (gstreamer, libgcrypt, libgd, mosquitto, php, python-pillow, qtwebengine5, and webkit2), openSUSE (postgresql12 and postgresql13), SUSE (haproxy, postgresql12, postgresql13, and rabbitmq-server), and Ubuntu (commons-io and linux-oem-5.13).

Version 14 of the PostgreSQL relational database manager is out.

PostgreSQL 14 brings a variety of features that help developers and administrators deploy their data-backed applications. PostgreSQL continues to add innovations on complex data types, including more convenient access for JSON and support for noncontiguous ranges of data. This latest release adds to PostgreSQL's trend on improving high performance and distributed data workloads, with advances in connection concurrency, high-write workloads, query parallelism and logical replication.

More information can be found in the release notes.