The Linux Foundation Technical Advisory Board (TAB) has decided to "restrict Kent Overstreet's participation in the kernel development process during the Linux 6.13 kernel development cycle" based on a recommendation from the Code of Conduct committee. In particular, the scope of the restriction will be to "decline all pull requests from Kent Overstreet" during the development cycle. Overstreet is the creator and maintainer of the bcachefs filesystem.

This action stems from a message Overstreet posted back in early September that was abusive toward another kernel developer; there is a fair amount of back-and-forth about the incident and the committee's attempts to extract a public apology from Overstreet in that thread. Overstreet has published a lengthy blog post describing his side of the story.

The Linux kernel community's discussions about including Rust have gotten a lot of attention, but the kernel is not the only project wrestling with the question of whether to allow Rust. The Git project discussed the prospect in January, and then again at the Git Contributor's Summit in September. Complicating the discussion is the Git project's lack of a policy on platform support, and the fact that it does already have tools written in other languages. While the project has not committed to using or avoiding Rust, it seems like only a matter of time until maintainers will have to make a decision.

The 6.12.1, 6.11.10, 6.6.63, and 6.1.119 stable kernel updates have been released. As always, they contain important fixes.

CHICKEN Scheme, a portable Scheme compiler, is gearing up for its next major release. Maintainer Felix Winkelmann has shared an article about what changes to expect in version 6 of the language, including better Unicode support and support for the R7RS (small) Scheme standard.

Every major release is a chance of fixing long-standing problems with the codebase and address bad design decisions. CHICKEN is now nearly 25 years old and we had many major overhauls of the system. Sometimes these caused a lot of pain, but still we always try to improve things and hopefully make it more enjoyable and practical for our users. There are places in the code that are messy, too complex, or that require cleanup or rewrite, always sitting there waiting to be addressed. On the other hand CHICKEN has been relatively stable compared to many other language implementations and has a priceless community of users that help us improving it. Our users never stop reminding us of what could be better, where the shortcomings are, where things are hard to use or inefficient.

Since the very beginnings, the FreeCAD community had a clear view of what 1.0 represented for us. What we wanted in it. FreeCAD matured over the years, and that list narrowed down to just two major remaining pieces: fixing the toponaming problem, and having a built-in assembly module.

Well, I'm very proud to say those two issues are now solved.

The most common piece of advice given to users who ask about running their own mail server is don't. Setting up and securing a mail server in 2024 is not for the faint of heart, nor for anyone without copious spare time. Spammers want to flood inboxes with ads for questionable supplements, attackers want to abuse servers to send spam (or worse), and getting the big providers to accept mail from small servers is a constant uphill battle. Michael W. Lucas, however, encourages users to thumb their nose at the "Email Empire", and declare email independence. His self-published book, Run Your Own Mail Server, provides a manual (and manifesto) for users who are interested in the challenge.

Headline features in this release include: support for the Arm permission overlay extension, better compile-time control over which Spectre mitigations to employ, the last pieces of realtime preemption support, the realtime deadline server mechanism, more EEVDF scheduler development, the extensible scheduler class, the device memory TCP work, use of static calls in the security-module subsystem, the integrity policy enforcement security module, the ability to handle devices with a block size larger than the system page size in the XFS filesystem, and more. See the LWN merge-window summaries (part 1, part 2) and the KernelNewbies 6.12 page for more details.