> and also works across platforms and operating systems

As a mac user, I'm not sure I agree with this. Docker does technically work cross platform of course. But it's slow everywhere except for linux. I'd much rather have binary (or even better a `brew install`) than a docker image.

It's a lot faster if you don't rely on the default volume mounting: https://nodewood.com/blog/how-to-speed-up-docker-on-macos/

Still not as fast as on Linux, but within 10% of running it natively for me.

SO the argument here is that it's the storage layer that slows things down? I deduce this since the linked article is about installing a new storage driver to sync to external volumes.

What about server workloads where the storage is completely inside the container / on a different server?

It's less the storage layer and more the volume mount on OSX - the default is very reliable, but at the cost of a LOT of speed. Mutagen offers varying levels of reliability, and occasionally I have to restart the sync (like maybe once a week), but it's _much_ faster.

The circumstances you're describing sound like it wouldn't be suffering this specific issue in the first place, so I'm not sure how much it'd help.

A lot of people don't realize docker on macos runs in a vm.

It would be much nicer if apple coexisted instead of apple-language, apple-frameworks, apple-laserlike-navel-focus. Do community interaction, not just over-the-wall to opensource.apple.com

a native apple docker would be great. Imagine:

  FROM macos:10.13.2
  RUN xcode-build ....

Apple will never commoditize its own stuff.

They're perfectly willing to ruin the lives of countless devs / CI/CD devs, who have to support their crappy platforms, because you can't virtualize MacOS (only AWS can, and even then, it can only be rented in 24h increments at super high prices).

Apple controls the end users, their end users have money so devs just have to come crawling to be able to make and sell their apps.

I’ve used Anka for running macos VMs with good success. So much so that we replaced all our bare metal workloads with portable and repeatable environments. The trade offs are performance related and bugs with the VM tech but those are less costly than managing the bare metal.

That's true, unfortunately, volumes are especially problematic. Though I think it's gotten better over the years, and performance should be acceptable for most workflows.

I'm not saying it should be the _only_ distribution option, and standalone binaries and other packages should be provided as well, but there's no reason for Docker to not be one of them.

Also, I guess, it's needless to say, most of people don't have Docker already installed (unless your target audience is a dev-ops community). So it's not just "docker run".

Lol no. Docker is only slow on Mac. It works great on all other platforms.

It was slow on Windows to run Linux images the last time I tried. I think they now use WSL2 making it faster, but I haven't used it since.

It's not just slow on Windows, but BSOD shutdowns/reboots as well.

> and also works across platforms and operating systems

That's the greatest lie that Docker managed to convince people of.

Docker is not portable, its images are not portable. It runs on Linux and that's it. It doesn't even run on other *NIXen.

Docker on Mac runs inside a VM. Docker on Windows runs inside a VM. Technically Docker for Windows supports Windows containers. But they only run on... Windows.

Docker is as portable as any software I can get my hands on and that I can run inside a VM. So almost all the desktop software I know of.

Docker just managed to package its software in a nicer way so that many people don't even realize that there's a VM behind the scenes (most usually notice because Docker is slower/much slower on non-Linux platforms).

I don't care if it runs in a VM or not. That's just an implementation detail.

What matters is whether my app and the myriad of dependencies it relies on can be run easily and consistently.

Docker for Windows is a thing, and it does run Windows binaries natively.

So you can publish for two platforms.

Java is still a good way to have bulletproof cross-platform experience, but JRE is sort of large. JDK 10 or 11, IIRC, allows to package your code, only the needed parts of stdlib, and the VM into a reasonably lean self-contained executable.

Rust/Go are much better at than Java. You do need a separate binary for each platform which makes it slightly more of a pain for the maintainer to setup CI, but it's much more convenient for the end user.

Good point for services being installed. Especially when I'm just testing something I don't want to see a full page on how to get it up and running, or even care about the underlying tech. Just give me a docker oneliner. Doesn't have to be the standard way of distributing the app, but at least make a simple image for local testing / development.

Tested RabbitMQ this weekend, and the getting started was soo easy.

Some context to my comment, last time I was doing app distribution I used the contemporary best practice which was SVN. I’ve read a dozen articles on the theory of Docker vs VM but still don’t get it. Apparently it saves resources by not replicating the whole OS. Do everyone’s apps really not rely on the specific kernel at all? Even in i.e. PHP apps I usually have binaries tied in that are compiled for the kernel I’ve developed on.

Containers are peripheral to my work so I don’t understand but I’m curious.

Docker takes advantage of various linux sandboxing features. On a linux bare metal host it's just a combination of namespaces and resource constraints (cgroups) whereas on other platforms it will have to be the above within a bonafide VM running a linux kernel. The general rule is that linux maintains backward compatability even in ABI so as long as the host kernel is the same or newer than the image requirements it should just work. Things wont work for example if your image requires iouring (a brand new syscall interface) but your host OS is running 4.x (doesn't map iouring syscalls to anything).

what kind of php app are you running that requires to be linked against a specific linux kernel

Let's say I integrate with a CLI utility, which comes up. Docker wouldn't work? If the answer is no I think I'd say I understand the theory better. Unless docker is providing some kind of universal kernel API or something?

In that case you would bundle a copy of the CLI utility into your docker container, with the correct version. This also applies to any system libraries your code might be compiled against. Things like shared libraries or CLI utilities are part of the "operating system", but not part of the "kernel".

This does mean that you end up with multiple copies of the same utilities and libraries on the system - although docker does have a mechanism to avoid duplication between different docker containers. It also means that if you take your docker container and move it over to a different system with a newer operating system (or a different distribution) all the parts of the operating system it cares about come with it.

The Linux kernel - the part that gets shared between containers - is mostly just responsible for process and memory management, networking and interacting with the computer hardware.

What makes you assume that all people have or even want docker runtime in their machines? Not to mention all the security headaches it brings with it.

The OCI image format is an established standard and registries are supported across tools. Publishing an image on Docker Hub also makes it available to tools like Podman that don't require a runtime and can run rootless containers. You're also free to download, extract the image and run the binaries however you wish, even outside a container.

Docker is a packaging format with a distribution platform and a common execution interface. I see offering it as an option to users only as a net positive. Not to mention that it opens the orchestration door making the application easy to integrate into CI pipelines and complex workflows.

As a user I much prefer a single binary to a docker image.

Considering they use Go, they get this out of the box. Half the motivation for Docker isn't there if you're using Go.