Live data from Hacker News

Asahi Linux lead developer Hector Martin resigns from Linux kernel

lkml.org

801–810 of 1001 posts

Re: Asahi Linux lead developer Hector Martin resigns from Linux kernel

#801

LWN has a great impartial summary of what is occurring, including background on why the DMA subsystem is an important interface point for rust drivers: https://lwn.net/SubscriberLink/1006805/be4cb766fd906623/ (This is a shared link to a subscriber-only LWN article, please consider a paid subscription to LWN if you liked it!)

This isn’t impartial. Jonathan Corbet is naming and shaming, on behalf of one side. > But Christoph Hellwig … turned this submission away with a message reading, in its entirety: "No rust code in kernel/dma, please" (despite the fact that the patch did not put any code in that directory) > Already overworked kernel maintainers will have to find time to learn Rust well enough to manage it within their subsystems. Fran…

Journalists having an opinion in a news article, or even printing an opinion in an op-ed page, is not the same as—or even close to—social media brigading. It’s also a practice as old as the press itself. Brigading is about harassment and intimidation, not about possessing or publishing an opinion.

Re: Asahi Linux lead developer Hector Martin resigns from Linux kernel

#802
post #284
post #195

Earlier quoted context omitted.

> Arguably his reprimand of Martin is a clear signal that he will never show Rust any favor That doesn't really have anything to do with Rust; but with Hector's behaviour. Threatening a social media campaign to out people is completely toxic behaviour. This is a long-term contributor who is perhaps a bit abrasive, not Jimmy fucking Saville. Other than that, it's not a binary yes/no question; no one is really against…

> Threatening a social media campaign to out people is completely toxic behaviour. This is a long-term contributor who is perhaps a bit abrasive, not Jimmy fucking Saville. I'm no where near in the loop on this, but that sounds incredibly toxic. Are there some good links to summarize this? EDIT: OK, these are fully enough to allow me to understand the issue. Marcan: https://lore.kernel.org/rust-for-linux/208e1fc3-cfc…

I think this is an important data point, too:

Gunthorpe [nvidia]: https://lore.kernel.org/rust-for-linux/20250130154646.GA2298...

Basically, there is concern that even with a declaration that Rust-for-Linux devs will maintain this (and potentially every other) cross-language API translation layer file, the demarcation point between C and Rust isn't sufficient, and is causing C developers lag or headaches by having PRs rejected because of Rust-side failures. I don't see how that can be fixed without wholesale buy-in to Rust of enough kernel devs that they can fix whatever Rust problems are created by C API changes. Or Linus will have to accept PRs that break Rust-enabled builds. The R4L devs, by themselves, don't have the bandwidth to keep up. Even if they can rapidly fix problems, that adds potential friction to every C API change.

Hellwig may not be communicating in a good way, but he might be right, unfortunately. Linux may need to stay as a C-only codebase until an AI language-translation tool is good enough to do things like maintain the Rust API translation layer itself. Or until basically all maintainers learn and accept Rust.

Re: Asahi Linux lead developer Hector Martin resigns from Linux kernel

#803
post #680

Earlier quoted context omitted.

https://www.redox-os.org/ It's not a fork of Linux but a ground up effort to write a kernel in Rust. Still they're trying to make it compatible with Linux/BSD

Rust aside, it uses a microkernel, multiserver architecture. And, of course, drivers run in userspace and interact with the system through a clearly defined API. Other systems like this include Robigalia, Lions OS and Genode. They would likely quickly overtake Linux if they got 1% of the resources Linux receives.

Correction, where I said Robigalia I meant Managarm.

Robigalia is also an effort, but one that hasn't been touched in nearly a decade.

Re: Asahi Linux lead developer Hector Martin resigns from Linux kernel

#804
post #63
post #43

Quoting from this thread https://lore.kernel.org/rust-for-linux/Z6OzgBYZNJPr_ZD1@phen... > Simona Vetter: (addressing Hector) ...Now I'm left with the unlikely explanation that you just like thundering in as the cavalry, fashionably late, maximally destructive, because it entertains the masses on fedi or reddit or wherever. I have no idea what you're trying to achieve here, I really don't get it, but I am for sure fe…

Sima also went way too far with some of her comments this morning: https://lore.kernel.org/rust-for-linux/2b9b75d1-eb8e-494a-b0... Quoting > Being toxic on the right side of an argument is still toxic, [...] unironically, immediately after saying @marcan > and if that then causes you to ragequit, because you can't actually deal with the heat you've been dishing out coming back around the corner: fuck off ...is quite…

Sima is another Rust for Linux member, right?

Re: Asahi Linux lead developer Hector Martin resigns from Linux kernel

#805

LWN has a great impartial summary of what is occurring, including background on why the DMA subsystem is an important interface point for rust drivers: https://lwn.net/SubscriberLink/1006805/be4cb766fd906623/ (This is a shared link to a subscriber-only LWN article, please consider a paid subscription to LWN if you liked it!)

This isn’t impartial. Jonathan Corbet is naming and shaming, on behalf of one side. > But Christoph Hellwig … turned this submission away with a message reading, in its entirety: "No rust code in kernel/dma, please" (despite the fact that the patch did not put any code in that directory) > Already overworked kernel maintainers will have to find time to learn Rust well enough to manage it within their subsystems. Fran…

I came away with the opposite interpretation of yours.

The first quote of yours edited out the part where it says he does a lot of work in the DMA subsystem. It’s saying “someone who does a lot of work in the kernel turned the patch away”, which is absolutely true.

The second quote is understanding of the maintainers’ side, saying that they’re already overworked and now they’ll have to find time to learn rust on top of that. Not so much “I think these people ought to learn Rust”, but “accepting these patches means they will now have to learn rust”. This seems true to me? If anything it’s overly partial to the maintainer’s side, admitting that rust patches put more work on the old guard maintainers who are already overworked. It’s interesting that you feel this is too partial to the Rust side.

Re: Asahi Linux lead developer Hector Martin resigns from Linux kernel

#806
post #27

The Rust drama is an uncommon failure of leadership for Torvalds. Instead of decisively saying "no, never" or "yes, make it so," he has consistently equivocated on the Rust issue. Given the crisis of confidence among a sizeable (and very vocal) contingent of the Linux community, that decision has backfired horribly. And it's quite out of character for Linus not to have a blazingly clear opinion. (We all know his stan…

I agree with all statement from Linus. Keep it separated/downlined project I think is the best for both worlds.

Re: Asahi Linux lead developer Hector Martin resigns from Linux kernel

#807
post #427

Earlier quoted context omitted.

I think you're discounting the very real damage that would be done by Linux a project controlled by Linus and a community being replaced by Linux a project controlled by Google/Samsung/Redhat/Microsoft. I'm afraid that this is what is going to happen with the Linus tree effectively rejecting rust drivers by subjecting anyone attempting to upstream rust code to persistent bullying, but I don't want it to happen.

> subject upstream rust code to persistent bullying I don’t remember seeing this bullying accusation in your original comment. Was it edited in? Regardless, the “bullying” happened on both sides. Hector Martin started the social media brigading and quit when he couldn’t get his personal enemy suspended for CoC violations. Jonathan Corbet wrote a letter naming and shaming maintainers, in the guise of a report. All in…

I may have edited the phrasing within a minute or two of posting, couldn't say. I haven't edited the comment in the 14 hours since then, and the sentiment was in the original.

(I have edited this comment on the other hand, first to explicitly disagree with various statements in the above, then to delete those disagreements since I don't really want to get baited into an argument)

Re: Asahi Linux lead developer Hector Martin resigns from Linux kernel

#808
post #274

Earlier quoted context omitted.

Nothing in Linux is "here to stay", it always has to demonstrate its worth, and what it's worth is depends enirely on the technology and its developers, not Linus.

DEC Alpha support is somehow still in the mainline Linux kernel...

The ghost of the Alpha's infamously weak memory model coming back to bite it's undead self.

Re: Asahi Linux lead developer Hector Martin resigns from Linux kernel

#809
post #290

You know, Redox (as the "most serious" Rust kernel I can think of) could probably do with non-trivial drivers. It would be unfortunate for aspiring or even seasoned kernel developers to step away from the practice entirely, simply because R4L fails to launch.

Part of me feels like something like Redox isn't exactly worthit. Now I hope the project succeeds in whatever goals they have, and honestly where they've gotten to is impressive; what I mean to say is that I think it would be far more interesting to imagine beyond just Unix and especially the problems of POSIX. I think the "next" thing, if that even ever materializes needs to be that, something reimagined. Computers…

It seems fuchsia might me something for you

Re: Asahi Linux lead developer Hector Martin resigns from Linux kernel

#810
post #274

Earlier quoted context omitted.

DEC Alpha support is somehow still in the mainline Linux kernel...

Yeah m68k is still around too and it has more than a decade on alpha. People use and maintain them and they have very little impact outside arch/ nowadays so they're on the happy side of cost/benefit I guess.

M68k has the advantage that it has a fairly typical memory model.

Alpha's memory model has problems with providing atomic access to single bytes, which i'd imagine in a kernel is a bit annoying :-)

And then there's just the social aspect, m68k was used in the Amiga/Atari/Mac/QL/x68k, so there is a whole generation of us m68k fans who are willing to keep it alive.

Alpha has it's fans (me included!), but it's not exactly the same. So in a way it's no surprise it's slowly bitrotting away.

Post reply on HN