Hacker News Reader

Comment by behnamoh | Hacker News Reader

meanwhile Apple won't even make it easy to boot Asahi Linux on Apple Silicon.

Buying Apple hardware with the intent on running anything but what Apple wants you to run is setting yourself up for a battle, including trying to use non-Apple hardware with the hardware you purchased. It's why I'm not spending any personal money on Apple hardware.

Could've been worse. At least they're not locking you out of your device like on iPhones and iPads. They don't stop you from running Asahi, they just aren't interested in helping anyone run Asahi.

Microsoft, on the other hand, sells laptops that actively prevent you from running Linux on them. Things get a little blurry once you hit the tablet form factor (Surface devices run on amd64, but are they really that different from an iPad?) where both companies suck equally, though Microsoft also sells tablets that will run Linux once someone bothers to write drivers for them.

Obligatory: "Challenge accepted!"

https://www.youtube.com/watch?v=4iOi_iPNC50

Apple might not be releasing documentation on their peripherals, but they went out of their way in making it possible in the first place.

Apple could just have gone and do a straight port of the iOS boot procedure to their ARM Mac lineup... and we'd have been thoroughly screwed, given how long ago the latest untethered bootrom exploit was.

Or they could have pulled a Qualcomm, Samsung et al and just randomly change implementation details between each revision to make life for alt-os implementers hell (which is why so many Android BSP dumps are the way they are, with zero hope of ever getting anything upstream). Instead, to the best of my knowledge the UART on the M series SoCs dates back right to the very first iPod.

The fact that the Asahi Linux people were able to create a GPU driver that surpasses Apple's own in conformance tests [1], despite not having any kind of documentation at all is telling enough - and not just of the pure genius of everyone involved.

[1] https://appleinsider.com/articles/23/08/22/linux-for-apple-s...

Macs are almost universally seen as developer computers. If you are going to be developer friendly, then you need to do things that are developer friendly. Asahi project is 80% reverse engineering stuff.

On the macOS side, https://github.com/lima-vm/lima is the closest equivalent to WSL.

Parallels also has a commercial offering that does some nice GUI-level integration with both Windows and Linux VMs.

My understanding is that these are both built on top of some Apple API, and Parallels actually collaborates with Apple on making it work for their use case. So it's not the first-class support that you get from Microsoft with WSL, but it's still pretty good.

Nah, the closest thing to WSL on macOS is OrbStack.

Exactly same experience to WSL - great out of the box experience, easy to use, and insist on using their own patched kernel.

Apple's opinion is probably that if you want to run a *NIX-like OS on their hardware, you should use MacOS.

Which is... not necessarily wrong.

Eh, I have a Mac but end up SSHing into some Linux machine pretty often. There are too many differences between the two unless I'm using something like Python or JS. Docker helps too, but that's Linux.

Also, it's really annoying that macOS switched to zsh. It's not a drop-in for bash. Yeah you can change it back to bash, but then any Mac-specific help/docs assume zsh because defaults matter. Pretty fundamental thing to have issues with.

You can also use zsh in Linux ;)

Yeah but it's pretty much assumed that you're using bash there

Apple has gone out of their way to build first party virtualization APIs in their OS to boot a Linux VM directly by specifying kernel and initrd on disk. That would be a direct point of comparison to WSL, not Asahi. What are you talking about?

[1]: https://developer.apple.com/documentation/virtualization/vzl...

P.S. They also specifically built Rosetta for Linux to compile x64 Linux binaries into aarch64 to run inside Linux VMs on their machines.

I don't know about any of that, just that as a user, I cannot run Linux on my Mac easily.

You can’t? Just install UTM for a full VM one-click install (easier than wsl /install and two reboots) or any number of docker thingies that people build for the Mac.

Hm, never heard of that one but I'll try it.

https://mac.getutm.app/

This is very far from smooth, it has network issues, runs muuch slower than native etc. etc.

Would be just better to have linux but doesn’t seem realistic how everything works so flawlessly in macos, touchpad, sound etc.

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.

Er wait, when I said Linux, I meant a common x86 distro. I'll try it anyway though.

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.

[1]: https://developer.apple.com/documentation/virtualization/run...

Thanks, that makes more sense. I do have an RPi which is also arm64 (still different from Apple's), and the mainstream things work ok at least.

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.

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.

It's easier to dual boot Asahi than Windows. Secure boot and disk partitioning are two examples of roadblocks that are streamlined in the Asahi installation, but quite difficult on Windows

Let's be honest, nobody earnestly expected them to care about running native Linux in the first place. You knew what you got into when you bought the Mac.

Really, the only thing that is saving their reputation is their hardware being top notch compared to competition, whose hardware is more "open".

That must be the reason hackers(even here) still insist on buying apple hardware.

What? Apple made changes to actually help them.

https://news.ycombinator.com/item?id=29591578

Apple implementing iBoot is table stakes. They should have gone the extra mile actually, and implimented UEFI the same way Intel did; but that would have made it too easy to support Apple Silicon on Linux. Sticking to their proprietary bootloader forces reverse-engineers to painstakingly guess at DeviceTree drivers until a bare-minimum boot environment is possible.

If Apple hadn't opened iBoot in some way then I don't know how they would handle a secure reinstall process. If that's "to actually help them" then they very clearly didn't try too hard. Without driver code or UEFI support they're basically telling the community to pound sand, and modern Asahi efforts reflect that.

Reply on news.ycombinator.com