Cross compilation of entire distributions requires such distributions to be prepated for it. Which is not a case when you use OpenEmbedded/Yocto or Buildroot to build it. But it gets complicated with distributions which are built natively.

Fedora does not have a way to cross compile packages. The only cross compiler available in repositories is bare-metal one. You can use it to build firmware (EDK2, U-Boot) or Linux kernel. But nothing more.

Then there is the other problem: testing. What is a point of successful build if it does not work on target systems? Part of each Fedora build is running testsuite (if packaged software has any). You should not run it in QEMU so each cross-build would need to connect to target system, upload build artifacts and run tests. Overcomplicated.

Native builds allows to test is distribution ready for any kind of use. I use AArch64 desktop daily for almost a year now. But it is not "4core/16GB ram SBC" but rather "server-as-a-desktop" kind (80 cores, 128 GB ram, plenty of PCI-Express lanes). And I build software on, write blog posts, watch movies etc. And can emulate other Fedora architectures to do test builds.

Hardware architecture slow today, can be fast in the future. In 2013 building Qt4 for Fedora/AArch64 took days (we used software emulators). Now it takes 18 minutes.

Because I can.

Is it good enough answer?

I updated blog post after reading comments from Matrix/Slack/Phoronix/HN/Lobster/etc. places.

- mentioned which board had 143 minutes, added info about time on Milk-V Megrez board

- added section 'what we need hw-wise for being in fedora'

- added link to my desktop post to point that it is aarch64, not x86-64

- wording around qemu to show that I use it locally only

Depends on how you look at it.

Would you call Threadripper system "a normal build"? For many people they are normal builds because they need more computing power or more PCIe lanes than "normal user" desktop has.

On the other side you have those who pretend to use raspberry/pi 3 as "an Arm desktop" despite only 1GB of ram and 4 sluggish cores.

Those auctions are where we looked at. No answer from seller - probably they did not wanted to deal with sending packages outside of USA.

Apple Mac you can buy now will have M3 or M4 cpu. While Asahi team supports only M1 and M2 families.

So you cannot run Linux natively on currently-in-store Mac hardware.

And raspberry/pi is a toy. Without any good support in mainline Linux.

"claims" is very good summary

In my previous post https://marcin.juszkiewicz.com.pl/2025/06/20/the-hunt-for-a-... I wrote:

> There were “Arm V9” systems before it, so it was not “World’s First”. There were several blobs needed to run it, so it was not “Open Source”.

Apple Mx family of cpus supports only 4k and 16k page sizes. There is no way to run 64k binaries there without emulating whole cpu.

This is not the full story. As I mentioned in parent comment, ARM64 supports a special "contiguous" bit in its page table entries that, when set, allows a "block" of multiple contiguous pages to be cached in the TLB as a single entry. Thus, assuming 4k granularity, 64k "pages" could be implemented as contiguous "blocks" of 16 physical pages.

@lisper because Q32 is more expensive than Q64 and I got offer for Q80 one.

Amount of options for sensible AArch64 hardware is too small (or too expensive).

OK, this is something I know very little about so you may have to explain it like I'm a complete noob, but I still don't understand why, if all you want to do is boot 64-bit Linux, you couldn't use, say, a Raspberry Pi 4 instead of spending thousands of zloties on an 80-core machine that requires industrial cooling.

A lot of these ARM boards use custom (read: outdated) kernels and proprietary boot methods, so I'm not really sure how applicable they are to people developing Linux distributions that work everywhere. NixOS, for example, is only supporting UEFI booting on ARM64 going forward. If Redhat has the same policy, then there is only a limited set of arm64 boards available. I researched this recently as I'd like to move my k8s cluster from renting expensive cloud machines to running them on cheap machines at home, and the situation is ... difficult. (I have tested the Orange Pi 5 Max and the Radxa Rock 5B+. Both required me to hack edk2-rk3588, but they do work well now that most rk3588 support is merged in Linux 6.15/6.16-rc1. But, this is an old CPU and is just now getting mainline kernel support, and that is always how arm has felt. It is, however, kind of neat to see a "BIOS" on an ARM board. I hope it catches on.)

Read https://marcin.juszkiewicz.com.pl/2025/06/20/the-hunt-for-a-... please.

Tool vs Toy.

Thanks!

OK, I tend to ignore HN but got link to this post from several people so will go and comment.