Rust For Linux Kernel Updated, Uutils As Rust Version Of Coreutils Updated Too (phoronix.com) 40
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.
whatever for (Score:4, Interesting)
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.
Re: (Score:3)
Yes, many of us multi-decade linux users have had reason to compile the kernel themselves. It's not uncommon and it's not hard, instructions for doing so exist for all major distros.
I'm taking my concerns right here and anywhere else I choose, you don't get tell me where and when I can post them. Fuck off.
Re: whatever for (Score:2)
Just use the older non-rust version of coreutils then. This is the first time I've heard of it, but it makes sense as cli based applications are having somewhat of a second renaissance thanks to rust. See for example ripgrep.
https://blog.burntsushi.net/ri... [burntsushi.net]
Re: (Score:2)
hahaha, compile kernel with multiple compilers hoping to god I have the rust with required brain farts, then older non-rust coreutils...
yeah this is sounding like mongolian goatfuck with drunken goats
Re: (Score:2)
Re: whatever for (Score:1)
Honestly you sound like an anti-vaxxer.
Re: (Score:2)
Honestly, you sound like a rust fanbo, You're the one being willfully obtuse and ignoring the issues of an immature and still mutating language being introduced into a kernel lacking nothing as a fanboi experiment.
It's unnecessary and making trouble for us all now, rust kernel module wannabees should play in some side project, we don't need you nor want you or your ilk.
Re: whatever for (Score:1)
No, I'm just playing the cultist that slashdot wants me to play. They want their Emmanuel Goldstein, and sometimes it's fun to play Emmanuel Goldstein, so that's exactly what I'm doing. Rust is a tool that happens to be part of my toolkit. It also happens to be a very nice tool.
And you're just a stupid anti-vaxxer who is afraid that a new tool is going to change his DNA and implant microchips into his blood.
Re: (Score:2)
I occasionally compile the Linux kernel myself, and would like it to not get to be even more of a PITA than it already is. Making it hard to build really goes against the whole spirit of the GPL.
Re: (Score:1)
Re: (Score:2)
Start your own fork if you want.
I don't want.
You do not have to use Rust if you do not want.
Unless some driver I need is written in it. Today, no. Tomorrow, maybe. That's why I'm speaking up today. If enough voices in the aggregate do so then it may help shape discussion in a way that provides that result.
Suggesting forking the kernel adds nothing of value to the discussion.
Re: (Score:2)
I don't want.
There is a built in mechanism if you do not like something in Linux. You are choosing not to do so but want to complain about it at the same time.
Unless some driver I need is written in it. Today, no. Tomorrow, maybe. That's why I'm speaking up today. If enough voices in the aggregate do so then it may help shape discussion in a way that provides that result.
There have been discussions on including Rust for over a year. If you did not participate then that is on you.
Suggesting forking the kernel adds nothing of value to the discussion.
You are the one that said that an open source project adding something new was against "the spirit of the GPL”. From the very beginning, if an GPL open source project goes in a direction you do not like, forking was always an option. You do not want
Re: (Score:2)
You are the one that said that an open source project adding something new was against "the spirit of the GPLâ.
That, sir, is a bullshit mischaracterization of what I said.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
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)
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)
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
Re: (Score:2)
"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)
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?
Re: (Score:2)
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.
Re: (Score:2)
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
Re: (Score:2)
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.
Re: (Score:2)
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)
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.
Re: (Score:2)
You don't contribute kernel code, do you?
Re: (Score:2)
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
Re: (Score:2)
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.
Re: (Score:2)
Re: (Score:2)
Well Linus is on board with Rust, but then he's onboard with the disaster known as systemd, an insecure and badly architect-ed morass that makes troubleshooting a nightmare. It's like he's losing his engineering sense in old age.
Re: (Score:2)
I'm older than he is, and have brain damage, and STILL understand that systemd is a poorly architected mess.
As a coder and project leader he's great, but the lack of a consistent architecture and design has made both Linux proper, and systemd, and X, and Wayland, and a lot of other crucial components of desktop Linux, much more convoluted and harder to maintain and extend and improve, than they need to be. Granted, still better in many of those areas than other desktop operating systems. But not where the
Re: (Score:2)
he[Linus]'s onboard with the disaster known as systemd
Please explain how exactly is Linus onboard with systemd. He runs systemd on his home computer? Or he is refusing to introduce changes in Linux kernel that would blacklist and disallow systemd? What is it?
Re: (Score:2)
systemd is not Rust. Rust is a programming language and systemd is an architecture how-not-to-do-it showcase.