Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Linux

Rust For Linux Kernel Updated, Uutils As Rust Version Of Coreutils Updated Too (phoronix.com) 40

Posted by msmash from the moving-forward dept.
UnknowingFool writes: This weekend, Miguel Ojeda, added support for a set of additional Rust patches in the kernel and separately a new version of Uutils which is the Rust version of GNU CoreUtils. These changes will go towards more inclusion of Rust into Linux. The v7 patches adds in abstractions used by Rust and the Uutils update contained fixes and addresses compatibility issues.
This discussion has been archived. No new comments can be posted.

Rust For Linux Kernel Updated, Uutils As Rust Version Of Coreutils Updated Too More

Rust For Linux Kernel Updated, Uutils As Rust Version Of Coreutils Updated Too

Comments Filter:

  • whatever for (Score:4, Interesting)

    by iggymanz ( 596061 ) on Monday May 23, 2022 @03:26PM (#62559412)

    Why do we need to introduce another compiler for a fad language with specs that are still jello into the linux kernel? Who needs a toolchain version mess/mix match. I don't. No one does.

    • Because the modern web ecosystem has proven that "computer science" is no longer a science.

    • Re: (Score:2)

      by Tom ( 822 )

      The toolchain is the necessary evil. What we do need is more assurance that we don't fuck up basics at the core level, and Rust provides those assurances. I know roughly 20 programming languages and Rust is the only one I know that has a really solid memory management concept built into the language. Everything else leaves a core problem to either the programmer (yes C, I'm looking at you, I still love you and I understand your embedded and low-level friends need that kink sometimes, but seriously...) or do

      • Re: (Score:1)

        by Uecker ( 1842596 )

        I also like the memory feature of Rust. And people who dismiss this language labeling it a SWJ language are obviously just idiots.

        But the toolchain complexities and compile times are worrying. Also the overall complexity of Rust is a problem in my opinion.

        Finally, it is not clear to me to what extend the memory safety will actually help in real-world project compared to other techniques that help to find memory safety issues. I agree that having well-defined parts marked unsafe is a good idea, but safet

        • Re: (Score:2)

          by Tom ( 822 )

          But the toolchain complexities and compile times are worrying. Also the overall complexity of Rust is a problem in my opinion.

          There is a couple things in Rust that I disagree with as well, yes. IMHO more of the Go approach of making it simple and readable would help a lot to eliminate more errors. Complexity is the enemy of security.

          Finally, it is not clear to me to what extend the memory safety will actually help in real-world project compared to other techniques that help to find memory safety issues.

          I think the fact that despite various tools and techniques and code analysis and all that we still have exploits that target memory issues is proof enough that there is a need.

          I agree that having well-defined parts marked unsafe is a good idea, but safety is substantially diminished if a lot of unsafe code is used.

          Agree. The aim should be to have no unsafe code, though at the kernel-level that isn't always possible, but it should be the ai

          • "Complexity is the enemy of security"

            It can be. It is certainly the enemy of being easy to learn and rust is quite hard there. Having said that, a lot of the complexity comes about from getting the type system to work. If you don't get the complexity or don't understand it, then the tendency is for the code to just not compile which leaves you in a safe (if useless) situation.

            So, I'd compare this to, for example, the complexity of MFA which only makes things harder and more complex for normal users, but is

            • Re: (Score:2)

              by Tom ( 822 )

              So, I'd compare this to, for example, the complexity of MFA which only makes things harder and more complex for normal users, but is generally held to be more secure.

              We're talking different complexities, I think.

              I'm talking about something like "for i in 0..5" compared to some [0..5](i)=>{ i.(int)*stuff } magic. Complex syntax can hide bugs that you'd spot in more simplistic syntax.

              they have later had to add to the language because it was simplistic rather than simple.

              No language is perfect. But do I want generics in kernel code?

        • kernels have to do "unsafe" things, the blather about rust safety in the context of kernel code is just hot air without proof for now, unproven assertion.

          • No, it's not an unproven assertion. It's an hypothesis with good a priori support on the basis that Rust has a set of features design to support safety. It could be further supported by looking, for example, for existing bugs and showing that Rust safety features would be expected to prevent them. This a priori support is enough evidence that it is worth testing. There are two ways to achieve that: one is write a kernel in Rust entirely and two is incorporate Rust into a kernel that exists elsewhere.

            This an

      • No, Rust assurances are not a given in the context of a kernel, kernels must do unsafe things, and even resource runaway with safety and memory management can crash a machine. Rust fanbois should go play somewhere else, their language isn't even finalized yet.

        • No, Rust assurances are not a given in the context of a kernel, kernels must do unsafe things

          Not often. Most of what kernels do can and should be done in a memory-safe language. Rust allows unsafe blocks where necessary, but they should be rare, and closely-scrutinized.

        • Re: (Score:2)

          by Tom ( 822 )

          Rust requires unsafe code to be explicitly marked, which is already a good thing. And a lot of kernel code can be written without unsafe code. I've written Linux kernel hardware modules. There's a lot going on that's not low level driver stuff.

    • You don't contribute kernel code, do you?

      • irrelevant question, we compile kernel code. This will make all kinds of unnecessary trouble with an immature and still mutating language.

        You rust fanbois should go play in some containment space with your passing fad language, not the Linux kernel

        • You don't contribute kernel code, do you?

          irrelevant question

          So, that's a "no".

          You rust fanbois should go play in some containment space with your passing fad language, not the Linux kernel

          Take it up with Linus. I'm sure he'll be gentle.

Slashdot Top Deals

No spitting on the Bus! Thank you, The Mgt.

Close