There have been multiple accounts created with the sole purpose of posting advertisement posts or replies containing unsolicited advertising.

Accounts which solely post advertisements, or persistently post them may be terminated.

One Of The Rust Linux Kernel Maintainers Steps Down - Cites "Nontechnical Nonsense"

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: youtu.be/WiPp9YEBV0Q?t=1529 – and to reiterate, no one is trying force anyone else to learn Rust nor prevent refactorings of C code."

0x0 ,

The kernel is mostly written in C, by C developers… understandably they’re rather refactor C code to make it better instead of rewritting everything in the current fancy language that’ll save the world this time (especially considering proponents of said language always, at every chance they get, sell it as C is crap, this is better).

Linux is over 30yo and keeps getting better and more stable, that’s the power of open-source.

AI_toothbrush ,

Most reasonable people say c is good, rust is better

troed ,
@troed@fedia.io avatar

C is crap for anything where security matters. I'll happily take that debate with anyone who thinks differently.

Duke_Nukem_1990 ,

What debate? You offered zero arguments and “C bad tho” isn’t one.

troed ,
@troed@fedia.io avatar

Do you believe C isn't crap when it comes to security? Please explain why and I'll happily debate you.

/fw hacker, reverse engineer

Duke_Nukem_1990 ,

That’s not how it works. You said:

C is crap for anything where security matters.

Argue for your point.

troed ,
@troed@fedia.io avatar

Figure 2: https://sci-hub.se/https://link.springer.com/article/10.1007/s11416-021-00379-x

Duke_Nukem_1990 ,

Link dropping is also not arguing.

troed ,
@troed@fedia.io avatar

Citing scientific research is. Now, please post your gut feeling in response.

Duke_Nukem_1990 ,

You continue to be antagonistic. I don’t think I want to waste my time here.

the_post_of_tom_joad ,

My gut feeling is you didn’t hook a programmer but a debate pervert (maybe shouldn’t have dropped the D word lol). Some people hear that word and turn they minds off cuz debates are simply a game for them to win. I’d just let this one swim brother

zaphod ,

Lots of categories which Rust doesn’t prevent, and in the kernel you’ll end up with a lot of unsafe Rust, so it can’t guarantee memory-safety in all cases.

loudwhisper ,

The biggest items on the graph are all out of bounds accesses, use-after-free and overflows. It is undeniable that memory safe languages help reducing vulnerabilities, we know for decades that memory corruption vulnerabilities are both the most common and the most severe in programs written in memory-unsafe languages.

Unsafe rust is also not turning off every safety feature, and it’s much better to have clear highlighted and isolated parts of code that are unsafe, which can be more easily reviewed and tested, compared to everything suffering from those problems.

I don’t think there is debate here, rewriting is a huge effort, but the fact that using C is prone to memory corruption vulnerabilities and memory-safe languages are better from that regard is a fact.

unexposedhazard ,

Maybe when you build some little application or whatever. When building the most used kernel in the world, there are probably some considerations that very few people can even try to understand.

pooberbee ,

I think most people would agree with you, but that isn’t really the issue. Rather the question is where the threshold for rewriting in Rust vs maintaining in C lies. Rewriting in any language is costly and error-prone, so at what point do the benefits outweigh that cost and risk? For a legacy, battle-tested codebase (possibly one of the most widely tested codebases out there), the benefit is probably on the lower side.

troed ,
@troed@fedia.io avatar

Isn't that exactly the strawman the maintainer got tired of?

pooberbee ,

Hmm… I admit I didn’t follow the video and who was speaking very well and didn’t notice hostility that others seem to pick up on. I’ve worked with plenty of people who turn childish when a technical discussion doesn’t go their way, and I’ve had the luxury of mostly ignoring them, I guess.

It sounded like he was asking for deeper specification than others were willing or able to provide. That’s a constant stalemate in software development. He’s right to push for better specs, but if there aren’t any then they have to work with what they’ve got.

My first response here was responding to the direct comparison of languages, which is kind of apples and oranges in this context, and I guess the languages involved aren’t even really the issue.

pivot_root , (edited )

Part of the hostility was the other maintainer misunderstanding the presenter, going on a diatribe about how the kernel Rust maintainers are going to force the C code to become unrefactorable and stagnate, and rudely interrupting the presenter with another tangent whenever he (the presenter) tried to clarify anything.

An unpleasant mix of DM railroading and gish galloping, essentially.

I wouldn’t quite call it a strawman, but the guy was clearly not engaging in good faith. He made up hypothetical scenarios that nobody asked about, and then denigrated Rust by attacking the scenarios he came up with.

Edit: I was thinking of the wrong fallacy. It is a strawman, yes.

ericjmorey ,
@ericjmorey@programming.dev avatar

He made up hypothetical scenarios that nobody asked about, and then denigrated Rust by attacking the scenarios he came up with.

This seems to be the textbook description of a strawman argument.

pivot_root ,

Wait, yeah. I was thinking of ad hominem when i wrote that, sorry. Correct, that is a strawman.

Bookmeat ,

If the timeline is long enough then it’s always worth the refactor.

fartsparkles ,

No idea what you’re being downvoted. Just take a look at all the critical CVSS scored vulnerabilities in the Linux kernel over the past decade. They’re all overwhelmingly due to pitfalls of the C language - they’re rarely architectural issues but instead because some extra fluff wasn’t added to double check the size of an int or a struct etc resulting in memory corruption. Use after frees, out of bounds reads, etc.

These are pretty much wiped out entirely by Rust and caught at compile time (or at runtime with a panic).

The cognitive load of writing safe C, and the volume of extra code it requires, is the problem of C.

You can write safe C, if you know what you’re doing (but as shown by the volume of vulns, even the world’s best C programmers still make slip ups).

Rust forces safe® code without any of the cognitive load of C and without having to go out of your way to learn it and religiously implement it.

0x0 ,

The cognitive load of writing safe C, and the volume of extra code it requires, is the problem of C.

Oh no, i’m having a meltdown with all the cognitive load…

Build all the fancy tools you want. At the end of the day if you put a monkey at the wheel of a Ferrari you’ll still have problems.

Nice that Rust is memory-safe, use it if you want, but why the insistence on selling Rust via C is crap? Doesn’t earn you any points.

How about rustaceans fork the kernel and once it’s fully Rust-only then try and get it to be used instead of the current one… win-win, eh?

Auli ,

Yes a monkey. All the vulnerabilities that have happened over the decades are just bad c programmers. So the question is are there any good c programmers?

fartsparkles ,

I’m not insisting anything; stating C is not a memory-safe language isn’t a subjective opinion.

Note I’m not even a Rust fan; I still prefer C because it’s what I know. But the kernel isn’t written by a bunch of Lewis Hamiltons; so many patches are from one-time contributors and the kernel continues to get inundated with memory safety bugs that no amount of infrastructure, testing, code review, etc is catching. Linux is written by monkeys with a few Hamiltons doing their best to review everything before merging.

Linus has talked about this repeatedly over the past few years at numerous conferences and there’s a reason he’s integrating Rust drivers and subsystems (and not asking them to fork as you are suggesting) to stop the kernel stagnating and to begin to address the issues like one-off patches that aren’t maintained by their original author and to start squashing the volume of memory corruption bugs that are causing 2/3rds of the kernel’s vulnerabilities.

0x0 ,

the kernel continues to get inundated with memory safety bugs that no amount of infrastructure, testing, code review, etc is catching.

I’d say this is the issue to fix. It’s not easy but if anything curl has proven it can be done efficiently.

troed ,
@troed@fedia.io avatar

Yeah, let's see what Bagder has to say about this:

C is unsafe and always will be

The C programming language is not memory-safe. Among the 150 reported curl CVEs, we have determined that 61 of them are “C mistakes”. Problems that most likely would not have happened had we used a memory-safe language. 40.6% of the vulnerabilities in curl reported so far could have been avoided by using another language.

Rust is virtually the only memory-safe language that is starting to become viable.

https://daniel.haxx.se/blog/2023/12/13/making-it-harder-to-do-wrong/

MotoAsh ,

Memory safe language that’s becoming viable … as a proper replacement of C.

There are many other memory safe languages out there. Just not ones most would like to pull in to the kernel…

qqq ,

The vast majority wouldn’t be able to be pulled into the kernel since they rely on the existence of the kernel via syscalls.

MonkderVierte ,

Someone stubbed a toe here.

corsicanguppy ,

having to go out of your way to learn it and religiously implement it.

Look! I painted the mona lisa in ketchup.

qqq , (edited )

They’re being downvoted because it’s a silly comment that is basically unrelated and also extremely unhelpful. Everyone can agree that C has footguns and isn’t memory safe, but writing a kernel isn’t memory safe. A kernel written in Rust will have tons of unsafe, just look at Redox: github.com/search?q=repo%3Aredox-os%2Fkernel unsa… That doesn’t mean it isn’t safer, even in kernel space, but the issues with introducing Rust into the kernel, which is already written in C, are more nuanced than “C bad”. The religious “C bad” and “C good” arguments are kinda exactly the issue on display in the OP.

I say this as someone who writes mostly Rust instead of C and is in favor of Rust in the kernel.

corsicanguppy ,

C is crap for anything where security matters.

True for people misusing it. If you want to argue the ease of mis-use, it’s a fun talk.

MotoAsh ,

Yea, it’s not C that is crap, but that it has zero guard rails. Like blaming a knife for not having a guard… Is it a bad knife without a guard? Depends on how sharp it is. The guard is orthogonal to the knife’s purpose, but might still be important when the knife is used.

Just because something doesn’t help prevent accidents does not mean it cannot serve its actual purpose well, unless its actual purpose is safety.

skullgiver ,
@skullgiver@popplesburger.hilciferous.nl avatar

C isn’t even bad, as long as you use the minimum amount required and do a LOT of security analysis on every line you write.

The problem with C code isn’t necessarily the language, a lot of it is the culture of people who think that unlike everyone else, they can write good, secure, bug-free C code, and they can ignore the warnings. They’re just that good!

These people seem to take the mere concept of a language that enforces memory access or security features as an insult to their intelligence.

Because of this bullshit, Linux is now behind in terms of Rust take up as Windows has begun rewriting components into Rust. I wouldn’t be surprised if the ego-based in-fighting between kernel devs will lead to Windows being significantly more secure in a few years.

troed ,
@troed@fedia.io avatar

Agree. I'm an absolutely awesome software dev myself - and I know C by heart (being my favorite language after assembler). However, with age comes humility and the ability to recognize that I will write buggy code every now and then.

Better the language saves me when I can't, in security critical situations.

Vincent ,

This sounds exactly like the type of nontechnical nonsense they’re complaining about: attacking a strawman (“they’re trying to prevent people from refactoring C code and making them rewrite everything in the current fancy language”) even after explicitly calling out that that was not going to happen (“and to reiterate, no one is trying force anyone else to learn Rust nor prevent refactorings of C code”).

corsicanguppy ,

at every chance they get, sell it as C is crap, this is better

For ‘sendmail’ values of $C, this resembles another argument. Also, of course for $C=sysvinit.

danielquinn ,
@danielquinn@lemmy.ca avatar

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 ,

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.

ramble81 ,

folks that have been doing this exclusively for 30 years

And yet the number of people I hear “just switch to Linux!” When the other person has been using Windows for 30 years blows my mind.

Inertia is a hell of a drug.

superkret ,

I wouldn’t tell a Windows developer with 30 years experience to just switch to developing for Linux.
Users are different. Most people who have used Windows for 30 years never touch anything outside of the desktop, taskbar and Explorer.

ILikeBoobies ,

It’s insane to find a windows user that doesn’t live in the terminal, it’s just not designed for it

Linux has a gui for everything

Vincent ,

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.

featured ,

There is a fully Rust based Unix-like OS out there, it’s called Redox and it’s very cool

ericjmorey ,
@ericjmorey@programming.dev avatar

It’s also a microkernel and intentional not POSIX compliant (but it’s close to compliant). I like the project, but it’s very experimental on purpose, so we should set our expectations accordingly. I’d love to see it become a success, but it may not be or it may only be successful in a smaller niche than the current Linux ecosystem.

That said, it seems very open to new contributors. I hope more people can help it along.

floofloof ,

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.

drwho ,
@drwho@beehaw.org avatar

That’s pretty well answered here: vger.kernel.org/lkml/-3

faltryka ,

Video url:

https://youtu.be/WiPp9YEBV0Q?t=1529

ik5pvx ,

At the cost of sounding naive and stupid, wouldn’t it be possible to improve compilers to not spew out unsafe executables? Maybe as a compile time option so people have time to correct the source.

0x0 ,

Compilers follow specs and in some cases you can have undefined behavior. You can and should use compiler flags but should complement that with good programming practices (e.g. TDD) and other tools in your pipeline (such as valgrind).

chrash0 ,

the semantics of C make that virtually impossible. the compiler would have to make some semantics of the language invalid, invalidating patterns that are more than likely highly utilized in existing code, thus we have Rust, which built its semantics around those safety concepts from the beginning. there’s just no way for the compiler to know the lifetime of some variables without some semantic indication

it_depends_man ,

At the cost of sounding naive and stupid

It may be a naive question, but it’s a very important naive question. Naive doesn’t mean bad.

The answer is that that is not possible, because the compiler is supposed to translate the very specific language of C into mostly very specific machine instructions. The programmers who wrote the code, did so because they usually expect a very specific behavior. So, that would be broken.

But also, the “unsafety” is in the behavior of the system and built into the language and the compiler.

It’s a bit of a flawed comparison, but you can’t build a house on a foundation of wooden poles, because of the advantages that wood offers, and then complain that they are flammable. You can build it in steel, but you have to replace all of the poles. Just the poles on the left side won’t do.

And you can’t automatically detect the unsafe parts and just patch those either. If we could, we could just fix them directly or we could automatically transpile them. Darpa is trying that at the moment.

MonkderVierte ,

Meaning a (current) kernel is actually a C to machine code transpiler?

ik5pvx ,

Thank you and all the others that took time to educate me on what is for me a “I know some of those words” subject

zaphod ,

Modern C compilers have a lot of features you can use to check for example for memory errors. Rusts borrow-checker is much stricter as it’s designed to be part of the language, but for low-level code like the Linux kernel you’ll end up having to use Rust’s unsafe feature on a lot of code to do things from talking to actual hardware to just implementing certain data structures and then Rust is about as good as C.

snaggen ,
@snaggen@programming.dev avatar

The problem is that C is a prehistoric language and don’t have any of the complex types for example. So, in a modern language you create a String. That string will have a length, and some well defined properties (like encoding and such). With C you have a char * , which is just a pointer to the memory that contains bytes, and hopefully is null terminated. The null termination is defined, but not enforced. Any encoding is whatever the developer had in mind. So the compiler just don’t have the information to make any decisions. In rust you know exactly how long something lives, if something try to use it after that, the compiler can tell you. With C, all lifetimes lives in the developers head, and the compiler have no way of knowing. So, all these typing and properties of modern languages, are basically the implementation of your suggestion.

kbal ,
@kbal@fedia.io avatar

3min 30s, sample for context

If you keep watching for 10 minutes, it's an interesting discussion. Too bad they had to cut it short due to time.

Findmysec ,

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 ,

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 , (edited )

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-0775 — use-after-free
CVE-2023-2513 — use-after-free
CVE-2023-1252 — use-after-free
CVE-2020-14314 — out of bounds read
CVE-2019-19447 — use-after-free
CVE-2018-10879 — use-after-free
CVE-2018-10881 — out of bounds read
CVE-2014-8086 — race condition
CVE-2009-0748 — null pointer dereference

luciferofastora ,

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

pivot_root ,

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.

Charadon ,
@Charadon@lemmy.sdf.org avatar

omfg, that guy in the video…

jjlinux ,
@jjlinux@lemmy.ml avatar

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.

IAmNotACat ,

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.

pivot_root , (edited )

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-10881 — out of bounds read
CVE-2014-8086 — race condition
CVE-2009-0748 — null pointer dereference

ijhoo ,

Who was the guy that had a lot of pauses with mmmmmm when talking?

  • All
  • Subscribed
  • Moderated
  • Favorites
  • •
  • [email protected]
  • random
  • lifeLocal
  • goranko
  • All magazines
    •