You think it's the same amount of time for both?
> It makes no sense to put them down on HN
Put them down? How, by sharing what I saw in their codebase, which anyone else can also do?
That's some apologist nonsense here and you sound super biased with those suggestions. I made and effort to assess the technicality of what I saw and I would absolutely stay away from what they do.
> Critical Bugs get caught quick too.
This is not just about kernel oops kind of bugs with a nice trace that LLM will fix in 5 minuyes. It's the race conditions, the lockups, all type of architectural, high-level things that their code does that create non-deterministic bugs, i.e. untraceable and virtually unfixable by LLMs nor a human being.
The fact this needs explaining even...
> why don't you submit some PRs to help them improve?
Is often a non-starter. If you believe a codebase is poor quality, any changes to improve it have a strong risk of making it worse and/or wasting your own time. In the case that you aren't a key player in said codebase already, it is even more likely your attempts to make changes will fail. Its not impossible to improve these repositories however doing so is quite a different skill-set to identifying their failings.
This is why there will likely be fragmented efforts for bringing up the hardware. Asahi already struggled merging all of their patches into the kernel, there's a 99%+ chance that Omarchy's patches will never be fully upstreamed if the reverse engineered devicetree is uninterpretable vibeslop.
So, even though Asahi's the slow-and-steady side, it makes a lot more sense to channel your effort there.
The device tree is the least of a problem, it's a very limited, highly structured language, you don't need super deep understanding of things to get it right.
Problem is the drivers they write. The hacks, the workarounds, the utter mess. There's hundreds of commits that I am certain no one keeps track of and understands their true purpose.