4 ms·

This whole Rust in Kernel will not end well. We can spend all the time of the World bean counting half-percentages of who is more at fault but regardless of the

This whole Rust in Kernel will not end well. We can spend all the time of the World bean counting half-percentages of who is more at fault but regardless of the Holy accounting this will not end well for Linux. When being challenged for anything both sides tend to be despicable zealots, but given the 30+ years of C in Linux I tend to side to keep it that way, since the whole "everything is better and secure if done with Rust" is starting to become an annoying myth and the "aggressive victim" mentality a not so small part of the community has manifested throughout the most recent years does not bode well to the kernel of an OS that powers most of the World. IMO its more like choosing a lesser known evil, because the new ones already demonstrated not being better. PS: I also blame Linus for this. When you're the "Benevolent Dictator" having the foresight to avoid these brewing nasty civil wars is where you get the credits for all those accolades. He failed miserably.

mustache_kimono 2y ago
> IMO its more like choosing a lesser known evil, because the new ones already demonstrated not being better. First, I would disagree re: the 2nd part. Rust has obviously demonstrated itself, specifically in kernel space, but also almost everywhere else systems programming matters. I don't know what more it needs to do. Second, why must we choose? I (and I think the R4L folks would agree) don't think it's necessary for us to choose between C and Rust, if you're simply writing drivers in Rust. The reason this seems like such a fit by Mr. Hellwig is that this is obviously premature. Why don't we see how it works first, before screaming about how it will never work. > This whole Rust in Kernel will not end well. Third, I think you may discount how important the Rust energy/mindshare is. If it's not Linux, it will be FreeBSD or some other kernel, and that will be where all the interesting kernel development will be happening in 10 years. FWIW, I'd much rather have arbitrary Linux binaries work on my Rust-y kernel 10 years from now, I'd much rather my cutting edge driver code works on a system we can use now, etc. I hope this will usher in an era of less rudimentary kernel systems, because of how hard complex things in C are to get correct. For instance, OSS filesystem development has mostly stood still since ZFS. That is -- years later, bcachefs and btrfs are still chasing ZFS. Can you imagine a new filesystem, built for NVME and async IO, with ZFS feature parity, and additional wild features only available on enterprise storage (3D RAID anyone?, clustering, distributed filesystems...), which ships and becomes stable in years not decades? Instead Linux users who prefer stability prefer to drive an antique, the equivalent of Porsche 356. Okay for its time, and for certain workloads fast, but only because it still lacks so much.
- PedroBatista 2y ago
  This is exactly why I blame Linus, this discussion (a civil one, hopefully ) but also nasty wars inside the kernel would not exist if he had the "straightforwardness" as he likes to use as an excuse for many of his sins, to say NO to this. IMO your points are valid, but from a practical perspective they are out of place. Their place is not in the existing Linux kernel. > Third, I think you may discount how important the Rust energy/mindshare is. I'm very much aware of it and I'm also old enough to see how it plays out and how it ends. That feverous energy would be much better applied in a fork. With all the problems of current old Linux, with all the advantages of Rust and energy/mindshare of the community, a fork is a no-brainer. Think of all the energy not wasted in this civil war and all the not screaming happening while everyone is busy out-coding each other try to prove the other side wrong. Linux is not the Holy Sanctity, it will end when a new better thing appears. Do that thing. Linus knows this and wanted to have the cake while eating it too. This is the result.
  - dralley 2y ago
    >This is exactly why I blame Linus, this discussion (a civil one, hopefully ) but also nasty wars inside the kernel would not exist if he had the "straightforwardness" as he likes to use as an excuse for many of his sins, to say NO to this. You're making the pure assumption that he secretly wants to cancel the project but is afraid to, rather than that he (and Greg KH, and many other maintainers) actually wants the experiment to succeed for a variety of reasons. Which he is actually quite "straightforwards" about, if you look up his actual words on the matter. https://www.youtube.com/watch?v=OvuEYtkOH88&t=6m06s https://www.youtube.com/watch?v=OvuEYtkOH88&t=6m06s
- snvzz 2y ago
  >I think you may discount how important the Rust energy/mindshare is Not sure what the actual mindshare is. What I know is: They are loud.
  - iczero 2y ago
    I have a hard time believing that you wouldn't be annoyed if some almost completely unrelated maintainer hard NACKs your patch and every suggestion you offer just because they hold a grudge against the language you used.
_ph_ 2y ago
Not everything might be better, but most things would be more secure and stable in shorter time for sure, when using Rust or any other suitable language which e.g. guarantees memory safety and general correctness. It just looks as Rust is the most promising and also the best fitting candidate for this. Also, I have heard just good things about the experience using Rust for Linux drivers. So the Linux project is now at a point where long-term decisions need to be made. The Rust integration requires the next step, one maintainer tries to block that entirely. This has to be resolved in one way or the other with the corresponding consequences.

mustache_kimono 2y ago

> IMO its more like choosing a lesser known evil, because the new ones already demonstrated not being better. First, I would disagree re: the 2nd part. Rust has obviously demonstrated itself, specifically in kernel space, but also almost everywhere else systems programming matters. I don't know what more it needs to do. Second, why must we choose? I (and I think the R4L folks would agree) don't think it's necessary for us to choose between C and Rust, if you're simply writing drivers in Rust. The reason this seems like such a fit by Mr. Hellwig is that this is obviously premature. Why don't we see how it works first, before screaming about how it will never work. > This whole Rust in Kernel will not end well. Third, I think you may discount how important the Rust energy/mindshare is. If it's not Linux, it will be FreeBSD or some other kernel, and that will be where all the interesting kernel development will be happening in 10 years. FWIW, I'd much rather have arbitrary Linux binaries work on my Rust-y kernel 10 years from now, I'd much rather my cutting edge driver code works on a system we can use now, etc. I hope this will usher in an era of less rudimentary kernel systems, because of how hard complex things in C are to get correct. For instance, OSS filesystem development has mostly stood still since ZFS. That is -- years later, bcachefs and btrfs are still chasing ZFS. Can you imagine a new filesystem, built for NVME and async IO, with ZFS feature parity, and additional wild features only available on enterprise storage (3D RAID anyone?, clustering, distributed filesystems...), which ships and becomes stable in years not decades? Instead Linux users who prefer stability prefer to drive an antique, the equivalent of Porsche 356. Okay for its time, and for certain workloads fast, but only because it still lacks so much.

PedroBatista 2y ago
This is exactly why I blame Linus, this discussion (a civil one, hopefully ) but also nasty wars inside the kernel would not exist if he had the "straightforwardness" as he likes to use as an excuse for many of his sins, to say NO to this. IMO your points are valid, but from a practical perspective they are out of place. Their place is not in the existing Linux kernel. > Third, I think you may discount how important the Rust energy/mindshare is. I'm very much aware of it and I'm also old enough to see how it plays out and how it ends. That feverous energy would be much better applied in a fork. With all the problems of current old Linux, with all the advantages of Rust and energy/mindshare of the community, a fork is a no-brainer. Think of all the energy not wasted in this civil war and all the not screaming happening while everyone is busy out-coding each other try to prove the other side wrong. Linux is not the Holy Sanctity, it will end when a new better thing appears. Do that thing. Linus knows this and wanted to have the cake while eating it too. This is the result.
- dralley 2y ago
  >This is exactly why I blame Linus, this discussion (a civil one, hopefully ) but also nasty wars inside the kernel would not exist if he had the "straightforwardness" as he likes to use as an excuse for many of his sins, to say NO to this. You're making the pure assumption that he secretly wants to cancel the project but is afraid to, rather than that he (and Greg KH, and many other maintainers) actually wants the experiment to succeed for a variety of reasons. Which he is actually quite "straightforwards" about, if you look up his actual words on the matter. https://www.youtube.com/watch?v=OvuEYtkOH88&t=6m06s https://www.youtube.com/watch?v=OvuEYtkOH88&t=6m06s
snvzz 2y ago
>I think you may discount how important the Rust energy/mindshare is Not sure what the actual mindshare is. What I know is: They are loud.
- iczero 2y ago
  I have a hard time believing that you wouldn't be annoyed if some almost completely unrelated maintainer hard NACKs your patch and every suggestion you offer just because they hold a grudge against the language you used.

_ph_ 2y ago

Not everything might be better, but most things would be more secure and stable in shorter time for sure, when using Rust or any other suitable language which e.g. guarantees memory safety and general correctness. It just looks as Rust is the most promising and also the best fitting candidate for this. Also, I have heard just good things about the experience using Rust for Linux drivers. So the Linux project is now at a point where long-term decisions need to be made. The Rust integration requires the next step, one maintainer tries to block that entirely. This has to be resolved in one way or the other with the corresponding consequences.