Hacker News new | ask | show | jobs
by skyfaller 631 days ago
While I'm not sure I agree with the arguments, I don't think the arguments for starting over from scratch are insane: https://drewdevault.com/2024/08/30/2024-08-30-Rust-in-Linux-...

The core argument is that attempts to convert the Linux kernel to Rust are burning out the people putting in that work. The choice might not be between Rust in Linux or a new kernel, but between burned out devs failing to put Rust in Linux or a new Linux-compatible kernel written from scratch in Rust.

2 comments

I think this will happen sooner than we think. Lots of not-old people with a lot of talents out there and who doesn't like "get off my lawn" culture of the Kernel.

They key aspect will be importing was has gone wrong in the Rust and kernel community cultures.

There is no such thing as a Linux-compatible kernel. There's only Linux. Linux is not even compatible with itself, it's only compatible with its major version number.

The argument may have been 'go pound sand', that's what it means.

I'd say that isn't true. The Linux version number is somewhat arbitrary, and does not denote incompatibility. And from the view of userspace, the Linux ABI is rather backwards compatible.

Also, WSL1 and some BSDs are examples of Linux compatibility.

Yes, the driver interface may or may not change, nobody knows where and when. That's a feature of the Linux versioning scheme and driver HAL policy. You can roll your own userspace-Linux-compatible kernel and it's going to be a toy until you develop drivers for it, which won't ever happen.

> Also, WSL1 and some BSDs are examples of Linux compatibility.

Yes, and they suffer from either performance or lack of drivers, hence WSL2 running a real Linux with some dark magic to share hardware and network, sort of. Surely you don't mean this as an argument in favor of rolling your own Linux-compatible kernel?

Linux is not semantically versioned and has the same versioning policy as Chrome or Firefox: all version updates are minor updates and we just increment the version whenever we like. This is because of Linux's strict no-breaking-UAPI policy.
If I considered adopting a Lirust (yes I just invented that name, feel free to seal :D ) as an engineer, I would want everything user facing not to break. If that promise is held then I think a hypothetical Lirust would be highly successful.