Hacker News Reader

Comment by frogblast | Hacker News Reader

Right, lots of confusion in this thread.

A12Z/DTK: HW does not support virtualization at all.

Apple M1 / New Apple Products: HW does support virtualization for ARM64 guests (both windows and linux demonstrated).

What about x86 software in the guestOS? Not with Rosetta. Instead, the guest OS will have to provide its own translation (such as windows/arm's current x86->arm64 or upcoming x86_64->arm64 feature). I'm not familiar if there is any usable high performance x86_64->arm translation available for linux.

Docker w/ arm images: needs some work to be able to work on mac/arm virtualization, but it's coming.

Docker w/ arm linux kernel + x86 userland images: Any translation solution would be found within the linux guestOS, not macOS. I don't know if any candidates exist. Maybe qemu?

Docker w/ full x86 image (incl. kernel): I don't think this is possible?

View on HN

This was a huge reason why I decided to go with a 16" MBP with an i9 vs the M1 today. I assume this will get worked out eventually, but as massive as Apple's gravity is in their ecosystem to pull apps along, they will have a much harder time against the massive library of x86 docker images.

Apropos of yesterday's thread(s?) around running a k3s cluster on Raspberry Pis - when I tried to do something similar, I very quickly ran out of steam trying to find manifests and charts that didn't have some random x86_64 image hardcoded somewhere inside them.

I spent more time trying to figure out ways to get the right images than I did learning k8s, so I kinda put the project down.

I do think this is exactly the sort of thing though that will start to flush that out, long term.

You did the right thing. This is not the right time for software developers to experiment with Apple Silicon, unless they’re willing to help develop software to work with Apple Silicon.

Largely depends on what kind of software developer you are. Not all developers rely on x86.

Our app is React/ Typescript and we don't use Docker/ x86 virtualization at all. I do need MySQL and a few other tools, but I don't expect they will be long coming (or maybe already running in Homebrew is there Homebrew ARM?)

If you make your living writing Mac or iOS software, this is a gift. Might be worth waiting for the next generation with more RAM and even beefier CPUs, but otherwise this is ideal.

> is there Homebrew ARM?

There is but it’s highly experimental still, with 50 % of formulae not working yet.

Better to run Homebrew with Rosetta for now.

In my experience it's always python and/or ruby that's causing the failues. As soon as they are fixed, most formulae will compile just fine.

One of the formula not working in Homebrew’s core functionality is the gcc compiler, which they expect might be ready by mid-2021. Another is Go, which iirc they’re expecting will begin working around January. Rust and Erlang aren’t ready, MySQL doesn’t even get past the build phase, and Python is only partially working.

You can track progress here. Be advised that packages listed as ‘check again when XYZ is fixed’ may themselves have issues that can’t yet be discovered.

https://github.com/Homebrew/brew/issues/7857

> Better to run Homebrew with Rosetta for now.

For some reason I'd completely forgotten this was an option. Looking at the discussions on the home-brew boards, it looks like this will be the way to run home-brew for some time.

I would definitely not take for granted that you’ll be able to develop such things on the M1 platform without encountering M1 platform obstacles in unexpected corners of the tool chains for the next thirty days. It might be fine, but if it’s not, you’re out of luck until it is.

Sure, M1 Apples are bleeding edge for at least six months, maybe a year or more.

I switched off Mac years ago.

My servers run Linux. Not bsd.

Having to deal with this sort of stuff is just a waste of time.

Mac's don't have a monopoly on quality, haven't for a long time.

And since it's a usual response, anyone claiming Linux is too fiddly haven't used it in a long time. And while it can be if you want to roll your own DE its completely optional. Using something like fedora you can literally do almost everything non developer based with point and click.

I moved to Linux last month. I currently run Windows, Linux and MacOS VM on my machine.

From being a Windows guy through all the years, I've found myself increasingly using Linux in this span of time. The only thing preventing me from a complete switch is MS Office. I barely used MacOS, except to diagnose issues on MacOS and run XCode.

May I ask what linux you are using and how you got a Mac VM running? I tried myself and was able to get Catalina running on Ubuntu 20.04 using Openboot. But then Catalina updated itself and crashed after that. I wasn't able to reinstall MacOS successfully anymore, even starting from scratch.

If you could help me out by pointing out which products/technologies you used and maybe a website describing step by step, that would be great.

Ubuntu system. Firstly, I disabled updates, not because of Mac in particular, but I've had issues with Windows updates crashing before, so I don't eagerly update.

Apart from that, standard QEMU process. This was the guide I used: https://www.funkyspacemonkey.com/how-to-install-macos-catali...

Thanks. I'll give it another try.

I moved to Linux in early 2019 and was surprised that I barely needed Windows anymore. I was already using Libre Office so Ms Office wasn't a sticking point for me. I assume you tried Libre office and its probably not compatible enough for you.

Ms Office is very compatible with Wine - even the newer ones. The only problems seem to be with apps were direct replacements like Skype or are irrelevant like OneDrive.

For setting up wine and managing my apps I use Lutris. It is meant for games but is brilliant for setting up windows apps as well. I wish they would acknowledge that fact in their UI but it doesn't bother me too much that everything is called a game.

I didn't enjoy Libre Office, largely due to the functionality being too low. I work with Excel spreadsheets with lots of macros and formulae, which doesn't port well over to Libre Office.

I can understand this, I make do with Google sheets but it's seriously limited with my bigger spreadsheets, especially if there is lots of custom code / API response parsing involved.

Have you tried the web based office? I haven’t, and I’m not sure if it’s a good solution, but friends have said good things

I use Excel pretty intensively, learnt all the shortcuts from my past finance days. I don't think the web version allows for those back-of-the-hand shortcuts.

Fedora is the new Ubuntu

I haven't touched fedora in a couple years. what's going on there?

in my case, they ship a almost up to date kernel, they don't use snaps, vanilla gnome, the distro is very stable. The linux community I follow also likes where the distro is going and the overall "Fedora philosophy".

That sounds exactly like what I’m looking for. Does it have an equivalent to “umake” for installing latest-version dev tools?

I guess the flip side is that, hopefully, the Docker ecosystem will start getting a lot better at multi-arch, at least for x86-64 and ARM. I just ordered an M1 MBP and I'll be quite happy to start thwacking bugs in images and upstreaming the fixes.

I naively assumed, until today, that the whole point of using linux in docker was that you get the multi-arch goodness of linux for free!

Not at all. Docker on a raspberry pi is a massive pain in the ass. Half the images are not compiled for ARM.

Not a bit deal. Building ARM images from Dockerfiles is trivial. And it has the benefit of not having to trust an upstream image content. If you want to go the extra mile, contribute to the project to provide multi arch images support.

What multi-arch goodness of Linux? Linux can't magically run code from any architecture even without Docker in the mix, and unless someone is maintaining packages for your specific architecture, you're building them yourself.

As a non-processor geek, isn't M1 an arm chip? How long will it take arbitrary software to target it?

Yes but afaik most arm softwares target arm7, not aarch64.

We operate a k8s cluster with our own software and lots of opensource stuff.

If i can't run our own images on a future mac, i will no longer buy one.

I can't force my team to maintain two versions if there is no better business reason.

I'm quite curious how this will play out.

Just a heads up; I haven't tried using my DTK in a while but... development was still VERY rough last time I checked. I was pretty much forced to write code on an x86 machine and schlep it over via ssh to then run it.

Also, be real careful you don't accidentally build for x86 when installing libraries or it all goes to shit. I got bitten by this by using iTerm (building it from source was fine though) and not realizing it was the x86 variant. That is to say, make sure your terminal is the system terminal or built for ARM-- otherwise when you install things using package managers they'll be the x86 variant.

Like, I'm super stoked for the M1, but also just totally fucking irritated about the toolchain changes and MacOS in general... They've not been the best stewards of their software and developer communities as of late, and they're pushing a totally proprietary architecture onto them expecting them to foot the bill (hours spent fixing/debugging) to make their platform usable.

Truly, I get paid to write software that runs on Linux not on Macs. In fact, I've never gotten paid to write software for Macs, because no production systems use Macs. Now it is harder for me to do primary development on a Mac; because I must fix MacOS or live with MacOS only bugs... bugs which only exist on a platform I do not intend to deploy my code to... these aren't just some config bugs either they're going to be a fucking mess of irritating, show-stopping, moving targets with a negative ROI.

I still can't believe they didn't incorporate containers into the OS before switching platforms to keep developers around but that's a totally different rant.

I find it quite ironic that solution that supposed to make things portable it is now standing in a way of portability.

Yes, I understand why, but still...

Apple has only ever used portable to refer to their own platforms. Which is a bit of a stretch of the term considering what it means to the rest of the technical world, but there you have it. Per their own definition they have improved portability among their own platforms.

Same reason why I chose the 2020 13” with the highest end Intel I could put in it. In another 3-4 years all this will be worked out and I’ll be happy to move to Apple Silicon

> Docker w/ arm linux kernel + x86 userland images: I don't what existing projects might me candidates, but any translation solution would be found within the linux guestOS, not macOS.

That could be something doing dynarec like box86, which is mindboggingly the only way to run (x86) Zoom on a arm7hf Linux atop a Raspberry Pi 4 (I tried it on a Pi3B: it works but it’s way too slow)

https://github.com/ptitSeb/box86

> Docker w/ arm linux kernel + x86 userland images

as mentioned in the issue comments: Docker x86 version already supports running ARM images via qemu out of the box on Windows and Mac, so x86 images via qemu on ARM host should not be a problem...

> Docker x86 version already supports running ARM images via qemu out of the box on Windows and Mac

it "works", but on my overpowered i7, running a raspberry pi docker image that way with qemu-user-static is... only marginally faster than running the code on an actual rpi 3, which is pretty much potato-levels of power.

Yep, so if you're a developer and buy a Macbook with the M1, all the potential performance gains would be lost when depending on common Docker images. That's quite sad.

(It would at least be a huge problem for me. I mostly develop server software that runs on Kubernetes on AMD64 machines.)

Why not just run the ARM images instead of the x64? Granted not everyone makes ARM images, but in a year or so I fully expect that all serious Docker images will have ARM support (not because of Mac, but rather because of ARM’s progress in the server space). And in the meanwhile, building the image yourself isn’t that hard.

Why would your employer pay you to build and test ARM images when the server they're running on is AMD64? Okay, let's be realistic: they'll probably never find out. But still this is wasted effort when you could just as well use a regular x86 machine for development. Cross compilation will lead to many small problems that add up over time...

They would do it so their developers can use Macbooks.

More likely than not, those servers are at AWS. And if that's the case, once all the components have ARM images the server instances can be switched over to the M6g instance type for significant cost savings.

Even if not AWS, every cloud provider will have cheaper ARM offerings in a few years. The writing is on the wall at this point. Not to mention that some significant portion of the PC market will certainly follow suit, and now whether you’re developing for desktop, mobile, or server, there’s a good chance you’ll be targeting ARM.

All of this already works on Windows in the other direction:

PS C:\Users\hokaa> docker run -it --platform aarch64 ubuntu root@aaf35d3fd9de:/# uname -a Linux aaf35d3fd9de 4.19.128-microsoft-standard #1 SMP Tue Jun 23 12:58:10 UTC 2020 aarch64 aarch64 aarch64 GNU/Linux

And yes, AFAIK it uses qemu's binary translation.

X86 software running in a VM hosted ARM Windows/Linux env, but using Apples translation layer is not something I would expect to work anyway - seems like a weird thing for them to try to do to me.

you should be able to run x86 vms through qemu. Just like running arm vms on x86 today

Reply on news.ycombinator.com