'Maybe the problem is you' ... Linus Torvalds wades into Linux kernel Rust driver drama : opensource

[–] Gayhitler@lemmy.ml 55 points 3 weeks ago (3 children)

https://lore.kernel.org/lkml/20250108122825.136021-1-abdiel.janulgue@gmail.com/

Here’s the source thread.

Tldr: someone wants to put rust in the dma part of the kernel (the part that accesses memory directly)(it’s a memory allocator abstraction layer written in rust which rust code can use directly instead of dealing with the c allocator abstraction layer), is told that rust should use the extant methods to talk to the c dma interface, replies that doing so would make rust programs that talk to dma require some more code, gets told “that’s fine. We can’t do a split codebase”. The two parties work towards some resolution, then hector martin comes in and acts like jerk and gets told to fuck off by Linus.

Martin is no lennart poettering but I don’t try to see things from his perspective anymore.

It’s worth noting that Linus’ “approval” of rust in the kernel isn’t generally seen as a blanket endorsement, but a willingness to see how it might go and rust people have been generally trying to jam their code everywhere using methods that rival the cia simple field sabotage manual.

I don’t think it’s on purpose (except for maybe Martin) but a byproduct of the kernel maintainers moving slowly but surely and the rust developers moving much faster and some seeing the solution to that slow movement as jamming their foot in the door and wedging it open.

[–] verdigris@lemmy.ml 23 points 3 weeks ago (6 children)

To be fair, I'm not sure how "I will do everything in my power to oppose this" is the anti-Rust side "work[ing] towards some resolution"...

[–] Gayhitler@lemmy.ml 21 points 3 weeks ago (2 children)

That’s tame for the kernel mailing list lol.

The context is that hellwig doesn’t want another maintainer or deal with a split codebase in the dma subsystem which I honestly agree with.

If I were a maintainer in that position I’d be barring the doors too. It’s not a driver for some esoteric realtek wireless card or something.

Even if I didn’t agree with that position it’s normal to only post on the kernel mailing list about shit you actually care deeply about because it’s public and aside from all your fellow devs taking the time to read what you wrote, psychotic nerds like myself watch it and will try to read the tea leaves too!

load more comments (2 replies)

[–] uis@lemm.ee 9 points 3 weeks ago

https://lore.kernel.org/lkml/293df3d54bad446e8fd527f204c6dc301354e340.camel@mailbox.org/

General idea seems to be "keep your glue outside of core subsystems", not "do not create cross-language glue, I will do everything in my power to oppose this".

load more comments (4 replies)

[–] M1ch431@lemmy.ml 7 points 3 weeks ago* (last edited 3 weeks ago) (2 children)

trying to jam their code everywhere using methods that rival the cia simple field sabotage manual.

I am aware of the manual, but I fail to see how adding to a codebase is "sabotage" if it's all generally seen as fine by the project lead - it's far from a hostile takeover.

Would a CIA saboteur even want memory safety as a rule? Just speculating, but I'd say that's unlikely.

Edit: I changed the order of the sentences, as it was not intentionally ordered, and slightly clarified my second thought.

[–] Gayhitler@lemmy.ml 8 points 3 weeks ago (1 children)

I don’t think the ends are those of the cia, and I didn’t say that the means were either, only that they were similar to those in a famous mid century guide for those trying to halt or hijack organizations.

I don’t think the rust devs are a cia opp, before you ask. I think some rust devs and even proponents of rust who only cheer from the sidelines are sometimes behaving in ways that raise red flags. I think it’s natural and laudable that the existing devs and maintainers are alarmed by that same behavior. It’s their job.

I also think Linus position on rust has been stretched to the point of breaking and I personally find it hard to take positions seriously that distill the complex process of integrating new languages into a very old very large codebase with many full time developers into “Linus said I could”.

[–] M1ch431@lemmy.ml 4 points 3 weeks ago* (last edited 3 weeks ago) (1 children)

Again, I am aware of the manual. I was recently exposed to it, as well, so it's very fresh in my mind. I understand why you mentioned it and understand what you are saying, but I disagree, I don't see the parallels.

I think Linus just wants the drama to stop and the progress to flow, but I'll let him speak for his emotions towards the R4L project and avoid speculating about him.

I'm just openly speculating that there are vulnerabilities in the code, and that the R4L project will uncover those as a natural product of its evolution. I don't think a CIA sabotage manual is apt to describe the R4L project, largely because I see it as progress. From my perspective, maintaining old C code is not something they are sabotaging.

As opposed to the R4L members, there are those who are openly admitting to sabotaging the progress of the R4L project. If you've seen the past public clashes between the R4L project and the Linux kernel community, you'd also be able to garner that from those interactions as well.

[–] Gayhitler@lemmy.ml 4 points 3 weeks ago (1 children)

It’s surprising to see that statement get brought up in the news considering it’s immediately followed by a parenthetical specifically enumerating a multi language code base as the subject not rust specifically.

Iirc it’s even preceded by something to the effect of “I like rust, it’s good and there’s nothing wrong with projects that use it”.

The news coverage of kernel mailing list stuff is always so needlessly breathless.

[–] M1ch431@lemmy.ml 5 points 3 weeks ago* (last edited 3 weeks ago) (1 children)

From my understanding, it's not Hellwig's job to maintain the Rust side of the code. They can find multi-language codebases a pain all they want and throw a gigantic tantrum focused towards the R4L project - it doesn't affect the code that they are responsible for. I don't see why the whole R4L project couldn't just be removed if R4L is not maintained by those who develop and support it.

but I will do everything I can do to stop this.

Is an open admission of Hellwig to sabotaging the R4L project.

Seeing the R4L folks as saboteurs or anything close is not in evidence. This isn't the '90s, we have the means to be a lot more productive in regards to coding and managing codebases, and historical maintenance problems are irrelevant. If the R4L team is truly sabotaging the codebase by adding too much complexity or overhead, there are levers that can be pulled to change their direction without blindly rejecting or hindering their efforts.

[–] Gayhitler@lemmy.ml 4 points 3 weeks ago (2 children)

Again, so much of the discussion around kernel mailing list exchanges excludes the context that what hellwig is talking about is not rust in the kernel at all or even r4l but a split code base.

I dealt with a c/c++ codebase once and it was beyond my meager abilities to handle both those ostensibly similar languages at the same time and I had people who were very knowledgeable in c involved with the project.

So when someone says “I think a split codebase is cancer to the Linux kernel” or “I will oppose this (split codebase) with all my energy” I’m like “yeah, that makes sense.”

I also need to clarify that I don’t think anyone is sabotaging anyone else and my intent in bringing up the simple field sabotage manual was to point out that the behaviors don’t necessarily indicate sabotage but fall into a broad category of behavior that isn’t gonna solve problems or get anywhere which is why it’s included in the manual.

I wasn’t aware it was circulating in social media recently and about fifteen years ago when I got exposed to it the main lessons to draw were not that people doing those things were active saboteurs but that those behaviors can lead to waste of energy and resources and they’re the first thing to avoid interacting with.

My exposure to and understanding of the manual was “here are some things to avoid in your own life” not “here’s how to throw a wrench into their plans!”

load more comments (2 replies)

load more comments (1 replies)

[–] princessnorah@lemmy.blahaj.zone 6 points 3 weeks ago* (last edited 3 weeks ago) (1 children)

Except you're wrong about them wanting to put Rust code in the DMA subtree. As per the article linked below by M1ch431:

In a message to the Linux kernel mailing list, Hellwig wrote: "No Rust code in kernel/dma, please." For what it's worth, the patch added code to the rust/kernel portion of the Linux source tree, not kernel/dma, as far as we can tell.

All they were doing is adding an abstraction layer, within the already existing Rust code, so that rust drivers could communicate with the C DMA code in a uniform and predictable manner. It would have put far more work on maintainers, both C and Rust alike, to have each and every driver implement its own abstraction to the DMA API. Issues would have been/will be filed against the kernel/dma subtree in error due to issues with these myriad abstraction layers.

[–] Gayhitler@lemmy.ml 5 points 3 weeks ago

It’s a duplication of functionality in kernel/dma.

That’s why the submitter didn’t say “I didn’t submit to kernel/dma, checkmate libs!”.

The intent is to duplicate functionality in kernel/dma then get it included directly or linked to.

That’s what the r4l project is trying to do explicitly!

Before you say that kernel/dma didn’t have functional easy to use rust bindings, so the commit couldn’t have duplicated functionality: someone on kernel/dma said they didn’t want that and suggested using the c bindings instead which is what every other language has to do. Which means there was already a solution that was functional.

It’s like if there’s a community bicycle and you bring your drill and tap set so you can mount your bottle caddy and the community says “please don’t make a hole we have to tig in. Just use a pipe strap.” The right answer isn’t to start building a whole new down tube you can tap for an m5 for your bottle caddy, it’s to just use a pipe strap for your bottle caddy.

I didn’t read the linked article (or any linked article about this) because I’ve been reading the mailing list. Reporting on the kernel and people’s behavior on the list is tiring and often includes a bunch of baseless speculation.

[–] conditional_soup@lemm.ee 40 points 3 weeks ago (1 children)

FTA: "However, I will say that the social media brigading just makes me not want to have anything at all to do with your approach.

"Because if we have issues in the kernel development model, then social media sure as hell isn't the solution. The same way it sure as hell wasn't the solution to politics.

"Technical patches and discussions matter. Social media brigading - no thank you." -Linus

Yeah, I have to issue an unqualified agreement here. Linus isn't saying no to Rust, he's smackin' that ass for bringing drama out into social media instead of working through it in normal technical discussion channels.

[–] catloaf@lemm.ee 14 points 3 weeks ago (3 children)

It sounds like he tried that, and nobody with authority responded until he went outside the list. Even now, Linus hasn't actually answered the question of whether more rust code should be allowed.

[–] h4x0r@lemmy.dbzer0.com 15 points 3 weeks ago (1 children)

No offense, but reading through the comments it's apparent you're not very familiar with systems programming nor linux development. This is a common problem with vocal 'rustaceans', rust is their hammer regardless of the domain.

Although considering rust is prudent, there are still a ton of advantages to using C for systems programming. It is not a binary choice, there are pros and cons, and every project should choose what aligns with their priorities.

No one has ever stated that linux will be in the kernel. It was 'go ahead and give it a shot', which includes convincing maintainers to accept your patches. Linus has delegated trust to subsystems maintainers and an established process.

Hellwig could have been more tactful, but like it or not, arguments against a cross-language codebase have merit. Framing it as a 'clear confession of sabotage of the r4l project', attempting to weaponize the CoC, and trying to drum up an army via social media was all out of line.

Success was never a given, if they want r4l to succeed then they have to get patches approved and crying wolf ain't gonna cut it.

load more comments (1 replies)

[–] yozul 8 points 3 weeks ago (1 children)

I don't know how "whether more rust code should be allowed" is even a question. What, do you think they're going to just cut all the rust developers off or something? Linus has always been a move slow and don't break things kinda guy. Why should allowing rust into the kernel suddenly change that now? What is there to even answer?

[–] catloaf@lemm.ee 3 points 3 weeks ago (1 children)

Well, the rust devs are trying to add more rust code, and the dma maintainer rejected it because it was was written in rust. Thus, the question.

[–] yozul 9 points 3 weeks ago (1 children)

The dma maintainer wants all the code he's in charge of to be stuff he likes to work with. Whether you agree with that or not, that has absolutely nothing to do with Linus Torvalds allowing more rust code in the kernel.

[–] catloaf@lemm.ee 3 points 3 weeks ago (3 children)

That's the thing though, he's not in charge of this code.

load more comments (3 replies)

[–] conditional_soup@lemm.ee 5 points 3 weeks ago (1 children)

Sure, I saw that, too. This is Linus saying he won't play that.

[–] catloaf@lemm.ee 8 points 3 weeks ago (1 children)

So he won't answer on-list. He won't respond to off-list. I don't blame marcan for getting frustrated.

[–] conditional_soup@lemm.ee 3 points 3 weeks ago* (last edited 3 weeks ago) (1 children)

Yeah, I don't blame him for being frustrated. I definitely empathize with him here. I don't know about the culture around committing to the kernal, but maybe it would be better to fork and make the case with action?

[–] catloaf@lemm.ee 6 points 3 weeks ago

Forking the Linux kernel is unlikely to go anywhere.

There is Redox, a Unix-like whole OS implemented in Rust, though I don't know if being able to run unmodified Linux binaries is one of their goals. It looks like they're expecting most software to be ported.

[–] GammaGames 37 points 3 weeks ago (1 children)

The quote he replied to:

If shaming on social media does not work, then tell me what does, because I'm out of ideas.

Yeah, lol

[–] catloaf@lemm.ee 3 points 3 weeks ago* (last edited 3 weeks ago)

Yeah, Linus conspicuously did not answer that question either.

[–] prole@lemmy.blahaj.zone 22 points 3 weeks ago* (last edited 3 weeks ago) (4 children)

I'm relatively new to Linux and the FOSS scene, but I'm not sure how I feel about the unquestioning devotion to a single person. It seems antithetical to the entire philosophy.

Even if he was maybe right this time...

The dude did a complete 180 as soon as they heard from Linus, like daddy made his decision, and it's final, or some shit...

Edit: To be clear, I understand why developers respect and listen to Linus... I just think there are fundamental issues with this kind of top-down management of such a colossal project, and the desire to defer to one person seems antithetical to the FOSS philosophy.

[–] digdilem@lemmy.ml 24 points 3 weeks ago* (last edited 3 weeks ago) (1 children)

I don't think it's blind devotion - most of us would acknowledge the guy can be a bit of a dick sometimes.

But we're also grateful. Without his silly idea in the 90s, linux wouldn't exist. Computing today would be massively different - big, commercial, massively expensive unixes like Sco and Solaris dominating the industry. My main hobby for 20 years would be very different. My career for six years wouldn't exist.

That Linus has stayed an actively contributing member whilst not selling out in any way at all for 34 years is... wow. Could you do it? I'm certain i couldn't. I have neither the ethical strength nor moral compass to do it. And I'm certain if he dropped out, some of the massive egos that satellite around Linux, or the monetizing businesses would seek to take over and twist it to their needs.

And, y'know, on the matter of technical detail like this. He's nearly always right. Seriously, look it up. He's not polite, he's not diplomatic, but he's nearly always right. And when he's not, he'll admit it. Again, not your normal human.

So yeah, that's why we respect him and, when he talks, we listen. Even if it's not something we're involved with, it's usually an interesting ride.

[–] yozul 3 points 3 weeks ago (2 children)

Well, I certainly don't want to minimize what Linus Torvalds has done. No one has done more for open source software than him, but if he hadn't come along with his kernel when he did there were other options. BSD did eventually get out of the legal purgatory that Linux gave an alternative to, or heck, maybe if Linux hadn't come along Gnu Hurd could have even been a real thing.

I'm happy with Linus being in charge of the biggest open source project in the world. I agree with him more often than not. He's not the only reason open source operating systems exist though.

load more comments (2 replies)

[–] MentalEdge@sopuli.xyz 19 points 3 weeks ago* (last edited 3 weeks ago) (1 children)

If Linus genuinely went off the rails, the kernel would just get forked. Even right now, if the way the mainline project is run doesn't work for someone or what they are doing, that can and does happen.

Linus has power because the people who contribute to the project allow it, and they allow it because over the years he has consistently endeavoured to make decisions based on what is in the best interest of the project. People want him in charge, because he has done, and keeps doing, a really good job.

He hasn't always been nice to deal with, and he can get spicy when he puts his foot down, but whem he does, its not on a whim. And if he's wrong, and you can articulate why and how, in good faith, he won't ignore the logic of what you are saying out of some childish sense of pride.

load more comments (1 replies)

[–] ILikeBoobies@lemmy.ca 11 points 3 weeks ago

It’s just respect

[–] zagaberoo 4 points 3 weeks ago

The BDFL model, as it's called, is what allows large projects to continue to have focused vision rather than devolving into design-by-committee. The kernel is actually already well beyond pure BDFL, but my point is having a single point of overall leadership can be a huge boon for the organization of large and complex projects. FOSS philosophy has literally nothing to do with management structure; it's entirely about the rights of the end user.

BDFL is not without its own risks. WordPress is a good counterexample these days. But, when someone originates a project and sticks around to steer it, it would be silly to reject their proven successful leadership for such a vague reason as you have presented.

When things do go sideways, people are free to fork the project. That is what FOSS is.

[–] JayDee@lemmy.sdf.org 12 points 3 weeks ago

This whole thing reads not like a codebase versus, but a traditional engineering approach (don't act like you can patch this once you release it - get it done so it's stable the first time) versus the more modern "move fast and break things" approach.

[–] 7rokhym@lemmy.ca 10 points 3 weeks ago (1 children)

Rust people are so annoying.

[–] GnuLinuxDude@lemmy.ml 15 points 3 weeks ago

counterpoint: stonewalling c programmers are so annoying.

[–] SorteKanin@feddit.dk 7 points 3 weeks ago

Honestly I kinda wish the Rust devs would rather go and support a project like Redox OS and then maybe we can have less drama about all this.

[–] buwho@lemmy.ml 6 points 3 weeks ago (1 children)

linux is amazing. i dunno what rust is, but ive been using linux a long time. i appreciate the modern comfort. but whatever happens happens. itll still be good.

[–] urquell@lemm.ee 7 points 3 weeks ago

If code doesn't change quickly enough, it rusts. Linus makes sure that doesn't happen

[–] sith@lemmy.zip 5 points 3 weeks ago* (last edited 3 weeks ago) (1 children)

My gut tells me that any benefits of adding Rust is massively negated by the addition of a second language.

If one wants to write Rust, there is always Redox and probably a bunch of other kernels.

I like Rust, but it's for sure an over hyped language. In a year or two, people will push for Zig, Mojo or some new pure and polished functional low level language. Maybe a Scheme or a Lisp? That seems to be what the cool kids use nowadays.

Or maybe we'll just replace the kernel with an AI that generates machine code according with what should be your intention.

[–] yozul 6 points 3 weeks ago (3 children)

I dunno, people have been saying Rust will go away in a year or two for, like, five years now. This feels different to me. I could easily be wrong, but I don't think it's just another fad language.

load more comments (3 replies)

[–] DieserTypMatthias@lemmy.ml 3 points 3 weeks ago

This is just a dick measuring contest.

[–] droplet6585@lemmy.ml 3 points 3 weeks ago (3 children)

Can someone distill the good faith argument against rust? Is there one?

[–] SoulWager@lemmy.ml 7 points 3 weeks ago* (last edited 3 weeks ago) (3 children)

Can someone distill the good faith argument against rust? Is there one?

https://xkcd.com/927/

The problem is that even if it's objectively better, you can't magically convert everything instantaneously, and it's a lot more work maintaining rust and C versions of the same code until everything is re-implemented in rust.

load more comments (3 replies)

[–] uis@lemm.ee 7 points 3 weeks ago

Only one compiler nailed to LLVM. And other reasons already mentioned.

[–] lime@feddit.nu 7 points 3 weeks ago* (last edited 3 weeks ago) (1 children)

it's more niche than C, has less competency available, works very differently to C, and requires a whole new toolchain to be added to the already massive kernel compilation process. for it to be plain sailing adding it to the kernel some of the worlds' foremost domain experts on operating systems would have to re-learn basically everything.

~~also since rust is just coming up on 15 years of existence without a 1.0 release, there's no way to ensure that the code written today will be considered well-formed by the time 1.0 hits.~~

[–] nutomic@lemmy.ml 8 points 3 weeks ago (2 children)

??? Rust 1.0 was released 10 years ago and since then there have been no breaking changes.

https://blog.rust-lang.org/2015/05/15/Rust-1.0.html

load more comments (2 replies)

Open Source

Useful Links

Rules

Related Communities