back to article Docker Desktop for Apple Silicon is here, but probe a little deeper and you'll find Rosetta 2 staring back

Docker Desktop for Apple Silicon has been released, although it's not quite the seamless conversion some may expect. Declaring that getting Docker Desktop working on Apple's M1 chip as "by far our most upvoted roadmap item ever," the company is naturally chuffed that container fans selecting Apple's latest hardware can now …

  1. Anonymous Coward
    Anonymous Coward

    I can't imagine native M1 containers ever taking off either. Unless of course Apple opens the chip up to hardware that people will actually use in Linux servers.

    Perhaps aarch64 containers could be a target. I'm not even sure if M1 can run that to be honest.

    1. aebiv

      M1 is aarch64, Linux for ARM 64 bit works fine in Parallels, including the Windows ARM builds.

      Hell, there are already Linux builds for the M1 machines.

      So yes, native builds likely are the future.

      1. martyn.hare

        At scale, it looks like...

        ARM CPUs supported by specialised co-processors will be the future. Windows Insider Preview running on an M1 Mac Mini (via Parallels) already runs “good enough” for information worker processes and that is just first gen hardware. Over a 5 year period, the reduction in power costs alone pays for itself to the point where it’s a no-brainer to jump in, even with 2nd gen potentially delivering a far better result.

        Right now, even with tons of wasted RAM caused by dual architecture libraries, things work really well. Once x86 emulation becomes unnecessary for general users, we will see even 1st gen hardware get a performance boost over time.

        ....and I’m saying this as someone who HATES breaking backwards compatibility and who detests having to dump otherwise perfect software to grab “something new”

        1. Anonymous Coward
          Anonymous Coward

          Re: At scale, it looks like...

          'Windows Insider Preview' will throw people, it gives the impression it can run Intel x86/x64 Versions of Windows.

          Clearly, you mean Windows 10 ARM Insider Preview.

          It starting to feel like a (confusing) case of Déjà vu, reliving the days of the Surface RT and Windows RT (a version of Windows 8.x built for the 32-bit ARM architecture)

    2. Bruce Hoult

      One of us is confused.

      Aarch64 containers is exactly what Docker for M1 Mac runs, since aarch64 is the M1's native (and only) instruction set.

      64 bit OSes and binaries compiled for Raspberry Pi 3/4, Amazon Graviton instances (A1, M6g, M6gd, T4g, 6g, C6gd, C6gn, R6g, R6gd, X2gd) run perfectly under virtualisation, including Docker, on the M1 Macs.

      Just a lot faster than they do on their usual hosts.

    3. Charlie Clark Silver badge

      Given the number of developers using MacOS I think there will be reasonable demand. It may take a while for enough dedicated machines to come online à la MacPorts or Brew so worst thing is building the container locally. But seeing as M1 is ARM64 it's should be easy enough to compile on other hardware.

  2. Jason Hindle

    It’ll be interesting to see what limitations pop up

    ARM in a desktop PC (or at least this level of desktop PC) is still quite new. Even ARM Linux has some limitations*.

    * Though some might regard Google not being arsed to port Chrome to Linux/ARM as a positive advantage.

    1. Crypto Monad Silver badge

      Re: It’ll be interesting to see what limitations pop up

      AWS have Graviton ARM VMs you can rent, up to 64-core bare metal, at about half the cost of equivalent Intel ones.

      Lots of people run Raspberry Pi as desktop and/or server. Plenty of other ARM-based boards out there too, e.g. NASes and routers.

      1. A.P. Veening Silver badge

        Re: It’ll be interesting to see what limitations pop up

        Lots of people run Raspberry Pi as desktop and/or server.

        Mostly as server, one of the best known applications is as DNS-server (Pi-Hole).

  3. Henry Wertz 1 Gold badge

    threading and performance

    The problem I ran into several years ago, running x86 and x86-64 binaries on my ARM with QEMU (Acer Chromebook 13) was that ARM has weaker memory consistency guarantees than x86/x86-64; so, running a single-threaded application was 100% fine. Once you got a second thread involved, all hell would break lose, without explicit cache flush instructions ARM in no way guarantees a consistent view of memory between two CPUs, and QEMU's dynamic translation of x86/x86-64 to ARM instructions does not insert these instructions (it's a work in progress, but has been for like 5 years -- put cache flush instructions everywhere and execution would be correct but slow as hell, but putting them just where needed is a trick thus this whole situation.)

    As for usefulness -- I threw Ubuntu onto the Chromebook, this had a Tegra K1 (same as in the Nintendo Switch) -- a quad-core 32-bit ARM, and NVidia GPU pretty equivalent to a NVidia GTX 650, altogether using low enough power for a 20 hour battery life. I had full Ubuntu desktop, even flash (some kludge to use the Android flash plugin) and Java, and the NVidia driver supported OpenGL and CUDA. For regular use, it compared worst case to being equivalent to a Core 2 Duo, for typical use it's pretty close to my Core i5 750 desktop (actually bout CPU and GPU wise, it has a GTX 650 in it), for video encoding NEON reallly helps and the quad-core ARM trounced my I5, to the point that I'm looking into reviving the chromebook for this use. Unfortunately, Acer seemed to be quite good at engineering to spec or however you want to put it, after like 1.5 years of flawless service... the battery packed up, power connector got flakey, case started cracking, touchpad started acting up, and SDCard with Ubuntu on it died (can't blame that on them, I supplied the card) all within like 2 weeks of each other.

    (Yes, I did find you could use qemu to run x86-64 bins on the 32-bit ARM -- it's cross-compiling anyway, so had no complaint running a 64-bit app on a 32-bit system. I used this for a print driver, and since there was no ARM Android Studio back then, the bulk of Android Studio runs in Java... thankfully since the qemu performance was not blazing by any means... but it runs a few binaries when it buiilds a Java app, so those ran under QEMU.)

    1. Mark 124

      Re: threading and performance

      Apple gave the M1 the ability to support "Intel" strong memory ordering in hardware. That's why Rosetta 2 is so much faster than other x86 emulators running on ARMs.

    2. Anonymous Coward
      Anonymous Coward

      Re: threading and performance

      The M1 x86 emulation (Rosetta) doesn't have that problem, in emulation the M1 switches to use x86 memory ordering.

  4. TReko

    Docker for Windows is still a mess too

    It just runs a Linux VM to host Docker and won't work if the PC has VMWare installed.

    1. spireite Silver badge

      Re: Docker for Windows is still a mess too

      Is it a mess really? For me, using Windows, but developing containers to run in various linux flavours, it does the job more than well enough for me...........

      Usually, in my work scenario, you'd probably just want to Linux the development host anyway,, I just choose not to.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like