Resigning as Asahi Linux project lead • Hacker News Board

Re: Resigning as Asahi Linux project lead

#501

Post by uecker » Thu, Feb 13, 2025, 6:49 PM UTC

uecker wrote: post #457

mcosta wrote: post #393

Earlier quoted context omitted.

Or "change is progressing rapidly in an area I am working 20 years and I have seen this kind of thing failing before"

I think confronting those volunteers that maintain open-source software with arguments such as "you just do not want to learn new things" , "are scared of change", etc. is very unfair. IMHO new ideas should prove themselves and not pushed through because google wants it or certain enthusiastic groups believe this is the future. If Rust is so much better, people should just build cool stuff and then it will be success…

Overall, this whole situation seems entirely weird to me. All this stuff such as Unix, Linux, and C ecosystem was build by C programmers and maintained for decades mostly voluntarily, while most of the industry pushed into other directions (with a gigantic influx of money). It is completely amazing that Linux become so successful against all the odds. Certainly it also then had a lot industry support, but I used it already before most of this and witnessed all the development. But somehow, C programmers are now suddenly portrayed as the evil gatekeepers, not stepping aside fast enough, because some want to see change. In the past, the people wanting to see something new in the open-source community would need to convince the community by building better things, not by pushing aggressively into existing projects.

Re: Resigning as Asahi Linux project lead

#502

Post by tuna74 » Thu, Feb 13, 2025, 6:49 PM UTC

dataflow wrote: post #422

nindalf wrote: post #93

Marcan links to an email by Ted Tso'o ( https://lore.kernel.org/lkml/20250208204416.GL1130956@mit.ed... ) that is interesting to read. Although it starts on a polarising note ("thin blue line"), it does a good job of explaining the difficulties that Linux maintainers face and why they make the choices they do. It makes sense to be extremely adversarial about accepting code because they're on the hook for maintaining…

> It makes sense to be extremely adversarial about accepting code because they're on the hook for maintaining it after that. They have maximum leverage at review time, and 0 leverage after. I don't follow. The one with zero leverage is the contributor, no? They have to beg and plead with the maintainers to get anything done. Whereas the maintainers can yank code out at any time, at least before when the code makes it…

Maintainers can't yank out code if that leads to feature, performance or user space regressions.

Re: Resigning as Asahi Linux project lead

#503

Post by pornel » Thu, Feb 13, 2025, 6:49 PM UTC

cornstalks wrote: post #229

nindalf wrote: post #93

Marcan links to an email by Ted Tso'o ( https://lore.kernel.org/lkml/20250208204416.GL1130956@mit.ed... ) that is interesting to read. Although it starts on a polarising note ("thin blue line"), it does a good job of explaining the difficulties that Linux maintainers face and why they make the choices they do. It makes sense to be extremely adversarial about accepting code because they're on the hook for maintaining…

> Rust has a stability guarantee since 1.0 in 2015. Any backwards incompatibilities are explicitly opt-in through the edition system, or fixing a compiler bug. Unfortunately OP has a valid point regarding Rust's lack of commitment to backwards compatibility. Rust has a number of things that can break you that are not considered breaking changes. For example, implementing a trait (like Drop) on a type is a breaking ch…

Meaning of this code has not changed since Rust 1.0. It wasn't a language change, nor even anything in the standard library. It's just a hack that the poster wanted to work, and realized it won't work (it never worked).

This is equivalent of a C user saying "I'm disappointed that replacing a function with a macro is a breaking change".

Rust had actual changes that broke people's code. For example, any ambiguity in type inference is deliberately an error, because Rust doesn't want to silently change meaning of users' code. At the same time, Rust doesn't promise it won't ever create a type inference ambiguity, because it would make any changes to traits in the standard library almost impossible. It's a problem that happens rarely in practice, can be reliably detected, and is easy to fix when it happens, so Rust chose to exclude it from the stability promise. They've usually handled it well, except recently miscalculated "only one package needed to change code, and they've already released a fix", but forgot to give users enough time to update the package first.

Re: Resigning as Asahi Linux project lead

#504

Post by sneedle » Thu, Feb 13, 2025, 6:49 PM UTC

[dead]

Re: Resigning as Asahi Linux project lead

#505

Post by kllrnohj » Thu, Feb 13, 2025, 6:50 PM UTC

cogman10 wrote: post #30

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…

> Given the narrow set of hardware they're aiming to support and that they're writing many of their own drivers _anyway_ (and so are not relying as much on the large # of existing linux drivers), that approach might be more viable. They are relying heavily on mesa. I'd also assume that GNU stuff is also pretty essential. Perhaps Android would be possible? It has a HAL that might be easier to work with than the raw li…

Android would still come with the kernel development caveats which is where Asahi is having the most trouble. Android's HALs help abstract the userspace portion of drivers, but if you need to be in kernel space you're still stuck dealing with Linux. You could stick to just doing forks of the LTS releases, but then you're choosing between less-frequent-but-bigger merge conflicts every couple years vs. small-but-constant merge conflicts continuously.

Re: Resigning as Asahi Linux project lead

#506

Post by sangnoir » Thu, Feb 13, 2025, 6:50 PM UTC

ecshafer wrote: post #363

unclad5968 wrote: post #337

Earlier quoted context omitted.

> People will look on Rust community after this and say "Remember that time when _they_ where threatening kernel devs with social media drama?". It's not right but that's the perception that will last. Happened with actix, happened with serde, and now being threatened by kernel contributors. The perception seems at least somewhat based in reality.

Rust, which is a language I really enjoy, generates more social media outrage and religious wars than any other technical project I have been following for the past 20 years.

There's something about Rust that draws Zealots (or draws out zealotry in people). It's not at Haskell's level, but there are several culty elements for the fanatics: secret knowledge, being 'chosen' or set aside from the ignorant plebians, and an unshakable belief in a form of rapture when the language will inevitably win when everyone realizes the superiority of monads/memory safety.

Re: Resigning as Asahi Linux project lead

#507

Post by fransje26 » Thu, Feb 13, 2025, 6:52 PM UTC

ecshafer wrote: post #363

unclad5968 wrote: post #337

Earlier quoted context omitted.

> People will look on Rust community after this and say "Remember that time when _they_ where threatening kernel devs with social media drama?". It's not right but that's the perception that will last. Happened with actix, happened with serde, and now being threatened by kernel contributors. The perception seems at least somewhat based in reality.

Rust, which is a language I really enjoy, generates more social media outrage and religious wars than any other technical project I have been following for the past 20 years.

It must be said that from an outsider's point a view, in quite a few aspects it very much sounds like a cult.

Get an HN article about C++, and you can be certain the comment section is going to deteriorate at some point into a religious war mentioning Rust. Get an article about Rust, and there is going to be drama in the comments.

As a programmer that could potential consider Rust, it is off-putting.

Re: Resigning as Asahi Linux project lead

#508

Post by busterarm » Thu, Feb 13, 2025, 6:52 PM UTC

purplesyringa wrote: post #477

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…

Avoiding drama is a two-way street. I'm not saying marcan wasn't at least somewhat at fault here, but the reason the drama happened in the first place is a leadership crisis and Linux folks calling Rust a cancerous religion without any pushback. Might be valuable to resolve these problems instead of blaming a scapegoat, don't you think?

marcan wasn't even involved directly in the leadership crisis and made himself the martyr/scapegoat.

That's the entire problem.

He threw a shitfit after the situation was already being handled (not ideally, but handled), got the slightest bit of pushback from Linus and then threw all of his toys away but with high publicity.

Re: Resigning as Asahi Linux project lead

#509

Post by rowanG077 » Thu, Feb 13, 2025, 6:53 PM UTC

bayindirh wrote: post #460

rowanG077 wrote: post #436

Earlier quoted context omitted.

5%? Sure there is a lot of activity around software. But out of week of 40 hours I most certainly code more than at most 2 hours. If this is your workplace I think it's dysfunctional.

Not by time, but by weight. The code you write is worthless if you can’t communicate it or what you did.

You are implying that if you can communicate but have nothing backing it up that's worth 95%? If anything code can still be taken as is and understood by someone else. So to me it's always most important to be able to produce anything before being able to communicate.

Re: Resigning as Asahi Linux project lead

#510

Post by kibwen » Thu, Feb 13, 2025, 6:53 PM UTC

cornstalks wrote: post #257

cratermoon wrote: post #239

Earlier quoted context omitted.

I'm curious now. What are the backwards compatibility guarantees for C?

As long as you compile with the version specified (e.g., `-std=c11`) I think backwards compatibility should be 100%. I've been able to compile codebases that are decades old with modern compilers with this.

Not even close to 100%, the reason that it feels like every major C codebase in industry is pinned to some ancient compiler version is because upgrading to a new toolchain is fraught. The fact that most Rust users are successfully tracking relatively recent versions of the toolchain is a testament to how stable Rust actually is in practice (an upgrade might take you a few minutes per million lines of code).