4 ms·

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

by snvzz 2y ago

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

cryptonector 2y ago
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.
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.

by snvzz 2y ago

cryptonector 2y ago

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.

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.