Birbla

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

Sign in
  • Hacker News
  • 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.

    by rvz
  • Which is somewhat useless because it doesn't properly support ACPI/UEFI so that you can boot other operating systems
    by preisschild
  • If you think running a Linux desktop on an Ampere is bad, try running it on an M5 Mac!
    by jeroenhd
  • I use a DGX Spark every day as my daily driver and it's great. I barely use the "AI" facilities of it, but as an Aarch64 desktop Linux, I have no complaints.
    by cmrdporcupine
  • Well it's also more than double the price
    by anthonj
  • I'm glad I'm not the only weirdo like this. I dropped an unfathomable $800 on a Jetson AGX Xavier in early 2020 simply because I was obsessed with SBCs at the time and couldn't stop thinking about it. This was before the Raspberry/Orange Pi 5 and Apple Silicon. I still use it as a graphics development workstation.
    by aj_hackman
  • Can the ThinkPad T14 ARM Snapdragon variant function without pain as a daily Linux/BSD driver?
    by __patchbit__
  • Without pain? I mean, there is pain when using Linux. It just works better than, say, Windows.
    by shevy-java
  • No. The driver support is very poor and won't run at all well.

    Even. Setting it up is a pain: https://github.com/Jeremiah-Hawley/Linux-on-Snapdragon

    It can run Windows well though.

    by izacus
  • When I looked at this before I found https://github.com/kuruczgy/x1e-nixos-config - reasonable though not 100% support.

    I believe Ubuntu also has semi official X1 elite support, no idea if they're working on the latest generation.

    by bpye
  • Unlikely. I've been daily-driving the predecessor (X13s). While it's usable and technically all drivers are there, it's far from "without pain" due to endless number of small but annoying quirks. Just to give you an idea: boot fails 4 out of 5 times, external displays aren't recognized unless plugged in/out several times, sporadic resets during overnight sleep, etc. On top of that speakers will sound prohibitively tinny due unimplemented software-side speaker protection. I haven't tried T14s, but at least the audio issues will still apply there.

    Apple devices supported by Asahi are a far more polished experience.

    by neobrain
  • Qualcomm are slowly but steadily improving Linux support for the X1/X2 Snapdragon CPUs (such as the qcom-hamoa-ec driver in 7.2), so it's still a wait. I think there's some challenges with Secure Boot and the firmware with these Lenovo devices though.
    by jordand
  • Snapdragon has excellent single-thread performance (unlike Ampere) if that’s what you’re asking.
    by sedatk
  • I wonder if a source-based distro like Gentoo would have made OP's life slightly easier. Portage for instance should allow you to maintain a set of patches to automatically apply when you update your kernel. Those flatpak problems also shouldn't exist there.
    by ginko
  • At very least it would have given all those cores something to do :-)
    by lonelyasacloud
  • I would like to take a moment for this line:

    > 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:)

    by yjftsjthsd-h
  • My ARM64 experiment started in 2020 with the MacBook Air M1 and I have not looked back. ARM on the desktop or your lap is possible.
    by st3fan
  • I'm not sure why the author didn't attempt to dive deeper into the error message he saw. amd_vcn_dec sounds like it's an issue with the GPU's video decoding logic. If there's a timeout when trying to process a decode request, it may be that power management for the GPU is buggy somehow. Given that this is a server build and idle power consumption is likely not a big deal, I'd suggest pinning the GPU power state to see if it resolves the issue (see amdgpu.ppfeaturemask and amdgpu.runpm kernel parameters).
    by 10000truths
  • I believe something I call "the window phenomenon" has occurred. Sometimes, life allows you have the time to do these big experiments on your life and then it gets busy again and you can't dive into it with the same capacity, so you have to do what you have to do while surviving what you have at hand.

    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.

    by bayindirh
  • I feel that OP should be congratulated on trying!

    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.

    by kjellsbells
  • > 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?

    by edg5000
  • I don't know if it's your intent, but that reads really condescending. It's obvious the author knows how to build packages from source. They're working professionally for a Linux distro on arch support!

    But that was several layers deep into yak shaving broken graphics, and at some point you need to actually get your real work done.

    by jsnell
  • 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.
    by fragmede
  • > my major complaint is Device Tree sucks

    Why? Device tree is great. You can patch it yourself if something doesn't work, add overlays, etc.

    by M95D
  • This is not completely true. You can use a generic kernel with a custom device tree.

    The only problem is that distributions currently tend to package them together, but that shouldn't be obligatory.

    by bestouff
  • ACPI does exist for Aarch64, but is only really used for Windows client devices, and server hardware - though I think the Ampere hardware in the article would use ACPI not DT.

    If you want to run Linux on one of the modern Qualcomm Windows laptops, you still generally end up needing to use device tree.

    by bpye
  • I don't understand the kernel problem. Why did he feel he had to rebuild the kernel weekly? When the amdgpu stopped working why couldn't he just go back to the last working kernel?
    by dn3500
  • I presumed that as a kernel developer, he would run the kernel he runs, which would require rebuilding periodically. Daily doesn't make sense, monthly is too infrequent given the rate of change in the kernel.

    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.

    by nevi-me
  • He said he needed patches to make the GPUs work. Kernel package auto-updated does not have those patches and overwrites the custom kernel he built every time there was an update available.
    by M95D
  • I'm not surprised at the outcome. These Ampere system single core/thread performance is pretty low and that is where you feel it. The OS/software simply cannot allocate the threads across enough cores effectively to make up for this difference.

    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.

    by HerbManic