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.

You can write out of tree Rust drivers for Linux right now, no one is stopping you. Your 'very practical desire' to write Rust drivers doesn't extend into some sort of corresponding obligation for anyone else to accept that code into their projects. Your desires do not take priority over the desires and needs of others.

I feel like people have some kind of misconception about what OSS requires on this point. The only meaningful right you have with the Linux kernel, that you don't have with - say - NT, is the right to fork it. Nothing about the idea of OSS extends you a right to merge whatever code you want into someone else's project to satisfy your 'very practical desires'.

You could have the best idea of all time, and you still wouldn't have any rights to anyone else's OSS project other than forking it.

Drew is offering a practical solution here to all sides, and all that the critics can come up with is 'yeah but wouldn't it be nicer if they got along?' (it would! they don't) or 'I hate Drew', which is an irrelevant and cruel thing to say about an actual human being.

> Your 'very practical desire' to write Rust drivers doesn't extend into some sort of corresponding obligation for anyone else to accept that code into their projects.

Never said it did?

> Nothing about the idea of OSS extends you a right to merge whatever code you want into someone else's project to satisfy your 'very practical desires'.

And that's why I called them practical desires, not rights?

> Drew is offering a practical solution here to all sides, and all that the critics can come up with is 'yeah but wouldn't it be nicer if they got along?' (it would! they don't)

My solution is to first deal with the bad behavior or it will fester. Then I'd ask if the technical reasons for including Rust in the Linux kernel still hold. I think they do. So I'm not sure we've reached the point where a fork makes sense yet. If we forked every time a kernel dev acted nasty to others, we'd have far too many forks.

> or 'I hate Drew', which is an irrelevant and cruel thing to say about an actual human being.

That's not what I said. If anyone is curious, I address this elsewhere: https://news.ycombinator.com/item?id=41407312

As to why I really can't stand Drew's writing, which is at the core of this complaint, one might see: https://news.ycombinator.com/item?id=41404644

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

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

That's part of the problem, I think: The Rust group's primary goal appears to be increasing the usage and/or popularity of Rust, not merely hardening the Linux kernel.

After all, both the kernel devs as well as the Rust group knows very well that the Rust group can maintain out-of-tree patches indefinitely. By using a out-of-tree patch, they can slowly and effectively replace almost all of the drivers. Many people actually would download and use their `rustix` kernel.

But that doesn't allow them to achieve their goal of spreading the movement, hence their resistance to prove the concept out-of-tree and the pushback from kernel devs who see this purely as a popularity-booster.

There is no good argument against the Rust group proceeding with an out-of-tree development effort; all the ones around "it's too much work" reflects the fear that the kernel devs have that the Rust group would push Rush code into the kernel, and then not be around to maintain it when some C code breaks it.

Lack of internal APIs is not the problem if the putative Rust-based clone doesn't aim to be compatible with Linux drivers written in C, which I think it wouldn't. The real problem is that the Linux kernel ABis to user-land are merely stable, myriad, and poorly documented. Keeping up is not possible. The BSDs, Solaris/Illumos, and Windows all had at least one (sometimes two) attempts at being compatible with Linux kernel user-land ABIs, and all failed due to being woefully incomplete in spite of being huge.

> "Fine I'll do it myself" is a story basically as old as time.

Heavy survivorship bias in your list of examples, though.

But that's the point. With Rust's absolute superiority in all dimensions and highly motivated developers why wouldn't Rust OS project succeed?

That kind of sarcasm and putting words in other people's mouths is why people are burning out of the project.

And maybe you're right and some Rust-based UNIX will eventually outcompete Linux.

But it'll be a shame if it gets that far because one community distrusted the other so much it would rather sneer at them like you're doing and tell them to piss off than put any investment whatsoever into sharing work.