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 details in the article, and an interwebz search doesn't really show anything.
So I think that it doesn't do anything for the average Linux laptop, and is mostly intended for certain (mobile) hardware?
[1]: https://www.phoronix.com/news/Linux-6.16-USB-Audio-Offload
https://www.phoronix.com/news/Linux-6.16-QCOM-USB-Audio-OLOA...
Audio usb offloading. Only supported on Qualcomm soc's.
Article is misleading. Audio offloading is probably only useful to avoid waking the main CPU too often, so better battery management... CPU can remain sleeping a few microseconds longer, not all the time.
Not something many will benefit.
The whole point is to support stuff like this
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 how else that would work, other than essentially giving the whole audio file to the Bluetooth chip and let it handle streaming on its own... but I've never heard of a Bluetooth chipset capable of that, much less bluez actually being usable enough.
I'm sure there are aspects that are hard to reason about which I'm simply unaware of, but the idea makes sense to me.
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.
If the latter, why would they say pull request?
It is called a pull request because you are asking someone to do a `git pull` from your branch.
The analogy to GitHub-like "pull requests" in the kernel workflow is "git send-email" (or "b4 send" nowadays) which sends patch series as individual emails that can be reviewed inline as a plain-text email and are applied onto maintainers' trees (usually with something akin to "git cherry-pick"). I still find this system to be a superior method to GitHub's "pull requests" (you can send review comments to commit descriptions -- which I believe Gerrit supports, but GitHub definitely doesn't -- and everything is sanely threaded since it's all email).
Here's an example pull request email from the start of the week[1], containing some VFS changes to be included in 6.17-rc1.
[1]: https://lore.kernel.org/all/20250725-vfs-misc-599b4aef8eaa@b...
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
nice to see ext4 still getting improvements
This isn't actually right, is it? APX hasn't been released, to my knowledge.
tombert•6mo ago
Looking forward to this release once it hits NixOS Unstable.
xeonmc•6mo ago
Alupis•6mo ago
Still interesting indeed.
preisschild•6mo ago
dralley•6mo ago
lights0123•6mo ago
jeffbee•6mo ago
lights0123•6mo ago
infogulch•6mo ago
Twirrim•6mo ago
jeffbee•6mo ago
6SixTy•6mo ago
geodel•6mo ago
dralley•6mo ago
From what I can tell, he views Rust for Linux as a social project as much as a technical one - attract new (and younger) developers into the kernel, which has become pretty "senior", force all of the "unwritten rules" to be written down, and break down some of the knowledge siloing and fiefdom behavior that has taken place over the years (by sharing it specifically with that younger group of developers).
If you think about it, Rust for Linux is in some ways essentially an auditing committee reviewing all of the API interactions between kernel subsystems and forcing them to be properly defined and documented. Even if the Rust part were to fail (exceedingly unlikely at this point), it's a useful endeavour in those other respects.
But of course, if Rust is successful at encoding all of those rules using the type system, that unlocks a lot of value in the kernel too. Most of the kernel code is in drivers, and it's typically written by less experienced kernel developers while being harder to review by maintainers that don't have background on or access to the hardware. So if you can get drivers written in Rust with APIs that are harder to misuse, that takes a big load off the maintainers.
tombert•6mo ago
kstrauser•6mo ago
Note that I'm not saying Rust is easy to learn. I found it to be so, but it's going to be different for everyone. I do firmly believe that it's far easier for the average dev to learn the core of Rust than the core of C++, with far fewer footguns along that path.
tombert•6mo ago
pjmlp•6mo ago
davidhyde•6mo ago
https://doc.rust-lang.org/edition-guide/editions/index.html
Rust has a 6 week release cycle and a big complaint is that the language isn’t changing quickly enough so there is pushback from both ends to take into account here. My take is that there are only hard problems still to be solved given that that they need to be solved in a zero cost way.
jcranmer•6mo ago
If Linus's first introduction to C++ was to C++11, I'd imagine his opinion of C++ would be higher (probably not high enough to permit it into the kernel, though). To a large degree, Rust is "take the good new parts of C++11, strip out some of the legacy insanity, and let's also work out how to keep as much of the good stuff in a freestanding environment as possible." Which answers a lot of the objections that Linus had to C++!
Teknoman117•6mo ago
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.
pjmlp•6mo ago
That is why contrary to Linus opinion, Symbian, IBM z and IBM i, Windows (since Vista), GenodeOS, and OS X, have C++ running on their kernels even if it isn't the full blown language.
Additionally many of his criticism against C++, applies equally well to Rust, in terms of language complexity, just wait until some kernel driver go crazy with macros or FP inspired designs.
What is indeed a plus for Rust is the secure code mentality that both C and C++ communities have kept downplaying until companies and government had enough with burning money fixing exploits.
xorcist•6mo ago
Which is funny, because you can see the truth to it. With C++ comes endless debates. No technical reason really, but a social one, and so far the Rust culture seems to be closer to C in that regard.
hetman•6mo ago
knowitnone2•6mo ago