Live data from Hacker News

Asahi Linux lead developer Hector Martin resigns from Linux kernel

lkml.org

871–880 of 1001 posts

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

#871
post #448

Earlier quoted context omitted.

It's way more painful to contribute to the kernel than contribute to Firefox, at least, unless things have changed since I was involved with Firefox. Suppose you find a bug in the kernel and come up with a patch. You email the patch to some kernel mailing list and ask for feedback. Typically, you will receive no response whatsoever, because no-one is responsible for responding. You can try emailing random developers…

In my experience it's the opposite - the email patch usually gets dealt with within a week or two, Firefox and Chromium dragged out because it wasn't whatever Mozilla or Google prioritized right now. Or worse, it might go against an internal corporate KPI. In Firefox you have to fiddle with Mercurial, phabricator, and their homegrown CI. In Chromium its Gerrit and their homegrown CI, and oh btw you touched code that…

"The email patch usually gets dealt with within a week or two" is absolutely not my experience dealing with the kernel.

Firefox and Chromium's bespoke tools have their pluses and minuses but they're a lot easier to deal with that the kernel "workflow".

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

#872
post #869

Earlier quoted context omitted.

In general, upstreaming code to Linux involves interacting with difficult and sometimes outright hostile people. I've certainly had my share of both with much smaller changes. IMO pushing something like R4L requires very thick skin and almost infinite amount of patience. Bitching about that won't get you far, you need to be able to either work with or around those people.

This again gets back to the main point which you keep misrepresenting. This has nothing to do with a thick skin, this is a core subsystem maintainer outright saying they won't support R4L, which means its dead.

I'm not misrepresenting anything and R4L is not dead. In fact, two ways forward where suggested right in the LKLM email thread:

- Send the series directly to Linus since there is no code that Hellwig is maintainer of is actually being changed by it and let Linus decide whether to ignore Hellwig's nack. Linus may have done so before, but likely not after marcan's public meltdown.

- Copy/paste the code to every driver that will be using it. If it becomes useful, it will cause more pressure on Hellwig down the road because people will question why every change in code that is being wrapped by this is causing a fix in 10 different copies.

People here and on Reddit who are unfamiliar with the Linux development process but are attracted to the "drama" because it involves Rust somehow keep missing it.

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

#873
post #377
post #345

Earlier quoted context omitted.

I feel the exact same. Marcan has done amazing work, and his random blog entries etc have saved me hours of debugging time in the past. But jeez, it is really painful to see him say absolute nonsense like "If shaming on social media does not work, then tell me what does, because I'm out of ideas." - he has gotta Stop Posting and keep those kinds of thoughts away from his keyboard.

If Linus thinks that the social media angle is wrong, he should defuse situations before they become explosive because even if one of the devs didn't bring up the drama, there are dozens of news companies that would have printed up articles the second they found the discussion anyway. Linus should have stepped in long before a maintainer blew their stack and started throwing out ultimatums. Once that happened, Linus…

Linus, as someone far removed from LKML, seems like he hates external visibility of what he wants to be effectively "internal" discussion more than anything else.

Not in the sense of "he wants the mailing lists private", but in the sense that "he doesn't want public complaint about private discussions", which feels like an evolution of "technical merit should win", as a position.

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

#874
post #833

Earlier quoted context omitted.

Partially, but it takes two to tango. There are softer ways to work with abrasive attitudes that can ultimately accomplish your goals. A key part of that is knowing which battles are worth fighting. Sometimes, it's better to let a suboptimal solution in to appease an ego. I think Hector's change is the right one, but I also think with the dma maintainer being unwilling to budge the next move is to hack in a location…

Do you mean location as in different subsystem than dma, which is required for all modern devices. Or just location as in stash the files outside the dma directory?

> Or just location as in stash the files outside the dma directory?

This one. The code in question, AFAIK, is a rust wrapper around the DMA subsystem. I think that does best belong in the DMA subsystem but with the maintainer unwilling to accept it the next place to put it is either in a new rust-dma subsystem/wrapper or to pull out the parts needed and integrate them directly in the drivers in question (certainly nasty and a lot of duplicate effort).

The goal for such code should ultimately be to cause as little friction as possible with the DMA maintainer.

If it comes up in the mailing list that "this is dumb and you shouldn't do this" that's when you loop in the DMA maintainer and request their suggestions on how to proceed with whoever challenges the change. Put them in the seat of making the decision of where the code should go.

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

#875
post #774

Earlier quoted context omitted.

Sure, but (1) that ship has sailed for now, there are already Rust bits in the kernel; and (2) a patch email thread is not the best place to start discussing whether Rust has a place in the kernel.

Is it impossible to just delete the rust parts and go back to pure C? That ship could come back to port anytime.

That's not a decision that can or should come out of a patch review. I agree it's a possible decision, not something unthinkable. But if it were, it should be taken at a completely different level.

Basically, it's an obstructionist, uncivilized thing to hold up every discussion about a topic that you get to participate in by insisting the topic shouldn't be discussed in this forum. It's perfectly OK to advocate for the removal of Rust from the kernel, it's not ok to bring this up in every random Rust patch while the consensus is that Rust has a place in the kernel.

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

#876
post #834

Earlier quoted context omitted.

If you looks at the history then you will see that many different solutions have been proposed but Christoph's responses essentially boil down to 'do it somewhere else' and 'no not there', until it is basically 'not at all'. He is not in a position to make this decision, only Linus is. The patch as it stands lives outside of any sub-systems within Christoph's purview, he is simply being obstructionist out of tribalis…

> he is simply being obstructionist out of tribalism. What about the part quoted in GPs comment? > > The only reason Linux managed to survive so long is by not having internal boundaries, and adding another language complely breaks this Wouldn't adding another language add an internal boundary? I don't know enough the kernel or kernel development to say it's an good argument or not, but it doesn't seem to be tribalis…

I agree that it may not be tribalistic, it's very possible that the maintainer has a valid technical/social opinion on this.

However, I don't think it is in any way acceptable to insert this in discussions about a random Rust patch. It's disrespectful to the time and expertise of the people who submitted these patches to first nitpick various technical items, only to later make it clear you were never going to accept their patch in the first place, because you dislike and oppose the decision that you know has already been made, to allow Rust in the kernel.

If he instead was (1) upfront about the fact that he would never allow Rust code in the subcomponent he maintains, and (2) stepped out of the discussion of this patch once it was moved out of said component, and then (3) started a completely separate thread on changing the kernel's stance on Rust to block all future patches and consider removing it entirely, that would all have been normal respectable behavior.

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

#877

Earlier quoted context omitted.

I don't think that's true. I think the C guys told themselves that writing safe C code is just a matter of skill, but data shows that the amount of skill necessary to avoid writing unsafe C just isn't there. The average C developer isn't as competent as they claim. You can lie to yourself and say that the same security problems exist in other languages, but that isn't true. When I check the vulnerabilities marked as…

Rust is sadly more about marketing than actually being popular or safe. That stackoverflow survey rust folks so proudly crow about shows it’s the #1 ‘admired’ language, well #2 was closure and Zig over the years which clearly shows the value of the survey. Just marketing slop. The rust produces safe code claim is also marketing garbage. The rust standard library has over 7.5k (of 35k) unsafe functions in it. The core…

> "The rust produces safe code claim is also marketing garbage. The rust standard library has over 7.5k (of 35k) unsafe functions in it. The core library has 7K (of 21k) unsafe functions."

"it’s important to understand that unsafe doesn’t turn off the borrow checker or disable any other of Rust’s safety checks"[1]. Using the Rust keyword 'unsafe' doesn't make the code inside it the Wild West or automatically an exploit or a problem, it is a limited-scope relaxing of only some checks.

[1] https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html

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

#878
post #826

Earlier quoted context omitted.

But the initial cost is what determines whether the first patch will ever be sent, so the amortization may never happen.

I guess technically that’s true, but it cannot possibly take long to learn how to use `git format-patch`, and everyone should already know how to attach a file to an email. Even if you have to spend half an hour reading the entire output of `git format-patch --help`, is that really enough to prevent you from sending your first patch?

Yes.

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

#879
post #194

Earlier quoted context omitted.

I honestly don't understand what the difference is between "brigading" and "complaining about a thing on mastodon". It's not uncommon to express frustration about something/someone associated with the kernel development process, what makes this particular instance "brigading"?

The difference is between posting "ugh, having a hard time with someone on a project, they're blocking this merge and I don't think it's for a good reason" and literally starting your post with "Behold," linking directly to a mailing list post, and misrepresenting the other person's objections as "sabotage."

I mean when what you're frustrated about is a leader actively sabotaging what you're working on...

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

#880
Zig will likely go through the same trials and tribulations that Rust has for introduction into the Linux kernel. Considering Zig's better C interopt, the fact that the Zig compiler can natively compile C, the Zig community's lack of zealotry and proselytizing that plagues the Rust community, etc., I believe it will be better received.
Post reply on HN