520
submitted 3 months ago by pnutzh4x0r@lemmy.ndlug.org to c/linux@lemmy.ml

Wedson Almeida Filho is a Microsoft engineer who has been prolific in his contributions to the Rust for the Linux kernel code over the past several years. Wedson has worked on many Rust Linux kernel features and even did a experimental EXT2 file-system driver port to Rust. But he's had enough and is now stepping away from the Rust for Linux efforts.

From Wedon's post on the kernel mailing list:

I am retiring from the project. After almost 4 years, I find myself lacking the energy and enthusiasm I once had to respond to some of the nontechnical nonsense, so it's best to leave it up to those who still have it in them.

...

I truly believe the future of kernels is with memory-safe languages. I am no visionary but if Linux doesn't internalize this, I'm afraid some other kernel will do to it what it did to Unix.

Lastly, I'll leave a small, 3min 30s, sample for context here: https://youtu.be/WiPp9YEBV0Q?t=1529 -- and to reiterate, no one is trying force anyone else to learn Rust nor prevent refactorings of C code."

top 50 comments
sorted by: hot top controversial new old
[-] danielquinn@lemmy.ca 119 points 3 months ago

Oof, that video... I don't have enough patience to put up with that sort of thing either. I wonder how plausible a complete Rust fork of the kernel would be.

[-] rollmagma@lemmy.world 99 points 3 months ago

It's always been this way. Except that it was kernel developers arguing with kernel developers over C code. Now it's relative newcomers arguing with kernel developers over Rust code that the kernel devs don't necessarily care about. Of course it's going to be a mess.

A fork is of course possible, but operating systems are huge and very complex, you really don't want to alienate these folks that have been doing exclusively this for 30 years. It would be hard to keep the OS commercially viable with a smaller group and having to do both the day to day maintenance, plus the rewrite. It's already difficult as it is currently.

Rust will be a huge success in time, long after the current names have lost their impetus. This is not a "grind for 4 years and it's done" project.

load more comments (4 replies)
[-] Vincent@feddit.nl 68 points 3 months ago

That person in the audience was really grinding my gears. Just let the folks you're talking to answer you; no need to keep going on your diatribe when it's based on a false assumption and waste the whole room's time.

[-] moriquende@lemmy.world 19 points 3 months ago

let's not lose focus of what's important here, and that is a room full of people hearing my voice and paying attention to me for as long as I manage to hold it

[-] floofloof@lemmy.ca 33 points 3 months ago

I wonder how plausible a complete Rust fork of the kernel would be.

It sounds highly impractical, and it would probably introduce more issues than Rust solves, even if there were enough people with enough free time to do it. Any change must be evolutionary if it's going to be achievable.

[-] cerement@slrpnk.net 26 points 3 months ago

NOT a fork of Linux, but Redox is aiming for a Unix-like OS based on Rust – but even with “source compatibility” with Linux/BSD and drivers being in userspace, my guess would be hardware drivers are still going to be a big speed bump

load more comments (2 replies)
load more comments (8 replies)
[-] jjlinux@lemmy.ml 108 points 3 months ago

Ted Ts'o is a prick with a god complex. I understand his experience is hard to match, we all have something in our lives we're that good at, but that does not need to lead to acting like a fucking religious fanatic.

[-] pivot_root@lemmy.world 140 points 3 months ago* (last edited 3 months ago)

I understand his experience is hard to match, we all have something in our lives we're that good at

At some point, that mix of experience and ego becomes a significant liability. He's directly hurting the adoption of Rust in the kernel, while the C code he's responsible for is full of problems that would have been impossible if written in safe Rust.

CVE-2024-42304 — crash from undocumented function parameter invariants
CVE-2024-40955 — out of bounds read
CVE-2024-0775 — use-after-free
CVE-2023-2513 — use-after-free
CVE-2023-1252 — use-after-free
CVE-2022-1184 — use-after-free
CVE-2020-14314 — out of bounds read
CVE-2019-19447 — use-after-free
CVE-2018-10879 — use-after-free
CVE-2018-10878 — out of bounds write
CVE-2018-10881 — out of bounds read
CVE-2015-8324 — null pointer dereference
CVE-2014-8086 — race condition
CVE-2011-2493 — call function pointer in uninitialized struct
CVE-2009-0748 — null pointer dereference

[-] riodoro1@lemmy.world 56 points 3 months ago

Dude, three CVEs were enough. Stop kicking the blood puddle.

[-] Flipper@feddit.org 30 points 3 months ago

crash from undocumented function parameter invariants

My favourite, as that was the exact point the dev was making in his talk, that the stuff is badly documented and that the function signature would document it perfectly.

load more comments (9 replies)
[-] IAmNotACat@lemmy.world 36 points 3 months ago

Agreed. His experience might be useful if he were there to engage, but he’s clearly not. It seems like he just wanted to shout down the project and it seems like he was somewhat successful.

[-] qqq@lemmy.world 28 points 3 months ago* (last edited 3 months ago)

No intention of validating that behavior, it's uncalled for and childish, but I think there is another bit of "nontechnical nonsense" on the opposite side of this silly religious war: the RIIR crowd. Longstanding C projects (sometimes even projects written in dynamic languages...?) get people that know very little about the project, or at least have never contributed, asking for it to be rewritten or refactored in Rust, and that's likely just as tiring as the defensive C people when you want to include Rust in the kernel.

People need to chill out on both sides of this weird religious war. A programming language is just a tool: its merits in a given situation should be discussed logically.

load more comments (4 replies)
load more comments (2 replies)
[-] antihumanitarian@lemmy.world 67 points 3 months ago

The comments from that article are some of the most vitriolic I've ever seen on a technical issue. Goes to prove the maintainer's point though.

Some are good for a laugh though, like assertions that Rust in the kernel is a Microsoft sabotage op or LLVM is for grifters and thieves.

[-] Findmysec@infosec.pub 64 points 3 months ago

Who the fuck is this little shit? Can't they even be a little considerate towards rust? Just because they have 15 years worth of inertia for C doesn't mean they can close their eyes and say "nope, I'm not interested". I do not see how the kernel can survive without making rust a first class citizen

[-] IAmNotACat@lemmy.world 84 points 3 months ago

It’s Ted Ts’o, the maintainer of the ext4 filesystem amongst other things.

little shit

Though you’re still accurate despite his seniority.

[-] pivot_root@lemmy.world 71 points 3 months ago* (last edited 3 months ago)

There's really only one valid response to Ted Ts'o:

If you think you can do better with C, prove it.

CVE-2024-42304 — crash from undocumented function parameter invariants
CVE-2024-40955 — out of bounds read
CVE-2024-0775 — use-after-free
CVE-2023-2513 — use-after-free
CVE-2023-1252 — use-after-free
CVE-2022-1184 — use-after-free
CVE-2020-14314 — out of bounds read
CVE-2019-19447 — use-after-free
CVE-2018-10879 — use-after-free
CVE-2018-10878 — out of bounds write
CVE-2018-10881 — out of bounds read
CVE-2015-8324 — null pointer dereference
CVE-2014-8086 — race condition
CVE-2011-2493 — call function pointer in uninitialized struct
CVE-2009-0748 — null pointer dereference

[-] luciferofastora@lemmy.zip 30 points 3 months ago

You seem really invested in pointing out those shortcomings. I respect that.

[-] pivot_root@lemmy.world 52 points 3 months ago

Arrogant hypocrites are a pet peeve of mine. If someone is going to act like progressive technology changes are beneath them and unnecessary, they should be able to put their money where their mouth is.

load more comments (6 replies)
[-] JackbyDev@programming.dev 55 points 3 months ago

This is a little off topic and admittedly an oversimplification, but people saying Rust's memory safety isn't a big deal remind me of people saying static typing isn't a big deal.

load more comments (1 replies)
[-] Templa@beehaw.org 47 points 3 months ago* (last edited 3 months ago)

Someone linked the thread from Phoronix forum and the comments are so awful. Imagine having to deal with people like this.

One of them reads:

We need Microsoft people like we need fleas. Why can't they work for projects we don't like, like GNOME?

It is funny because Ts'o works at Google, lol.

[-] Vilian@lemmy.ca 17 points 3 months ago

Phoronix comments were always dumb, like, infuriating bad, I don't even read them anymore, the moderation on that site don't give a fuck about toxicity in there

load more comments (3 replies)
load more comments (2 replies)
[-] merthyr1831@lemmy.ml 34 points 3 months ago

The video attached is a perfect example of the kind of "I'm not prepared to learn anything new so everyone else is wrong" attitude that is eating away at Linux like a cancer.

If memory safety isn't adopted into the kernel, and C fanaticism discarded, Linux will face the same fate as the kernels it once replaced. Does the Linux foundation want to drag its heels and stuff millions into AI ventures whilst sysadmins quietly shift to new kernels that offer memory safety, or does it want to be part of that future?

load more comments (11 replies)
[-] olafurp@lemmy.world 32 points 3 months ago

There's always going to be pushback on new ideas. He's basically asking people questions like "Hey how does your thing work? I want to write it in rust." and gets the answer "I'm not going to learn rust.".

I think rust is generally a good thing and with a good amount of tests to enforce behavior it's possible to a functionally equivalent copy of the current code with no memory issues in future maintenance of it. Rewriting things in rust will also force people to clarify the behavior and all possible theoretical paths a software can take.

I'm not gonna lie though, if I would have worked on software for 20 years and people would introduce component that's written in another language my first reaction would be "this feels like a bad idea and doesn't seem necessary".

I really hope that the kernel starts taking rust seriously, it's a great tool and I think it's way easier to write correct code in rust than C. C is simple but lacks the guardrails of modern languages which rust has.

The process of moving to rust is happening but it's going to take a really long time. It's a timescale current maintainers don't really need to worry about since they'll be retired anyway.

load more comments (6 replies)
[-] svcg@lemmy.blahaj.zone 28 points 3 months ago

I am no visionary but if Linux doesn’t internalize this, I’m afraid some other kernel will do to it what it did to Unix.

Maybe that's not a bad thing? If you ask me the GNU people are missing a trick. Perhaps if they rewrote Hurd in Rust they could finally shed that "/Linux".

load more comments (6 replies)
[-] Charadon@lemmy.sdf.org 20 points 3 months ago

omfg, that guy in the video...

load more comments
view more: next ›
this post was submitted on 29 Aug 2024
520 points (98.7% liked)

Linux

48721 readers
2259 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