5 ms·
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 diff
by unclad5968 2y ago
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.
- snvzz 2y agoThe 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-.
- cryptonector 2y agoLack 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.
- lelanthran 2y ago> 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.
- PoignardAzur 2y ago> "Fine I'll do it myself" is a story basically as old as time. Heavy survivorship bias in your list of examples, though.
- geodel 2y agoBut that's the point. With Rust's absolute superiority in all dimensions and highly motivated developers why wouldn't Rust OS project succeed?
- PoignardAzur 2y agoThat 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.