A lot has change since then, like I stay away from node and `./node_modules` as much as possible via importmaps, but even then the FS performance wasn't enough for my needs.
"From the data gathered on our configuration, macOS is considered the most versatile system for operating with Docker containers."
I just don't like how the containers are ephemeral.. I want to use it like a VM.
> I just don't like how the containers are ephemeral.. I want to use it like a VM
I suspect you’ve just pulled some images and run them locally?
If you want your own custom image to run whenever you want for whichever purpose, take a look into building your own containers with a Dockerfile
https://docs.docker.com/get-started/docker-concepts/building...
That gets you the base “everything I need is already installed when I start it”.
After that it’s volume mappings for accessing local data within the running container
I wish it could automatically create a Dockerfile for me.
https://medium.com/@salah.mahmud/quick-introduction-into-usi...
On macOS, Docker uses HyperKit (which is a hypervisor built on top of macOS's Hypervisor.framework) to run a Linux virtual machine behind the scenes, so your containers actually are running in a VM, even if you don't (usually) interact directly with that VM.
I'd take this article with a grain of salt when it doesn't even mention it, or any of the other alternatives.
[1] https://docs.docker.com/engine/install/
[2] https://learn.microsoft.com/en-us/virtualization/windowscont...
Windows is suboptimal for running Linux containers? Sure, Docker on Windows is meant as development tool. If you have Windows Server but need to run Linux containers in production, you should run Hyper-V, install Linux and run container inside that VM.
MacOS has some funkiness for running containers as well that makes me think that's its disk operations are not truly backed. Also, Docker Desktop is again for Development, not actually running it in production since that would be really expensive server.
This entire paper could be a blog article. Did someone need to publish for some reason and threw this out there? What knowledge is being gained here? I WANT TO KNOW.
Development performance does matter in situations where, for example, you're running an elaborate test suite on your laptop. In that case they should also test OrbStack though.
They talk about this "fragility" like it's a common, known thing. I must be living in the woods, so to speak and feel silly. What's this known Ubuntu fragility they mention, anyone know?
I wish I could address your question, but I don’t think there is “fragility” in how Linux does random writing. It’s extremely durable. MacOS (and therefore Darwin) has some pretty awesome optimizations by owning both the hardware and software, but I don’t know if random writes on Mac “succeed” more often than on Linux. It’s also a bit nonsensical since the hardware really matters when we’re talking about write durability.
"it was discovered" as if the VM behind the docker engine running on those operating systems was hidden to the human race.
> The dynamite plots.
Please don't create dynamite plots. Use a box plot, or plot the dots of the different repetitions with some jitter to avoid overlap.
> The evaluation
As reported in other comments apparently OSX cheats when saying it's writing to disk. If the authors wanted to compare docker executions it would be useful for the discussion to see if the difference in performance was due to the docker overhead or to the operating system, by showing what's the write performance of a non-containerized program across operating systems.
In my opinion the article should not have been published as is. It should have been rejected or asked for major revisions. MPDI Applied Sciences is quite a bad journal already for "Computer Science Applications" https://www.scimagojr.com/journalsearch.php?q=21100829268&ti... so it's not surprising to see this published.
> This barrier could be overcome with the help of the T2-Ubuntu [32] distribution, designed to be installed on Apple computers with T2-chipped.
That reference leads to https://github.com/t2linux/T2-Debian-and-Ubuntu-Kernel?tab=r..., which provides instructions on how to use a non-Ubuntu kernel to work around a hardware support issue on the particular hardware they used.
So they didn't actually test Ubuntu at all. They tested a third party produced kernel hack used to get support for their hardware. They then falsely assume that this is somehow representative of running Docker in...what? Production? Or for development purposes? They seem to have neglected to think about their use case. You'd think that the hardware they used for this test would be representative of a developer use case - but then why does performance matter?
If you consider container technology of the form that Docker uses, the kernel used is paramount for performance. Host OS userspace doesn't matter since it isn't active - the container userspace is provided by the container!
So not using an official Ubuntu kernel means that they didn't actually test anything provided by Ubuntu at all in practice. They've just tested whatever Linux kernel Docker Desktop uses inside its VMs on Windows and macOS against this Linux kernel hack running natively.
Their abstract also says:
> Upon analyzing the distribution of Docker Desktop for Windows and Docker Desktop for macOS, it was discovered that running the Docker environment on these requires a lightweight virtual machine that emulates the Linux system.
This is inherently known to anyone who can remotely claim to understand container technology. If this was a revelation to them, then this would explain why they think they tested Ubuntu when they didn't, and why they were unable to spot this flaw.
Disclosure: I'm biased in favour of Ubuntu. But I think the flaws I've described above stand for themselves.
Would also have been interesting to compare different runtimes (podman,crun,runc) and drivers.
I hope the authors follow up with a more fleshed out version because the chosen benchmarks and setup could make for some interesting results with some more rigorous methodology and analysis.
