It's funny how the way to get a Linux on ARM machine with decent performance might be getting a Mac Mini and running Linux as a VM. I doubt nested virtualization will work though.
I haven’t tried docker, but given the widevine hack used it, presume all is ok on that front.
EDIT: gravitation -> graviton
I think you mean "Graviton" which is Amazon's custom processor using ARM Neoverse cores. You can't buy one of them as your own machine but you can use it through the Amazon cloud.
Undocumented custom Apple hardware with proprietary MacOS only drivers & locked up bootloader is the problem.
To add some detail to this: you can spin up an AArch64 server VM on Amazon AWS. You're given the choice of which OS you'd like. The usual GNU/Linux suspects are there, Debian, Ubuntu, Red Hat, SUSE. You can also go with FreeBSD. [0]
The Raspberry Pi also runs various distros, as tinus_hn points out.
[0] https://lists.freebsd.org/pipermail/freebsd-cloud/2019-April...
Apple has documentation up on how to self-sign your own binaries for installing whatever you want on M1 bare metal.
> proprietary MacOS only drivers
Drivers are specific to an OS, calling them proprietary is redundant. It would be a great service to the community if Apple were to release Linux drivers or at least specs so someone else could write them. But if you want unix running on Mac hardware, the best experience is almost always going to be running MacOS.
(Until of course Apple stops shipping MacOS for the current hardware)
Not at all, proprietary means it's closed source it has nothing to do with which OS it's for e.g. Nvidia has proprietary drivers for more than just one OS.
This leads into the rest of your comment in that Apple doesn't need to flat out make Linux drivers as a service to the community (though that would be great) rather they could simply share the info needed about their existing software or about the hardware so the community could focus on coding a driver instead of reverse engineering proprietary hardware and software.
You are correct. For some reason I had a whole other idea of what you meant in your previous comment.
Software being proprietary is independent of whether it's specific to an OS. I can write FOSS apps specifically for macOS. Drivers can also be FOSS.
> But if you want unix running on Mac hardware, the best experience is almost always going to be running MacOS
Maybe. If the standards get completely opened, no proprietary components or drivers, it remains to be seen which one would be best.
I've never really associated "Proprietary" with Open versus Closed source.
> Maybe. If the standards get completely opened, no proprietary components or drivers, it remains to be seen which one would be best.
It's been a while since I've used desktop Linux regularly so it's hard for me to say. Apple more or less designed this processor for running iOS & MacOS though so its going to have an edge regardless of quality of Linux drivers.
But that's what it's about, more or less: https://en.wikipedia.org/wiki/Proprietary_software. While exact definitions of open, closed and proprietary software vary, no mainstream definition is related to "specific to an OS". Software can be single/multiplatform and it can be FOSS/proprietary, and those two axes are independent.
> Apple more or less designed this processor for running iOS & MacOS though so its going to have an edge regardless of quality of Linux drivers.
If Apple retains some "secret magic sauce", sure. However, on a level field, with full access to the hardware for everyone who asks, who can say?
It makes sense. Just not really a term I would use that way so never occurred to me in that context.
> If Apple retains some "secret magic sauce". However, on a level field, with full access to the hardware for everyone who asks, who can say?
That's not really what I was thinking.
If you build the CPU and the OS together, you can make optimizations which aren't available to more modular systems.
So there are duplicate and diverse attempts to design purpose built ARM computers.
Just as it was with PowerPC Macs, ThinkPads, Xbox 360, PS3, Wii, router appliances, etc., that were all built on PowerPC CPU, “ARM platform PC” are usually not designed to run kernel binaries complied for any other machines.
There are recent attempts by SoC vendors to change that, too early to call widespread or matured just yet.
e: words
It says it's added to ARMv8.4 and M1 seems to be ARMv8.6, but I found no information if the M1 has these extensions.
However, Apple's virtualization solution doesn't currently support those.
It goes hand in hand with the fact that an emulated or virtualized system shouldn't be able to tell that it is emulated (if the emulator doesn't want it to know). It should run as if on real hardware. Inability to do nested virtualization reveals immediately that emulation is in play.