Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Resigning as Asahi Linux project lead

marcan.st

Post reply on HN
Print view View original

141–150 of 1001 posts

Re: Resigning as Asahi Linux project lead

#141

Post by diggan »

Capricorn2481 wrote: post #117
diggan wrote: post #85

Earlier quoted context omitted.

> He said it was not about literally shaming people The original message I read ( https://lore.kernel.org/rust-for-linux/208e1fc3-cfc3-4a26-98... ) they quite explicitly said (verbatim): "If shaming on social media does not work, then tell me what does, because I'm out of ideas."

Yes I'm aware of that quote, which doesn't make sense to link with the original quote because his intentions with the "Hall of shame" are different from this quote. This message brings up a lot of valid complaints about talented developers being stonewalled and you're honing in on one word that is not being used the way you think. Again, there are dozens of emails from Linus that are vastly more unprofessional than t…

> because his intentions with the "Hall of shame" are different from this quote.

Aha, I thought it was referring to the same "event"/context but it clearly didn't. Thank you for the correction.

Re: Resigning as Asahi Linux project lead

#142

Post by naasking »

Supermancho wrote: post #32
bezier-curve wrote: post #11

Earlier quoted context omitted.

What does social media have to do with bad code, though?

> What does social media have to do with bad code, though? Nothing. That's why this was said: >> *There's a deeper issue* in open-source culture where harshness and gatekeeping drive away passionate contributors. It's separate gatekeeping. I entertained getting involved in the kernel for about 3 days, in college. The process is so complex, I just went on to do other fun things. The drama will turn off others. Organiz…

I disagree. Provoking up a mob on social media will not endear you to anyone. You're just making the gatekeeper's jobs harder, and since their job is hard enough, they will simply gatekeep you to simplify things.

Regardless of whether you think the project should be maintained differently, that's not your call, that's their call. Fork it if you want different policies.

Re: Resigning as Asahi Linux project lead

#143

Post by sharpshadow »

lenova wrote: post #140

This part of the post is being overlooked: Then 2024 happened. Last year was incredibly tumultuous for me due to personal reasons which I won’t go into detail about. Suffice it to say, I ended up traveling for most of the year, all the while having to handle various abusers and stalkers who harassed and attacked me and my family (and continue to do so). This is _not_ ok in any form, what the actual hell?

Absolutely not okay and I somehow hope it hadn’t todo with Asahi Linux.

Re: Resigning as Asahi Linux project lead

#144

Post by ryandrake »

throwway120385 wrote: post #123
iamacyborg wrote: post #119

Earlier quoted context omitted.

When you pay for something, you’ve already demonstrated that you value whatever it is (a product, a service, etc). Free stuff tends to attract people who don’t value the thing.

There's also a level of professionalism depending on the product. When I'm responsible for an MSP team I'm very polite to them and always try to get them good, detailed, high-quality information when I'm telling them about problems with their work product, because I want them to do good work quickly and that's the best way to do that.

Yea, I'm not sure it's open-source vs other software. It's public vs. professional insiders.

My company's bug tracker is mostly internally-filed bugs, but accepts bugs from the public. The difference in tone and attitude is night and day. The public-filed bugs can be wild, varying across: Rude, entitled, arrogant, demanding, incoherent, insulting, irrelevant, impatient... They are also the worst when it comes to actually including enough information to investigate. Frequently filed without logs, without reproduction steps, sometimes without even saying what the filer thinks is wrong. We get bugs with titles "It doesn't work" and with a text description that reads like a fever dream from someone very unwell.

We do have strong personalities among employees, but bug reports tend to be professionally and competently written, contain enough information to debug, and always, always leave out insults and personal attacks. The general public (at least many of the ones technical enough to file bug reports) does not seem to have the emotional regulation required to communicate professionally and respectfully.

Re: Resigning as Asahi Linux project lead

#145

Post by jisnsm »

If Marcan (Hector Martin) is serious about quitting Linux development, he will stop contributing to the project using his Asahi Lina persona as well. Until then this is just empty posturing trying to elicit a reaction from the community.

Re: Resigning as Asahi Linux project lead

#146

Post by busterarm »

pmarreck wrote: post #108

Drama needs to be worked against, not expanded upon. A lot of what I’m reading seems to make me feel that drama was… not avoided by this person, putting it charitably. And I'm someone who I believe still sponsors them! Asahi Linux is an awesome, and dare I say necessary, project. There is value in learning how to relinquish a constant "defensive posture" mentally. (I have struggled with, and am still working through…

Agreed. There's such a victim mentality throughout this post.

While it's clear that marcan faced into headwinds, they're also definitely not somebody that I want to be around me in any kind of leadership position.

Re: Resigning as Asahi Linux project lead

#147

Post by imiric »

This is unfortunate, but before pointing fingers, it's worth putting things into perspective.

The linked "thin blue line" message[1] also says this:

> One of the things which gets very frustrating from the maintainer's perspective is development teams that are only interested in their pet feature, and we know, through very bitter experience, that 95+% of the time, once the code is accepted, the engineers which contribute the code will disappear, never to be seen again. As a result, a very common dynamic is that maintainers will exercise the one and only power which they have --- which is to refuse to accept code until it is pretty much perfect --- since once we accept the code, we instantly lose all leverge, and the contributors will be disappear, and we will be left with the responsibility of cleanig up the mess. (And once there are users, we can't even rip out the code, since that would be a user-visible regression.)

Which seems very reasonable. Maintainers shouldn't be expected to support a feature indefinitely just because a 3rd party is interested in upstreaming it. In the case of Rust for Linux and the Asahi project specifically, I imagine this would entail a much larger effort than any other contribution. So just based on this alone, the bar for entry for Asahi-related features should be much higher.

Perhaps this is ultimately a failure of leadership as TFA claims, but it would be foolish to blame the Linux maintainers or its development process, and take sides either way. Maybe what Asahi is trying to accomplish just isn't a good fit for mainline Linux, and they would be better served by maintaining a hard fork, or developing their own kernel.

[1]: https://lore.kernel.org/lkml/20250208204416.GL1130956@mit.ed...

Re: Resigning as Asahi Linux project lead

#148

Post by unethical_ban »

yencabulator wrote: post #129
unethical_ban wrote: post #39

It sound like there are two major questions: Do the demigods of the Linux kernel - Linus and the core maintainers - personally want the kind of code Asahi is developing to be merged into the kernel? The author writes as if part of his drive was that Linus himself showed enthusiasm for getting Linux on Apple Silicon. If there is interest in the work Asahi has done, then the Linux team needs to describe what they see a…

And it sounds like you read just one side of the story, with no background in Linux kernel internals. This is about how C APIs are typically inherently unsafe, Rust people wanting to build safe(r) abstractions on top, and a question of who is responsible for changing what code when it's time to refactor the underlying C API. And yes, marcan is being overly dramatic, though he is not alone in that.

I do not claim a background in Linux kernel internals. I'm a human who has seen teams miscommunicate in the past, and see it now. I'm not sure what I said that drew hostility.

It sounds like you agree with me though. The Linux team needs to clearly define the expectation they have for code maintenance from the team trying to upstream Rust code (edit) and the Asahi team needs to acknowledge how/if they can meet those expectations.

Re: Resigning as Asahi Linux project lead

#149

Post by segmondy »

galoisscobi wrote: post #13

> But then also came the entitled users. This time, it wasn’t about stealing games, it was about features. “When is Thunderbolt coming?” “Asahi is useless to me until I can use monitors over USB-C” “The battery life sucks compared to macOS” (nobody ever complained when compared to x86 laptops…) “I can’t even check my CPU temperature” (yes, I seriously got that one). This sounds so rough. I can't imagine pouring your…

You gotta have super thick skin to be a maintainer of an opensource project or even be popular on the net these days. Folks are going to come for you for whatever reason, if you read too much into it you're going to have a bad time.

Re: Resigning as Asahi Linux project lead

#150

Post by gpm »

surajrmal wrote: post #87
Octoth0rpe wrote: post #9

Well that's unfortunate. It seems like there's a balancing act between the benefits of writing drivers in Rust (easier, more maintainable), and getting those drivers mainlined (apparently soul-destroying, morale killing), I wonder if the Asahi team is considering simply abandoning linux in favor of something more rust friendly (redox being an obvious candidate, but maybe one of the BSDs?). Given the narrow set of har…

They would need to completely reset to do that. Do BSDs even have rust support for their drivers?

For what it's worth, the Oxide Computing people have written illumos driver(s) in rust: https://github.com/oxidecomputer/opte/tree/master/xde
Post reply on HN