Recently I was fielding some questions that someone had about some bugs that crop up on Docker for Mac, and it reminded me of what Shakespeare wrote in his famous tragedy about large-scale software orchestration, **Kubelet: the Prince of Benchmark**. When running Docker on Mac or Windows, some problems crop up occasionally, because Docker for Mac and Docker for Windows are both using some clever and mostly-hidden tricks to be able to run at all.  Containers are, fundamentally, a Linux technology, cobbled together from a handful of features native to the Linux platform. However, they're so popular and so useful that many folks would like to run them on their normal desktops/laptops. So, the folks at Docker, Inc. put together clients for those platforms which secretly spin up a [Hyper-V virtual machine that runs Linux](https://docs.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/linux-containers), and they run their containers inside there, on Linux. This layer of extra virtualization comes with extra complexities.  The networking bridge often collides with VPN software.  On Windows, you have an additional problem where Windows filesystem semantics and Unix filesystem semantics are very different and don't translate well.  (Fortunately, FreeBSD and Linux are similar enough that Docker for Mac usually doesn't have this problem.)  On both platforms, you have to have some protocol to make bind mounts work across the virtualization layer.  It's natural for some users to want to run "containers, but on Windows". Through Docker for Windows or Mac, we can give them the _illusion_ of this, but ultimately both of those clients are smoke-and-mirror shows. The more we interact with them, and the more complicated things we do with them, like networks of multi-container services, the more the illusion will break down. If you want a good container experience, port to Linux. Commit to it. Porting can be difficult, but it can be extremely worthwhile!  As the Bard wrote: > KUBELET: To port, or not to port -- that is the question: > Whether 'tis nobler in the mind to suffer > The slings and arrows of outrageous virtualization > Or to take arms against a sea of errors, > And by OS-porting end them. To move, to port-- > A chore--and by a port to say we end > The heartache, and the thousand natural shocks > That Windows and Mac are heir to. 'Tis a translation > Devoutly to be wished. To move, to port-- > To port--perchance to build: ay, there's the rub, > For in that land of Linux what Kubernetes may come > When we have shuffled off this Windows coil, > Must give us [pause](http://www.ianlewis.org/en/almighty-pause-container). > There's the change, that makes calamity of such long lifecycles. > For who would bear the bugs and port-forwards of Mac, > The Windows fsync, the impedance mismatch'd > The pangs of persisted files, I/O's delay, > The insolence of Hyper-V, and the spurns > That layer of abstraction that hides beneath, > When he himself might his productivity make > By embracing native Linux? Who would so endure, > To grunt and sweat under an eerie strife, > But that the dread of moving to another platform, > The undiscovered source-tree, from whose Bourne > No architect sees fit to leave, puzzles the will, > And makes us rather bear those bugs we have, > Than fly to platforms we know not of? > Thus Windows does make cowards of us all, > And thus the native hue of this solution > Is paper'd over with what Hyper-V hath wrought > And enterprise software of great pitch and moment > With this regard their sales leads turn away, > And lose the call to action.