41–50 of 54 posts
This isn't actually right, is it? APX hasn't been released, to my knowledge.
Earlier 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 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.
I'm still kind of surprised that Linus ended up allowing Rust into the kernel. Good, but surprising. Looking forward to this release once it hits NixOS Unstable.
Earlier 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.
True, but the Rust language itself is tiny compared to C++. There are only a slim fraction of the edge cases to learn. 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.
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?
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 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.
Seems like Linus should be able to tap someone else to do 6.17 while he is on vacation
Earlier 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…
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.
> 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…
A 20 MB 3.5 minute .flac file takes ~200 ms to decode into a 35 MB .wav on my desktop, so in principle the program could spend a small fraction of a second placing the decoded audio into a small buffer and give a pointer to hardware to keep playing it while the rest of the system goes to sleep for a few minutes. Or if the hardware has direct support for the codec, it could just give it the file as-is.
Earlier quoted context omitted.
True, but the Rust language itself is tiny compared to C++. There are only a slim fraction of the edge cases to learn. 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.
C++ was also tiny 40 years ago, just give it 40 years as well with the current six months release cadence.
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.