I don't know why your experience was poor. At least under Apple Virtualization for ARM64 Linux, the performance has been great. Perhaps as the other commenter suspects you might be running x86 Linux under software emulation?
In any case, I've run bare metal Asahi on M1 (and M1 Pro) and they work amazingly well too. Installation was quite straightforward too.
Maybe just skill issue, but I was using it for developing a large rust project. Compilation time was way worse than native and memory was a problem since I was allocating half of total to the vm and I only had 16 gb.
Also the network would cut out and I would have to restart the vm periodically.
Just using a linux laptop is way better but then I don’t have a nice touchpad, excellent battery life etc.
Even better is a Mac laptop with a desktop/cloud machine under your desk you can SSH into, which is what I personally do personally. Fast fiber connection with IPv6 and/or Wireguard helps. If you're using VSCode and Zed both have remote editing function over SSH too.
Everything has trade-offs. The baseline in this subthread was not bare metal Linux but WSL, which has the same exact issues. It might not give you the full RAM, but it should be smooth and the network should work.
I'd compare WSL to my older Intel MBP's setup, a VirtualBox VM. Both are subject to the RAM splitting and lacking GPU support, but at least things are simple and predictable on the CPU side, no emulation.
There's no "emulation" unless you specifically need to run x86 code. If your baseline is VirtualBox x86 on x86, the direct comparison, arm64 virtualized Linux experience on M1, is better than VirtualBox for sure.
I’ve done this numerous times and it’s never been onerous and everything has worked flawlessly. It’s also not slower than native if you’re running an ARM build of Linux.
Almost all relevant x86 distros have arm64 builds these days as well and once you enable Rosetta 2 you will be able to run x86 binaries/docker containers on them, but the Linux kernel remains arm64.
Otherwise, it is just using qemu interpreter to emulate x86 in software.
Biggest thing is that I don't want to get stuck rebuilding software from source because the package maintainer didn't make an arm64 binary.
Rosetta2 on my host OS enables the guest OS to run x86 binaries... that's interesting, I'll try it too, but I'd be surprised if it's truly hassle-free. At the very least would have to reconfigure apt-get to allow x86 binaries. Then idk about dynamically-linked x86 libs (I'm not a Linux expert).
I'm sure you can make apt work in a multilib world, but the mainstream way it generally works well is you stick to distro's arm64 packages (pretty comprehensive; arm64 is not some esoteric arch) for the most part and they work just great and you use/build docker containers that might be x86 and that is supported by `--platform` switch once you get basic stuff configured.
I suspect if your use case is more esoteric, it's likely not going to be worth the time. I'd just SSH to a second linux box.
To correct your statement on one key thing: Rosetta2 in this case is not running on host OS. Apple provides a Linux version of Rosetta 2 which runs inside your VM and is registered as a binfmt interpreter for ELF x86 binaries[1]. This is similar to how `wine` or `java` or `mono` can execute their respective binaries directly.
Oh, but Apple Silicon isn't the same kind of arm64 those builds target, right? Like, I don't see how you can run any kind of Ubuntu on an AS Mac without emulation. Unlike Asahi which is actually made for Apple Silicon.
Apple Silicon uses a standard arm64 target, not some esoteric thing. Not sure which Raspberry uses what, but it is the same thing as Amazon and Google cloud servers. You can run the Debian or Fedora arm64 images as guest OS without modification.
Would be just better to have linux but doesn’t seem realistic how everything works so flawlessly in macos, touchpad, sound etc.