Brief items

Kernel release status

The current development kernel is 6.1-rc7, released on November 27.

There is really nothing here that makes me at all worried, except that it's just a bit more than I'm comfortable with. It should just have slowed down more by now.

As a result, I'm now pretty sure that this is going to be one of those "we'll have an extra week and I'll make an rc8" releases. Which then in turn means that now the next merge window will be solidly in the holiday season.

Previously, 6.1-rc6 came out on November 20.

Stable updates: 4.19.266 was released on November 23; it consists entirely of backported fixes for speculative-execution vulnerabilities. 6.0.10, 5.15.80, 5.10.156, 5.4.225, 4.19.267, 4.14.300, and 4.9.334 were released on November 25 and 26.

The 6.0.11, 5.15.81, and 5.10.157 stable updates are in the review process; they are due on December 2.

Comments (none posted)

Lina: Tales of the M1 GPU

Asahi Lina gives a detailed update on progress toward a graphics driver for Apple M1 hardware.

There is still a long road ahead! The UAPI that we are using right now is still a prototype, and there are a lot of new features that need to be added or redesigned in order to support a full Vulkan driver in the future. Since Linux mandates that the UAPI needs to remain stable and backwards compatible across versions (unlike macOS), that means that the kernel driver will not be heading upstream for many months, until we have a more complete understanding of the GPU rendering parameters and have implemented all the new design features needed by Vulkan.

Comments (13 posted)

The BPF extensible scheduler class

It was only a matter of time before somebody found a way to inject BPF into the CPU scheduler. This patch series, posted by Tejun Heo and containing work by David Vernet, Josh Don, and Barret Rhoden, does exactly that. The cover letter covers the motivation behind this work in detail:

One of our main goals was to lower the barrier to entry for experimenting with the scheduler. sched_ext provides ergonomic callbacks and helpers to ease common operations such as managing idle CPUs, scheduling tasks on arbitrary CPUs, handling preemptions from other scheduling classes, and more. While sched_ext does require some ramp-up, the complexity is self-contained, and the learning curve gradual. Developers can ramp up by first implementing simple policies such as global FIFO in only tens of lines of code, and then continue to learn the APIs and building blocks available with sched_ext as they build more featureful and complex schedulers.

There is a bit more documentation in this patch.

Comments (3 posted)

Quote of the week

I *vastly* prefer code comments over this Documentation/ cesspit. Putting things in Documentation/ is a bit like an old-folks-home, neatly out of the way to (bit)rot in peace.

And that whole .rst disease is making it unreadable for anybody that still knows how to use a text editor

— Peter Zijlstra

Comments (2 posted)

Asahi Linux November 2022 progress report

For those who are waiting for Linux on Apple hardware, the Asahi Linux project has put out a detailed report on progress toward a working kernel and distribution.

This kind of safety model is not new: it is already commonplace on Android phones, where it is usually implemented in DSP firmware. But of course, the desktop Linux ecosystem doesn’t even have a speaker EQ database framework yet, nevermind safety models! The eternal lagging behind of Linux audio strikes again. What’s the plan? While this isn’t settled yet, our current idea is to implement the safety model in a stand-alone daemon that captures the voltage/current feedback data from the ALSA device, and drives the mixer volume itself as as means of implementing soft power limits, together with some kind of “safety watchdog interlock” with the kernel that only enables higher volume limits when the daemon is active and running

Comments (47 posted)

Cartier-Tilet: Emacs 29 is nigh

Lucien Cartier-Tilet looks forward to the upcoming Emacs 29 release.

In case you didn’t know, Emacs’ current syntax highlighting is currently based on a system of regexes. Although it is not the worst thing to use, it’s not the best either, and it can become quite slow on larger files.

TreeSitter parses programming languages based into a concrete syntax tree. From there, not only can syntax highlighting can be done at high speed, but a much deeper analysis of the code is possible and actions such sa syntax manipulation can also be achieved since the syntax tree itself is available as an object which can be manipulated!

Comments (13 posted)

A useful guide to FFmpeg

FFmpeg is an indispensable tool for working with audio and video streams, but it can be challenging to learn to use well. FFmpeg — The Ultimate Guide, posted by Csaba Kopias, can help. "This guide covers the ins and outs of FFmpeg starting with fundamental concepts and moving to media transcoding and video and audio processing providing practical examples along the way."

Comments (5 posted)

Review: GIMP 2.99.14 (Libre Arts)

Libre Arts looks at the GIMP as the 3.0 release approaches.

Releases like this are too rare to disregard and thus all the more to treasure. In one swift motion the team is doing away with floating selections and bringing strokes/outlines for text. But this has been a bumpy road

Comments (9 posted)

Welcome Stéphane Guillou, new QA Analyst for LibreOffice (Document Foundation)

The Document Foundation has announced the hiring of a quality-assurance analyst, bringing its staff up to 13 people.

A lot of my time will be spent on triaging the issues users report on Bugzilla – our bug-reporting platform. There is a lot of activity on Bugzilla, and classifying and testing the reports is fundamental for us to focus on the most pressing issues, help the work developers are doing, and keep improving the software for everyone! Part of the work will also be to analyse and summarise the wealth of data available to help us see the bigger picture and make better decisions when allocating resources.

Comments (8 posted)

Development quote of the week

When I said GCC makes the assumption that it cannot happen this is what I meant: tmp is not supposed to overflow so part of the condition I had in place was simply removed.

I reported that exact issue to GCC to make sure it wasn't a bug, and it was indeed confirmed to me that the undefined behaviour of an integer overflow is not limited in scope to whatever insane value it could take: it is apparently perfectly acceptable to mess up the code flow entirely.

While I understand how attractive it can be from an optimization point of view, the paranoid developer in me is straight up terrified by the perspective of a single integer overflow removing security protection and causing such havoc. I've worked several years in a project where the integer overflows were (and probably still are) legion. Identifying and fixing of all them is likely a lifetime mission of several opinionated individuals.

— Clément Bœsch

Comments (105 posted)

Open source community split over offer of 'corporate' welfare for critical dev tools (Register)

The Register looks at the discussion around the GNU Tools Infrastructure proposal.

Sourceware, a volunteer group that has been supporting various critical FOSS developer tools for more than two decades, is being courted by The Linux Foundation's Open Source Security Foundation (OpenSSF). The OpenSSF aims to improve open source software security by providing Sourceware projects with more modern IT infrastructure.

But some members of the Sourceware community fear that accepting the help of the OpenSSF would give the corporate Linux world more leverage over FOSS developer tools. They would prefer to seek support from the Software Freedom Conservancy, a charitable non-profit that they believe is better aligned with software freedom.

LWN covered this discussion back in September.

Comments (199 posted)