Brief items

Security quote of the week

When an entire class of technology states on the packaging that it was made in China but intended "for overseas use only," this should really give you pause before plugging it into your network.

You will find this verbiage on a lot of Android TV streaming boxes for sale at the major retailers. There's a very good reason the country that makes this crap doesn't want it on their own networks. My advice: If you have one of these Android streaming boxes on your network or get one as a gift, toss it in the trash.

— Brian Krebs

Comments (7 posted)

Kernel release status

The current development kernel is 6.19-rc2, released on December 21. Linus said: "I obviously expect next week to be even quieter, with people being distracted by the holidays. So let's all enjoy taking a little break, but maybe break the boredom with some early rc testing?"

Stable updates: 6.18.2, 6.17.13, and 6.12.63 were released on December 18. Note that the 6.17.x series ends with 6.17.13.

Comments (none posted)

A change of maintainership for linux-next

Stephen Rothwell, who has maintained the kernel's linux-next integration tree from its inception, has announced his retirement from that role:

I will be stepping down as Linux-Next maintainer on Jan 16, 2026. Mark Brown has generously volunteered to take up the challenge. He has helped in the past filling in when I have been unavailable, so hopefully knows what he is getting in to. I hope you will all treat him with the same (or better) level of respect that I have received.

It has been a long but mostly interesting task and I hope it has been helpful to others. It seems a long time since I read Andrew Morton's "I have a dream" email and decided that I could help out there - little did I know what I was heading for.

Over the last two decades or so, the kernel's development process has evolved from an unorganized mess with irregular releases to a smooth machine with a new release every nine or ten weeks. That would not have happened without linux-next; thanks are due to Stephen for helping to make the current process possible.

Comments (2 posted)

Results from the 2025 TAB election

The 2025 election for members of the Linux Foundation Technical Advisory Board has concluded; the winners are Greg Kroah-Hartman, Steven Rostedt, Julia Lawall, David Hildenbrand, and Ted Ts'o.

Comments (none posted)

Quotes of the week

Linus made an interesting observation: he enjoys doing merges in C and has become exceptionally good at it through decades of experience - he can "do them in his sleep". But he also observed that merges in Rust are more difficult as he's not familiar enough with the language. He tries to resolve them himself, then refers back to linux-next's resolution. When his resolution doesn't match, he uses it as a teaching moment.

This observation points to something fundamental about merge conflict resolution: it is the epitome of understanding code. To resolve a conflict, one must understand why the divergence occurred, what the developers on each side were trying to accomplish, and then unify the divergence in a way that makes the final code equal to or better than the sum of both parts.

LLMinus is a tool designed to support a maintainer's decision making around merge conflict resolution by learning from past merges as well as investigating into the different branches, trying to understand the underlying reason behind a conflict.

— Sasha Levin

The Linux kernel's mm system weighs in at about 200KLoC, and Lorenzo [Stoakes] wrote a book on its design that weighs in at about 1300 pages, or about 150 LoC/page. This suggests that the Linux-kernel scheduler, which weighs in at about 70KLoC and has similar heuristics/workload challenges as does mm, would require a 430-page textbook to provide a similar level of design detail. By this methodology, RCU would require "only" 190 pages, presumably substituting its unfamiliarity for sched's and mm's deeply heuristic and workload-dependent nature.

Sadly, this data does not support the hypothesis that we can create comments that will provide understanding to people taking random dives into the Linux kernel's source code. In contrast to code that is closely associated with a specific type of mechanical device, Linux-kernel code requires the reader to possess a great deal of abstract and global conceptual/workload information.

This is not to say that the Linux kernel's internal documentation (including its comments) cannot or should not be improved. They clearly should. It instead means that a necessary part of any instant-understanding methodology for the Linux kernel include active software assistance, for example, Anthropic's Claude LLM or IBM's (rather older but less readily accessible) Analysis and Renovation Catalyst (ARC). I am not denigrating other options, but rather restricting myself to tools with which I have personal experience.

— Paul McKenney

In the interest of full disclosure, this review came from a local version of my prompts that told AI to review as though it was a kernel developer who preferred vi over emacs.

— Chris Mason

Comments (none posted)

Jackson: Debian’s git transition

Ian Jackson (along with Sean Whitton) has posted a manifesto and status update to the effect that, since Git repositories have become the preferred method to distribute source, that is how Debian should be distributing its source packages.

Everyone who interacts with Debian source code should be able to do so entirely in git.

That means, more specifically:

1. All examination and edits to the source should be performed via normal git operations.
2. Source code should be transferred and exchanged as git data, not tarballs. git should be the canonical form everywhere.
3. Upstream git histories should be re-published, traceably, as part of formal git releases published by Debian.
4. No-one should have to learn about Debian Source Packages, which are bizarre, and have been obsoleted by modern version control.

This is very ambitious, but we have come a long way!

Comments (105 posted)

Loong64 is now an official Debian architecture

John Paul Adrian Glaubitz has announced that loong64 is now an official architecture for Debian, and will be part of the Debian 14 ("forky") release "if everything goes along as planned". This is a bit more than two years after the initial bootstrap of the architecture.

So far, we have manually built and imported an initial set of 112 packages with the help of the packages in Debian Ports. This was enough to create an initial chroot and set up the first buildd which is now churning through the build queue. Over night, the currently single buildd instance already built and uploaded 300 new packages.

Comments (7 posted)

Elementary OS 8.1 released

Version 8.1 of elementary OS has been released. Notable changes in this release include making the Wayland session the default, changes to window management and multitasking, as well as a number of accessibility improvements. The 8.1 release is the first to be made available for Arm64 devices, which should allow users to run elementary on Apple M-series hardware or other Arm devices that can load UEFI-supporting firmware, such as some Raspberry Pi models. See the blog post for a full list of changes.

Comments (1 posted)

FreeBSD laptop progress

The FreeBSD Foundation has a blog post about the progress it has made in 2025 on the Laptop Support & Usability Project for FreeBSD. The foundation committed $750,000 to the project in 2025 and has made progress on graphics drivers, Wi-Fi 4 and 5 support, audio improvements, sleep states, and more.

The installer for FreeBSD has gained a couple of new features that benefit laptop users. In 15.0 the installer now supports downloading and installing firmware packages after the FreeBSD base system installation is complete. Coming in 15.1 it will be possible to install the KDE graphical desktop environment during the installation process. Grateful thanks to Bjoern Zeeb and Alfonso Siciliano respectively. [...]

The project continues into 2026 with a similar sized investment and scope. Key targets include completing work on sleep states (modern standby and hibernate), adding support for graphics drivers up to Linux 6.18, Wi-Fi 6 support, USB4 and Thunderbolt support, HDMI improvements, UVC webcam support, and Bluetooth improvements.

A substantial testing program will also start in January, aiming to test all the functionality together across a range of hardware. Community testers are very welcome to help out, the Foundation will release a blog post and send an invite to help to the Desktop mailing list some time in January 2026.

Comments (4 posted)

Qubes OS 4.3.0 released

Version 4.3.0 of the security-oriented Qubes OS distribution has been released. Changes include more recent distribution templates, preloaded disposable virtual machines, and the reintroduction of the Qubes Windows Tools set. See the release notes for more information.

Full Story (comments: none)

GDB 17.1 released

Version 17.1 of the GDB debugger is out. Changes include shadow-stack support, info threads improvements, a number of Python API improvements, and more, including: "Warnings and error messages now start with an emoji (warning sign, or cross mark) if supported by the host charset. Configurable." See the NEWS file for more information.

Full Story (comments: none)

Incus 6.20 released

Version 6.20 of the Incus container and virtual-machine management system has been released. Notable changes in this release include a new standalone command to add IncusOS servers to a cluster, qcow2-formatted volumes for clustered LVM, and reverse DNS records in OVN. See the announcement for a full list of changes.

Comments (none posted)

Systemd v259 released

Systemd v259 has been released. Notable changes include a new "--empower" option for run0 that provides elevated privileges to a user without switching to root, ability to propagate a user's home directory into a VM with systemd-vmspawn, and more. Support for System V service scripts has been deprecated, and will be removed in v260. See the release notes for other changes, feature removals, and deprecated features.

Comments (none posted)

Development quote of the week

LibreOffice these days is sufficiently compatible with Microsoft Office documents that I can exchange edited change-tracked books with >3000 tracked changes and several hundred comments with my production editor without them blinking. (DOCX is an output format as far as Scrivener is concerned; it's an input format as far as publishing is concerned: the real work gets done in Adobe InDesign, which I'm not touching with a barge-pole.)

— Charlie Stross

Comments (none posted)