Hacker News Reader

Comment by koffiezet | Hacker News Reader

I understand the machine is great or going to be great for most use cases. My mbp is my main workhorse, but as a freelance SRE "devops" guy, the Apple ARM platform won't be suitable for my job any time soon, if ever.

Docker is not yet available - but even when it would become available, emulating virtualised x86 code is explicitly not going to be supported. That in many cases means pulling a docker image built in a ci/cd pipeline where a dev screwed something up and debugging it locally is no longer an option. If I wasn't freelance, I could probably get away with some cloud instance to run all my docker stuff, but I'm dealing with too many different environments, for clients with various different legal requirements making this simply 'not an option'.

Too bad, because the machines look very promising for everything else. Development tools aren't there yet, but I expect that to be fixed pretty quickly.

View on HN

FWIW, I never run docker on my local machine (I develop on a remote machine), benefits: remote machine os + setup is very close to production and GBit bandwidth up and down at my hoster is so much nicer when working with Docker images.

VS Code Remote SSH makes this a really nice experience too.

It really does, I started using it recently, and I was very impressed.

The dev containers that power codespaces are pretty exciting tech imo.

> If I wasn't freelance, I could probably get away with some cloud instance to run all my docker stuff, but I'm dealing with too many different environments, for clients with various different legal requirements making this simply 'not an option'.

While not the exact same reasons as GP, I also need to be able to do this locally.

Even with legal restrictions: just put an Ubuntu server at home and ssh to it. Then you wouldn't have the GBit connection but still better than using Docker on a non-production OS.

I'd argue there's some benefit to being able to code on a train. While Internet connectivity has grown with tethering, it's just nice sometimes to not need to be connected to do your work. That's my opinion, anyway.

> emulating virtualized x86 code

I don't think this is an issue for Docker. They can run an ARM64 Linux VM instead of the current x86 one, and then use QEMU to run x86 Docker containers within it if they want.

The bummer is that this won't be taking advantage of Rosetta 2 so it'll likely perform bad, but it might be good enough for debugging the odd image or even development depending on _how_ bad.

Qemu performance without hardware virtualization is painfully slow and is not really practical for eg running a Kubernetes cluster.

Yeah that's what I was getting at.

There is no hardware virtualization here because it's emulating a different architecture.

Rosetta 2 is able to do this entirely in software with very impressive performance but I doubt QEMU will be in the same league.

That said, if you can get most of your containers in native ARM (you can already run k8s on ARM, for instance), it might be a valid escape hatch for the odd image that hasn't updated yet.

> I don't think this is an issue for Docker. They can run an ARM64 Linux VM instead of the current x86 one, and then use QEMU to run x86 Docker containers within it if they want.

If youre at the point where you have to run a container running inside an emulator inside a VM on an ARM Mac then you should just get an x86 linux machine and enjoy performance and native support for containers.

This is not what running an ARM64 Linux VM means.

Are you just talking about using an ARM64 container your root container? This kind of breaks the point of docker if you're running on x86 in the cloud, doesn't it? You're no longer developing in your exact deployment environment, which is one of the key benefits of docker.

How many years left till everyone run arm on server side too anyway?

I mean, greater than zero, so it's still a relevant problem

Docker has QEMU built in. You can run ARM docker images on x86, and I believe you can run x86 docker images on ARM.

This is not very widely talked about, I stumbled across it by accident: I was working on an x86 emulator on my Chromebook, and was going back and forth between the ARM Chromebook and an x86 laptop. I was working within docker on both machines. At some point I was running a test binary saying "this is an ARM-binary" and forgot to run it using the emulator - but it still executed directly on the x86 machine. It was very confusing and took me a while to figure why my x86 cpu was executing this little static ARM binary just fine - QEMU inside Docker.

It'll be interesting what happens in a couple of years if server side gets more mixed with ARM as well.

Unless AWS starts selling their graviton CPU, whose going to create chips for the arm server market? The volumes are huge and the margins are tiny, which is not something Apple was ever interested in.

> whose going to create chips for the arm server market

Why not Microsoft and Google ? Amazon did.

And they surely aren't going to let AWS/ARM run away without any competition in the cloud space.

Ampere and Marvell have already.

AMD could still revive the K12 and apply their Zen 3/4/5 experience to it.

Uhhhh...quite a few companies?

For a myriad of reasons, I don't think Apple would ever want to sell their chips standalone.

OTOH, Apple could consider releasing a line of Apple silicon cloud servers.

Even if more expensive than x86 servers, they could eventually become VERY competitive if they are more power efficient, which is a real issue for cloud providers. It would pay off any upfront cost if, on the long run, the server uses ie. 50% less energy than x86 alternatives for the same bang.

Now, the thing is that the typical cloud or datacenter machine today is more of a custom built piece of witchcraft than an off-the-shelf blade. So, meh, maybe not. But an ARM-based cloud, Apple or not, sound like the way to go, at least for the long term.

Linus Torvalds was and is probably still right that unless developers have the same breed of processor (not just AArch64 but the actual chipset, for example) on the bench it'll probably never be particularly prevalent server-side.

That and Apple presumably dream of not letting developers touch anything without going through their stack, so no touching the hardware for you. For example, I believe Apple expose Performance counters through Instruments in Xcode - but without a Mac to test it on I should say - it doesn't seem to be close to perf. The wider point being that Apple will probably never let you run Linux on their hardware, and your server will probably not be running MacOS either.

I suspect the previous poster was referring to non-Apple ARM hardware, not Apple servers.

> The wider point being that Apple will probably never let you run Linux on their hardware

Apple has already issued docs on how to load alternative OSs on their system and has said explicitly that Windows support is up to Microsoft. Linux on Mac metal is not out of the question, but it's going to take some time to get running well.

That was for x86 Macs. Apple is not supporting alternative operating systems on the M1 Mac except via virtualization.

Not so: https://www.zdnet.com/article/top-apple-exec-native-windows-...

From the sounds of it, Apple hasn't put anything in the way of installing Linux or Windows on the M1 based Macs. They don't have the sort of built in support the Intel based Macs have, but they should be able to boot Linux or Windows on bare metal.

Recently there was a Apple support article posted here on HN detailing it.

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

Making Linux work on an ARM SOC is a lot harder than on a regular laptop. It basically requires help from the vendor to make the peripherals and such work, although there. Will be a lot of eyes on this so I'd be surprised if someone hasn't got it working within a year or so (working is not equal to usable)

> Making Linux work on an ARM SOC is a lot harder than on a regular laptop.

Yep. It's going to be a while, and it'll be pretty rudimentary for some time. I think Linux on the Mac mini will be viable well before it's interesting on the MacBook.

If for no other reason than because power management is not essential.

> The wider point being that Apple will probably never let you run Linux on their hardware, and your server will probably not be running MacOS either.

I agree the idea of running Apple Silicon in the cloud seems far-fetched, but at the same time, if Apple actually does achieve the best price/performance processors in the world, it almost seems like a failure of the market if they do not also serve the cloud market.

> [...] the Apple ARM platform won't be suitable for my job any time soon, if ever.

> Docker is not yet available - but even when it would become available, emulating virtualised x86 code is explicitly not going to be supported.

Is there any reason why Apple couldn’t add support for emulated virtualized x86 code in a future ARM CPU? The M1 doesn’t support it, but might the “M2” or “M3” support it?

I ask because I’m in the same situation as you, where not being able to run x86 Docker containers would make me not buy an ARM MacBook Pro.

Reply on news.ycombinator.com