> How can people still not see this?

Perhaps the 30+ years of non-LLM generated Linux support for UEFI/ACPI and ARM device tree chips has something to do with it.

▲

bitwize 21 hours ago | parent [-]

Developed with techniques that were state-of-the-art at the time.

The state of the art has changed.

▲

cromka 16 hours ago | parent | next [-]

> The state of the art has changed.

I keep repeating myself, but make an effort to check the "state of the art" of the crap they added to their kernel tree.

▲

bigyabai 19 hours ago | parent | prev [-]

You still need documentation. Asahi on M1 is 7 years old, with no ACPI substitute.

It may shock you to hear that coding was never the bottleneck for emulation or reverse-engineering.

▲

bitwize 17 hours ago | parent | next [-]

LLMs are arguably even more superhuman for the bits that do matter for reverse engineering, than they are at coding!

Again, any RE project that forbids AI use will get its milkshake drunk by a similar project that embraces AI.

	▲	bigyabai 15 hours ago \| parent [-]
		I'll believe it when I see it. As I said, there are still unsolved problems that AI can't fix taking shots in the dark. I have no particular love for Asahi, but they've made 10x more progress than the vibe coded alternatives.

▲

orangecat 18 hours ago | parent | prev [-]

It may shock you to hear that coding was never the bottleneck for emulation or reverse-engineering.

Yes, and LLMs work well for the non-coding parts too. Pointing Claude at Gravity's repos has gotten Linux running well on my M4 Pro mini, with GPU acceleration as of a few days ago. So either I'm a genius or LLMs are pretty good at this, and I'm not a genius.

	▲	bigyabai 15 hours ago \| parent [-]
		The Honeykrisp driver and upstream M4 Linux support was written by Asahi, not Gravity: https://www.phoronix.com/news/Linux-7.4-SoCs You're downstream of all of those kernel and Mesa changes on Gravity.