- First, having good hardware support even on x86_64, a known platform with vendor support, can be problematic.
Even on a standard laptop where Linux works just fine, it's still a struggle for the community to get all the peripherals working after a new laptop has been released. Usually new computers can take a year or two before everything is sorted out. For example, on my Lenovo tablet, it took a whole year before every driver has stabilized, yet the integrated audio still didn't work (even when two company employees were actively supporting it on Linux), and I had to take an USB soundcard on-the-go, a really frustrating experience. Eventually I found the problem in the source code, fixed it, and submitted it to LKML - happy end. But it's not the only problem I had, and not everyone is lucky to have an easy problem - the more non-standard the platform is, the more problematic it is, just ask Microsoft Surface Book users for confirmation.
- Second, power management is already a somewhat unsolvable problem on x86_64, again, it's a known platform, and often with vendor support.
It's increasingly difficult to do power saving in modern laptops with highly integrated SoC - a single component can prevent the entire system from entering a deeper power saving state. In the old days, CPU and graphics were basically everything, but nowadays there can be an endless number of traps - a SATA driver or an audio driver can be the culprit. And even when developers have gone through the trouble of supporting power saving in a device driver based on the existing documentation, it's often plagued with mysterious bugs that baffles everyone (the Window driver often includes nonstandard workarounds that is difficult to be discovered without familiarity with the hardware and systematic testing). And not to mention that many subsystems are poorly documented that prevents the implementation of power management. On many machines, it's already safe to say that nobody knows how power management really works, and nobody knows how to fix it.
- Third, reverse engineering the GPU driver is hard, GPU driver is still a disaster on Nvidia x86_64 and ARM SoCs.
In the past decade, it's well known that Nvidia had done a successful job to destroy Nouveau, the free and open source driver for Nvidia graphics, by simply not providing documentation and tech support. It took years of reverse engineering to get basic 3D rendering, and another few years for reclocking support. And the introduction of signed firmware for hardware initialization and control essentially rendered Nouveau unusable on the last few generations. The problem is GPU is not limited to complex hardware like Nvidia graphics, even the graphics on relatively simple ARM SoCs have this problem, documentation is nonexistent and reverse engineering is slow. The Mali GPU commonly found on ARM single board computers is still having problem on performance, stability and hardware support.
Even on an extremely popular platform, with known documentation (after requests from the community) and strong community support - the Raspberry Pi, it still takes 3 years or so before the 3D graphics driver, VC4, is developed into a usable state.
---
Porting Linux to Apple Silicon is a challenge that requires developers to accomplish a similar task, but under the conditions of (1) to a brand new platform, (2) with unknown, new and non-standard peripherals, including the GPU, (3) without adequate documentation. It's easy to make the kernel boot, but making it usable is the sum of all nightmares.
You'll find none of the peripherals works, and the community reverse engineering efforts will take years before getting basic functionality, and even then, the battery will only last for 2 hours and will forever be broken. Graphics acceleration will be nonexistent or just borderline usable. And only Apple knows the technical details, nobody can fix it.
Unless the circumstances change and indicate otherwise, I think the Apple Silicon port will be a serious waste of community time, talents, and resources. It's better to spend time on a platform where vendor support and documentation exists...
However, the conclusion assumes that a serious competitor of Apple Silicon will eventually emerge and more supportive to the community, but it won't necessarily happen. I'm somewhat afraid that biting the bullet and reverse engineering the Apple Silicon could be the only way to have a high-performance Linux desktop on ARM - I hope not.
