I don't see why it's so important to rewrite parts of the kernel in rust, or why Drew is so sympathetic to the cause. The linux project uses static analysis tools which provide some of what rust guarantees (outside of unsafe).
The language isn't the problem, it's the architecture. In Linux, all of the drivers run with the rest of the kernel. A bad driver can take down the whole thing, or perform arbitrary badness.
In Drew's own Helios microkernel, the architecture is right, and it's ready to have folks start piling on drivers in user-space. Those drivers can be written in pretty much any low level language that can produce ELF binaries.
It's surely a better path forward to slap a Linux syscall API on top of Helios + some new drivers than to clone the whole linux system architecture in another programming language. At least then, we would have gained something tangible (drivers can't ruin the kernel). Instead of having another Linux written in a different language, with all the same design flaws.
> I don't see why it's so important to rewrite parts of the kernel in rust, or why Drew is so sympathetic to the cause. The linux project uses static analysis tools which provide some of what rust guarantees (outside of unsafe).
It’s important because static analysis tools get nowhere near the coverage of a memory safe language.
Static analysis can find bugs but it cannot prove their absence. A memory safe type system proves absence. Rust’s type system proves absence module uses of unsafe, which is still much better than what any C static analysis could do.
(I am saying this as a Rust hater who’s trying to obviate the need for it.)
> The language isn't the problem, it's the architecture. In Linux, all of the drivers run with the rest of the kernel. A bad driver can take down the whole thing, or perform arbitrary badness.
This is a case of “why not both”.
Sure, you can harden an OS by compartmentalizing. And you can also harden using memory safety. As time goes on, folks will do both. The fact that you could (and should) do one of these things is not an argument to not do the other.
> I don't see why it's so important to rewrite parts of the kernel in rust,
It'd be nice to be able to say, "We're pretty sure these source code files don't contain any null pointer dereferences, array out-of-bounds errors, use-after-free errors, double frees, or (if the kernel rust project fully embraces the Rust way of doing concurrency, I'm not familiar with the technical details) race conditions, because otherwise it wouldn't have compiled." When absolutely necessary, unsafe code blocks can provide a back door around some of these checks, but as long as the unsafe code blocks are relatively small, it's a much smaller surface area for these kinds of bugs to show up.
Not to mention the type system is in some ways much more user friendly. Proper algebraic types are easier than trying to cobble something ad-hoc together with tagged unions.
> or why Drew is so sympathetic to the cause.
He's not, he's suggesting in the most polite and diplomatic way possible that he thinks they should stop what they're doing, and do something else instead that kernel maintainers don't have to deal with.
I think this is a mischaracterization. If you read the original post[1] it's clear he's not at all sympathetic to the cause, though given recent news he is more sympathetic to the people who have the cause (even if he thinks it's misguided).
How is he sympathetic to the cause? He isn’t. The original article gave the project a thumbs down and so does this one… only this time he is here to admit defeat on behalf of the project because of “burnout”.
All the praise is just nerdstroking to soften the kernel of the argument that they are working on the wrong thing.
I am sympathetic to the cause. I respect the Linux project as a whole forming a consensus on the right direction for the kernel and I respect the right of the Rust developers to participate in the consensus-making process and advocate for what they believe is the right direction -- and put in the work to get there. I can hold this view and disagree with their opinion at the same time. I celebrate the difficult technical and political work they're doing to advance their cause, and I respect the hell out of that -- the fact that I would make different choices doesn't contradict this in any way.
The fact of the matter is that politics was always going to be difficult, and for all of the respect and admiration I have for the Rust-for-Linux team -- which I do have, thank you -- I am equally sympathetic to the kernel hackers who didn't ask for this project on their doorstep, and for their own needs to be accommodated. I condemn the toxicity that has bubbled up in this process, from C hackers and Rust hackers alike, but even absent that toxicity I think that the political challenges of Rust-for-Linux are enormous and distract from the fundamental work of the project.
People have burnt out and quit the project, and you cannot erase their experience when it questions the viability of the project. I'm offering them compassion and a different path that might celebrate their work without leading to burnout. People having burnt out and quitting the project is a historical fact, and not my fault, even if I'm the easy polemic for you to pin the blame on. I think it'd be a fucking shame if they quit pursing their passions for OS development in Rust over it and I've said as much and that's more than I can say for you and everyone else filling my messages with personal attacks and bad faith reading of everything I have to say.
gtm strategy trumps nerdy perfectionism. Linux is successful because of its timing and probably accidental social engineering - regularly breaking out-of-tree drivers incentivized upstreaming hardware support. Doesn't matter how good an alternative would be on technical merits, there's too much momentum behind Linux.
Except maybe a fork where oxidation proceeds much faster, sponsored by a large corporation with bespoke hardware they can develop for and interest in security. Cloud OS-es or Android maybe.
> Here’s the pitch: a motivated group of talented Rust OS developers could build a Linux-compatible kernel, from scratch, very quickly, with no need to engage in LKML politics.
The BSDs, Solaris/Illumos, and Windows all have tried, some more than once even. I think there have been at least 4 Linux kernel ABI compatibility layers for those OSes. They've all failed. And all future attempts will fail too for the same reason:
The Linux kernel ABI is not
specified anywhere, and it's
insanely large (and growing).
Besides the system calls (easy), many ioctls (hmmm), proc(4) (oof), and many ioctl-like ABIs within ABIs, there's loads of driver-specific ABIs and things like security modules and what not that add their own ABIs and which you'll invariably end up having to support. The last effort in Illumos land foundered on proc(4), IIRC.
To top it all off that undefined (but stable) ABI is a moving target: it's always evolving / getting extended.
The only thing you have to help you is that whatever the ABI, Linux [mostly] commits to maintaining backwards compatibility with it. If your compatibility ever gets good enough, that will help you, but in the meantime you'll be chasing a never ending and ever growing ill-defined ABI.
No, just download the source and check. It's 14M C/C++ and 4M in Rust. There is another 3.3M in Go and 1.1 in Dart. This is a usual trope that Rust is just about to replace C++ but in fact more and more gets written in C++.
I think the real reason is very few developers are interested in that and because virtualisation solve most users issues related to not being able to run software X on BSD and most open source software are relatively easy to port to these OS if there is interest.
You do not become a BSD or illumos developer because you are interested in replicating Linux.
I am split on this. Maybe I am idealistic and naive, but I will always wish people can just stop fighting, and work together. Fragmenting the community and starting a project out of grudge, is always the last resort, IMO.
OTOH, I also recognize sometimes it is really that bad and going your own way is the best thing to do. But I think Linux isn't at that position yet.
Replacing C with Rust within the kernel is not going to be peaceful. It's been made clear by now that most Linux developers, including those most prominent, prefer C and do not wish to invest any time or effort accommodating Rust developers.
>but I will always wish people can just stop fighting, and work together.
Two separate ideas are conflated here.
It would make me happy if they stopped fighting, and instead worked separately on their C and Rust kernels respectively.
All the Rust kernel developers have to know C. Is that true of the bigger maintainers who are arguing against it?
It’s fine to prefer one over the other.
If you haven’t learned one and refuse to try it and your argument boils down to “it’s not what we’ve done and I don’t want to change” that’s not good technical decision making.
How many times has this succeeded for fundamental work? I can think of a couple, including Xorg and GCC. I don't know if those cases can be characterized as "grudges" exactly but, in each instance, someone was unsatisfied with the prevailing conditions, forked the work, and then subsumed the legacy.
Doubtless there have been far more failures than successes. I also know that computing probabilities based on such ratios is simple minded: other factors exist and the equation is non-linear.
> But I think Linux isn't at that position yet.
I was disturbed by the irrational behavior I saw in this talk[1]. What the presenter sought was reasonable: communicate the intended semantics so Rust kernel developers can track the evolution. This was somehow understood as: forego C and become a Rust programmer, take responsibility for our work and maintain it going forward.
No, I do not believe the former implies the latter. There are endless silos, both formal and informal, for both good reasons and bad reasons, permeating all intellectual work, whether "open" or not. It is entirely reasonable to imagine that this pattern can be employed among reasonable people for the matter at hand, especially for something like file systems, where even parallel implementations can and do exist simultaneously.
If this behavior is prevalent enough then drastic steps are justified. Whether they're feasible or not is another matter, and also a many factored, non-linear calculation. One could, for instance, reimplement only some fraction of the kernel and be entirely sufficient for most of the backend cloud server Linux use case. Given the enthusiasm for Rust among major cloud operators, I suspect this might be attempted at some point.
> Here’s the pitch: a motivated group of talented Rust OS developers could build a Linux-compatible kernel, from scratch, very quickly, with no need to engage in LKML politics.
Rust is many things, but devoid of political drama it is not.
I also disagree with his take that the Kernel could be replicated in Rust by 6 motivated volunteers in 4 or 5 years. That could be said of many projects, you could probably reproduce AAA entertainment software with such a team in such a span of time, but the trick is getting these people to stay on track, fed, and satisfied for that time. Who's going to pay for their rent/mortgages? Are they just not going to work for the duration?
It's naive grandstanding in the best of cases, and malicious proselytizing in the worst.
You are misrepresenting the original article. Drew did not say six volunteers or 4 or 5 years. Those are your numbers, so feel free to agree to disagree with yourself.
A Linux kernel clone is the epitome of a large Rust community project (for many reasons, some noble, some not so noble). It would likely pull in hundreds if not thousands of developers in an arms race assuming the end goal is well defined.
Nobody claims it's a small task, but I believe it can probably be accomplished. Particularily in the scope of the original claim "applied to a new Linux-compatible OS we could have something production ready for some use-cases within a few years."
How do the current Rust/Linux maintainers pay their rent?
Also your estimate for AAA game development is massively optimistic, AAA team sizes are in the hundreds today (not a good thing for quality and innovation, but that's how it is).
Someone in a sub-thread accused Drew of being incurious, and reading the article, I kind of agree.
It's a very polite, high-effort, superficially humble piece of writing, that nevertheless boils down to "You guys should probably leave us alone and work on stuff we don't need to worry about".
Now, working on a Linux fork as a "proof of value" thing could be interesting, but it also means that this hypothetical Linust project would be stuck forever chasing Linux's API decisions without any power to influence them (and, if recent history is any indication, quite a lot of hostility from OG Linux maintainers).
I can't help but notice that Drew's plan doesn't include any exit strategy, any point where the projects merge or Linux starts taking components from Linust or something.
Maybe Drew thinks that forever being stuck between shadowing a concurrent project's API and trying to convince its billion users to switch to yours instead is an attractive prospect. If I was a Rust-on-Linux developer, I'd find that patronizing.
This is all predicated on the assumption that forks and clones are a bad thing, when they're actually a good thing? Why does a clone require an 'exit strategy'? Does Linux have an exit strategy for merging back into Unix? When is Unix getting merged back into Multics, for that matter?
If Rustnux is safer and more performant in the ways that Rust advocates believe it will be, Rustnux will gain traction and demonstrate the potential benefits of Rust in the kernel itself. This is intrinsically beneficial, and I'm unsure how convincing a billion people to switch has anything to do with it. (Also, bizarre metric, does every purcharser-of-an-IoT-thermostat get their choice of OS kernels?)
For those who don't want to work on "shadowing" an API (quick, someone tell the Wine crowd they're 'stuck' and should stop), Redox already exists. He's not saying to shut it down. For a bunch of people accusing Drew of being incurious, these some some aggressively 'in the box' takes.
> This is all predicated on the assumption that forks and clones are a bad thing
No, they are just different things. Linux is what people use. It would be nice to be able to write drivers in Rust for the system people use. It's a very practical desire to want to use Rust and Linux to build real systems, right now, instead of having to choose one or the other.
Just seems pragmatic to me. The people contributing rust to Linux are having a bad time so the advice is to do something else. It sucks I guess but it's no different than any other open source project.
"Fine I'll do it myself" is a story basically as old as time.
- Walt Disney
- Ferruccio Lamborghini
- King Henry VIII
- Juan Pujol Garcia
I doubt Drew has the power to serious change the culture among Linux kernal contributors and maintainers, so he's just offering advice.
The elephant in the room, which is Linux's untenable complexity and lack of internal APIs (even for drivers), is not addressed.
Doing anything on Linux is many times as hard as doing it on systems that put a strong emphasis on structure. This is true not just for microkernel, multiserver systems, but for other unices/unix-like such as the BSDs (which put far more emphasis on structure relative to Linux) as well.
Thus, I agree entirely with Drew, with extra reasons, that we (developers in general, not specific to rust) should try and put some effort elsewhere than Linux.
It doesn't have to be Linux. It isn't the end-all in operating systems. It's just what happens to be most popular -right now-.
There's an attempt at heading off the driver commentary with a note at the bottom. The note makes some hand-wavy thing which is essentially "assuming you have an army of people with specifications, this won't be a problem", but that assumption is crazy. Fuchsia is a real OS effort funded by Google (at varying levels of funding through it's lifecycle, which is still ongoing AIUI) - I worked on Fuchsia for a number of years, from approximately the time the kernel had become usable, through to launching on nest hubs where it replaced the existing OS from bootloader to GUI. Drivers remain a huge problem for Fuchsia despite funding. SOC vendors don't provide docs or assistance, even for serious efforts, they demand money first - they're literally holding the software world hostage with this activity.
After leaving Fuchsia and reflecting on the whole thing, I really believe that despite the many problems Linux may have over the long term, the only viable strategies for a broadly and practically usable safer OSS system are either: someone donates at least $2bn to get it done in a PBC well managed and focused over a decade, or you slowly mutate Linux into that thing. Anything drastically different is, for now, dependent on the world being a different shape / people & companies having different attitudes than they do. I'd love to see something like Redox prove me wrong, but real world experience suggests that's extremely unlikely. RISCv is the one thing in flight that might "change the shape of the world" enough to alter this, but RISCv comes with it's own stack of long challenges to overcome to meet the originally stated goal of broadly and practically usable.
Writing a core kernel and usable userspace isn't something to be trivialized, but by cost and work volume, getting a broad set of drivers is far far more effort by an astronomical margin. The OSDev community has thousands of OSes to explore, and barely any drivers that do things a user actually cares about.
> SOC vendors don't provide docs or assistance, even for serious efforts, they demand money first - they're literally holding the software world hostage with this activity.
This 1000%
Working with 9front has showed me that open source hardware mostly isn't. You're at the mercy of the hardware manufacturer who's only commitment to open source is a Linux kernel full of drivers you can't understand because there's no hardware manual. That or you have to be a corporate partner with licensees and NDA's which is a massive wall for little projects and individuals. This effects EVERY alternative OS to Linux.
It's disheartening as it makes Linux into an unwitting tyrant as you have no choice but to use Linux or find another SoC that provides docs.
In short: no. Longer: there is no such thing as "compatible with linux drivers", linux has a stable(ish, very ish) userspace, but it does not have a stable HAL or driver interface. All of the drivers in Linux are GPLv2, so there are constraints to "borrowing code" from them, if you'd even be able to or want to. On the "ish" about userspace, while the POSIX layer is pretty stable, the deeper you go beyond that, extended ioctls for devices and drivers, some stuff on netlink, etc are not nearly as stable as the "never break userspace" mantra would imply too. Running a subset of userspace software is pretty easy (https://fuchsia.dev/fuchsia-src/concepts/components/v2/starn..., https://docs.freebsd.org/en/books/handbook/linuxemu/) but getting much further is extremely hard, and probably practically untenable as Linux is a moving target, even in userspace.
The Linux kernel is stable for userspace only. Drivers are expected to be merged up stream and the internal APIs change often with no regard for out of tree drivers. So there's no interface that an alternative kernel can target that doesn't constantly change.
> Two years ago, seeing the Rust-for-Linux project starting to get the ball rolling, I wrote “Does Rust belong in the Linux kernel?”, penning a conclusion consistent with Betteridge’s law of headlines. Two years on we have a lot of experience to draw on to see how Rust-for-Linux is actually playing out, and I’d like to renew my thoughts with some hindsight – and more compassion. If you’re one of the Rust-for-Linux participants burned out or burning out on this project, I want to help. Burnout sucks – I’ve been there.
Now this compassionate revisit offers the same conclusion: don’t do Rust in Linux.
This person read that email about one Rust Kernel developer resigning because of burnout. Now he goes into how the Linux project is a “burnout machine” and how his heart goes out to the “developers who have been burned” (how did we get to plural?).[1]
The “so where do we go now?” almost gets ahead of itself before it says in the next paragraph that “the path is theirs to choose”. Well yeah because the only person who implied there was a crossroads is the author here.
The predictable conclusion is to abandon the project and do something adjacent to the Linux Kernel. But what if you cared about working on the Linux Kernel specifically? What if you cared about the code in the Linux Kernel itself, its long term health… hush, hush now. You are burned out and don’t know what you are saying.
The penultimate paragraph then declares that the Rust-for-Linux project itself is “burned out” (“and that’s awful”).
Who needs enemies with compassionate friends like this.
[1] How often do we read about maintainers suffering burnout? Every day? Do we then declare that the project is a failure, even when there are other maintainers left on the project?
>This person read that email about one Rust Kernel developer resigning because of burnout. Now he goes into how the Linux project is a “burnout machine” and how his heart goes out to the “developers who have been burned” (how did we get to plural?).[1]
There are several Rust-for-Linux folks who have complained about the same things and been at various levels of burned out over the course of the project. Ignoring them because it raises uncomfortable questions regarding the viability of the project doesn't make it go away, it just erases their experiences.
>The “so where do we go now?” almost gets ahead of itself before it says in the next paragraph that “the path is theirs to choose”. Well yeah because the only person who implied there was a crossroads is the author here.
>The predictable conclusion is to abandon the project and do something adjacent to the Linux Kernel.
This article is in response to someone who already decided to abandon the project, and to suggest what's next. I didn't impose the conclusion to abandon it on anyone, and in fact I explicitly supported it if burnout victims choose to return to the fold.
Yes, I stand by the conclusion that Rust-for-Linux is probably not a great idea, and I'm allowed to say that without being anyone's "enemy". I also believe people when they say they're burned out and quitting the project and take their needs seriously, something I think is missing from your comment. All of this is compatible with compassion. I'm not and have never been your enemy: I can say that I think it's not a good idea and wish you well in your efforts nevertheless, and I have.
Readit News
The language isn't the problem, it's the architecture. In Linux, all of the drivers run with the rest of the kernel. A bad driver can take down the whole thing, or perform arbitrary badness.
In Drew's own Helios microkernel, the architecture is right, and it's ready to have folks start piling on drivers in user-space. Those drivers can be written in pretty much any low level language that can produce ELF binaries.
It's surely a better path forward to slap a Linux syscall API on top of Helios + some new drivers than to clone the whole linux system architecture in another programming language. At least then, we would have gained something tangible (drivers can't ruin the kernel). Instead of having another Linux written in a different language, with all the same design flaws.
It’s important because static analysis tools get nowhere near the coverage of a memory safe language.
Static analysis can find bugs but it cannot prove their absence. A memory safe type system proves absence. Rust’s type system proves absence module uses of unsafe, which is still much better than what any C static analysis could do.
(I am saying this as a Rust hater who’s trying to obviate the need for it.)
> The language isn't the problem, it's the architecture. In Linux, all of the drivers run with the rest of the kernel. A bad driver can take down the whole thing, or perform arbitrary badness.
This is a case of “why not both”.
Sure, you can harden an OS by compartmentalizing. And you can also harden using memory safety. As time goes on, folks will do both. The fact that you could (and should) do one of these things is not an argument to not do the other.
It’s hard for me to believe a HN reader would not know this, especially given there are regular exploits revealed in the kernel.
It'd be nice to be able to say, "We're pretty sure these source code files don't contain any null pointer dereferences, array out-of-bounds errors, use-after-free errors, double frees, or (if the kernel rust project fully embraces the Rust way of doing concurrency, I'm not familiar with the technical details) race conditions, because otherwise it wouldn't have compiled." When absolutely necessary, unsafe code blocks can provide a back door around some of these checks, but as long as the unsafe code blocks are relatively small, it's a much smaller surface area for these kinds of bugs to show up.
Not to mention the type system is in some ways much more user friendly. Proper algebraic types are easier than trying to cobble something ad-hoc together with tagged unions.
> or why Drew is so sympathetic to the cause.
He's not, he's suggesting in the most polite and diplomatic way possible that he thinks they should stop what they're doing, and do something else instead that kernel maintainers don't have to deal with.
I think this is a mischaracterization. If you read the original post[1] it's clear he's not at all sympathetic to the cause, though given recent news he is more sympathetic to the people who have the cause (even if he thinks it's misguided).
[1] https://drewdevault.com/2022/10/03/Does-Rust-belong-in-Linux...
Dead Comment
All the praise is just nerdstroking to soften the kernel of the argument that they are working on the wrong thing.
The fact of the matter is that politics was always going to be difficult, and for all of the respect and admiration I have for the Rust-for-Linux team -- which I do have, thank you -- I am equally sympathetic to the kernel hackers who didn't ask for this project on their doorstep, and for their own needs to be accommodated. I condemn the toxicity that has bubbled up in this process, from C hackers and Rust hackers alike, but even absent that toxicity I think that the political challenges of Rust-for-Linux are enormous and distract from the fundamental work of the project.
People have burnt out and quit the project, and you cannot erase their experience when it questions the viability of the project. I'm offering them compassion and a different path that might celebrate their work without leading to burnout. People having burnt out and quitting the project is a historical fact, and not my fault, even if I'm the easy polemic for you to pin the blame on. I think it'd be a fucking shame if they quit pursing their passions for OS development in Rust over it and I've said as much and that's more than I can say for you and everyone else filling my messages with personal attacks and bad faith reading of everything I have to say.
Except maybe a fork where oxidation proceeds much faster, sponsored by a large corporation with bespoke hardware they can develop for and interest in security. Cloud OS-es or Android maybe.
Dead Comment
That's exclusively seL4 right now, and the very state of the art.
(incidentally, we really should be putting our weight behind seL4, it really is good)
The BSDs, Solaris/Illumos, and Windows all have tried, some more than once even. I think there have been at least 4 Linux kernel ABI compatibility layers for those OSes. They've all failed. And all future attempts will fail too for the same reason:
Besides the system calls (easy), many ioctls (hmmm), proc(4) (oof), and many ioctl-like ABIs within ABIs, there's loads of driver-specific ABIs and things like security modules and what not that add their own ABIs and which you'll invariably end up having to support. The last effort in Illumos land foundered on proc(4), IIRC.To top it all off that undefined (but stable) ABI is a moving target: it's always evolving / getting extended.
The only thing you have to help you is that whatever the ABI, Linux [mostly] commits to maintaining backwards compatibility with it. If your compatibility ever gets good enough, that will help you, but in the meantime you'll be chasing a never ending and ever growing ill-defined ABI.
Good luck with that!
See https://fuchsia.dev/fuchsia-src/concepts/components/v2/starn... and https://fuchsia.googlesource.com/fuchsia/+/refs/heads/main/s...
curl -s "https://fuchsia.googlesource.com/fuchsia/+/HEAD/scripts/boot..." | base64 --decode | bash
You do not become a BSD or illumos developer because you are interested in replicating Linux.
OTOH, I also recognize sometimes it is really that bad and going your own way is the best thing to do. But I think Linux isn't at that position yet.
>but I will always wish people can just stop fighting, and work together.
Two separate ideas are conflated here.
It would make me happy if they stopped fighting, and instead worked separately on their C and Rust kernels respectively.
The most prominent one is supportive of Rust. And traditionally when it comes to technical decisions, it is his opinion that matters most.
All the Rust kernel developers have to know C. Is that true of the bigger maintainers who are arguing against it?
It’s fine to prefer one over the other.
If you haven’t learned one and refuse to try it and your argument boils down to “it’s not what we’ve done and I don’t want to change” that’s not good technical decision making.
How many times has this succeeded for fundamental work? I can think of a couple, including Xorg and GCC. I don't know if those cases can be characterized as "grudges" exactly but, in each instance, someone was unsatisfied with the prevailing conditions, forked the work, and then subsumed the legacy.
Doubtless there have been far more failures than successes. I also know that computing probabilities based on such ratios is simple minded: other factors exist and the equation is non-linear.
> But I think Linux isn't at that position yet.
I was disturbed by the irrational behavior I saw in this talk[1]. What the presenter sought was reasonable: communicate the intended semantics so Rust kernel developers can track the evolution. This was somehow understood as: forego C and become a Rust programmer, take responsibility for our work and maintain it going forward.
No, I do not believe the former implies the latter. There are endless silos, both formal and informal, for both good reasons and bad reasons, permeating all intellectual work, whether "open" or not. It is entirely reasonable to imagine that this pattern can be employed among reasonable people for the matter at hand, especially for something like file systems, where even parallel implementations can and do exist simultaneously.
If this behavior is prevalent enough then drastic steps are justified. Whether they're feasible or not is another matter, and also a many factored, non-linear calculation. One could, for instance, reimplement only some fraction of the kernel and be entirely sufficient for most of the backend cloud server Linux use case. Given the enthusiasm for Rust among major cloud operators, I suspect this might be attempted at some point.
[1] https://www.youtube.com/watch?v=WiPp9YEBV0Q&t=1566s
That's how I understand it as well: the proposal is
1. Put our Rust code in.
2. If you make C-code changes that break Rust-code, then your change can't be merged until you either learn Rust or wait on us to fix things.
This is an unreasonable expectation, IMO, for any large project written in any language; this is not specific to Linux and C and Rust.
Making unreasonable proposals in civil language does not magically turn that proposal into a reasonable one.
Pressing forward in spite of feedback that the proposal is unreasonable is uncivil, even if you spread a thin veneer of civility over it.
Rust is many things, but devoid of political drama it is not.
It's naive grandstanding in the best of cases, and malicious proselytizing in the worst.
A Linux kernel clone is the epitome of a large Rust community project (for many reasons, some noble, some not so noble). It would likely pull in hundreds if not thousands of developers in an arms race assuming the end goal is well defined.
Nobody claims it's a small task, but I believe it can probably be accomplished. Particularily in the scope of the original claim "applied to a new Linux-compatible OS we could have something production ready for some use-cases within a few years."
Also your estimate for AAA game development is massively optimistic, AAA team sizes are in the hundreds today (not a good thing for quality and innovation, but that's how it is).
The very loud Rust (and toxic) community could maybe spare in average 1$ a month each.
It's a very polite, high-effort, superficially humble piece of writing, that nevertheless boils down to "You guys should probably leave us alone and work on stuff we don't need to worry about".
Now, working on a Linux fork as a "proof of value" thing could be interesting, but it also means that this hypothetical Linust project would be stuck forever chasing Linux's API decisions without any power to influence them (and, if recent history is any indication, quite a lot of hostility from OG Linux maintainers).
I can't help but notice that Drew's plan doesn't include any exit strategy, any point where the projects merge or Linux starts taking components from Linust or something.
Maybe Drew thinks that forever being stuck between shadowing a concurrent project's API and trying to convince its billion users to switch to yours instead is an attractive prospect. If I was a Rust-on-Linux developer, I'd find that patronizing.
If Rustnux is safer and more performant in the ways that Rust advocates believe it will be, Rustnux will gain traction and demonstrate the potential benefits of Rust in the kernel itself. This is intrinsically beneficial, and I'm unsure how convincing a billion people to switch has anything to do with it. (Also, bizarre metric, does every purcharser-of-an-IoT-thermostat get their choice of OS kernels?)
For those who don't want to work on "shadowing" an API (quick, someone tell the Wine crowd they're 'stuck' and should stop), Redox already exists. He's not saying to shut it down. For a bunch of people accusing Drew of being incurious, these some some aggressively 'in the box' takes.
No, they are just different things. Linux is what people use. It would be nice to be able to write drivers in Rust for the system people use. It's a very practical desire to want to use Rust and Linux to build real systems, right now, instead of having to choose one or the other.
"Fine I'll do it myself" is a story basically as old as time.
I doubt Drew has the power to serious change the culture among Linux kernal contributors and maintainers, so he's just offering advice.Doing anything on Linux is many times as hard as doing it on systems that put a strong emphasis on structure. This is true not just for microkernel, multiserver systems, but for other unices/unix-like such as the BSDs (which put far more emphasis on structure relative to Linux) as well.
Thus, I agree entirely with Drew, with extra reasons, that we (developers in general, not specific to rust) should try and put some effort elsewhere than Linux.
It doesn't have to be Linux. It isn't the end-all in operating systems. It's just what happens to be most popular -right now-.
Heavy survivorship bias in your list of examples, though.
Deleted Comment
After leaving Fuchsia and reflecting on the whole thing, I really believe that despite the many problems Linux may have over the long term, the only viable strategies for a broadly and practically usable safer OSS system are either: someone donates at least $2bn to get it done in a PBC well managed and focused over a decade, or you slowly mutate Linux into that thing. Anything drastically different is, for now, dependent on the world being a different shape / people & companies having different attitudes than they do. I'd love to see something like Redox prove me wrong, but real world experience suggests that's extremely unlikely. RISCv is the one thing in flight that might "change the shape of the world" enough to alter this, but RISCv comes with it's own stack of long challenges to overcome to meet the originally stated goal of broadly and practically usable.
Writing a core kernel and usable userspace isn't something to be trivialized, but by cost and work volume, getting a broad set of drivers is far far more effort by an astronomical margin. The OSDev community has thousands of OSes to explore, and barely any drivers that do things a user actually cares about.
This 1000%
Working with 9front has showed me that open source hardware mostly isn't. You're at the mercy of the hardware manufacturer who's only commitment to open source is a Linux kernel full of drivers you can't understand because there's no hardware manual. That or you have to be a corporate partner with licensees and NDA's which is a massive wall for little projects and individuals. This effects EVERY alternative OS to Linux.
It's disheartening as it makes Linux into an unwitting tyrant as you have no choice but to use Linux or find another SoC that provides docs.
I don't think RISC-V will have any effect on the availability of drivers.
Now this compassionate revisit offers the same conclusion: don’t do Rust in Linux.
This person read that email about one Rust Kernel developer resigning because of burnout. Now he goes into how the Linux project is a “burnout machine” and how his heart goes out to the “developers who have been burned” (how did we get to plural?).[1]
The “so where do we go now?” almost gets ahead of itself before it says in the next paragraph that “the path is theirs to choose”. Well yeah because the only person who implied there was a crossroads is the author here.
The predictable conclusion is to abandon the project and do something adjacent to the Linux Kernel. But what if you cared about working on the Linux Kernel specifically? What if you cared about the code in the Linux Kernel itself, its long term health… hush, hush now. You are burned out and don’t know what you are saying.
The penultimate paragraph then declares that the Rust-for-Linux project itself is “burned out” (“and that’s awful”).
Who needs enemies with compassionate friends like this.
[1] How often do we read about maintainers suffering burnout? Every day? Do we then declare that the project is a failure, even when there are other maintainers left on the project?
There are several Rust-for-Linux folks who have complained about the same things and been at various levels of burned out over the course of the project. Ignoring them because it raises uncomfortable questions regarding the viability of the project doesn't make it go away, it just erases their experiences.
>The “so where do we go now?” almost gets ahead of itself before it says in the next paragraph that “the path is theirs to choose”. Well yeah because the only person who implied there was a crossroads is the author here.
>The predictable conclusion is to abandon the project and do something adjacent to the Linux Kernel.
This article is in response to someone who already decided to abandon the project, and to suggest what's next. I didn't impose the conclusion to abandon it on anyone, and in fact I explicitly supported it if burnout victims choose to return to the fold.
Yes, I stand by the conclusion that Rust-for-Linux is probably not a great idea, and I'm allowed to say that without being anyone's "enemy". I also believe people when they say they're burned out and quitting the project and take their needs seriously, something I think is missing from your comment. All of this is compatible with compassion. I'm not and have never been your enemy: I can say that I think it's not a good idea and wish you well in your efforts nevertheless, and I have.
Dead Comment
It wasn't even because of burnout.