Live data from Hacker News

Asahi Linux lead developer Hector Martin resigns from Linux kernel

lkml.org

161–170 of 1001 posts

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

#161

Earlier quoted context omitted.

I don't know anything about him, but it seems like he has a pretty negative view of Reddit users as well: > Added some clarifications in bold, because Reddit users having enough reading comprehension to understand what Christoph said and why it's exactly* what I described with other words is apparently a Lv.100 impossible challenge boss.* https://web.archive.org/web/20250206022420/https://social.tr...

An Intel employee in a reply makes a extremely good point that I think everyone these days needs to follow > And if you're wondering why you didn't realize this: It's impossible to change people by telling them they're wrong. What does tend to work is explaining different perspectives, so that they can figure it out themselves. And sometimes that's just way too subtle to ever register.

Said Intel employee needs to follow their own advice.

https://chaos.social/@sima/113961285815637787

> when you're that harmful with your calling out, eventually I'm going to be fed up, and you get a live round shot across your bow 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

>or as Dave put it "Being toxic on the right side of an argument is still toxic, [...]"

(that second comment made apparently without any sense of irony re: the first)

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

#162

Linus replied: How about you accept the fact that maybe the problem is you. You think you know better. But the current process works. It has problems, but problems are a fact of life. There is no perfect. 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…

Context I struggle to follow the LKML through the web-interface. LORE seems to provide a better view: 1. https://lore.kernel.org/lkml/a869236a-1d59-4524-a86b-be08a15... Maintainer of DMA wants to keep the code clean and not mixing languages[1]. And tries to avoid dangerous offers like "we will maintain it for you".[2] 2. https://lore.kernel.org/lkml/a869236a-1d59-4524-a86b-be08a15... Somebody references social media…

>Maintainer of DMA wants to keep the code clean and not mixing languages[1]. And tries to avoid dangerous offers like "we will maintain it for you".[2]

The Rust bindings are not in his tree. They do not touch his code. They are effectively no different than any other subsystem or driver which uses DMA. If he tried to veto some random driver that needed DMA from using DMA for no reason other than because he didn't want to have to deal with it if he changed the API in the future, that maintainer would be told to F-off because that's not his call.

Christoph is throwing NACKs around that he doesn't actually have the authority to NACK.

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

#163

Earlier quoted context omitted.

What is the interpretation of "cancer" in this context that isn't rude, offensive, or hostile to the R4L project?

Mixing codebases in the Linux core. I think the conversation is more about people equating R4L as validation for rust or even themselves.

That is not what is happening! Nobody is mixing languages in the Linux core...

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

#164
post #142

Earlier quoted context omitted.

I don't think you can conclude anything from that since a ton of UNIX systems implemented in C are also dead.

C was created to rewrite UNIX from its original Assembly implementation, naturally it is a symbiotic relationship not shared by other languages. Note that many folks even forget that C++ was equally developed on the same Bell Labs group, and is probably one of the first examples of guest languages, making their best to fit into the platform, taking advantage of the ecosystem with almost zero friction, but never being…

> C was created to rewrite UNIX from its original Assembly implementation

I don't think I can go with that one. C was created in the same period as people were trying to find a way to create a common platform, but C was more about trying to solve the problem of having a higher-level language that wasn't available for the low-end hardware (ie PDP-11, etc) of the time. Richie wasn't trying to reinvent the wheel.

He would have been happy to use other languages, but they were either design for large platforms which needed more resources (Fortran) or looking to be locked behind companies (IBM's PL/I). Richie considered BCPL, which at the time had a design that made it pretty easy to port if your computer was word-based (same size of bit-width for all numbers regardless of purpose). But, mini-frames were moving towards byte-based data and word or multi-word-based addressing. Plus, mini-frames had poorer hardware to make it cheaper, so typing on them meant more physical work.

A lot of UNIX design came from trying to use less: less memory, less paper, less typing. Richie tried to simplify BCPL to be less wordy by making B, but ultimately decided to jump to the next thing by making a language that would require as few keystroke as possible. That's why C is so symbolic: what is the least amount of typing to perform the concept? That made it pretty easy to translate to a fixed set assembly instructions; however, it hasn't had a symbiotic relationship with assembly.

If anything, it is the reverse. Just look at the compiler for all of the memory addressing it has to know. Look at any reasonably complex program of all of the compiler directives to see all the platform exceptions. C++ really took failure modes to the next level. My favorites is "a = b/*c;" Is that "a equals b divided by value pointed at by c" or "a equals b" with a comment? I left C++ a long time ago because I could take code that would compile on two different platforms and result in totally different behavior.

I think all of this drama has to do with the simple fact of there a bunch of people content to live in a one-langauge dominated environment and the head of Linux doesn't want to decide if that is or isn't the mandate; however, by not taking sides, he has effectively taken the one-language mandate. Rust needs to reimplement Linux.

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

#165
The frustration seems justified.

Spending significant time adapting core kernel code or developing a safe Rust abstraction for DMA, only to be summarily shut down by a single gatekeeper who cites "not wanting multiple languages" is demotivating. It's especially incongruent given that others have championed Rust in the kernel, and Linux has begun hosting Rust modules.

If the project leadership — i.e. Linus — truly wants Rust integrated, that stance needs to be firmly established as policy rather than left up to maintainers who can veto work they personally dislike. Otherwise, contributors end up in a limbo where they invest weeks or months, navigate the intricacies of the kernel's development model, and then find out a single personality is enough to block them. Even if that personality has valid technical reasons, the lack of a centralized, consistent direction on Rust's role causes friction.

Hector's decision to leave is understandable: either you have an official green light to push Rust forward or you don't. Half measures invite exactly this kind of conflict. And expecting one massive rewrite or an all‐encompassing patch is unrealistic. Integration into something as large and historically C‐centric as Linux must be iterative and carefully built out. If one top‐level developer says "no Rust", while others push "Rust for safety", that is a sign that the project's governance lacks clarity on this point.

Hector's departure highlights how messy these half signals can get, and if I were him, I'd also want to see an unambiguous stance on Rust — otherwise, it's not worth investing the time just to beg that your code, no matter how well engineered, might be turned down by personal preference.

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

#166
post #98

Earlier quoted context omitted.

So moving to effectively censor criticism that you can't control is justified? Maybe the problem IS marcan, as Linus suggested. If you do things that are in the public interest, people are going to have opinions about what you do and on a wide spectrum. If you can't handle that, you probably shouldn't be doing work that's so public and visible. Especially something like maintainer work that is inherently social.

[flagged]

I remember that HN thread[0] and don't think Asahi's version is a good-faith, accurate summary of the contents. IMO they are inaccurately viewing a small number of flagged/dead comments as representative of HN in general.

[0] probably: https://news.ycombinator.com/item?id=33789940 , though you could look at any of the big 2022-2023 asahilinux.org discussions and find something flagged/dead

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

#167
post #160

Rust or not, mixing two different languages within a single project is a sure fire way for a maintenance nightmare. Specially for a large project like Linux. I sincerely don’t want something like that happening to the Linux kernel. Just let it die with C. However it may seem improbable, writing a kernel from scratch is the way to go for new wanna be system programming languages.

and they have one: Redox

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

#168

Earlier quoted context omitted.

I'm just parsing the thread but it seems that changes to the C api can break the Rust bindings. This leads to two situations: the C maintainer has to also update the Rust binding, or the patch has to wait for a Rust capable maintainer to fix them up. For the first solution, the C maintainer is claiming he has enough work on his plate just keeping up with the C code that he doesn't want to work on Rust. He also believ…

No, the point is nonsense. Rust is a consumer of the APIs just like every other driver / subsystem is. Any change to the C APIs would likely require collaboration with those other maintainers no different than Rust. And CH would be immediately shut down if he tried to roadblock some random driver that needs DMA purely because he doesn't want the existence of that driver to "increase his workload".

> some random driver that needs DMA purely because he doesn't want the existence of that driver to "increase his workload".

This isn’t blocking any drivers. Just adds duplicate code.

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

#169
post #56

Earlier quoted context omitted.

Yikes, re that fedi thread.

This one bit looks exactly right, though: > As for how to move forward, (...) Either Linus takes the pull, and whatever Christoph says is irrelevant, or he doesn't, and R4L dies. Everything else is a waste of everyone's time and energy. It does look like maintainers should have a "disagree and commit" mentality at some point, whatever decision they end up making. I thought Rust in Linux was evaluated, discussed and a…

That's a much stronger argument when you aren't at the same time yelling about the email patch system. I want R4L to succeed!

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

#170

Linus replied: How about you accept the fact that maybe the problem is you. You think you know better. But the current process works. It has problems, but problems are a fact of life. There is no perfect. 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…

Context I struggle to follow the LKML through the web-interface. LORE seems to provide a better view: 1. https://lore.kernel.org/lkml/a869236a-1d59-4524-a86b-be08a15... Maintainer of DMA wants to keep the code clean and not mixing languages[1]. And tries to avoid dangerous offers like "we will maintain it for you".[2] 2. https://lore.kernel.org/lkml/a869236a-1d59-4524-a86b-be08a15... Somebody references social media…

> The position of the DMA maintainer seems also to make sense for me, to keep code maintainable over decades it must remain in a nice and tidy state.

Perhaps so, but that discussion was two or three years ago. Stalling other contributors' work now is counterproductive, especially for changes that do not touch files maintained by them.

This does not justify any brigading behavior, though.

Post reply on HN