The end of my AArch64 desktop experiment
marcin.juszkiewicz.com.pl
marcin.juszkiewicz.com.pl
This is why things like the Apple M Series feels so fast, because while they don't win the multi core performance especially when going up against a 80 core beast like this, they have single thread performance exactly were it is needed.
Maybe we will need 80 cores in future, that is cool but for daily home use it is still just way too much for what we need.
Ampere's primary focus is running lots of simple tasks concurrently, at relatively low power, with lots of I/O. So, many tens to hundreds of cores, not too fast, at lower power draw than amd64, with lots of PCIe lanes for storage and network.
Apple's primary focus is user experience and power efficiency. That's why you'll find a handful of fast performance cores and low power efficiency cores, along with graphics acceleration to drive high resolution displays.
> I work at Red Hat. Mostly on AArch64 support in several projects.
So an ARM developer, working for a major Linux distro vendor and trying to dogfood their work, used the closest thing to an ARM workstation that Linux can run on.
What other alternatives would you suggest? The various Apple Silicon or Snapdragon laptops that have their own well-documented problems running Linux? A smartphone running as a desktop?
There aren't very many ARM-based options that are even feasible for use as a developer desktop, even if the software did work correctly.
(I actually do development on ODroids, they're quite nice, if underpowered compared to the Intel/AMD equivalents).
My speculation though. When I was building an app I was using, I used to run a recent stable build on my device instead of just the one released in the Play Store. Simplifies having to keep multiple devices.
If you want to run Linux on one of the modern Qualcomm Windows laptops, you still generally end up needing to use device tree.
The only problem is that distributions currently tend to package them together, but that shouldn't be obligatory.
Why? Device tree is great. You can patch it yourself if something doesn't work, add overlays, etc.
All this doesn't require any enumeration and was still standard until BIOS/CSM was removed. PCs could use the same IDE driver for 30 years of hardware! All chipsets were compatible, from 386 to today's SATA in compatibility mode.
ARM made the mistake of not standardizing anything beside CPU instructions (and even those aren't always the same - see the mess armv7 created with thumb, thumb-ee, simd, neon, crypto acceleration, etc.). Of course it needs enumeration. But x86 is now catching up with the mess. Just wait...
Enumeration instead of standardized hw is bad, but I prefer the least worse device tree.
So ARM did what everyone else has always have done.
Let's take an example. Raspberry Pi doesn't have a RTC, but it has GPIO header. You add a RTC module on that header, one of several models of RTCs.
With the device tree, you load an overlay with some parameters and a kernel driver module. And it works.
How do you do that with ACPI? Ask the manufacturer for a UEFI update that scans for dozens of RTC types on each I2c bus? Good luck with that! What happens 5 years later when the board is long abandoned (not Raspberry's case, but think of an ordinary chinese manufacturer)?
Oh, and an even more complex UEFI+ACPI solution won't be broken?
And you don't have to belive me. See what Linus said[1] about ACPI:
> [...] ACPI was designed by a group of monkeys high on LSD, and is some of the worst designs in the industry [...]
[1] https://lkml.iu.edu/hypermail/linux/kernel/0507.3/2331.html
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?
But that was several layers deep into yak shaving broken graphics, and at some point you need to actually get your real work done.
I guess my impression was that in this case the yak shaving was the real work, or at least a part of it? If you're trying to make ARM support fully work in your distro, then daily-driving it and dealing with these things is how you get there. Granted, if that's not the goal and they were just having fun by using an ARM box, that's fair.
I dont see this experiment as any kind of "failure". Something was learned, and OP is better off for it. Computing and science literature would be a lot better off if people, like OP, honestly documented where things went wrong.
I have gone through many patches like this, and I believe he had to handle life while is experimental workstation had to limp through.
Then when he had the time, he had just pulled the plug.
Exactly because the window of time I had for fooling with home networking had closed.
At least the code is there, info is there and other people are picking up the flag where I left. This is how I comfort myself. At least I was able to push the process a little further.
> The “wooster” system stays powered on, churning through RISC-V package builds. It may be weak in single-thread, but it flies when it comes to multi-core load.
Feels vaguely hilarious that the ARM box didn't work out as a desktop, so instead it gets repurposed to cross-compiling RISC-V packages:)
I can't even say there was any pain whatsoever. The experience is now more akin to MacOS circa 10.6.x years.
Even. Setting it up is a pain: https://github.com/Jeremiah-Hawley/Linux-on-Snapdragon
It can run Windows well though.
I believe Ubuntu also has semi official X1 elite support, no idea if they're working on the latest generation.
Apple devices supported by Asahi are a far more polished experience.
What's that?
The effect is understated there, perhaps because Apple speakers are actually somewhat usable without this feature. For the X13s, the speakers might as well not exist in the current state on Linux.
Certainly way cheaper than a Ampere system like the author here is talking about. I actually looked into building such a system and ... it feels weird to gripe about DGX Spark prices when building out a system like that. The Altra requires ECC RAM (though DDR4 at least). Have fun kitting that out.
Those systems were built for highly highly concurrent multicore server (or some workstation) loads. Meant to be carved up into multiple virtual machines, really. I have plenty of applications that would do well on a machine like that, but playing YouTube videos etc is not one of them.
Also a chance to learn some of the serving stack for inference.
In the end, it's worked out. It is power efficient, it shipped with a vendor supported Ubuntu. I can run Qwen 3.6 27b reasonably well on it. And it basically does everything I need applications wise.
It's also small and convenient enough I can toss it in a backpack and take it with me on trips when I'm staying at my elderly parents, just needing monitor/keyboard/mouse.
A laptop with same chipset would be nice but has its own downsides.
It is called Apple Silicon.
From what I've understood there's significant backwards compatibility for the new SoCs, so the significant work they need to do is to support new features, not getting things running.
Look out for Systemready
> It turned out that there was no org.freedesktop.Platform.GL.nvidia in Flatpak repositories for AArch64. And I used both of those tools quite often.
is more on the side of being a software problem... with this particular hardware.
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 such high core count system comes with tradoff on core size and interconnect/memeory bus complexity.
And I mean.. my phone is a middle lower end device and for sure I can play youtube videos (maybe in a popup as well) and run the browser without noticing that much difference from my laptop.
But iirc for both Firefox and chromium on Linux desktop hw acceleration is tricky so maybe it's that.
It does admittedly take some effort to set up; I assume Google is hesitant to enable it by default because of issues with Nvidia GPUs. But when configured, it works and has for years.
how it helped to solve problems and search over git sources.
intresting what he would achieve mixing nixos and ai for patches.
Moreover, playing with code which fiddles with hardware directly is neither simple, nor easy, nor fun.
What exactly codebase is unexplored in article? Patches? Just load them in context. Linux is already in model as well as nix and hardware specs.
AI is good in search and playing(constrained synthesis) over hardware, Linux and configurations specs. Not fun thing.