“The latest version of the Linux kernel adds an array of improvements,” writes the blog OMG Ubuntu, ” including a new memory sealing system call, a speed boost for AES-XTS encryption on Intel and AMD CPUs, and expanding Rust language support within the kernel to RISC-V.”
Plus, like in all kernel releases, there’s a glut of groundwork to offer “initial support” for upcoming CPUs, GPUs, NPUs, Wi-Fi, and other hardware (that most of us don’t use yet, but require Linux support to be in place for when devices that use them filter out)…

Linux 6.10 adds (after much gnashing) the mseal() system call to prevent changes being made to portions of the virtual address space. For now, this will mainly benefit Google Chrome, which plans to use it to harden its sandboxing. Work is underway by kernel contributors to allow other apps to benefit, though. A similarly initially-controversial change merged is a new memory-allocation profiling subsystem. This helps developers fine-tune memory usage and more readily identify memory leaks. An explainer from LWN summarizes it well.

Elsewhere, Linux 6.10 offers encrypted interactions with trusted platform modules (TPM) in order to “make the kernel’s use of the TPM reasonably robust in the face of external snooping and packet alteration attacks”. The documentation for this feature explains: “for every in-kernel operation we use null primary salted HMAC to protect the integrity [and] we use parameter encryption to protect key sealing and parameter decryption to protect key unsealing and random number generation.” Sticking with security, the Linux kernel’s Landlock security module can now apply policies to ioctl() calls (Input/Output Control), restricting potential misuse and improving overall system security.

On the networking side there’s significant performance improvements to zero-copy send operations using io_uring, and the newly-added ability to “bundle” multiple buffers for send and receive operations also offers an uptick in performance…

A couple of months ago Canonical announced Ubuntu support for the RISC-V Milk-V Mars single-board computer. Linux 6.10 mainlines support for the Milk-V Mars, which will make that effort a lot more viable (especially with the Ubuntu 24.10 kernel likely to be v6.10 or newer). Others RISC-V improvements abound in Linux 6.10, including support for the Rust language, boot image compression in BZ2, LZ4, LZMA, LZO, and Zstandard (instead of only Gzip); and newer AMD GPUs thanks to kernel-mode FPU support in RISC-V.

Phoronix has their own rundown of Linux 6.10, plus a list of some of the highlights, which includes:

The initial DRM Panic infrastructure
The new Panthor DRM driver for newer Arm Mali graphics
Better AMD ROCm/AMDKFD support for “small” Ryzen APUs and new additions for AMD Zen 5.
AMD GPU display support on RISC-V hardware thanks to RISC-V kernel mode FPU
More Intel Xe2 graphics preparations
Better IO_uring zero-copy performance
Faster AES-XTS disk/file encryption with modern Intel and AMD CPUs
Continued online repair work for XFS
Steam Deck IMU support
TPM bus encryption and integrity protection

Read more of this story at Slashdot.

“6.9 is now out,” Linus Torvalds posted on the Linux kernel mailing list, “and last week has looked quite stable (and the whole release has felt pretty normal).”

Phoronix writes that Linux 6.9 “has a number of exciting features and improvements for those habitually updating to the newest version.” And Slashdot reader prisoninmate shared this report from 9to5Linux:

Highlights of Linux kernel 6.9 include Rust support on AArch64 (ARM64) architectures, support for the Intel FRED (Flexible Return and Event Delivery) mechanism for improved low-level event delivery, support for AMD SNP (Secure Nested Paging) guests, and a new dm-vdo (virtual data optimizer) target in device mapper for inline deduplication, compression, zero-block elimination, and thin provisioning.

Linux kernel 6.9 also supports the Named Address Spaces feature in GCC (GNU Compiler Collection) that allows the compiler to better optimize per-CPU data access, adds initial support for FUSE passthrough to allow the kernel to serve files from a user-space FUSE server directly, adds support for the Energy Model to be updated dynamically at run time, and introduces a new LPA2 mode for ARM 64-bit processors…

Linux kernel 6.9 will be a short-lived branch supported for only a couple of months. It will be succeeded by Linux kernel 6.10, whose merge window has now been officially opened by Linus Torvalds. Linux kernel 6.10 is expected to be released in mid or late September 2024.

“Rust language has been updated to version 1.76.0 in Linux 6.9,” according to the article. And Linus Torvalds shared one more details on the Linux kernel mailing list.

“I now have a more powerful arm64 machine (thanks to Ampere), so the last week I’ve been doing almost as many arm64 builds as I have x86-64, and that should obviously continue during the upcoming merge window too.”

Read more of this story at Slashdot.

Liliputing.com has an update about the System76 Meerkat, which they describe as “a compact desktop computer with support for up to 64GB of RAM, up to two storage devices (for as much as 16TB of total storage), and up to an Intel Core i7 mobile processor. It’s basically a rebranded Intel NUC.” (Escept that System76 offers a choice of Pop!_OS or Ubuntu Linux pre-installed.)

“Previously available with a choice of 10th or 11th-gen Intel Core processor options, the Meerkat now also supports 12th-gen Intel chips.”

That means there are a total of 9 different processor options available. Prices start at $499 for an entry-level model with a Core i3-10110U processor, 8GB of RAM and a 128GB SSD. The prices rises by $50 if you want to go with a Core i3-1135G4 model, while prices start at $599 for a Meerkat mini PC with a 12th-gen Intel Core processor….

But the biggest difference is that Intel’s 12th-gen processors introduce a hybrid architecture that pairs Performance and Efficiency cores, leading to much higher core counts for better multi-core performance.

Read more of this story at Slashdot.

Linux kernel boss Linus Torvalds has released the first release candidate for version 6.1 of the project and added an appeal for developers to make his life easier by adding code earlier in the development cycle. The Register reports: “Let me just say that after I got my machine sorted out and caught up with the merge window, I was somewhat frustrated with various late pull requests. I’ve mentioned this before, but it’s _really_ quite annoying to get quite a few pull requests in the last few days of the merge window.”

He then offered further guidance on how kernel devs can do it right. “Yes, the merge window is two weeks, but that’s very much to allow me time to look things over, not ‘two weeks to hurriedly put together a branch that you send Linus on Friday of the second week’,” he wrote. “The whole ‘do an all-nighter to get the paper in the day before the deadline’ is something that should have gone out the window after high school. Not for kernel development.” His next line was: “You know who you are.”

“Anyway, it’s not the first time I’ve said this, I doubt it will be the last. But maybe more people could take it to heart, ok?” he added, before concluding his post with a slightly non-traditional call for testers to visit Linux’s git tree because “The merge window may not be the biggest ever, but it’s certainly big enough that the shortlog is much too big to post, and below is just my usual merge log.” “For all the gory details, please refer to the git tree.”

Read more of this story at Slashdot.

slack_justyb writes: As previously indicated on Slashdot, Rust was slated to be coming to the Linux Kernel sometime in the 6.x version. Well wonder no longer on which version of kernel 6.x will have the first bits of Rust officially in the kernel, as Linus has confirmed that 6.1 will be the first with the new NVMe kernel drivers being in Rust. The first version non-production ready code for the NVMe Rust based kernel drivers were already producing performance comparable to C code. So the final drivers to hit 6.1 are already looking promising. It also helped Rust’s case that, thanks to the ground-breaking work of Linux kernel and Rust developer Miguel Ojeda, Rust on Linux has gotten much more mature. Kernel maintainers were convinced it is time to move forward with Rust in Linux. In short, they agreed that Rust on Linux was ready for work.

Read more of this story at Slashdot.

Microsoft software engineer Stephen Hemminger has proposed removing the DECnet protocol handling code from the Linux kernel. The Register reports: The timing is ironic, as this comes just two weeks after VMS Software Inc announced that OpenVMS 9.2 was really ready this time… That announcement, of course, came some months after the first time it announced [PDF] version 9.2 […]. The last maintainer of the DECnet code was Red Hat’s Christine Caulfield, who flagged the code as orphaned in 2010. The change is unlikely to vastly inconvenience many people: VMS is the last even slightly mainstream OS that used DECnet, and VMS has supported TCP/IP for a long time. Indeed, for decades, the oldest email in this reporter’s “sent” folder was a 1993 enquiry about the freeware CMUIP stack for VMS.

One of the easier ways to bootstrap VMS on an elderly VAX these days is to install it on the SimH VAX hardware simulator, and then net-boot the real VAX from the simulated one. Anyone keen enough to do that will be competent to run an older version of Linux just for the purpose. Although their existence is rapidly being forgotten today, TCP/IP is not the only network protocol around, and as late as the mid-1990s it wasn’t even the dominant one. The Linux kernel used to support multiple network protocols, but they are disappearing fast. […] For a long time, DECnet was a significant network protocol. DEC supplied a client stack called PathWorks to let DOS, Windows and Mac clients connect to VAX servers, not only for file and print, but also terminal connections and X.11. Whole worldwide WANs ran over DECnet, and as a teenage student, your correspondent enjoyed exploring them.

Read more of this story at Slashdot.

ZDNet writes that in late 2020 Red Hat decided “they’d no longer release CentOS Linux as a standalone distribution. Instead, CentOS Stream would work as a beta for RHEL.”
So where are we now?
The competition immediately sprang up to replace CentOS. The two most important of these are the AlmaLinux OS Foundation’s AlmaLinux and Rocky Enterprise Software Foundation’s Rocky Linux. [May 16th saw the release of Rocky Linux 8.6.] Now, mere weeks after the release of RHEL 9, AlmaLinux 9 has arrived.

Like RHEL itself, AlmaLinux 9 starts from CentOS Stream via RHEL. Indeed, AlmaLinux developers are CentOS Stream contributors. The bottom line is that CentOS 9 is an identical twin to RHEL 9 — except for the names and trademarks. It has all the same features, all the same advances, and, for better or worse, all the same bugs.

Besides the big server architectures, AlmaLinux is also ready to run on everything from cloud and Docker images to Microsoft’s Windows Subsystem for Linux and Raspberry Pi, the article points out.

And Jack Aboutboul, AlmaLinux’s Community Manager, tells ZDNet “We are building AlmaLinux with the specific goal of creating an independent CentOS successor that is truly community-centric and designed for everyone… We offer everyone a uniform platform that is safe, secure, easy to use, and dependable to build your tomorrow on.”

Read more of this story at Slashdot.

Liliputing reports:
When Valve’s Steam Deck begins shipping to customers later this month, the handheld gaming PC will be running a Linux-based operating system called Steam OS. And that could give gaming on Linux a bit of a boost.

While Valve’s game client has been able to run on Linux for years, as of last month just over 1% of Steam users were running Linux (and fewer than 3% were using macOS, with Windows holding a 96% share). It’ll be interesting to see if that starts to change once the Steam Deck hits the streets. And if it does, maybe we’ll see more game makers add support for Linux… but one of the most popular games around isn’t going to add Linux support anytime soon: Epic CEO Tim Sweeney says the company has no plans to port Fortnite to Linux.

He says it’s because Epic doesn’t “have confidence that we’d be able to combat cheating at scale under a wide array of kernel configurations including custom ones,” but it’s an interesting take since Epic has already ported its anti-cheat software to support Mac and Linux devices including the Steam Deck.

Read more of this story at Slashdot.

Slashdot reader sombragris writes: Slackware, the oldest actively maintained Linux distribution, released version 15.0 yesterday after a long release cycle that goes all the way back to 2016 where the last version (14.2) was released. According to the release notes, the whole spirit of this release is: “Keep it familiar, but make it modern.”
Among the news, this release offers kernel 5.15.19, PAM, PipeWire and PulseAudio, Wayland and X11 graphical systems, and Rust and Python 3. As graphical environments, both Xfce 4.16 and the latest Plasma 5 (Plasma 5.23.5, Frameworks 5.90, KDE apps 21.12 running under Qt 5.15.3) are available, with Cinnamon and Mate also available from third parties. The main compilers are gcc-11.2 and llvm 13.0. The default browser is Firefox 91.5esr, with Chromium available as a third-party repository. And… no systemd at all.

Slackware can be downloaded from a variety of mirrors. BitTorrent downloads are going to be available too. I’ve used Slackware for 20 years and it’s always impressed me with its stability and speed. I encourage everyone interested to try it. Slashdot readers arfonrg and saxa also shared the news.

Read more of this story at Slashdot.

Earlier this year TechRepublic argued that while 2021 wasn’t the year of the Linux desktop, “there was no denying the continued dominance of Linux in the enterprise space and the very slow (and subtle) growth of Linux on the desktop. And in just about every space (minus the smartphone arena), Linux made some serious gains.”

So would 2022 be the year of the Linux desktop? “Probably not.”

But developer Tim Wells honestly believes we’re getting closer:

The idea of the year of the Linux desktop is that there would come a year that the free and open source operating system would reach a stage that the average user could install and use it on their pc without running into problems. Linus Sebastian from Linus Tech Tips recently did an experiment where he installed Linux on his home PC for one month to see if he could use it not only for everyday tasks, but for gaming and also streaming. Ultimately he concluded (in a video just released) that this year will not be the year of the Linux desktop and that while doing everyday stuff was reasonably okay, the state of gaming on Linux (despite Valves lofty goals) is to put it simply, a shit-show. (That’s my word, not his)… The experiment done by Linus seems to show that while some games do indeed run well using [Valve’s Windows compatibility layer] Proton, there are just as many that run with issues. Some of those issues can be game breaking. Such as the game running, but its multiplayer functionality not working at all. Some games just plain don’t work at all due to dependencies on services such as Easy Anti Cheat…

In his video Linus mentions that the main problem preventing the “year of the Linux desktop” is the fragmentation. By fragmentation, he means the range of available distributions and the fact that each distribution has (potentially) different versions of libraries and drivers and software that makes the behind the scenes operate…. Flatpak and Snap as well as AppImage are making progress towards fixing this fragmentation issue, but those are not yet perfect either. Flatpak works by ensuring that the expected versions of libraries required for that software are installed along side it and independent of the existing library the distro may provide…

Valve have said that the Steamdeck will also use an immutable core operating system for the same reasons.

So while Linus is sure that 2022 isn’t yet the year of the Linux desktop and that fragmentation is the biggest problem. I think maybe, just maybe, we’re closer to solving those problems and closer perhaps to the year of the Linux desktop that some might realise.

Read more of this story at Slashdot.