It really does seem like there's some old-guard who are utterly determined to now allow this to happen. That's not to say that Rust is inevitable in the kernel, but they're refusing to even allow the attempt. The amount of bad-faith argumentation happening is really discouraging about the state of Linux development.
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!
>It really does seem like there's some old-guard who are utterly determined to now allow this to happen.
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.
Anybody can write a good kernel for one single computer (not just CPU) in a couple years. What makes linux useful is the vast amount of different hardware combinations it supports, often with "black magic" because some hardware doesn't work unless you do something weird (commonly you have to wait some amount of time after the power comes on before using it). One computer is easy, adding support for a second that is even slightly different is more work. Linux works correctly on millions of combinations by now (most of those combinations have not been tested but they would work)
Linux is like 27 million lines of code. The core is several million.
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.
> The amount of bad-faith argumentation happening is really discouraging about the state of Linux development.
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.
I think the nature of the problem is the other way around. This is not harming the long-term viability of Linux. It is harming the long-term viability of Rust. As a systems programming language, the promise of which was using it to write secure kernel and system code, not being accepted into a mainstream OS kernel on either technical or political merit is a death sentence.
Both perspectives need to be tested against each other, carefully.
> One can just infer lifetime by reading the code.
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.
Have you actually looked at Linux device model code? Or filesystem code? Or most other code? Most is poorly documented. Most is overcomplicated. Quite a bit is flat-out wrong.
Sure you can, particularly in simple cases. However some code needs years to understand because something seemingly unrelated happening elsewhere changes things. The kernel often has to run on several different CPUs at the same time, and shouldn't sync the CPU caches if it is possible to avoid it.
> 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.
Learning a 2nd programming language isn't a big deal. Learning 2000 is a big deal. All projects should thus carefully limit what languages they allow so that people working in them don't have to learn too many. However you should also be learning new languages once in a while just for personal growth reasons.
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.
Well, the infosec industry itself is an existential threat to sane, responsive software for power users without the cult of safetyism, so it is potentially still a net win.
If your program eats all computer resources given specific inputs, is this a DoS vulnerability, simply a bug or even expected behaviour? It depends.
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.
Practice this transition :) -> :| Maybe throw in a sigh or a smirk or something. Know that no matter what the reason for or against a change is, you should be able to find a reason why it improves or harms security
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.
First develop some level of loathing and disgust at the state of all software. Let this fuel your desire to break it. Then learn to build it securely. Then market yourself as a security engineer. PROFIT!
As someone who has been doing "software" for about 30 years now, I completely agree with this. The only people I know who are good at what they do, do it because they use the hatred and disgust of the state of things as fuel for the fire. Optimism and anything similarly airy-fairy doesn't burn as well.
To be fair, I have been in offensive security and security engineering for like 18 years now. I genuinely have an optimistic outlook. But some days the rage wins and I hack/build in anger lol. I tame it. It is fleeting. The mission matters more to me in the long run. And security engineering as practiced in many big tech style firms genuinely matters and makes a holistic difference for users and everyone. It isn’t perfect, but it is way better than 18 years ago.
I personally have complaints about bringing rust into the Linux kernel (not a maintainer or contributor so my opinion matters very little), however making changes to the kernel to make it safer or more robust should always be welcome.
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.
I've very casually followed this process (lwn articles, read a few emails) and honestly I feel like this was predictable, the problem is the maintenance cost this places on the maintainers. The kernel is developed as one whole thing, the internal C APIs get changed and those changes are applied to all the code contained in the codebase. If there's Rust code calling those APIs then it needs to be fixed as well and they don't know how to do that.
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.
> the problem is the maintenance cost this places on the maintainers. ... If there's Rust code calling those APIs then it needs to be fixed as well and they don't know how to do that.
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.
> This is not the case. The C folks are allowed to break the Rust. The Rust folks are committed to fixing it.
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.
> What happens to that code if those maintaining the bindings/wrappers suddenly get a new job, or get tired of doing the work?
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.
> 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.
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.
All I can say is, take it up with Linus. I think "let's see if this even works before we hash out policy" is a far more reasonable approach than "let's argue over every last bit of this before we see if it's even feasible." Others are free to disagree, of course, but that doesn't really change that this is the plan.
No one can deny that kernel devs have a valid complain and concerns. Of course Rust and Linux can work together and is feasible, on paper, and everybody wants to see it in the mainline someday.
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?
I'd guess compile time would be a complaint, since Rust generally takes a lot longer to compile than equivalent C. Safety is one thing, but it isn't the be-all and end-all of kernel development; feature development is also important, and reducing productivity impacts that.
Rust is a significantly more productive language than C. It's not even a comparison.
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.
I think we need to consider the perspective of the linux maintainers.
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.)
> 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.
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.
> Nobody is asking them to do that. They are being asked to review C patches to enable Rust-in-Linux.
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.
They are repeating this as if it’s true when it’s been explained that it is not. The Rust for Linux people have committed to picking it up. They don’t even have to wait for them to do that work before merging, though they did ask if they could get a heads up email so the turnaround time would be faster.
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.
From what I've understood about Rust, they'll be bogged down in a verbose language, and may never reach feature parity. Their only hope of getting Rust into a mainstream kernel is probably to take over an existing project.
That sounds feasible. I just wrote my first Rust program (search for Ruststrike in this thread) and wow it's stupid verbose and not particularly safe if put in my hands. I can see while there is determinism and fewer footguns, it painful on a C++ level to write.
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.
Nah, an IDE was already a hell of a drug for the first levels of formalism in paradigms.. The most formal language is going to end up with a lot of transpiled code made in a combat between AI and features like a borrow checker, then once their eyes stop bleeding, the most stubborn will make it marginally better than any less formal language can achieve, then others will be able to work with just eye drops.
> Momentum is a bitch. It's why Windows still exists.
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.
As a casual Rust user, I feel it’s a bit ridiculous to think something could outdo Linux only by choice of programming language. Is that the “nontechnical nonsense” here?
> 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.
I agree on the desire for less drama, but being as OSS has lots of support from people that have made it their passion, I'd expect less drama would mean less caring about the project. Having companies support OSS project more could help, but would also need to be balanced by what is "best" for the project, which could just push drama more towards being monetarily driven. I just hope that this doesn't become an issue that causes a fracture big enough to split the community.
I was considering writing a microkernel OS in Zig that transpiles to Rust and targets WebAssembly on a RISC-V CPU. That would be ultimate security. No one would be able to peel off all the layers!
For me, this discussion won't lead anywhere because it covers the wrong topic.
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.
https://news.ycombinator.com/item?id=41387924
https://news.ycombinator.com/item?id=41423146
https://news.ycombinator.com/item?id=41424608
https://news.ycombinator.com/item?id=41431856
https://news.ycombinator.com/item?id=41438402
https://news.ycombinator.com/item?id=41443306