Live data from Hacker News

Resigning as Asahi Linux project lead

marcan.st

551–560 of 1001 posts

Re: Resigning as Asahi Linux project lead

#551
post #453

Earlier quoted context omitted.

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.

Can’t say I’d want you on the team characterizing a situation like this, and communicating about a situation like this, as “victim mentality.” There’s a lot of toxic behaviors that have wormed their way into certain parts of culture. I’m not as concerned about bright, brash men like Hector.

lol - you're not concerned about having people who threaten to create a "hall of shame" for kernel developers??!

Jesus, I wouldn't want to work with either of you...

Re: Resigning as Asahi Linux project lead

#552
post #425
post #175

Earlier quoted context omitted.

> And then he can't help himself. After being so reasonable, he throws shade on Rust. Shade that is just unfortunately, just false? Many discussions online (and offline) suffer from a huge-group of people who just can't stop themselves from making their knee-jerk reactions public, and then not thinking about it more. I remember the "Filesystem in Rust" video ( https://www.youtube.com/watch?v=WiPp9YEBV0Q&t=1529s ) whe…

> "no one will be forced to use Rust in the Kernel" Is this true, though? One reason for this altercation seems to be the basic circumstance that in Linux kernel development, if there is a dependency between two pieces of code A and B, the responsibility to keep B consistent with changes to A lies, in order, with anyone proposing patches to A, the subsystem maintainer for A, and finally the subsystem maintainer for B…

It's absolutely not true, it's one of the lies being told by Rust 4 Linux people. The end goal is absolutely to replace every last line of C code with Rust, and that's what they will openly tell you if you speak to them behind closed doors. That's why there is always an implicit threat directed at the C maintainers about job loss or "being on the right side of history". The Rust 4 Linux people are absolutely attempting a hostile takeover and nobody should believe a word that comes out of their mouths in public mailing lists when they are contradicting it so consistently behind closed doors.

Re: Resigning as Asahi Linux project lead

#553

Earlier quoted context omitted.

Thank you to share the Ted T'so LKM post. Can you explain the culture reference "thin blue line"? I never heard it before.

It's a motto used by American law enforcement to justify extrajudicial punishment. Since they are the "thin blue line" that separates the public from anarchy, they are justified in acting independently to "protect" us when judges and juries do not "cooperate".

That is a very strange take. The phrase isn't American and has no negative connotation. It has nothing to do with "extrajudicial punishment". It simply refers to the (obvious) fact that what separates societies from anarchy is the "thin blue line" of law enforcement.

Rowan Atkinson had a sitcom set in a London police station in the 90s called "The Thin Blue Line". Are you under the impression he was dogwhistling about extrajudicial violence?

Re: Resigning as Asahi Linux project lead

#554

"we were still stuck without DP Alt Mode (a feature which required deep reverse engineering, debugging, and kernel surgery to pull off, and which, if it were to be implemented properly and robustly, would require a major refactor of certain kernel subsystems or perhaps even the introduction of an entirely new subsystem)." Few maintainers care about the platform in question (to whom it's more a curiosity like maybe 68…

Are you saying that PCs do not usually have the ability to plug into a monitor, to charge, and to connect to a USB hub for the rest of your devices from a single USB-C port? You guys still plug three cables each time you sit at a desk?

When was the last time you touched a PC, 2003? They most certainly do, when the OEM actually supports it: https://www.kernel.org/doc/html/latest/admin-guide/thunderbo...

It's not ever coming to Apple Silicon on Linux since post-Thunderspy, Thunderbolt is dangerous to implement even in the best of circumstances. You'd have to reverse-engineer and update Apple's IOMMU, write software drivers for the port since it doesn't have firmware and test it across a variety of vulnerable devices to see how secure it is.

Re: Resigning as Asahi Linux project lead

#555

Earlier quoted context omitted.

I was hit by a similar thing. Rust once caused regression failures in 5000+ packages due to incompatibility with older "time" packages [1]. It was considered okay. At that point, I don't care what they say about semver. [1]: https://github.com/rust-lang/rust/issues/127343#issuecomment...

That was a mistake and a breakdown in processes that wasn't identified early enough to mitigate the problem. That situation does not represent the self imposed expectations on acceptable breakage, just that we failed to live up to it and by the time it became clearer that the change was problematic it was too late to revert course because then that would have been a breaking change. Yes: adding a trait to an existing…

Maintaining backward compatibility is hard. I am sympathetic. Nonetheless, if the rust dev team think this is a big deal, then clarify in release notes, write a blog post and make a commitment that regression at this level won't happen again. So far, there is little official response to this event. The top comment in the thread I point to basically thinks this is nothing. It is probably too late do anything for this specific issue but in future it would be good to explain and highlight even minor compatibility issues through the official channel. This will give people more confidence.

Re: Resigning as Asahi Linux project lead

#556

Earlier quoted context omitted.

It's not just that "people are hard" - it was clear that this will end up this way the moment marcan started ranting on social media about having to send kernel patches via e-mails. Collaborating on software development is a social activity and stuff like convincing maintainers to trust you and your approach is just as important part of it (if not more important) as writing code. Not realizing that is a sure road to…

> it was clear that this will end up this way the moment marcan started ranting on social media about having to send kernel patches via e-mails. Collaborating on software development is a social activity and stuff like convincing maintainers to trust you and your approach is just as important part of it (if not more important) as writing code. Yeah but FFS using email for patches when there are so much better ways of…

> Yeah but FFS using email for patches when there are so much better ways of doing development with git?

You are missing one point, namely that email is probably the only communication medium that's truly decentralized. I mean, on most email providers you can export your mailboxes and go to someone else. You can have a variety of email clients and ways to back up your mailboxes. No git clone, no specific mailbox or server is in any way special, I think Linus emphasized recently that they made efforts to ensure kernel.org itself is not special in any way.

Yes, I find Github's or Gitlab's UI, even with all enshittification by Microsoft and whatnot, better for doing code reviews than sight-reading patches in emails. And yet I cannot unsee a potential danger that choosing a service — any service! — to host kernel development would make it The Service, and make any migration way harder to do than what you have with email. Knowing life, I'd say pretty confidently that an outcome would be that there would be both mailing lists and The Service, both mandatory, with both sides grumbling about undue burdens.

Have you ever been in a project which had to migrate from, say, Atlassian's stack to Github, or from Github to Gitlab, or vice versa? Heck, from SourceForge + CVS/SVN to Github or similar? Those were usually grand endeavors for projects of medium size and up. Migrate all users, all issues, all PRs, all labels, test it all, and you still have to write code while it all is happening. Lots of back-and-forth about preserving some information which resists migration and deciding whether to just let it burn or spend time massaging it into a way the new system will accept it. Burnout pretty much guaranteed, even if everyone is cooperating and there is necessity.

But you could probably build tools on top of email to make your work more pleasant. The whippersnappers who like newer ways might like to run them.

Re: Resigning as Asahi Linux project lead

#558

Earlier quoted context omitted.

Yup, I think it went too far. The fact is, you need buy in from other devs and if a dev won't buy in you need to work out a way to avoid them or avoid conflict. It sucks, it slows things down, but frankly making it a "them vs us" is a sure fire way to make them oppose any change you want to make. Public shaming even more disastrous as there's no better way to entrench someone in a position.

But the point is that the Rust developers have tried literally everything else. If the C developers make it a "Them vs Us" thing, there IS NO ALTERNATIVE for the Rust developers. Linus' reaction is quite literally the equivalent of a parent only punishing the loudest child, not the child that's been silently bullying that kid for months.

Why should there be an alternative for Rust developers? Are they entitled to having their code merged?

Re: Resigning as Asahi Linux project lead

#559
I was contributing a (very small) amount of money each month until 2024, when it seemed like Marcan had stopped working on the project.

It was hard to decide to stop the financial support. On the one had I want maintainers to be able to take breaks without worrying about their livelihood. On the other hand, it was very difficult to tell what was going on and whether Marcan would ever get back to working on the project.

Re: Resigning as Asahi Linux project lead

#560

Earlier quoted context omitted.

That was a mistake and a breakdown in processes that wasn't identified early enough to mitigate the problem. That situation does not represent the self imposed expectations on acceptable breakage, just that we failed to live up to it and by the time it became clearer that the change was problematic it was too late to revert course because then that would have been a breaking change. Yes: adding a trait to an existing…

TBH that's a level of quality control that probably informs the Linux kernel dev's view of Rust reliability - it's a consideration when evaluating the risk of including that language.

Kernel devs more than almost everyone else are well aware that even the existing C toolchains are imperfect.
Post reply on HN