5 ms·

I'm really happy about the inclusion of Rust in the linux kernel. Not because it is Rust but because it shows that we can evolve. And I hope in a thousand years

I'm really happy about the inclusion of Rust in the linux kernel. Not because it is Rust but because it shows that we can evolve. And I hope in a thousand years we aren't still stuck on C or Rust but "moved on" to even better things. It would make me quite hypothetically sad if in a thousand years we were still using tools designed by hackers in the infancy of computer science.

ArcMex 4y ago
>As can be seen, these patches are slowly building the in-kernel Rust code up so that real functionality can be implemented in Rust, but this process has some ground to cover yet. It's not clear whether more Rust code will be proposed for 6.2, or whether this is the full set. The pace of change may seem slow to developers who would like to start doing real work in Rust, but it does have the advantage of moving in steps that can be understood — and reviewed — by the kernel community. The Rust-for-Linux work has been underway for a few years already; getting up to full functionality may well take a while longer yet. Me too, I agree.
ilovecaching 4y ago
I'm really tired of the cargo culted idea that Rust is a silver bullet and C hasn't evolved since the 1970s. Neither of those things are true. The vast majority of people spouting opinions on Rust don't even write systems software, and have never even compiled a kernel driver. Linux, systemd, grub are all written in C and continue to have fewer flaws than trivial userland applications that allow for privilege escelation. The kernel core is incredibly high quality C, and time would be better spent working on the actual kernel security model. Dennis Ritchie himself wrote a paper about the deficiencies of the Unix security model which was designed for a trusting and shared computing environment. But of course updating the API surface isn't as sexy as writing in a new cool programming language. Cargo culting this notion that Rust is good because it is a security silver bullet is both ignorant AND dangerous because it moves the focal point away from the areas that actually need work to make Linux more secure. It's also completely asinine to assume that poorly written Rust will have fewer flaws than expertly written C that has been vetted for literally decades. Iterative improvement has ALWAYS been the answer over throw everything away and start fresh. C tooling has gotten better over the decades, the C standard has evolved, and people will continue to successfully write secure and performant applications in C. Edit: Also are you upset that people still use hammers in 2022? I guess if we aren't throwing away all of our tools instead of improving on their design we aren't really seeing any *Progress*
- pjmlp 4y ago
  Apparently many C users aren't aware that lint exists since 1979.
- throwaway894345 4y ago
  > It's also completely asinine to assume that poorly written Rust will have fewer flaws than expertly written C that has been vetted for literally decades. No one is advocating for writing the kernel in “poorly-written Rust”. This whole post is one giant, obvious straw man.
  - hn_go_brrrrr 4y ago
    It's not entirely a strawman. The steelman version: When replacing battle-tested code with newly-written code, you're going to encounter new bugs. Guaranteed.
    - ravi-delia 4y ago
      And as always when this comes up, Rust is currently slated to be used for new development. Even putting aside the safety aspect, Rust has a lot of nice high level language features without too much overhead.
    - atoav 4y ago
      If the code is only battle tested you have a problem. If you did the correct thing and have written the actual tests for each of the lessons learned nothing stops you from porting these over to Rust. If you don't have the tests you just listed another reason why using a language with better safety guarantees that will not let broken things compile is a good idea. The way I see it even battle tested old code can become a liability, if it's surrounding and dependencies change.
      - hn_go_brrrrr 4y ago
        It's often impractical to fully test every single aspect of all code. An example that I've seen several times is bottlenecks in unexpected places. Once was due to false sharing, another due to worse standard library QoI.

ArcMex 4y ago

>As can be seen, these patches are slowly building the in-kernel Rust code up so that real functionality can be implemented in Rust, but this process has some ground to cover yet. It's not clear whether more Rust code will be proposed for 6.2, or whether this is the full set. The pace of change may seem slow to developers who would like to start doing real work in Rust, but it does have the advantage of moving in steps that can be understood — and reviewed — by the kernel community. The Rust-for-Linux work has been underway for a few years already; getting up to full functionality may well take a while longer yet. Me too, I agree.

ilovecaching 4y ago

I'm really tired of the cargo culted idea that Rust is a silver bullet and C hasn't evolved since the 1970s. Neither of those things are true. The vast majority of people spouting opinions on Rust don't even write systems software, and have never even compiled a kernel driver. Linux, systemd, grub are all written in C and continue to have fewer flaws than trivial userland applications that allow for privilege escelation. The kernel core is incredibly high quality C, and time would be better spent working on the actual kernel security model. Dennis Ritchie himself wrote a paper about the deficiencies of the Unix security model which was designed for a trusting and shared computing environment. But of course updating the API surface isn't as sexy as writing in a new cool programming language. Cargo culting this notion that Rust is good because it is a security silver bullet is both ignorant AND dangerous because it moves the focal point away from the areas that actually need work to make Linux more secure. It's also completely asinine to assume that poorly written Rust will have fewer flaws than expertly written C that has been vetted for literally decades. Iterative improvement has ALWAYS been the answer over throw everything away and start fresh. C tooling has gotten better over the decades, the C standard has evolved, and people will continue to successfully write secure and performant applications in C. Edit: Also are you upset that people still use hammers in 2022? I guess if we aren't throwing away all of our tools instead of improving on their design we aren't really seeing any *Progress*

pjmlp 4y ago
Apparently many C users aren't aware that lint exists since 1979.
throwaway894345 4y ago
> It's also completely asinine to assume that poorly written Rust will have fewer flaws than expertly written C that has been vetted for literally decades. No one is advocating for writing the kernel in “poorly-written Rust”. This whole post is one giant, obvious straw man.
- hn_go_brrrrr 4y ago
  It's not entirely a strawman. The steelman version: When replacing battle-tested code with newly-written code, you're going to encounter new bugs. Guaranteed.
  - ravi-delia 4y ago
    And as always when this comes up, Rust is currently slated to be used for new development. Even putting aside the safety aspect, Rust has a lot of nice high level language features without too much overhead.
  - atoav 4y ago
    If the code is only battle tested you have a problem. If you did the correct thing and have written the actual tests for each of the lessons learned nothing stops you from porting these over to Rust. If you don't have the tests you just listed another reason why using a language with better safety guarantees that will not let broken things compile is a good idea. The way I see it even battle tested old code can become a liability, if it's surrounding and dependencies change.
    - hn_go_brrrrr 4y ago
      It's often impractical to fully test every single aspect of all code. An example that I've seen several times is bottlenecks in unexpected places. Once was due to false sharing, another due to worse standard library QoI.