434
submitted 2 weeks ago by tux0r@feddit.org to c/linux@lemmy.ml

Linux people doing Linux things, it seems.

you are viewing a single comment's thread
view the rest of the comments
[-] pete_the_cat@lemmy.world 48 points 2 weeks ago* (last edited 2 weeks ago)

part of the problem is that old-time kernel developers are used to C and don't know Rust," Torvalds said. "They're not exactly excited about having to learn a new language that is, in some respects, very different. So there's been some pushback on Rust."

Linus hit the nail on the head. If you've been a Kernel dev for a decade or more, and have spent decades learning the ins and outs of C, why would you want to switch to something that is similar, but different in a lot of ways, just because a small subset of devs think it's the best way forward? Let them handle Rust and the majority of devs will keep using C, even though Rust is objectively better.

As one of the other quotes suggested: fork the kernel project and rewrite it entirely in Rust, that way there isn't any push back from the C devs. Replacing C with Rust in the upstream kernel is akin to replacing the engine in a car while it's running or being used every day.

[-] emax_gomax@lemmy.world 101 points 2 weeks ago* (last edited 2 weeks ago)

This specific talk was about defining shared common interfaces so these different groups could work together and the guy who actually talked him into stepping down essentially said "I'm gonna keep writing C and if that breaks your rust stuff that's not my problem". This isn't about convincing the c devs to write rust it's about convincing them to work together when some of them seem to have made up their mind to sabotage rust support (either through indifference or willful interface regressions). Personally I'm more ashamed what this points to for someone new wanting to come in contribute to Linux.

[-] pete_the_cat@lemmy.world 1 points 1 week ago

Ah, but I still agree with the C devs, it creates unnecessary headaches for them. Also, old habits die hard.

I view it as the same way ZFS is supported: Linus and Greg KH are like "you can maintain it, but we don't give a shit about it, and if what we do breaks ZFS support, well too bad."

[-] emax_gomax@lemmy.world 2 points 1 week ago

The reverse is also true. Any dev wanting to contribute to Linux in rust which linus himself allowed (despite his silence on this matter) are just going to have to deal with constant headache trying to maintain compatibility with the C interfaces which the devs keep breaking. Either they should've never allowed rust in the kernel or they should force devs to at least act in good faith and collaborate (and any that refuse to, well they should be ousted because they can't behave responsibly). This entire situation is so toxic and I see that as a failure in leadership. That zfs comment is also a little toxic but I don't think it's a direct quote. It also doesn't seem like a fair comparison because from what I can tell zfs isn't even part of the kernel code base and due to legal reasons cannot be. While it would be great for the kernel not to break it, it is, for all intents and purposes an external project. This rust debacle is different because it's rust kernel devs and c kernel devs both operating in the same project and trying to find some kind of alignment. To me it seems like there's enough of an acknowledgment of the value of memory safety that rust support was considered but there's no authority figure actually supporting it or defending the devs that were invited to actually contribute in it. What a mess.

[-] floofloof@lemmy.ca 26 points 2 weeks ago

As one of the other quotes suggested: fork the kernel project and rewrite it entirely in Rust

That's not practically possible given the scale of the kernel. And doing a total rewrite is almost always a recipe for getting stuck and, if you ever create anything, creating something worse.

Replacing C with Rust in the upstream kernel is akin to replacing the engine in a car while it's running or being used every day.

Almost all real-world software development is like this. That's what we do.

[-] pete_the_cat@lemmy.world 1 points 1 week ago

Yeah it is a monumental task, but it's also the one with the least push back. I don't mean start from scratch, but convert the C code to Rust in a dev branch or something and release a Linux-Rust kernel image.

Almost all real-world software development is like this. That's what we do.

I'm aware, I've written my own software even though I'm a SysEng, all I'm saying is that it's not an easy process with a potential for disaster. Just look at CrowdStrike (not saying that they were attempting to switch languages but just the scale of the fuck up and the fallout that it caused), we don't want that to happen with Linux.

[-] De_Narm@lemmy.world 25 points 2 weeks ago

The kernel is probably too large to rewrite the whole thing at once. This could lead to a future without any new C kernel devs, leading to stagnation, while the Rust kernel could be many years away from being finished. (Assuming we actually move away from C.)

At that point you might as well just start an entirely new kernel and hope it is good enough to eventually replace the Linux one once all devs are gone. Kinda the X11 and wayland thing.

[-] Eranziel@lemmy.world 17 points 2 weeks ago

You can very safely remove the "probably" from your first sentence.

[-] qprimed@lemmy.ml 4 points 2 weeks ago* (last edited 2 weeks ago)

the Rust kernel could be many years away from being finished.

the number I saw floating around was 3 years to production useful. regardless, C's end days as the go-to, large systems level language are drawing nigh.

edit: tear

[-] ijhoo@lemmy.ml 6 points 2 weeks ago

I think this number is overblown. Production useful doesn't have to mean 1:1.

Running it without all graphics drivers would be fine for server use. Also, not all filesystems need to be ported: basic ones should be enough for start. But not only servers, home routers run Linux kernel...

If every OEM starts contributing their drivers in rust, this could move quickly...

[-] pete_the_cat@lemmy.world 1 points 1 week ago

I agree. C isn't going anywhere anytime soon, but if we don't start modernizing the kernel now we could end up with a future like the US government is in where all critical systems run on COBOL code and no one wants to touch it for the fear of breaking everything.

I'm not sure if it was in my above post or not, but the article said we should start modernizing the kernel now before someone does to Linux what Linux did to Unix.

Redox OS already exists and is functional (meaning it boots and has a GUI, but it's lacking in various aspects), from what I understand it's pretty much Linux/Unix rewritten entirely in Rust and looks pretty promising. In 5 or so years it could be a competitor with BSD and then overtake Linux once it has a proven track record.

[-] PotatoesFall@discuss.tchncs.de 23 points 2 weeks ago

It blows my mind that Linus is just so darn based all the time. That guy has a good take on like every issue.

[-] toastal@lemmy.ml 6 points 2 weeks ago

Strong opinions. Sometimes Linus’s takes are ‘bangers’ &, while probably fewer, he’s had a lot ‘woofs’ on the opposite end.

[-] PotatoesFall@discuss.tchncs.de 3 points 2 weeks ago

got some examples of the woofs? I'm not doubting the claim just interested :D

[-] leisesprecher@feddit.org 18 points 2 weeks ago

Replacing C with Rust in the upstream kernel is akin to replacing the engine in a car while it's running or being used every day.

That's in no way what's been proposed. Rust is used in a very well defined niche, nobody wants to get rid of C.

But it's just that sentiment that got us here, you're arguing against a non-existent threat, and thus reject the whole proposal.

[-] pete_the_cat@lemmy.world 1 points 1 week ago

I'm not rejecting it, I'm just saying that it's very difficult to completely change the code of a critical piece of software. The long-term goal is for Rust to overtake C in the kernel (from what I understand, I'm a System Engineer, not a software dev. I know Go, not Rust) due it being memory-safe and about 30 years newer. Critical code gets left untouched (a lot of the time) because no one wants to be the one that breaks shit (and get bitched out by Linus 😂) so I'm sure there is tons of code from the early 90s that could be made better with a newer language like Rust, but it's not as mature as C right now so that's not going to happen for a while, if at all.

[-] leisesprecher@feddit.org 1 points 1 week ago

The long-term goal is for Rust to overtake C in the kernel (from what I understand

Your understanding wrong. Rust is limited to some very specific niches within the kernel and will likely not spread out anytime soon.

critical code gets left untouched (a lot of the time) because no one wants to be the one that breaks shit

The entire kernel is "critical". The entire kernel runs - kind of by definition - in kernel space. Every bug there has the potential for privilege escalation or faults - theoretically even hardware damage. So following your advice, nobody should every touch the kernel at all.

[-] tux0r@feddit.org 17 points 2 weeks ago

even though Rust is objectively better.

In some of its characteristics, Rust is certainly a good language. The borrow checker, however, still haunts my restless dreams today.

[-] pimeys@lemmy.nauk.io 33 points 2 weeks ago

The borrow checker is exactly what the kernel needs.

[-] TimeSquirrel@kbin.melroy.org 8 points 2 weeks ago

I'm a C/C++ dude but I heard it being called the "Karen compiler". It doesn't look that scary based on samples I've seen, but there's way more to it I am assuming.

[-] floofloof@lemmy.ca 21 points 2 weeks ago

I'm no Rust expert, but in my experience the borrow checker is a pain for a bit, then you start to get a sense of what works and what doesn't, and after a while it has taught you to write cleaner code.

[-] trevor@lemmy.blahaj.zone 12 points 2 weeks ago* (last edited 2 weeks ago)

"Karen compiler" is almost perfect, except unlike Karens, the compiler is delightfully helpful with the error messages it gives you (usually). It usually gives a straightforward error, an error code, and sometimes, an easy fix.

As someone that started with Rust, but just yesterday had to fix some C++ code, working with any other compiled language makes me shudder. I have nothing but respect for devs that have to wade through stuff like that.

[-] floofloof@lemmy.ca 4 points 2 weeks ago

To be fair, most of them aren't as nasty as C++. But Rust certainly gives you a sense of security you don't get with most other languages.

[-] shy_mia@lemmy.blahaj.zone 2 points 1 week ago

At least it has something to complain about, unlike Karens.

[-] tux0r@feddit.org 0 points 2 weeks ago

Ha, I'll steal that! "Karen compiler" - quite fitting, to be honest.

[-] verdigris@lemmy.ml 4 points 2 weeks ago

Oh, so the main reason why it's so good?

[-] pete_the_cat@lemmy.world 2 points 1 week ago

I'm not a software dev (I'm a SysEng), and have never touched Rust (I've looked at the Rust source code and it scares me haha), but I know a fair amount of Go, and even the Go compiler is a pain in the ass occasionally. I've "mother fucked" it so many times.

[-] cm0002@lemmy.world 12 points 2 weeks ago* (last edited 2 weeks ago)

Tl;Dr: Old farts holding us back, as always

[-] pete_the_cat@lemmy.world 1 points 1 week ago

"If it ain't broke, don't fix it!"

I'm not a software dev, but I'd imagine that the codebase could definitely be reduced once most things are converted to Rust. From what I've heard, the kernel is a huge mess of spaghetti code that most people don't want to touch, for the fear of going insane in the process 😂

[-] delirious_owl@discuss.online 3 points 1 week ago

Rust is not objectively better. That's your opinion

this post was submitted on 03 Sep 2024
434 points (97.6% liked)

Linux

47325 readers
661 users here now

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 5 years ago
MODERATORS