
ARM Macs and Virtualization: It's going to be great - mlillustrated
http://www.ml-illustrated.com/2020/06/25/ARM-Macs-virtualization-different-take.html
======
reaperducer
"It's going to be great!"

"It's the end of the world!"

"This will make my life so much easier!"

"I'll never buy another Mac again!"

I've stopped clicking on rando blogs linked on HN. It's all bait at this
point.

~~~
mercer
I don't know if it's a summer thing, but same here.

That said, I've clicked on every Apple-related link and made a point of mostly
skimming through each of them. There was usually something valuable (by my
standard), but yeah, a lot of it I really don't want clogging up my brain.

------
ivanstojic
I worked for several large companies where the on-machine (not containerized)
development was very clean.

That hygiene required a large team of dev tools engineering to support it. For
the smaller companies, dockerizing individual projects for development was...
a regrettable but easy shortcut to not having to wrangle with local setup.

I wonder if this author never experienced or already forgot fighting with
venv/pipenv/conda?

------
andrewguy9
If this slows or stops the use of Docker in local development I’m all for it.
Docker for development is a plague on this earth. It burns battery, slows
builds, makes fan noise, eats huge amounts of bandwidth/HDD space, makes
debugging a nightmare. All for what? It’s marginally better at setting up a
self contained dev environment. Oh wait, Docker can’t do that; you also need
docker compose.

~~~
wayneftw
Most of the problems you listed are because you want to use a laptop to work
for some reason. Ewww. Why anyone would want to optimize for working in
trains, planes, automobiles, hotel rooms and meetings - I'll never understand.

I've never had any of these problems with my very inexpensive tower computer,
which I upgraded to 32gb of RAM and terabytes of disk space, that was probably
a third of the cost of your laptop.

~~~
txcwpalpha
Better yet, why not have the best of both worlds?

I know most devs are hesitant to try anything that's "always online", but
remote development apps have really gotten better recently. VSCode with the
Remote extension makes doing development on a VPS a breeze, and unless you
have a _really bad_ internet connection, you probably won't even notice it's
remote. And then you also get the benefits of the VPS having a faster internet
connection (faster package downloads, etc), most likely better specs than your
laptop for only $10-15/mo, more resiliency, and better security. It also
completely solves the whole "my laptop is ARM but my servers are x86" problem
that keeps getting talked about.

~~~
OkGoDoIt
I use VS Code remote development via SSH to a $5 a month digital ocean server,
and it’s so incredibly smooth and easy. You would never know it wasn’t local.
I’ve been using Windows for decades so I’m very productive running windows on
the desktop, but I prefer to use Linux on the server. VS Code remote over SSH
is the perfect combination for me. For someone who loves macOS the situation
should be exactly the same, regardless of whether they are on ARM or x86. If
you haven’t tried it yet, I highly recommend giving it a try!

------
brians
I believe it’s going to be great for ANE users, but let’s just say that this
author’s opinions on how local Docker shouldn’t be part of the “core
development cycle” don’t match my environment. This is going to mean
investment in Linux laptops, for all their problems, for us.

~~~
MrBuddyCasino
Yeah that part was just "you're holding it wrong". I'm surprised that the
option of running ARM containers on an ARM Linux isn't even mentioned? This
would surely be the way forward?

~~~
znpy
Not necessarily.

What if your laptop is arm but your production environment is x86 ?

You might think "well i'll have arm containers on my laptop and x86 containers
in production" but then it means that dev and prod diverge: you're running
different software, that might have different behaviors.

One of the core ideas of docker was that you could have ideally the same
artifact both in developmend, testing, staging, qa and prod environments.

There's little way around the core problem: mac os x badly suited for running
docker containers. The most performant way to run docker containers is to run
them in native gnu/linux (hence: gnu/linux laptops)

~~~
ed25519FUUU
Can you articulate any divergence you expect that wouldn’t otherwise be
present running your container on another environment (prod)? I think
“divergence” is a non-issue here if you’re testing locally, but the final
build and push comes from another x86 CI host.

------
jacknews
There seem to be a quite few gushing Apple pieces recently.

"enable developers to write code on their ARM Macs, test across devices
locally, and deploy to iOS devices and server-side"

I believe a step is missing, "Apple approve/sign the code".

~~~
GeekyBear
For Mac apps, there is no human approval process, just an automated malware
scan/code signing workflow.

Frankly, I find this less troublesome than Windows Defender refusing to run
apps from indie developers who don't have a good enough "reputation score".

------
jayd16
>Its going to be great! What about Docker being slow? The great news is you
shouldn't use Docker! :D

What nonsense is this?

------
sheeshkebab
Author seems to be iOS developer with coreml experience...

No question that iOS dev will be better with these arm macs, as to development
on Mac for other platforms it’s hard to say but my bet will be world of pain
for the next few years.

------
fnordsensei
This post hints at something that I've thought might be Apple's potential
answer to "how will it make economical sense to make workstation-grade CPUs
for the higher end of the Mac line, given the amount of such units sold?"

The potential answer is to go AWS. Build up a cloud platform using the same
CPUs, move all Apple cloud infrastructure onto it, rent the rest of the
capacity out to the public.

With this, plus the sales from high-end Macs/MacBooks, the R&D overhead for
high end CPUs might make sense.

~~~
jamil7
Do you think they have the kind of culture and experience inhouse to pull
something like that off? I'm skeptical that it's in Apple's wheelhouse but
it'd be interesting to see.

~~~
fnordsensei
I honestly don't know, it just made sense as a possible solution given the
limited insight I have.

Before AWS, I didn't expect Amazon to become the power that it is with regards
to cloud either.

Perhaps Apple can provide some unique attributes of cloud infrastructure
that's specifically useful to people who otherwise operate within their
ecosystem, without feeling like they need to compete with Amazon/Google/MS in
every aspect.

------
RivieraKid
> Funnily enough, I’d say this is the biggest rationale for Apple going ARM
> for Macs, which is to make the development environment exactly the same as
> their deployment targets, namely iOS, iPadOS, Apple Watch, Apple TV, and
> soon, MacOS.

No it's not. This is a negligable advantage for iOS developers (I am one and
don't care about this at all). Improving the developer experience a bit does
not bring enough value to Apple to make such a risky and expensive move.

------
sradman
> ...the problem of x86 emulation can be dealt with if Apple offers ARM-based
> cloud servers.

Amazon has a very good ARM64 cloud offering with their M6g instances. Pure
ARM64 server-side Linux stacks are not yet mainstream but the ARM64 Macs will
help.

~~~
TheCondor
Apple dropping Intel changes the way I feel about Graviton. I thought it was
sort of a ploy from Amazon to maybe get better deals from Intel and AMD and to
give them a fixed cost way to run their own stuff.

It makes me think that Intel's issues are substantially bigger than some
process issues and maybe an architecture generational issue to be sorted out.
These are two big, high profile customers that have lost the faith.

~~~
sradman
Amazon’s James Hamilton has been bullish on server-side ARM for a long time.
[1]

[1] [https://perspectives.mvdirona.com/2015/10/arm-server-
market/](https://perspectives.mvdirona.com/2015/10/arm-server-market/)

------
TYPE_FASTER
Does anybody have any tips on minimizing CPU resource use when running Linux
containers on a Mac? I'm currently running Docker Desktop Community 2.3.0.2.
Thanks in advance for any help.

~~~
znpy
Eh: run Linux on your mac. You'll skip the whole linux vm overhead and nfs i/o
overhead.

There's not much way around it.

------
nickcw
Has there been an announcement from Apple to say they will virtualize Docker
to run x86 images or is it just speculation?

I would have thought running arm64 Docker images would be the best way
forward.

~~~
sigjuice
Docker will not run x86 images.
[https://youtu.be/Hg9F1Qjv3iU?t=3742](https://youtu.be/Hg9F1Qjv3iU?t=3742)

------
insaneirish
> The concern is that under x86 emulation instead of hypervisor, the
> performance hit could be significant.

You are not going to be able to run an x86 hypervisor/VM on Apple Silicon
Macs. This is very clearly laid out by Apple:
[https://developer.apple.com/documentation/apple_silicon/abou...](https://developer.apple.com/documentation/apple_silicon/about_the_rosetta_translation_environment)

~~~
snowwrestler
That is about Rosetta, not Apple Silicon.

~~~
insaneirish
> That is about Rosetta, not Apple Silicon.

It's about Rosetta... on Apple Silicon: "Rosetta is a translation process that
allows users to run apps that contain x86_64 instructions on Apple silicon."

The original post pre-supposes that you're going to be able to run x86 VMs on
Apple Silicon Macs. You can't: "Rosetta doesn’t translate the following
executables [...] Virtual Machine apps that virtualize x86_64 computer
platforms"

~~~
snowwrestler
Rosetta has the specific purpose of running MacOS applications that were
compiled for x86 on Apple Silicon. It is not a general x86 emulator and
therefore you can't run an arbitrary x86 VM on top of it.

There will be other applications created--probably not by Apple--that will
provide general-purpose x86 emulation on Apple Silicon.

------
seek3r00
Look, I get it, Docker has its downsides and it wasn’t meant for local
development.

But it just works (most of the times). I can worry about getting shit done,
instead of messing around with web servers, interpreters and package managers
(it’s fun the first couple of times, but then I want to get to the code).

The problem is that Docker on Mac sucks, because it’s basically a VM running
Linux, and it eats up most of my 8 gigs of RAM (yeah I know, 2020).

Maybe, what Apple really needs is something like WSL2.

~~~
vbezhenar
WSL2 basically is a VM running Linux :) There's actually Windows-native docker
which runs Windows containers. But it's not very useful, because there are
very few images compiled for Windows.

Docker is useful because of those thousands of companies publishing "official"
images. You can't expect them to publish those images for every possible
platform. They target Linux x64. May be they'll target Linux ARM, may be not.

~~~
seek3r00
Well, you’re right, but the hypervisor under-the-hood is better.

------
ed25519FUUU
This announcement aligns well with Graviton. I can see people building and
deploying ARM64 from start to finish, and running it in Amazon’s economical
graviton fleet.

------
bovermyer
I am not an Apple developer. I do a lot with Docker and Linux system
administration. I develop and maintain applications that run in Docker or on
Linux directly. I also dual-boot Linux and Windows on my home PC.

I'm intrigued by macOS on ARM. Intrigued enough to buy an ARM Mac when they
come out.

I'm not all-in on this by any means. It's more accurate to say I'm cautiously
optimistic.

------
santoshalper
This one feels a lot less substantive than the original article it is intended
to rebut.

------
gdsdfe
It would be crazy to see Apple entering the cloud market with ARM based
servers

~~~
sgillen
Does ARM offer any advantage in the server space? Is there really demand for
OS X cloud compute?

------
pilililo2
Spoiler: no it's not.

