| |
| ▲ | mrkstu a day ago | parent | next [-] | | Asahi doesn't take AI generated code, so they won't take Omarchy code, but they are trying to get upstream core Linux to accept their patches. | |
| ▲ | manofmanysmiles a day ago | parent | prev | next [-] | | I imagine some of the maintainers of distributions are uncomfortable with the amount of LLM-generated code. I also imagine they will be left behind, for better or for worse as AI-authored software and hardware will satisfy people's needs faster than that developed by humans. I don't see a way to merge these rapidly moving frontiers of software without radically different distributed software development and distribution networks where AIs collaborate on a global scale. Perhaps the only way to keep playing is to grow a "super cortex", a projection of ourselves into the digital. Like today's agents, but improved, grounded by our knowledge and understanding. This smells a bit like Skynet. Also, Software Heaven. I'm not sure how I feel. | | |
| ▲ | mrkstu a day ago | parent | next [-] | | Linus is full steam ahead on AI, so one way or another those distros will be running AI code unless they want to fork the kernel. | | |
| ▲ | bigyabai a day ago | parent [-] | | It doesn't mean that people don't review the code, though. You still can't ask Linus to merge a million-line patch, even if it works. And more importantly, documenting Mac hardware takes time. Components like the speaker on a Macbook can be permanently damaged if you don't write the drivers in a specific way. Other features like the Secure Enclave, power management, and TouchID might be unsupportable depending on how Apple designed it. Asahi's stance isn't particularly crazy, and it probably aligns with how Linus feels about upstreaming code that nobody understands. | | |
| ▲ | benoau a day ago | parent | next [-] | | I think the other factor is all these additional projects are starting from the work Asahi has done, whether they're actually able to deliver substantial value themselves is yet to be seen, especially safely and securely. Personally I don't think it's very likely the tables would turn and Asahi became dependent upon their contributions. I foresee a much bleaker future for Omarchy, crashing and burning from some reckless and unnecessarily abrasive whim of DHH. I'm not optimistic about Gravity Linux either, it's a single-dev project and that's prone to failure for many reasons. | |
| ▲ | gorilla_fight a day ago | parent | prev [-] | | TouchID is already supported on Omarchy, I use it on my daily driver MacBook works great. The speaker too. It is quite remarkable how far along support has come: https://aurorasilicon.org/devices/ | | |
| ▲ | cromka 16 hours ago | parent | next [-] | | > TouchID is already supported on Omarchy, I use it on my daily driver MacBook works great. And the way they have written that driver is absolute crap, not submimissible at all. They will need to write it from scratch, properly, using a TEE driver, a sensor driver, a userspace supplicant plumbing and an fprintd patch. What they did, instead, is they run pretty much everything in-kernel. So, can't wait for ridiculous exploits that make your fingerprint effectively a backdoor to your OS. That fingeprint implentation to me is a perfect example of how ignorant Omarchy people and their users are about security and I wish more people were loud about it. Just point your LLM at that TouchID code to audit it, see the amount of stuff it flags. | |
| ▲ | justauserid 19 hours ago | parent | prev | next [-] | | https://github.com/omacom/omarchy/blob/quattro/manual/44-mac... but here they say > Please note that installing on an M-series Mac is not directly supported at this time. | |
| ▲ | whilenot-dev 19 hours ago | parent | prev | next [-] | | Support would be great, but there seems no way to download it atm: https://aurorasilicon.org/docs/download/ | |
| ▲ | bigyabai 21 hours ago | parent | prev [-] | | For M4 and M5, the speakers are not listed as working. M1, M2 and M3 are all using Asahi drivers. > It is quite remarkable how far along support has come Is it? All I'm seeing from that page is that they forked Asahi's M1-M4 work, and then failed to bring up M5 and M6. What's remarkable here? |
|
|
| |
| ▲ | bitwize a day ago | parent | prev [-] | | > I imagine some of the maintainers of distributions are uncomfortable with the amount of LLM-generated code. Then those distributions will fail. It's 2026. Any open source project with an anti-AI stance will get its milkshake drunk by a fork that embraces AI. How can people still not see this? | | |
| ▲ | bigstrat2003 16 hours ago | parent | next [-] | | a) it's not a race. b) being left behind is a good thing if your counterparts are headed in the wrong direction. I think projects which lean into LLMs are going to find they have a hot mess a year or two from now, whereas projects that eschewed them will be in a good place. | |
| ▲ | hakfoo 19 hours ago | parent | prev | next [-] | | I don't buy that. Not everything is a race-to-the-finish competition. The primary message we get out of the AI ecosystem is "MORE MORE MORE FASTER FASTER FASTER". First off, that's not really what plenty of projects are about. You might like your favourite Linux distribution or desktop environment because it represents less, as a curated vision-- an AI "workalike" could offer ten thousand new features per week, but break the earned trust that a single clear vision provided. Second, beyond a certain point, speed burns through the human components of a software project. There are only so many reviews that can be done, whether the source is AI or enthusiastic humans. Quality eventually suffers, contributors burn out, and the project dies. If you point a well-funded slop cannon at an unfunded open-source project, they're not going to say "let's find 20 new reviewers to keep up with the firehose of commits!" They either have to circle their wagons and get finicky about what they allow, throw up their hands about quality, or rely on the machine itself, the dreamworld where they build enough test suites and harnesses to somehow keep Microsoft Paint from having zero-days. Given those choices, I feel like I'd be happier to see "we circled the wagons". This doesn't necessarily mean "no AI" but it means keeping the project at a manageable scale, and right now, the way to handle that is to push away AI contributions without a bulletproof background behind them. Going even further, it's high time we saw a "slow software" movement to counter the "move fast and break things" and its new cousin "move even faster and let the bot break things for you". I want smaller programs written by happier people under less psychic and economic assault. | | |
| ▲ | andrekandre 9 hours ago | parent [-] | | > "MORE MORE MORE FASTER FASTER FASTER".
this has been true for just about everything tbf. news cycles, product cycles, movies/tv all have to accelerate to feed economic demands for growth... ai just a potential accelerator of that.. |
| |
| ▲ | bigyabai 21 hours ago | parent | prev | next [-] | | > 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 16 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. | | |
|
|
| |
| ▲ | cromka 16 hours ago | parent | prev | next [-] | | > How can people still not see this? You fanboy people are so insufferable, if you had any clue about the code quality standards and cared about security, YOU would see this other way. I have personally vetted their code for TouchID and some other aspects, including USB-C/Thunderbolt. I absolutely cannot wait to hear your apologist brown-nosing when you start getting targeted with exploits. | |
| ▲ | cyclopeanutopia a day ago | parent | prev [-] | | Maybe it's you who are seeing what you want, not what's there. :) |
|
| |
| ▲ | favorited a day ago | parent | prev | next [-] | | It's Asahi Alarm + Omarchy configs. | |
| ▲ | wyre a day ago | parent | prev [-] | | Fedora and Void Linux both can run on Asahi Linux (M1-M3 macs) |
|