I haven't had time to experiment with it yet. How is agent directed development doing with Rust 0-to-1 an 1-inf. product gen?
Rust in the kernel is no longer experimental
681–690 of 853 posts
Re: Rust in the kernel is no longer experimental
#682Earlier quoted context omitted.
That is why most of the world has not been using c/c++ for decades.
I'm not on the Rust bandwagon, but statements like this make absolutely no sense. A lot of software was written in C and C++ because they were the only option for decades. If you couldn't afford garbage collection and needed direct control of the hardware there wasn't much of a choice. Had their been "safer" alternatives, it's possible those would have been used instead. It's only been in the last few years we've see…
you took the ragebait bro :))
Re: Rust in the kernel is no longer experimental
#683Earlier quoted context omitted.
The “Ouch.” was in reference to being compared to Phoronix. Has anyone found them to be inaccurate, or fluffy to the point it degraded the content? I haven’t - but then again, probably predominantly reading the best posts being shared on aggregators.
I don't know about the "ouch" but the rest of the comment seems pretty clear that they didn't intend to imply the clickbait.
That’s correct!
That’s why I was chatting about the “Ouch.”
because it was the only part of the comment that didn’t make sense to me in isolation,
so I opened the context, what he was replying to.
Re: Rust in the kernel is no longer experimental
#684Earlier quoted context omitted.
Why? It depends on what you want to replace, but the Rust project has a long history of using tools written in other languages. Python is used a lot in build tooling, bors-ng was written in Elixir, llvm is written in c, ... gcc-rs doesn't contain a lot of rust code either, it's purely other languages according to https://github.com/Rust-GCC/gccrs Fundamentally, if a tool is good and provides benefits then why not use…
It doesn't detract from your main point, but LLVM is written in C++, not C.
Thanks for the correction.
Re: Rust in the kernel is no longer experimental
#685Earlier quoted context omitted.
One perspective is that Rust appears to be forced into the Linux kernel through harassment and pressure. Instead of Rust being pulled, carefully, organically and friendly, and while taking good care of any significant objections. Objections like, getting the relevant features from unstable Rust into stable Rust, or getting a second compiler like gccrs (Linux kernel uses gcc for C) fully up and running, or ensuring th…
Personally, I observe that Rust is forced everywhere in the Linux ecosystem. One of my biggest concerns is uutils, mostly because of the permissive license it bears. The Linux kernel and immediate userspace shall be GPL licensed to protect the OS in my opinion. I have a personal principle of not using LLVM-based languages (equal parts I don't like how LLVM people behave against GCC and I support free software first a…
Wait till you see the vulnerabilities introduced... Makes you wonder how organic it really is
Re: Rust in the kernel is no longer experimental
#686Earlier quoted context omitted.
That's not the case. It's using Rust as a selling point. All the noise around using Rust is marketing. The fact that you think linux machines are enjoyed by only a specific group of people makes me happier with my choice
> That's not the case. It's using Rust as a selling point "Rust as a selling point" was a big thing in 2018-2022ish. You see it a lot less of the "written in Rust" in HN headlines these days. Some people were very excited about Rust early on. What feels more common today are people who unnecessarily hate Rust because they saw too much of this hype and they (justifiably) got annoyed by it. If there is a new, optional…
No worries I didn't take offenses. I just disagree. The title should've been we reduced bugs in the kernel and here is some proof of that. The 2018-2022-ish hype (I call it bullying campaign) is still strong. Google recently did a blog post about Rust speeding up their development, in the age of LLMs, seriously! I can't stop lol'ing at that
Re: Rust in the kernel is no longer experimental
#687Earlier quoted context omitted.
> both NixOS and Arch enable the QR code kernel panic screen Interesting, I use both (NixOS on servers, Arch for desktop) and never seen that. Seems you're referring to this: https://rust-for-linux.com/drm-panic-qr-code-generator (which looks like this: https://github.com/kdj0c/panic_report/issues/1 ) Too bad NixOS and Arch is so stable I can't remember the last time any full system straight up panicked.
Yep, that's what I'm referring to. For now there aren't many popular drivers that use Rust, but there are currently 3 in-development GPU drivers that use it, and I suspect that when those get merged that'll be the real point of no return: - Asahi Linux's driver for Apple GPUs - https://rust-for-linux.com/apple-agx-gpu-driver - The Nova GPU driver for NVIDIA GPUs - https://rust-for-linux.com/nova-gpu-driver - The Tyr…
I can confirm that the ChromeOS debian container now has defaulted to turn off GPU acceleration, perhaps to turn on other acceleration on this Mali.
Re: Rust in the kernel is no longer experimental
#688Earlier quoted context omitted.
It's an optional tool that can be used to implement drivers now, not forced. If you don't like the idea of another language being supported for implementing a subset of kernel modules, I don't think you wouldn't enjoyed having a Linux machine anyways.
That's not the case. It's using Rust as a selling point. All the noise around using Rust is marketing. The fact that you think linux machines are enjoyed by only a specific group of people makes me happier with my choice
> It's using Rust as a selling point.
That's just not true. Neither Linus Torvalds, nor the Linux Foundation, nor any major distro, nor anyone else who could conceivably be considered responsible for "marketing" Linux is saying you should use it because a small part of it is written in Rust.
I just went to ubuntu.com and the word "rust" does not appear anywhere on the front page. So what are you talking about?
Re: Rust in the kernel is no longer experimental
#689Earlier quoted context omitted.
literally from the quote: unsafe{} doesn't actually disable all or even most of Rust’s safety checks (a common misconception).
They also say The practice of encapsulation enables local reasoning about safety invariants. which is not fully correct. Undefined behavior in unsafe blocks can and will leak into the safe Rust code so there is nothing there about the "local reasoning" or "encapsulation" or "safety invariants". This whole blog always read to me as too much like a marketing material disguised with some data so that it is not so obviou…
> which is not fully correct. Undefined behavior in unsafe blocks can and will leak into the safe Rust code so there is nothing there about the "local reasoning" or "encapsulation" or "safety invariants".
Strictly speaking, that encapsulation enables local reasoning about safety invariants does not necessarily imply that encapsulation guarantees local reasoning about safety invariants. It's always possible to write something unadvisable, and no language is capable of preventing that.
That being said, I think you might be missing the point to some extent. The idea behind the sentence is not to say that the consequences of a mistake will not be felt elsewhere. The idea is that when reasoning about whether you're upholding invariants and/or investivating something that went wrong, the amount of code you need to look at is bounded such that you can ignore everything outside those bounds; i.e., you can look at some set of code in complete isolation. In the most conservative/general case that boundary would be the module boundary, but it's not uncommon to be able to shrink those boundaries to the function body, or potentially even further.
This general concept here isn't really new. Rust just applied it in a relatively new context.
Re: Rust in the kernel is no longer experimental
#690Earlier quoted context omitted.
> Is it something that can be fixed with editions? My guess is no, or at least not easily. Assuming I'm reading these blog posts [0, 1] correctly, it seems that the size_of:: () == size_of:: () assumption is changeable across editions. Or at the very least, if that change (or a similarly workable one) isn't possible, both blog posts do a pretty good job of pointedly not saying so. [0]: https://faultlore.com/blah/fix-…
Great info! Personally, I like 3.1.2 from your link [0] best, which involves getting rid of pointer integer casts entirely, and just adding methods to pointers, like addr and with_addr. This needs no new types and no new syntax, though it does make pointer arithmetic a little more cumbersome. However, it also makes it much clearer that pointers have provenance. I think the answer to "can this be solved with editions"…
> Personally, I like 3.1.2 from your link [0] best, which involves getting rid of pointer integer casts entirely, and just adding methods to pointers, like addr and with_addr. This needs no new types and no new syntax, though it does make pointer arithmetic a little more cumbersome. However, it also makes it much clearer that pointers have provenance.
Provenance-related work seems to be progressing at a decent pace, with some provenance-related APIs stabilized in Rust 1.84 [0, 1].
[0]: https://blog.rust-lang.org/2025/01/09/Rust-1.84.0/
[1]: https://doc.rust-lang.org/std/ptr/index.html#provenance