The short answer is that selling developer tools is hard. Software engineers especially do not like to pay for stuff. We used to be in the DevOps space [0] and it is something that requires heavy enterprise sales to monetise well. There are few companies that truly took off in selling digital shovels, one example is probably Jetbrains. Most developer tooling/platform companies either died or got acquihired once they run out of funding. Flynn and Deis were both acquired and I suspect even the new generation of PaaS like Vercel would have to look for alternate sources of revenue once the VC funding dries up and if they do not achieve profitability. The container space is extremely challenging if you are competing directly with companies like Google with tremendous amount of cash and a willingness to buy developer mindshare. Docker may have popularised containers and singlehandedly brought the ideas of BSD jails mainstream but profiting from it is another thing entirely (you can do pretty well consulting on Kubernetes etc. but that would hardly give unicorn levels of return).

[0] https://news.ycombinator.com/item?id=23254394

This is why Microsoft's strategy is so interesting. They're capturing the value of IDEs and GitHub (a company that struggled to monetize while solo) by soft-bundling them together with Azure, which is extremely easy to monetize.

If it works, all those cool VS Code features will be covered in your monthly cloud bill.

Which microsoft understood well: those dev tools are popular, but can't make money. Well, they have money and they need to become popular again.

Deal.

Why is JetBrains a rare success compared to others?

I suppose it's hard to sell tools to people whose job it is to build tools, e.g. John Resig could never have sold jQuery because someone would have just written a feature compatible version for free. (edit, well the source is visible so that might be a bad example)

One thing coders do poorly is UX. Most things I’ve seen that are UX heavy done right are commercial and light-years ahead of open-source versions.

Mostly because they are really, really good, and they don't ask much for it.

I think I pay them less than $150 for a yearly subscription to their entire toolset, which is a price point that makes it stupid not to buy them. ReSharper is well worth a cup of coffee a week, by itself, and then there is DataGrip, WebStorm, IntelliJ, profilers, decompilers, and other stuff thrown in.

I also enjoy their universal subscription but I recommend trying Rider if you like ReSharper. Outside of small solutions, I find that ReSharper requires more patience than I can muster. The type-and-wait is significantly worse than I remember from classic Mac all-in-ones from the early/mid 90s.

Type and wait is literally the main reason I do most of my actual work in VS Code now instead of Visual Studio... I can't stand the full vs experience... code is just nicer imo.

What do you mean by type and wait ?

JetBrains seems to do a good job sticking with the core audience of in-the-trenches coders, instead of trying to expand in a way that feels corporatey and enterprisey.

The eternal question of how much you can capture of the value you create.

They were early in doing decent userland tooling around cgroups etc. Docker Hub too was a genius idea.

However their engineering went to crap - tonnes of issues with new versions where networking and other stuff broke, plus the whole "runs as root" thing. People only then realised that Docker wasn't the tool, it was the wrapper around it.

All this time they were trying to monetise it and failed pretty much.

This is the view as an outsider who's used it for years - anybody got a more accurate view?

They got their business solution (docker-swarm) eaten by kubernetes. So now they're only really the CLI and the public registry.

On Linux they aren't even the CLI anymore. Buildah and podman are much better

The downside to podman is that you lose docker-compose. (Yes I know there is podman-compose, but it isn't as complete.)

docker-compose has issues of its own, but when you can use it then it works really well.

At least for my use case, I haven't really noticed anything missing from podman-compose when I dumped docker-compose for it.

I think ideally they want you to use kube XML for this use case, though I haven't because it doesn't let me associate a named volume with a set of containers. The suggestion is to use bind mounts to the host instead, which feels like an issue for container portability. Podman Compose does not have this limitation

I tried to use the Podman and Podman-compose stack for a large develop docker environment I run locally.

The individual containers build alright, but running the compose with Podman-Compose failed miserably with unhelpful output - just a bunch of Python stack traces. Running it with Docker-Compose just worked.

I think that Docker-Compose is just a lot more lenient with Yaml type errors - where things should and shouldn't be surrounded in quotes. Podman-Compose just needs to be a little more forgiving, and continuing to parse the compose files if the semantics can be assumed, even if the syntax is not perfect.

How are they "much better"? Docker works extremely well. I build and run Docker containers all over the place and they Just Work.

"Docker" is just the userspace component of a Linux kernel feature. "Docker" doesn't run anything, the kernel does.

Podman has three main advantages over docker: Not needing to run as root, not requiring a daemon in the background and being packaged directly by linux distros.

Not so much the distros part, it's not in the latest Ubuntu 20.04 LTS unlike Docker. It's landed in the development branch of Debian though so maybe someday.

(Granted Docker is only in Ubuntu's "universe" section and not as a supported package that would receive security patches etc)

It is in Fedora and Arch. Ubuntu generally doesn't really follow any technologies anyone other than Canonical pushes out.

1. systemd runs as root, doesn't bother me that docker daemon does as well, since they do similar things (for me). Only users with access to the socket file have access.

2. I like the idea of not having a daemon but never actually had a problem with this in practice. The daemon has never crashed on me. systemd also has daemons that have also never crashed on me.

3. It's like 3 lines to install the official docker package. This is a non-issue for me.

Those do not sound like very meaningful advantages. Certainly not significant enough for me to want to switch from something that Just Works.

Thanks for the reply though. I'll be sticking with Docker.

The actual advantage of Podman and Buildah is that it is not Docker. Because of the tribal nature of tech communities, that is a desirable property for members of the "anti-Docker" tribe. Everything else is an exercise in retroactively justifying a subjective decision with seemingly objective criteria.

If you don't understand why others are so excited about those tools, it simply means that you're not part of their tribe.

Podman when not run as root has some significant drawbacks (e.g. containers can't communicate with each other). That's not specific to podman it's just hard to do without root.

Podman has long running processes as well, there's a podman process that'll run once you've launched at least one containner, and a conmon for each container (equivalent to containerd-shim)

Packaged directly... it is by RH and SUSE, don't think by debian/ubuntu. At least for ubuntu, 20.04 packages Docker 19.03 just fine.

Containers within the same pod can certainly communicate with each other without root? I'm running that setup right now for my graylog container and it's mongo and elastic search dependencies

Within the same pod sure, they share the same netns. I was talking about individual container comms.

With rootless podman they use slirp4netns and all get the same IP, with rootful podman or Docker a bridge network is established so that containers that aren't in the same pod can communicate with each other.

Interesting! I now refuse to allow the docker daemon anywhere except a VM on my machine as it does some really stupid things, runs as root etc.

Are there any downsides to podman that you know about?

    yrro@host$ podman run --rm -it debian:unstable bash -x -c 'id; cat /proc/self/uid_map'
    + id
    uid=0(root) gid=0(root) groups=0(root)
    + cat /proc/self/uid_map
             0  876099160          1
             1     231073      65536

This is done as a regular user with special rights on the system; all that is required are entries for yrro within /etc/subuid and /etc/subgid. There's no equivalent of Docker's daemon that hands out root on the machine to anyone who can connect to its socket.

I had the exact same question, and for podman one of the selling point is that it's a drop in replacement and you don't need root privilege : https://opensource.com/article/19/2/how-does-rootless-podman...

They're newer, and fewer people have heard of them.

Cut out the middle man. They don’t require the Docker daemon for one, which isn’t necessary. The client/server socket interface is the wrong model, the posix userland and filesystem interfaces to the kernel are a much better fit.

Not running as root, for one. There are also many other advantages, such as decoupling the building from the running, and running rootfs tarballs directly, blah blah blah.

I've struggled with podman, esp when following tutorials for docker when podman doesn't quite replicate. Is it worth persisting?

Yes, it's definitely worth persisting, especially if you use K8s. Podman can import/export Pod objects with the same API as K8s, so it makes it trivial to run the same k8s yaml locally and in a deployed environment.

Running a light weight Kubernetes setup like k3s locally is a better solution for that use case, imo.

k3s is something I've heard about but know very little. Does it use a VM? I tried skimming their website but couldn't parse that out.

No VM, it is just a light weight distribution of Kubernetes that can be effortlessly installed and run on Linux.

I personally feel that any pain you might face with podman is worth it just for the ability to treat container applications just like any other application on your system

https://www.redhat.com/sysadmin/podman-shareable-systemd-ser...

so daemonless (tbh I'm not even sure why is this a good thing) and better security through rootless aside, what are some strong points to switch over?

Rootless is really the big selling point for me. Means I can just let gitlab CI log in as a specific user to deploy my personal apps, without someone compromising gitlab/my gitlab account giving them root on my personal servers.

The other advantage is that it can setup containers based on kubernetes xml file or export a local setup to a kube xml file. This is because Podman is really aimed at the small scale setups - if you would have used docker-compose with docker, you might consider Podman, but the export lets you prototype with something convenient locally then export a config when you're happy to test on the big complicated tooling.

I keep hearing this meme that Kubernetes made it hard for Docker to monetize Swarm. But as far as I can tell, Swarm is free and open-source. Docker has never actually charged money for it. What am I missing?

Docker was spun out from dotCloud(Heroku like service) and dotCloud service was sold. I'm curious what if they could monetize from dotCloud.

telemetry.

docker has a bunch of telemetry.

microsoft is gathering data: linkedin, windows, wsl, github, docker

who's who, and what are they doing, compiling, checking in, deploying