bigyabai

Omarchy isn't contributing to Linux development, though. Donating to Omarchy doesn't help put code in the Linux kernel, it just creates more tech debt for their distro.

Viral licenses like the GPL are a shot across the bow for anyone foisting downstream code and laundering it as their own features. Omarchy can still use Asahi's upstream code, but they generally shouldn't take credit for downstream work.

They didn't dispute market share, they were just suggesting that the software deficiencies you were pointing out are outdated.

I mean, look at him. He's got more three-letter agencies reaching up his ass than a Jim Henson puppet.

I personally hold no stock in Nvidia, nor do I consider Jensen beyond reproach. The title is blatantly misleading.

The top comment is correct to question the title, as it leads to more interesting HN comments than the driveby CEO pugilism that many bottom-barrel commentators participate in. Your response to the top comment is condescending and speculative instead of curious or informative. It seems to me like people are fulminating on both sides, and clearly Nvidia's board doesn't know the whole story either.

Does anyone actually think Musk is that smart? The running consensus seems to be that he's a CIA sockpuppet.

It's not wrong that Jensen is being investigated, it's just not the scope of the stated investigation.

HN's title, as the top comment alleges, is extremely misleading as to what the board's goals are.

It is editorialized, and doesn't match the title or contents of the statement.

HN has a rule about titles to avoid derailed threads like this.

...because HN's title is editorialized, and exacerbates the linked statement.

HN will advocate for quite literally anything except taxation, huh?

Upstreamed PRs are the only thing people run. You can whine, sling ad-hominem at maintainers and recompile a custom kernel for every minor version bump, but nobody else is going to. If you don't go through the upstream, your code is never being run at-scale.

You dodged my actual question; how, exactly?

AI cannot squeeze blood from a stone. We still have outstanding issues (eg. PSCI support) that AI hasn't reverse-engineered. Is that "pretty soon" supported, too? What about the Secure Enclave? Do you think there's an ice cube's chance in hell that Linux ever supports it?

Unless you're willing to prove that AI can do this stuff, kindly refrain from making ridiculous predictions because "muh AI" will allegedly fix it. It won't. There are undocumented interfaces that AI will never fully reverse-engineer, that's just how Apple designed their SOC.

It's just about the only headlining feature of Omarchy.

> Omarchy has practically unlimited tokens

And yet they have a total of zero upstreamed PRs, and haven't fixed enormous and glaring issues like PSCI control either.

It's almost as if the parent is correct, and Apple's ARM architecture isn't standardized enough for ordinary models to blindly reverse-engineer without documentation. If tokens were the only constraint on supporting Apple Silicon, we'd have reversed the entire SOC device tree years ago. Alas...

Apple owes me a usable experience once they stop supporting the hardware.

If you think that laptops deserve to become e-waste when the OEM says so, then your opinion can be safely discarded.

They can blame whoever they want, and unless you're familiar with the hardware then you have no authority to overrule them.

I didn't make a mistake. Macs are a vast minority of the PC market share, and you belong to that minority if you use macOS.

Apple eventually stops OEM support for Macs, which means that support via an alternative operating system is a foremost imperative.

Mac users are like motorcycle drivers petitioning their city to replace the highway lanes with bike lanes. You are a second-class citizen here, having forgotten what roads are actually used for.

I'm sorry that you're absorbed in your fantasy, but it's not my job to accommodate it.

> but they've just been left in the dust with their anti AI stance.

How, exactly? AFAIK, Asahi officially supports just as many Macs as Omarchy does. The vast majority of Apple Silicon support in Omarchy comes from upstream Linux changes merged by Asahi, not any of the Omarchy devs.

The only feature I'm aware of Omarchy adding is the fingerprint reader driver, which is in such a poor state that it could never be merged upstream. Which, if that's the standard of quality Omarchy is holding themselves to, they're the ones getting left in the dust.

Because TWM ricing isn't new. Nor is shipping pre-riced distros, or using an Arch base.

Starshield exists specifically for this. The US loses money for every Starshield satellite that orbits on-station without any allies using it. It is a literal waste of taxpayer money not giving Ukraine access.

Reread both of our comments. You are complaining about an LDAP bug and a Rustc issue, the sky is not falling Mr. Chicken Little.

There is not a single Linux feature you have named that would impede your day-to-day workflow.

Methinks the lady doth protest too much.

> Terrible? I love it.

You're part of a minority.

> What other things outside of containers or iPad apps?

Linux with fully native Vulkan drivers, for one.

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.

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.

You willingly let "perfect" be the enemy of "good" in this case. It's absolutely possible to build software runtimes that obviate this type of nonsense. It's not grandstanding by elite developers, most of these choices are common-sense mitigations.

Close-knit ones, the sort that don't trade principles for outreach.

Bully on me for expecting narcissists to grow a spine.

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.

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

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?