Hacker News Reader

> 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.

> It’s important because static analysis tools get nowhere near the coverage of a memory safe language

It’s hard for me to believe a HN reader would not know this, especially given there are regular exploits revealed in the kernel.

> 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.

Safe rust cannot guarantee the lack of race conditions, only the lack of data races.

A fair point. You could have two simultaneous code paths access the same hardware device, if such were not protected by a lock or some form of exclusive access to some associated data structure.

> why Drew is so sympathetic to the cause

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...

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.

This just gives all the power to abusers.

I'd rather fix the abuse (the cause of the particular burnout), because it impacts not only the Rust developers, but all current and future contributors, and indirectly us users as well.

> 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.

In a metaphorical sense… since HN is not your inbox and this is not your submission.

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.

Do we get also realtime (10ths us latency) out-of-the-box, where badly written drivers cannot negatively interfere good ones?

To get to that point (mixed criticality, some processes and drivers can be critical and others not be), you need to be able to reason about time.

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)

Everyone trying to sell the utopia of micro-kernel never bothered to learn why it never worked and never will

It's not a utopia, but a viable alternative that should receive more attention and investment.