Collin Richards has announced version 0.0.1 of tmux-rs, a port of the tmux terminal multiplexer to Rust.

For the [past] 6 months or so I've been quietly porting tmux from C to Rust. I've recently reached a big milestone: the code base is now 100% (unsafe) Rust. I'd like to share the process of porting the original codebase from ~67,000 lines of C code to ~81,000 lines of Rust (excluding comments and empty lines). You might be asking: why did you rewrite tmux in Rust? And yeah, I don't really have a good reason. It's a hobby project. Like gardening, but with more segfaults.

Richards says that the next goal for the project is to convert it to safe Rust. It is currently "not very difficult to get it to crash", but he wanted to share the project with other Rust fans now. The project is available on GitHub.

• Front: Kernel features from Python; i686 in Fedora; Kernel development with LLMs; Rust drivers; Load balancing with machine learning; Transparent huge pages.
• Briefs: Bcachefs removal; Coccinelle for Rust; Netdev Foundation; Oracle Linux 10; GNU HHIS 5.0; Rust 1.88.0; Quotes; ...
• Announcements: Newsletters, conferences, security updates, patches, and more.

Debian's Bananas team has put out a call for people with Apple M1 or M2 systems to help test Debian on those machines:

The Bananas Team has set up an installer at with images for GNOME, KDE and console installations. While we'd like to build an actual Debian installer sooner or later (we may need a heads-up from the Debian Images team for that), at this time we only provide an asahi-type installer, which installs both the "bootloader" and the OS partitions to disk from the network (as opposed to only installing the bootloader and then letting you install Debian using a d-i USB stick). We haven't forked Trixie from Testing yet, so what you'll get is Debian Testing quite deep into the freeze.

The initial motivation was to move the NIPA testing outside of Meta, so that more people can help and contribute. But there should be sufficient budget to sponsor more projects.

(NIPA is Netdev Infrastructure for Patch Automation).

Today, GPLv3 turns exactly 18 years old. This month, GPLv2 turned 34 years old. These are both great licenses and we love them. Nevertheless, at least once in a generation, FOSS needs a new approach to strong copyleft.

Transparent huge pages (THPs) are, theoretically, supposed to allow processes to benefit from larger page sizes without changes to their code. This does work, but the performance impacts from THPs are not always a benefit, so system administrators with specific knowledge of their workloads may want the ability to fine-tune THPs to the application. On May 15, Usama Arif shared a patch set that would add a prctl() option for setting THP defaults for a process; that patch set has sparked discussion about whether such a setting is a good fit for prctl(), and what alternative designs may work instead.

All these 15 years can be roughly divided into three stages. For the first five years, we built the very basic functionality—offline maps and navigation that just worked. Over the next five years, we transformed OsmAnd into a full-fledged application with plugins, extensive settings, and professional tools. We dedicated the third five-year period to deep internal work: completely rewriting and improving key components like the rendering engine and routing algorithms.

Now, a new, fourth stage begins. We have reached functional maturity, and our main goal for the near future is to polish what we've already built. We will focus on stability, speed, and consolidation. User expectations are growing, and what was once considered normal must now be flawless.

(Thanks to Paul Wise).

A change proposal to end support for 32-bit x86 (i686) applications on the x86_64 architecture with the Fedora 44 release has been withdrawn after significant pushback. As proposed, the change could have had a significant impact on gamers, compiler development, and the Bazzite project, which uses Fedora as a base for a gaming-focused distribution. While i686 gets a reprieve for now, the question still lingers: who is going to keep the necessary i686 packages in working order when few upstream maintainers or volunteer packagers care about the architecture?

In 2023, Fujita Tomonori wrote a Rust version of the existing driver for the Asix AX88796B embedded Ethernet controller. At slightly more than 100 lines, it's about as simple as a driver can be, and therefore is a useful touchstone for the differences between writing Rust and C in the kernel. Looking at the Rust syntax, types, and APIs used by the driver and contrasting them with the C version will help illustrate those differences.

The history of the bcachefs filesystem in the kernel has been turbulent, most recently with Linus Torvalds refusing a pull request for the 6.16-rc3 release. Torvalds has now pulled the code in question, but also said:

I think we'll be parting ways in the 6.17 merge window.

You made it very clear that I can't even question any bug-fixes and I should just pull anything and everything.

Honestly, at that point, I don't really feel comfortable being involved at all, and the only thing we both seemed to really fundamentally agree on in that discussion was "we're done".

Bcachefs developer Kent Overstreet has his own view of the situation. Both Torvalds and Overstreet refer to a seemingly private conversation where the pull request (and other topics) were discussed.

Kernel versions 6.15.4, 6.12.35, 6.6.95, 6.1.142, 5.15.186, 5.10.239, and 5.4.295 have all been released.