The Omarchy M team is doing great work with this. They are currently working on the M6 bring-up already!

https://x.com/JoshuaSWarren/status/2111923039378211100?s=20

I personally looked into their code an patches. This is an absolute mess of workarounds, permissioning negligence and other types of antipatterns.

They are truly and utterly a definition of a slop. And, expectedly, their work is unstable and not efficient, just look into Reddit discussion complaining about power draining.

I am afraid no one, or very few, has any deep understanding of low level architecture of these platforms or even Linux kernel and hardware in general, looking at their contributors’ previous front end NodeJS projects.

The only good thing is you can take their otherwise time-consuming work, have an agent infer and write a spec and use that to implement proper improvements.

If you took the time to really analyze their codebase and judge, why don't you submit some PRs to help them improve?

It makes no sense to put them down on HN. I love using Omarchy, and like many others, I coudln't care less about what's going on under the hood. It works great for me, is OSS and I can tweak it anytime I want. Critical Bugs get caught quick too.

As someone who hasn't looked at the repositories in question;

> 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.

> I coudln't care less about what's going on under the hood.

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.

> will never be fully upstreamed if the reverse engineered devicetree is uninterpretable vibeslop.

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.

> If you took the time to really analyze their codebase and judge, why don't you submit some PRs to help them improve?

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 take the time to help them improve when they havent even taken the time to write it?

I wouldn't call it fast, these are several years old and no GPU, Thunderbolt, etc. support still. It's steady, but not fast.

If I was to do it myself, it would take centuries. I guess it's a matter of perspective :-).

And if Apple did it themselves, like Intel or AMD do, it would be released at the same time as macOS.

Intel and AMD sell to customers that build computers running Linux, especially servers. Apple sells to itself, to build computers that run their own OS.

No one said otherwise. We’re discussing the speed of onboarding here. Intel is fast, Apple support via Asahi can do what they can do, but it must be and is slow without any documentation whatsoever.

We agree on that, it is inevitable.

Furthermore we are lucky that Apple at least tolerates Asahi and does not throw at them more technical hurdles, legal issues (DMCA?) or whatever. Based on past history (in the 90s, so a lot of management changes) Apple would shut them down if they were a threat to their bottom line. I remember the shortly allowed Mac clones so, a possible scenario: a significant fraction of sold Macs is immediately reinstalled with Linux and provide zero dollars to cloud services and followup sales of other hardware. Apple is not going to like that.

Sure. But is that a reason to complain? If Apple made bikes, they may be nice bikes. But I don't see a reason to complain about Apple not making bikes. I mean... they don't have to, do they?

Would be cool if Apple decided to support Linux, of course. But why would they? If it was profitable for them, they would do it. Instead they think it's more profitable to enshittify their products. That's life.

Now people who reverse engineer that to help us run Linux on Apple hardware... I would guess they don't make a fortune doing that, and I find it impressive work.

It's perfectly reasonable to complain about things you aren't entitled to. My Surface brand laptop has similarly ad-hoc Linux driver support. I don't expect Microsoft to support it better, but I'm still annoyed they don't.

I guess I don't like that people complain against the Asahi team because Apple would be faster.

Sure, Apple (like all other BigTech) suck. But the Asahi project is quite amazing. I don't see a reason to complain about the Asahi project.

> I don't see a reason to complain about Apple not making bikes. I mean... they don't have to, do they?

This analogy is really tortured. Apple doesn't make bikes.

But they do make software, and hardware. People want to use them however they choose.

This is more like a bike company choosing a proprietary air valve that only lets you inflate your bike tires with their own company-branded air pump, even though there's been other air pumps for many decades before them, and their design isn't particularly better than the others. And you say "well they don't have to design an air valve adapter to use other air pumps" and -- yeah, that's true. But people are gonna bitch.

> and -- yeah, that's true.

So we agree :-). Of course I would like it if Apple was making my life better. I just find it naive to consider that companies are anything other than profit-maximizing machines. If they happen to do something you like, it's because it is profitable for them. They couldn't care less about you.

> But people are gonna bitch.

Whatever you do, people are gonna bitch. Again it would be a bit naive to think that if you do "your best", or if you do "what's right", or if you "genuinely try", then everybody will appreciate. There will always be enough people bitching, of that I am certain.

> Whatever you do, people are gonna bitch.

So we agree :-)

> their design isn't particularly better than the others

Well, to be fair, they occasionally make rather nice hardware.

For my usage, the reason the Linux-on-Mac efforts are useful is that Apple hardware becomes easily and cheaply available once it is no longer supported. My home server is an old Mac Mini (GigE, HDD + SDD, double core Haswell, 7 W power envelope, doesn't take up space, silent) running stock Debian. When it dies, I'll probably be able to replace it with an M2 model, thanks to Asahi and friends.

Some people like Apple hardware, but not Apple software. I wouldn't be surprised to find out, that some of them might even work in the Apple. Not everything must be about immediate consumer profit. Developer goodwill also worth something. Remember Steve Ballmer? Developers, developers, developers, developers...

I have this dream that previous gen M chips will be worth more than current gen M chips b/c people want to run local inference on Apple silicon... but they want to use Linux and not OS X.

I'm curious on why you think that, say, an M2 running linux will ever be a better choice for AI workloads than an M5 Pro running MacOS? What is it that you think is in the hardware that you'd be able to unlock with linux but isn't exposed by MacOS?

I'm sure a lot has changed since cough 2004, but that was the state with the PowerPC G4 and G5. Machine learning Linux applications used the IBM Power architecture because of their vectorization features, and that hardware was ridiculously expensive. When Apple started using Motorola and IBM's cheaper PowerPC chips with Altivec this small market was pumped, but none of their groovy scientific applications worked on OSX.

This created a large enough market for Linux distros installed on Apple hardware to make it a sustainable business model the makers of Yellow Dog Linux to buy the hardware through a reseller channel, ship it to the building, install Linux on it, then ship the device to customers. I worked there and it was fun.

Lots has changed since then of course, one of which being that Apple controls the chip from top to bottom, and their near-indifference in 2004 now seems to have transformed into something more adversarial.

> I'm curious on why you think that, say, an M2 running linux will ever be a better choice for AI workloads than an M5 Pro running MacOS?

I mean that if Asahi starts to gain on Apple with respect to generation of M chip they support. If Asahi supported M4 chips...

But clearly, my dream hasn't come true yet :-)

> What is it that you think is in the hardware that you'd be able to unlock with linux but isn't exposed by MacOS?

I believe that Linux would give me more control over exactly what is running on the machine (and using up precioius memory). Maybe it would also have better support for the toolchain/ecosystem needed to run local inference?

Just because you have a device tree file, doesn't mean its correct, or even accurate.

On the other hand - I just had to send my Asus vivobook s15 to repair, because Linux (most likely) fried the wifi chip.

Pretty disappointed in Qualcomm's promise of upstream support for Snapdragon X Elite turning out to be: lol, not actually so you can run Linux on devices, only so you can maybe boot without most devices working...

Hope things will keep improving despite lack of help from vendors.

Not one of the downvoters. How would the kernel fry the Wi-Fi chip?

It's not the radio actually frying the chip - poor choice of words on my part.

It's the firmware that locks up - with Bluetooth and wifi devices not working at all anymore (does not show up in Linux or Windows device manager). And even a complete power drain and reboot can't resurrect them.

The radio limits are very heavily guarded by the firmware solely because its regulatory compliance: different jurisdictions have different limits and you can’t just let userspace or kernel change it at will. Heck, most manufacturers don’t let you change WiFi card anymore or allow only a whitelisted WWAN card for same reason.

So, I would be super interested how you inferred it was Linux’ fault but I sssume b/s at this point.

Well, I'd say it's Asus fault for having crappy firmware - but Linux triggers it - causing the card to permanently no longer come up on boot.

"Fried" was a poor choice of words - the device is dead - but it's due to firmware and probably something to do with sleep states.

I didn't mean to imply the radio was actually fried.

It'll be interesting to see what the technicians end up doing to get it working. It might be enough to disconnect the card and force some even deeper reset than a power cycle with drained laptop battery does - but as I still have valid guarantee on the machine, I stopped short of opening it up. Especially since I might need a new wifi card anyway.

If I were to wild-guess here, it sounds like and rfkill in nvram that isn't properly handled by the Asus EC driver for your laptop model. This is a fairly common issue for Windows-first laptops and Asus EC drivers are reverse engineered because they don't support Linux themselves. I assume switching to Windows was not bringing it back anymore?

Chance is you could probably have Claude or Codex had look into it and have them fix it for you.

I had ai look into it, and that took it from works in windows, shows up in Linux - to dead and gone from both os'.

Ed: user AI on the Linux side, to help with getting firmware blobs etc - might be random combination of flaky firmware, flaky Linux support and reboots that did it - not AI or any particular driver/firmware version.

It's the first time I've seen drivers knock out a hw component completely on a consumer product - but I gather the platform is fickle.

The arm64 Snapdragon elite support is very poor unfortunately (due to there being zero upstream support).

Which wouldn't be so bad if they weren't marketed with a promise of Linux support.

Well, thanks for the write up. Will be interesting to hear what they fixed, but chances are they'll just replace the board and not think twice about it.

i want to know weather the windows will detect it just driver issue are real fried