Does it though?

So, "it's better because our code exists, and their code doesn't" isn't the brag you think it is.

Especially since the only reason your code exists in the first place is that they did the hard work and your project forked.

Enshittification comes for everybody.

I must have missed that; could you share a link to the Linux kernel that's tested and certified as functional on M4 hardware?

It's the operating system, mate. People don't just use operating systems to take screenshots and then post on social media.

> it's better than Asahi code, because our code exists, and their code doesn't

This is an especially horrific comment if you are really related to the project and this also adds to the perspective on why Asahi team might have wanted to have no nothing to do with this project and related people and their thought process. Anyway, good luck.

> This release is intended for developers.

RE always ran a risk of everything you mentioned.

If this project had been started before the AI craze by some RE amateur you probably wouldn't be this dismissive.

People would still be nervous about the legal ramifications of accepting code from an Apple employee though.

Even good code is a liability. Admittedly "horrific" code is a 10x or 50x liability. Sometimes you accept that kind of technical debt because "it's really important" — e.g. the company will go bankrupt, or whatever.

(Historically, btw, this is why proprietary corporate code is often so much worse than even fairly incompetent open-source code. Because it's just not really that important to ship horrific slop when nobody's income depends on it.)

The idea that shipping "horrific" code now is somehow better than not shipping it until it is fit for human consumption works in some narrow business life-cycle scenarios, but not in any kind of user-facing scenario, and certainly absolutely fucking not any kind of user-facing OS implementation scenario... (T_T)

Why didn't you start from scratch building something of higher quality? Lack of skill or only of tokens?

Unironically yes. I think it's great that you don't have to be as extraordinarily skilled as the Asahi developers in order to get Linux running on new hardware.

Otherwise one can also say Asahi is compiler-generated slop compared to hand written assembler code.

Some of us still care.

Or not feeling good for the intellectual theft involved in the training of AI to begin with?

Or not caring for the de-skilling of of human brains who are delegating coding to AI, and increasingly even the architectural and decision part?

Or the training material being AI degradation that awaits most code being written by AI?

Or the baragge of slop PRs that overwhelms my favorite FOSS projects?

Or deeping of big AI dependency, in times of climate and economic crisis that it worsens, but that it also risks not having the luxury of it forever?

Or the ease with which any stupid direction can be followed via AI, and the resulting always changing projects, already a problem with short attention span project leads even for big projects like Gnome?

Or the lack of deeper understanding to control all this in future generations of programmers reduced to "AI operators"?

The rest is all just why you don't love AI generally.

(Not saying you're wrong; just that you expanded the topic substantially.)

Well, none of those stop to matter or get a free pass just because it's Asahi Linux & Gravity Linux.

Especially since I wasn't just answering for Asahi Linux & Gravity Linux. I was answering the question I quoted in general:

"Who cares [if AI is used on a project] if it gives you the features with good-enough performance?"

There are a few significant reasons worth considering when getting down to the level of OS and hardware drivers. Long term maintainability is one. But another big one is that such software is capable of physically and permanently destroying the hardware it's operating on, with the textbook example for Macs being the speakers found in Macbooks. The only way to get the kind of performance they offer out of that physically light/thin package is to give them the power to destroy themselves if run at full force continuously but then run it from software so that they aren't run at full force continuously, but rather take advantage of the headroom that offers for very brief audio spikes whose overall integrated power still falls below safe limits. This all needs to be done from software since response of real world analog isn't instant. That enables much more range then if they were hardware capped at the maximum level they could run constantly, but it also means that if they're driven wrong, poof. The drivers have to never go to certain bad states, purely from software.

LLMs can't offer those kinds of guarantees, they don't really "know" how things work and then produce something deterministic off of that. It's even worse if, as-is the case with this sort of vibecoding effort, the LLM operator is in fact depending on the LLM for that part because they don't know how it really works either (vs someone who is just using it for boiler plate and knows exactly where the critical paths are).

Obviously everyone is welcome to roll the dice with their own hardware as they wish, and it may be ok. Or if using really old hardware one might just not care. And not all hardware is as sensitive as modern notebooks of course. Just be aware the analog world can be messy and you might not actually have the guardrails to screw up that you're used to in a higher level software environment.

>Otherwise one can also say Asahi is compiler-generated slop compared to hand written assembler code.

No, one cannot say that. Or at least not without looking really stupid.

https://github.com/GravityLinux/linux https://github.com/niklassheth/mesa-wip

but as a shipped product you are currently right. That'll change when we ship.