Live data from Hacker News

The end of my AArch64 desktop experiment

marcin.juszkiewicz.com.pl

11–20 of 89 posts

Re: The end of my AArch64 desktop experiment

#11

The Desktop Linux will take over from here guys. Next year it will be ready, together with GNU Hurd for everyone and their Grandma.

Has anyone ever pretended that (non-Apple) ARM hardware running Linux makes for a remotely suitable desktop experience for the general public or are you shadow boxing here?

Re: The end of my AArch64 desktop experiment

#12
post #9

The AArch64 desktop experiment started in 2020 with the Macbook M1 and it ended in 2026 with great success with Apple phasing out support for Intel. It is called Apple Silicon.

Which is somewhat useless because it doesn't properly support ACPI/UEFI so that you can boot other operating systems

Linux on apple silicon is a thing though: https://asahilinux.org/

Re: The end of my AArch64 desktop experiment

#13
post #9

The AArch64 desktop experiment started in 2020 with the Macbook M1 and it ended in 2026 with great success with Apple phasing out support for Intel. It is called Apple Silicon.

Which is somewhat useless because it doesn't properly support ACPI/UEFI so that you can boot other operating systems

Wasn’t booting other operating systems supported from early on (two months after release of M1)? It was reverse engineering the graphics hardware that took time and effort.

Re: The end of my AArch64 desktop experiment

#15
post #8

I see the problem, but I don't see a clear analysis on the actual source of the problem. I assumed the issue was mainly single core performance, but he is also suggesting context switches could be the cause? So could you fix that with a new scheduler? Or you just need another SoC with better single core performance? I could imagine that the latter already exists, just not in soc with >16 cores. My naive view is that…

I think the single core performance would be bearable if it wasn't combined with maintaining a custom built kernel.

Re: The end of my AArch64 desktop experiment

#16
post #12

Earlier quoted context omitted.

Which is somewhat useless because it doesn't properly support ACPI/UEFI so that you can boot other operating systems

Linux on apple silicon is a thing though: https://asahilinux.org/

True, but they had to implement their own bootloader chain and because of such overhead they need a lot of effort to port to each new apple SoC generation

Re: The end of my AArch64 desktop experiment

#17
> there was no org.freedesktop.Platform.GL.nvidia in Flatpak repositories for AArch64

All he had to do was build some packages from source, right? It's really worth learning how to do this, since it removes a lot of constraints.

And the kernel patch should land in the kernel pretty soon, I hope? He won't have to run a patched kernel forever. Should be possible to get that in a release in a year or so?

Re: The end of my AArch64 desktop experiment

#18

Can the ThinkPad T14 ARM Snapdragon variant function without pain as a daily Linux/BSD driver?

Without pain? I mean, there is pain when using Linux. It just works better than, say, Windows.

I just setup Gentoo on a Lenovo laptop last week. It was the least painful process for a Linux laptop of my entire career. Everything just works. Even sleep and the fingerprint sensor for sudo. LLM tuis replaced Google entirely.

I can't even say there was any pain whatsoever. The experience is now more akin to MacOS circa 10.6.x years.

Re: The end of my AArch64 desktop experiment

#19
post #9

The AArch64 desktop experiment started in 2020 with the Macbook M1 and it ended in 2026 with great success with Apple phasing out support for Intel. It is called Apple Silicon.

If you think running a Linux desktop on an Ampere is bad, try running it on an M5 Mac!

Re: The end of my AArch64 desktop experiment

#20
Fascinating! I've been running the laptop version-ish of this experiment with the 14M9610, and my major complaint is Device Tree sucks. It's been explained to me why all of ARM can't just enumerate devices like PCs do, but it still sucks. This means every ARM device starts off in custom kernel territory, which makes all sorts of hacks okay to begin with, since you need a custom kernel anyway.
Post reply on HN