Live data from Hacker News

Resigning as Asahi Linux project lead

marcan.st

721–730 of 1001 posts

Re: Resigning as Asahi Linux project lead

#721
post #249
post #145

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.

Is he really still pretending that his vtuber persona is a different person? That makes this way more of an embarrassing attention-grab than it already was.

Yes. He is not fooling anyone else. We all know that marcan is Asahi Lina.

Out of the links that one other person posted in the replies, these are the most convincing and the most damning to conclude this. [0] [1] [2] [3]

[0] https://news.ycombinator.com/item?id=35251905

[1] https://news.ycombinator.com/item?id=37550189

[2] https://news.ycombinator.com/item?id=35238601

[3] https://news.ycombinator.com/item?id=43041525

Re: Resigning as Asahi Linux project lead

#722
To me, this is more like a Rust cancer situation.

Supporting and developing Rust is a nice to have, but too often its proponent try to force stuff it deeply inside important stacks that are using other languages like for Linux, or what is going on with major things in Python also.

Here we can see the case, that is almost a blackmail that the Linux community is not nice and will die if they don't make Rust support core and mandatory.

My point is that, if you like Rust and Rust is so nice, just go all-in, do your own kernel, do your own stuffs, and we will see the result in the end. But don't ruin existing good stuffs that were working well on their own.

Re: Resigning as Asahi Linux project lead

#723

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".

No, that's not really true.

Directly, "the thin blue line" expresses the idea that the police are what separates society from chaos.

It doesn't inherently suggest police are justified in acting outside the law themselves, though, of course, various people have suggested this (interestingly, from both a pro-police and anti-police perspective).

It seems obvious to me that the post was using this phrase in the sense of being a thin shield from chaos.

Re: Resigning as Asahi Linux project lead

#724

Earlier quoted context omitted.

>They're not "forced to use Rust". They are maybe forced to work with Rust developers of whichever subsystem needs to be updated So if the maintainer of subsystem X can be forced to work with the rust developers of their own subsystem, then that rust developer just got promoted to co-maintainer with veto power. Effectively that's what they'd be, right? I can see why maintainers might not like that. Especially if they…

If a subsystem C developer makes a change and introduces a bug in another driver or subsystem (also written in C) as a result, then you would expect them to be able to help at least insofar as explaining what they changed. That isn't "effective co-maintainership".

I've been in a spot kinda like this. I've maintained C++ with python interfaces. In my case I wrote both. I know how interlocked the changes were. If I touched code that was exposed to the python, I updated the python interface and the consumers of that python interface.

It was nothing like making changes that cut across into another developer's C++ code (hell, I would even update their python interfaces/consumers too). That was temporary coordination. The python part was much more frequent and required much more detailed understanding of the internal APIs, not just the surface.

Having someone else responsible for the python part would have come at a huge cost to velocity as the vast majority of my changes would be blocked on their portion. It's ridiculous to imply it's equivalent to coordinating changes with another subsystem.

Re: Resigning as Asahi Linux project lead

#725

Earlier quoted context omitted.

People are free to think whatever they want, and, if they what to rewrite things in Rust or whatever language, that's how many of us learn! Yes, they're free to rewrite their own projects in Rust. They aren't free to force others to do the same to their projects. That's what this is all about: a prominent R4L community leader tried to use brigading and shaming to force a Linux kernel maintainer into accepting and mai…

> Yes, they're free to rewrite their own projects in Rust. Um, or any other they so choose? > Yes, they're free to rewrite their own projects in Rust. They aren't free to force others to do the same to their projects. Where is anyone forcing anyone else to do a rewrite in Rust?

If you're forking the Linux kernel then it becomes your own project, de facto, since you're taking over maintenance of the fork. You're free to rewrite it in Rust when you do that!

Where is anyone forcing anyone else to do a rewrite in Rust?

When hellwig likened the R4L project to a cancer, he was implying exactly this. He saw this one patch as a Trojan horse (in the original Greek sense, not in the computer virus sense) to get Rust into the main kernel tree. This brings all of the toolchain and language issues into it. By relegating Rust to drivers only, the kernel maintainers avoid the issue of having to maintain a cross-language codebase and toolchain, whether they like it or not.

Being a maintainer of a project that accepts patches from contributors is like operating an orphanage. Allowing anyone to just drop off their unwanted babies results in an unmaintainable nightmare. You can say that the Rust for Linux team have been acting in good faith but the very public actions of one of their (now former) leaders contradicts this. The stated goal of the project was to allow drivers to be written in Rust. Adding Rust bindings to the kernel oversteps that goal. It's a legitimate concern.

Re: Resigning as Asahi Linux project lead

#726
post #426

Earlier quoted context omitted.

This is not how the kernel works. You cannot rely on someone's "commitment" or "promise". Kernel maintainers was to have very good control over the kernel and they want strong separation of concern. As long as this is not delivered, it will be very hard to accept the Rust changes.

At some level this is just concern trolling. There is nothing the Rust developers could possibly do or say that would alleviate the concern you've just expressed. You are asking for something that is impossible. What could they possibly "deliver" beyond a strong commitment to fix the code in a timely manner themselves?

The standard procedure is to maintain a fork/patchset that does what you want and you maintain it for years proving that you will do the work you committed to.

Once it’s been around long enough, it has a much better chance of being merged to main.

Re: Resigning as Asahi Linux project lead

#727

Staying away from the emotional part of this blog post. I was about to write a question to ask why, if these downstreams are forked, that it is such a big deal to be gatekeeping the upstream and I think I got my answer from this: "In fact, the Linux kernel development model is (perhaps paradoxically) designed to encourage upstreaming and punish downstream forks. While it is possible to just not care about upstream an…

>Is it wrong for Linus to take the side of the kernel and not of the various distros? Serious question. I don't completely understand all of the background here.

Linus is pro-R4L. He wants to see Rust drivers in the kernel upstream, and has expressed frustration that it has been such a slow process, and that he doesn't understand why some maintainers turn it into a religious issue.

The problem is that he hasn't done much in the way of actually standing up against arbitrary stonewalling by those maintainers. This ensures that everyone gets pissed off and creates a giant mess of arguments. Rust people get pissed off because they were told their contributions were welcome and feel like their time investment is being wasted on bullshit, and C maintainers because the lack of a clear policy leads to ruminating and imaginations running wild.

Re: Resigning as Asahi Linux project lead

#728
post #43

Earlier quoted context omitted.

> Did you read the article? Did you read the rest of it? Sure Apple being not as great to develop drivers, but ~99% of the article is about displeasure working with Linux maintainers. EDIT: Here is the breakdown by paragraphs. | Paragraph # | Tone | | ----------- | -------------------------------------------------------------------------- | | 1 | History recap | | 2 | History recap | | 3 | mentions Apple and M1 in po…

This is a beautiful and well done table. The exact formatting and the inclusion of extra statistics are appreciated.

Table formatting credit goes to Obsidian Text. I'm just surprised it worked so well with Google Drive copy-pasta.

Re: Resigning as Asahi Linux project lead

#729
post #497

Earlier quoted context omitted.

> which is actively hostile to a second Rust compiler implementation Which is hilarious since Linux itself was actively hostile to the idea of a second C compiler supporting it. Just getting Linux to support Clang instead of only GCC was a monumental task that almost certainly only happened because Android forced it to happen.

It happened because the Android people put in the work to make it happen both in Linux and in Clang/LLVM.

hello!

Re: Resigning as Asahi Linux project lead

#730

> 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…

This is every successful product, small, medium, large. I've never ever worked on a big corporate or small personal project and not experienced this. The secret is to have a healthy system for taking in those requests, queueing them by priority, and saying, "you are 117 in the queue, you can make it faster by contributing or by explaining why its higher priority". You can't let feature requests get to you, the moment…

Open source is about liberating computing not about liberating users.

If you're supporting end users you need to be collecting money from them.

The mechanics of this system are entirely upside down. The corporations have bought into open source to regain control of computing and passionate developers are mired in the swamp of dumb user requests.

Something went very wrong here.

Post reply on HN