For the comparison to os x docker, the biggest slowdown for os x docker is the file system mapping. It basically breaks any reasonable performance chart: look up posts getting into alternatives like mutagen. The slowdown makes using an IO-heavy dev flow like live editing via `npm run watch` relatively unusable: 30X+ slowdowns are normal. There might be high CPU overheads too (I recall we had to tweak seccomp), but when basic IO is so slow, the rest doesn't matter.
In contrast, yes, wsl2 has 5% CPU hits (hyperv, ...),but a sane FS mapping, so the total overhead is imperceptible for a windows dev box.
I was pleasantly surprised to see wsl2 Just Work. Our only issue preventing wsl2 from being the official team rec over native Linux has been wsl2's lack of opencl, and that's just specific to our use of GPUs. As someone whose preferred dev box has been osx for ~20 years, even when at MS, I was biased against Windows for most dev... but no longer.
Oh right yeah — to be honest because I was so used to file system mapping being so slow (and even on my W10 box it’s not perfect for deep file system trees like node_modules), I stopped using it.
VSCodes “Create Remote Dev Container from Repository” functionality has made it even easier. My dev containers have no overlap with the host filesystem so macOS and Windows are equally performant for my use cases :)
Yes, wsl2 afaict works like that and a bit improved. Instead of dual booting or a restricted dev env, I click my Linux terminal icon and jump into a full & fast Ubuntu, including UIs when helpful. Sharing with Windows is possible through a shared mount of C:, but I rarely encounter it, basically only for a web downloads folder or working around certs. Same thing for VS Code, have a Windows mode and a wsl2 mode, and it opens the right one for you.
Almost all our dev is generic, so that means Windows for Office/web/... and full Linux for dev (except no real OpenCL).
HyperV is lightweight and from what I understood, windows runs on top of hyperV too when you enable WSL2. You may lose a few % of performance in video games.
In theory yes, and we got tiny programs running this way, but could not afford to keep subsidizing megacorp politics.
Nvidia punts to IBM RHEL8 docs for GPU podman, which is unusual and risky to see. We officially recommend against it for HA environments due to this kind of lack and overall low relative confidence. I think k8s envs may be moving to something here, so maybe in a year or two? I'd be curious of folks doing stock rhel8 podman with tensorflow/torch on nvidia, which should be as vanilla as you can get for enterprise ai. We generally see more interesting GPU envs here (ex: DGX with advanced networking hw/sw), but we don't have confidence for the simple case, which is the starting point..
What got me at first are the limitations around rootless containers, which I wasn't accustomed to. Rootfull docker makes many things (networking, volumes etc.) Fairly easy.
The main use case right now is that your company won't spring for a docker desktop license (and you work in a windows/mac shop).
It works well enough for single docker images, but I've never gotten it to work well with a complicated docker-compose set-up (I haven't tried in a couple months though, so go check the docs before you write it off).
The macOS Docker Desktop app (I haven’t experienced other versions) is free and works fine. The paid upgrade is only required for certain features that I would imagine many teams don’t need.
My complaint with it is that I’d prefer if there was a 100% feature-parity CLI interface so it could run in the background, and that it should be open source.
To have a low-level developer tool that’s required to be in my menubar and administered through a closed-source GUI is IMHO an insane departure from web software development norms. I use lazydocker for now but it should be an official utility that replaces the GUI app.
Docker Desktop is now only free "for small businesses (fewer than 250 employees AND less than $10 million in annual revenue), personal use, education, and non-commercial open source projects." per https://www.docker.com/products/docker-desktop/
It works fine if you're working solo, but companies have to pay for it.
> To have a low-level developer tool that’s required to be in my menubar and administered through a closed-source GUI is IMHO an insane departure from web software development norms.
Yeah, this is why I mentioned the mac/windows shop part. Desktop is only required on mac/windows. On linux, it's just the cli, which works just fine (it's also free).
Docker desktop works pretty well, and I'm not saying they don't deserve the money, but I'm not going to spend my own money to do enterprise work, so I have to investigate alternatives (minikube and podman worked the best, in my experience).
If the company is of a certain size, Docker Desktop is no longer free. As in, it's free to install and use, but your company is supposed to pay a license.
Yeah, but there's no release of docker daemon for mac or windows. You have to run a linux VM and install and use it there. Docker desktop basically wraps that VM process up into a little gui app. If you're willing to do it yourself then yeah a simple virtualbox VM can run docker without issues or license fees.
From what I read, the "Personal" $0 tier still has "small businesses" listed, and the little info tooltip for Docker Desktop also explicitly mentions "small businesses."
This can be found at the very bottom of that page:
> Docker Desktop can be used for free as part of a Docker Personal subscription for: small companies (fewer than 250 employees AND less than $10 million in annual revenue), personal use, education, and non-commercial open source projects.
It's possible to run podman in podman in podman in …, which is nice if you containerize the build system but don't want to pack everything into one large image nor want to divide it into stages called by some main script on the host.
Podman has an almost identical CLI to Docker, and can have a daemon that is fully Docker compatible (thus, all Docker integrations work against it including docker-compose). It is literally a drop-in replacement but it doesn't require your company to buy licenses. So yes, you should if you can.
podman has had repeat compatibility issues for us, and redhat has made docker installation stupidly hard in rhel8 at the policy level, which matters given the monopoly status of rhel in secure environments. It is hard for me to support the podman community for basically ethical reasons at this point. Normally I like competition and innovation, but not like this.
IBM/RHEL seem to be the effective the stewards of Podman, and are using their monopoly-like position in enterprise OS segments to take control of the virtualization layer through it. This is similar but worse to old MS/Windows doing tricks for IE vs others. Supporting Podman is supporting explicitly anti-competitive IBM/RHEL OSS behavior for enterprise, utility, & gov environments.
This doesn't make any sense to me. How is stewardship over a method of running and managing containers that was originally born out of another project not collaborating with the commons (docker engine) enforcing a monopoly position?
Everything Red Hat produces is open source (except the branded offerings, which are derived from the OSS upstreams). They charge for support. If you don't want support, use the OSS upstreams. What lock-in are you explicitly pointing to? Because I have no idea what you mean by taking "control of the virtualization layer".
Also, I should note that Nutanix and VMWare are a thing but again I am unclear at what unethical behavior you are actually pointing to at Red Hat. I am only responding to a shaky interpretation of what I think you are pointing to.
Maybe you are not familiar with how enterprise , and especially utility and gov systems work? It is often hard to not use RHEL due to compliance policies. IBMers deciding to swap in their race horse -- and simultaneously hobbling the current one -- is effectively making the decision for the US Gov for the next 2 years.
Yeah sure OSS in theory and IBM is a free entity. But for the same freedom, I am free to call from for divesting from any use of IBM/RHEL products and consultants in enterprise and gov contracts as no longer a trusted and ethical partner due to their anti-competitive self-dealing at the clear expense of the community & customer. RHEL lost neutrality & HA credibility as an infra layer and IBM as a partner through this. Nothing personal, just business and trying to protect our users, same as the RHEL org's actions helping themselves.
Docker largely entered Enterprise (regulated & security conscious markets) like utilities, us gov, banks, etc. via rhel 7 / centos 7 . A lot of people doing a lot of compliance work everywhere, from approvals to infra to audits, invested serious time, $, and social capital to make that happen. With RHEL 8, IBM / RHEL bet on podman (or, "not docker"), all the way from marketing to M&A to repositories to where developer hours go. On its own, I think that's great: tech should keep pushing, and good pressure on docker for things like rootless. But, that's not the issue here.
Where this gets problematic for a commonly "single-sourced" infrastructure technology in regulated envs is IBM/RHEL also prevented docker from making it into the RHEL 8 repos. Podman was obviously technically deficient as a critical infra replacement due to immaturity like many unimplemented compatibility APIs, yet it was marketed as compatible and instead of offering both until the community could prove it out etc, RHEL8 didn't include docker. NBD for people doing redhat at home or whatever easy environments, but if you're doing something like bringing AI to important societal problems at big world-reaching orgs, having to go outside the main repos can be a major drain on time, staff, budget, and even an existential risk. This is the kind of BigCo malfeasance we're supposed to be moving away from by promoting Linux, OSS, and containers.
In secure airgapped environments, very much so. We blew time setting up new offline install processes & tutorials for the Nvidia docker ecosystem for rhel8, which basically reused centos7, as most of our users took weeks/months when they tried to figure out for themselves. Think utilities, gov, banks, etc: Anything not supported by official RHEL8 repos causes problems both technical and compliance.
RHEL8 felt like a repeat of IE vs Firefox but now for RHEL (main sponsor of Podman) vs Docker, and much worse. It's one thing if docker was never there or containers were removed, but this was replacing with a binary-incompatible tool under their effective control and marketing to security-critical customers (and on hackernews) as a safe and ready replacement. So we also burnt time diagnosising people were trying to use broken podman tech because that's all RHEL gave them and tricked them into thinking was appropriate.
Podman doesn’t have a daemon, it has a socket that will replicate the docker API. That comes with some limitations, especially around the lifecycle of containers in ie starting containers on boot, restarting unhealthy containers etc which require you to use systemd. Podman’s integration with systemd is pretty easy now though.
I'm not going to attest for accuracy on the statement, but from my RHCSA training I recall that docker runs as a daemon, while podman runs containers in separate processes; so it should be easier to avoid lockup/blocking.
