Rust in Linux lead retires rather than deal with more "nontechnical nonsense"
arstechnica.com
arstechnica.com
In addition, the changes needed on the C side for RiL are needed anyways! Lifetimes aren't just a Rust thing, it just makes them forefront. You still need to keep track of them in C, and so they need to be documented since the language sure isn't going to help you. Refusing to document them isn't just harming Rust in Linux, it's harming the long-term viability of Linux in general. When the current maintainers quit, who's going to be able to untangle all that? Bug fixes still need to happen if they're only discovered because someone tried to formalize your interface!
unices and then into the linux project have been a massively successful series of massive C library/API/threading/timing/bittwiddling coordination efforts.
some people now want to turn that Ship of Theseus into catamaran, while it's sailing? Rust people could probably more easily just use the Linux sources and rewrite it into a new better system, clean effort.
Coordinating people is time consuming and difficult, and this "project" clearly makes that issue a lot worse in the interim phases. Seems downright Bayesian, if you know what I mean.
I think efforts like gVisor and other sandboxing technologies are the future. gVisor and friends like it can minimize the attack surface of unsafe code down to some minimum.
Rust in Linux as an experiment should go on. Core functionality can likely be re-implemented in Rust and continue to get some meaningful % of the critical path of code safer, but there will always be some level of "unsafe" code in an operating system kernel.
"Rust people" are annoying because they largely want their stuff upstreamed, and they want it NOW. If you have any form of doubt they'll call you names and mark your word as nonsense. It's just obnoxious.
It's okay to want changes, and I think Rust in Linux is a great thing, but you can't expect people to just drop off everything and give you all the attention you want in the exact specific way you want it, and to give all that attention TODAY.
Otherwise just go ahead, fork Linux and do your thing... If it's any good Linux will pull and merge the changes.
I don't think most of it is bad-faith argumentation so much as a failure to assume good faith. This is mostly conjecture on my part (I've only read a small percentage of the LKML and Mastodon threads about this stuff), but I think the idea is pretty straightforward:
Rust trains developers to think about lifetimes, locks, race conditions etc. in pretty specific ways, learn the language of borrow checker errors, and so on. People who haven't written a lot of both Rust and C simply won't have the particular mindset and skill set to look at any given "Rust problem" and understand how it could map to a shortcoming in the C code it's wrapping. So when a Rust developer is trying to wrap a C API and discovers an issue, I think the C-only developer taking the report/patch is primed to see not an indication of a legitimate bug, but rather an attempt to force C code to conform to Rust semantics, for the sake of simplifying the Rust developer's job. The Rust developer tries to explain, but this comes across as an irrelevant appeal to some obscure theoretical concern. At this point, further objections are obviously just the Rust developer being lazy, stubborn, doctrinaire, and otherwise not cut out for kernel development. Something like this probably only needs to happen a handful of times to mutate into a fairly durable meme of "Jesus fucking Christ, these Rust evangelists are exhausting. What the fuck is wrong with them?".
From my position as an observer, Rust proponents need to deal with their own zealots before they can get annoyed with Linux kernel old-guard for being stubborn.
Both perspectives need to be tested against each other, carefully.
(That said, having it encoded in the type system makes it many times easier)
For trivial cases sure, for complex ones though this is akin to saying "you can know if there's any bugs by reading the code" which we all know is not true for any reasonable time investment put into reading the code.
Enormously load-bearing "just" there. And if there's a subtle lifetime bug ... ?
> A new scientific truth does not triumph by convincing its opponents and making them see the light, but rather because its opponents eventually die and a new generation grows up that is familiar with it
It's interesting to hear the complaint is "you can't make me learn another language" from someone like Ted Tso. Learning your 2nd language is very hard but at some point it becomes routine, especially since a good chunk of these languages are all Algol-based in some sense. And the main "new" thing is different concepts like functional ways to write programs and various other ergonomic improvements. But really those things just make your code clearer.
If you write code in a memory unsafe language reading about Rust's borrow checker should be very interesting to you. You might conclude it isn't compelling on its own, but you should be very interested and at least thinking about how you can solve the problem in your current code (which might be adopting Rust, might be some other language, or might be change to your current language). If you don't admit that Rust solves a difficult problem I have no discussion for you - but you can say that the downsides to rust are not worth it.
Edit: just in case anyone took this too seriously, it was facetious.
Edit: I don't even know Rust but I wrote a prototype:
fn main() {
const LOL: *mut u64 = 1 as *mut u64;
unsafe {
std::ptr::write(LOL, 0);
}
}
The safest software is the one that does nothing.
Is Spectre a vulnerability? Even that depends on what code you run and on which machine.
The reason your salary is going up is because there is no sensible access control management and sensible threat model for software. Can we know in which circumstances some software (or CPU) will be used? Can we assume who the users are? No, we can't because there are billions of computers out there and, thus, billions of different use-cases. And we all have to suffer from slower execution because someone wants to expose access to their machine through a multi-tenant single-process cloud environment or whatnot.
But jokes aside its mostly about realising that when you consider all aspects of computing its such a wide, deep field that no one, no matter how much of a "power user" they think they are, will ever do things perfectly, and mistakes add up over time until one day Validimir Hackowski is running bitcoin miners in your AWS account. Then you find one aspect or more of computing and investigate the infosec fields that help find those bugs/mistakes and fix them. I like websec and linux/windows config security, myself, all of which is in high demand.
I'm curious if this is a case of only getting a single side of the story or not though. I've heard a lot from the rust side, but nothing from the c side of the issue (obviously response is pending.) I'm going to wait on forming an opinion on the limited information currently available.
Obviously you can argue over whether the need to maintain the Rust code would end up improving the C code as a result, but ultimately Linus isn't pushing hard for this to happen. Those who want Rust in the kernel need to convince those who will end up maintaining the Rust code why it's worth having, and I don't think that step has been successful.
This is not the case. The C folks are allowed to break the Rust. The Rust folks are committed to fixing it. The existing maintainers do not have any extra work to do, unless you view the Rust folks saying "hey an email when you break stuff would be nice so we can fix it quickly" is extra work.
I mean sorry but that's just not realistic. What happens to that code if those maintaining the bindings/wrappers suddenly get a new job, or get tired of doing the work? It's nice (in some ways) that they've offered to maintain the Rust bindings, but it's always the maintainer's code at the end of the day.
End users don't care if an FS driver is written in C or Rust, they do care if it doesn't work in a release. It's the maintainer's problem because if they break a Rust module and nobody is around to fix it they either fix it themselves or revert their changes, those are the only two options. That's basically the one hard rule Linus has - no breaking userspace.
This is the case for everything in the kernel, by accepting a module or new driver the subsystem maintainer is committing to updating it as the internal APIs change, that's why there's no stable API. They're not going to be happy to allow modules and parts of their subsystem to be written in Rust just because others are promising to keep it updated, there needs to be a plan for how the maintainers can do it themselves and convince them to be willing to own it. IMO that's the only path forward.
> unless you view the Rust folks saying "hey an email when you break stuff would be nice so we can fix it quickly" is extra work.
What happens if they come back and say "that's too much work for us to fix in time for the next release"? I'll reiterate again that stuff being broken in a release is not acceptable, it doesn't matter _why_ it is broken.
Then the experiment will have failed, and Rust would get removed. Again, this is about a trial to see how things go. If it’s decided to be made permanent, we’ll see what the policy ends up being. But that’s a discussion for then, not now.
> That's basically the one hard rule Linus has - no breaking userspace.
File systems are not user space. That’s why they’re allowed to be changed to break consumers in the first place.
> What happens if they come back and say "that's too much work for us to fix in time for the next release"?
It is currently an experiment, and so it would end up broken for that release. That’s why it’s not considered to be more than an experiment for now.
This plan is Linus approved, so it seems these tradeoffs are acceptable.
Not discussing it now is a fatal mistake, it's the whole game. When people are told "we'll discussion ownership at a later time" all they're hearing is "this is going to be my problem in the future, so I better express the issues I see now before it becomes more widely used".
But again there's really no discussion to be had on "policy" because it's already known, there's no world where the Rust bindings can simply be left broken if it's used for anything semi-important.
> File systems are not user space. That’s why they’re allowed to be changed to break consumers in the first place.
I think you misunderstood me? I'm saying that a filesystem driver being missing from a release breaks userspace stuff that relies on that filesystem being supported. IE. a user can't access their files because the driver is not there. Linus doesn't allow changes to the kernel that breaks something like that, the reason it broken is irrelevant. It won't matter if the reason is "nobody updated the Rust bindings", that's your problem because you made the code change that broke them.
> It is currently an experiment, and so it would end up broken for that release. That’s why it’s not considered to be more than an experiment for now.
"There's nothing more permanent than a temporary solution". Again that's simply not a realistic view. As soon as it gets used for something the idea of not maintaining it gets significantly more complicated.
But in reality working for and with the kernel is more than just writing code. And being realistic, you wouldn't base months worth of work on the hands and the will of some coder that may or may not have your interests in mind that week. Would you?
Proof: Asahi Lina wrote an entire driver for a modern GPU, with zero reported runtime crashes, and explicitly stated this would have been impossible in C.
Learning and mastering a new language and applying it to an existing code base is quite a lot of work. That takes a lot of time away from other things they might be working on.
I think these are mostly (overwhelmingly?) volunteers, so you can't just assign them work. You need to convince them to want to do the work. Doing this shouldn't be dismissed as nontechnical nonsense... it's a very significant hurdle, and one that's directly on the critical path.
BTW, naming and shaming and internet pitchforks are guaranteed to make people not want to do the work, so unless you actually want to kill rust-in-linux, you might want to shut that down.
(Also, I wonder if there isn't a better way to bring memory-safety to the linux kernel. One that is just as effective as rust but less disruptive. The hostile us-vs-them dynamic building up around RiL might torpedo the whole thing, so it might be worth looking for effective alternatives.)
Nobody is asking them to do that. They are being asked to review C patches to enable Rust-in-Linux.
> I think these are mostly (overwhelmingly?) volunteers, so you can't just assign them work
The vast majority are professionals. A few work for the Linux Foundation, many work full time on Linux inside of big corps. For example, Ted T'so works for Google.
My understanding of their issue is that this can't really be true. Any C code that affects Rust bindings in any way (which will be more and more as long as the integration grows) will become impossible to change without either knowing Rust or hoping/waiting for someone else to pick up that part.
That’s good to know. But I guess the money is coming from a bunch of different companies/management structures, so you probably still can’t just tell everyone what to do.
> Nobody is asking them to do that.
Perhaps not now, but I don’t think anyone thinks or claims the ambition for rust in linux is for rust to stay on the fringes and out of the way (otherwise, why even bother?). The more rust there is in the kernel, the more likely it is a linux dev will either need to master rust or make way for someone who will.
That's how this ends.
And I'm fine with that. May the best solution win.
I think just having less in the kernel and moving bits out (like Mach) into isolated domains is probably better than reinventing the universe for some purity argument.
Windows is already shipping Rust in the kernel, with more to come. They're moving faster on this than Linux is, even with all of that historical baggage.
Remember managed C++?
Maybe that's a project people could pile into. Though as a Google project, it's unlikely to have the open community spirit that Linux has.
Predictably, the Rust people play the victims while they are the ones who are asking something from all other kernel developers.
Yeah I mean I don't see how you don't hear this person talking and not think they are disdainful and dismissive.
In other news, Redox continues to improve and an amazing pace. May the best kernel win.
> Ralloc – memory allocator
> RedoxFS (file system) – inspired by the ZFS file system
It doesn't seem necessary to write either one of these if you just want a Rust kernel.
For one thing, secure malloc replacements are not very useful because the main customer that needs them, web browsers, will ignore yours because it's "too slow" and continue using their own. (Also, unless you're testing on an MTE/CHERI system your assumptions about what makes one secure are probably incorrect.)
The point of this work isn't "just a kernel in Rust." The point is to help the millions/billions/zillions of Linux deployments get better. A different kernel is a different goal.
Rust for Linux had great potential, and would have been a cool alternative to the existing C driven model.
At least eBPF has diverse corporate sponsorship, so drama is somewhat tempered.
Would be great if more companies pitched in to help the FOSS ecosystem, otherwise the only option is an Open Core model.
It's not about Rust or C - it's about transparency. The existing maintainers assume that it is not a priority for them whether they break something downstream or not. They therefore work in a space with interfaces that they can change as they see fit, without giving any guarantees as to their continued existence or wanting to subordinate themselves to a defined change process.
Rust is just a symptom of growing pains. Growth would be achieved if they could agree on common rules which would foster independent development linked by the interface contracts.
Instead, the issue is that established maintainers have grown fond of their zoo and are only pursuing their own priorities in a landlord-like manner. On the other hand, they see new technologies appearing and disappearing on the horizon and have consequently realized that a new technology or language cannot improve an existing system.
And yet they are classically talking past each other.