The article mentions Linux pull requests. Does Linux contribution do actual pull requests now? Or is it still a mailing list? If the latter, why would they say pull request?
Its a terrible article.
Linux 6.16: faster file systems, improved confidential memory, more Rust support
31–40 of 54 posts
Re: Linux 6.16: faster file systems, improved confidential memory, more Rust support
#32The article mentions Linux pull requests. Does Linux contribution do actual pull requests now? Or is it still a mailing list? If the latter, why would they say pull request?
It's subsystem maintainers asking Linus to pull from their branches, e.g. https://lkml.org/lkml/2025/7/29/291
Re: Linux 6.16: faster file systems, improved confidential memory, more Rust support
#33The article mentions Linux pull requests. Does Linux contribution do actual pull requests now? Or is it still a mailing list? If the latter, why would they say pull request?
Pull requests took their name from the git request-pull script (which actually predates Github by a couple years): https://github.com/git/git/commit/ab421d2c7886341c246544bc8d...
It is called a pull request because you are asking someone to do a `git pull` from your branch.
Re: Linux 6.16: faster file systems, improved confidential memory, more Rust support
#34The article mentions Linux pull requests. Does Linux contribution do actual pull requests now? Or is it still a mailing list? If the latter, why would they say pull request?
"Pull requests" can also be done via a mailing list (it's literally a request to pull from some URL, see git-request-pull). It is not common on LKML, but I've seen it used that way. I think it's mostly maintainers that use it among themselves, everyone else just mails patches.
Re: Linux 6.16: faster file systems, improved confidential memory, more Rust support
#35Earlier quoted context omitted.
I just remember how much shit he talked about C++, and I guess I assumed that that would carry over to Rust as well.
From my memory of Linus's C++ comments, they basically boil down to "the kernel needs to do everything in freestanding mode, and everything that's interesting in C++ is not in freestanding mode, so what good is it?" (plus some ranting about "zero-cost" exception handling being rather more expensive than its name implies). In general, a strong vibe of someone who tried C++ in the early 90s, gave up on it then, and is…
That's also in line with my memory of it.
We still don't have all of the interesting C++ features in freestanding mode. It's still a fairly unknown component of libc++ and libstdc++. I've only been playing with it recently because I was curious about how many of the c++17 and newer compile time features I could get to work in avr-g++.
And the answer is ... not much.
I've been spoiled by Rust's "core" crate.
Re: Linux 6.16: faster file systems, improved confidential memory, more Rust support
#36Neat to see zero-copy networking get TX, after RX shipped a while ago. Good stuff. I wonder how it overlaps-with/interacts with the various kernel offloads? I forget if this is TCP only or UDP too: would be really nice with QUIC / HTTP3 to see more love for UDP. https://www.phoronix.com/news/Device-Memory-TCP-TX-Linux-6.1...
The filesystem Folio work has been yielding such amazing results. In general I'm just so impressed how much the storage subsystems keep improving! IO_Uring has totally changed the game in terms of iops delivered just on it's own. But then the various filesystems & upper level multi-queue support have also been consistently finding really nice wins. Folios have been incredible! https://lwn.net/Articles/1015320/
EROFS added compressed metadata support, which is showing a 2.5X win for readdir(3) (reading files from a directory). Given it's use in awesome works like composefs for next-gen & content-addressed based container overlay type systems, this is a nice win. https://github.com/composefs/composefs
Probably my favorite new feature is AMDGPU user queue (userq) work. Rather than the driver having to build out all the future work, now userspace can directly build the work of stuff to be done, sprinkling in various fences and what not. Some very interesting potential for GPGPU & perhaps ML! https://www.phoronix.com/news/Mesa-25.2-High-Priority-USERQ https://www.phoronix.com/news/Linux-6.16-AMDGPU-User-Queues
The Kernel Newbies release log is one of my favorite things to read through. It wasn't bursting-at-the-seams with awesome as you sometimes get with releases, but 6.16 was still very fun. https://news.ycombinator.com/item?id=44717122 https://kernelnewbies.org/Linux_6.16
Re: Linux 6.16: faster file systems, improved confidential memory, more Rust support
#37> Perhaps the most popular Linux file system, Ext4, is also getting many improvements. These boosts include faster commit paths, large folio support, and atomic multi-fsblock writes for bigalloc filesystems. What these improvements mean, if you're not a file-system nerd, is that we should see speedups of up to 37% for sequential I/O workloads.
nice to see ext4 still getting improvements
Re: Linux 6.16: faster file systems, improved confidential memory, more Rust support
#38> If your Linux laptop doubles as a music player, another nice new feature is that you can now stream your audio over USB even while the rest of your system is asleep. That capability's been available in Android for a while, but now it's part of mainline Linux. How does that work? You still need some program to actually play the music (mpv, Sotify, whatnot)? Or what am I misunderstanding? Unfortunately there are no d…
It probably requires active standby/s0ix. Modern Intel chips actually don't officially support s3 at all anymore, only s0ix.
The whole point is to support stuff like this
Re: Linux 6.16: faster file systems, improved confidential memory, more Rust support
#39> If your Linux laptop doubles as a music player, another nice new feature is that you can now stream your audio over USB even while the rest of your system is asleep. That capability's been available in Android for a while, but now it's part of mainline Linux. I thought Android did that by just turning off all but one CPU core and suspend all processes not required for streaming + bluetooth? I really can't imagine h…
On modern Intel systems sleep works the same as on android. You don't just ask the chipset for s3 anymore.
I wouldn't be surprised if one core stayed awake.
This is why tiger lake laptops had crummy battery life on Linux upon release (often on windows too). Without working s0ix they just never suspend, and old style s3 isn't really officially supported.
Re: Linux 6.16: faster file systems, improved confidential memory, more Rust support
#40Earlier quoted context omitted.
Why does the kernel need a QR code generator?
A QR code can capture 3k of data, you can capture a lot of context and details in that, particularly if you apply a little bit of compression (and the kernel has compression algorithms embedded in it). More than can be captured on a screen normally, without it zooming out of sight.
An 80x25 ascii display carries 2000 characters which isn't shabby. But yeah, a lot harder to photograph.