Hacker News Reader

Comment by west0n | Hacker News Reader

Neal Gompa opened a discussion on the Fedora development list, noting the license change and the need to remove Redis from Fedora.

Gompa also raised the issue on openSUSE's Factory discussion list.

After Docker was phased out, various distributions have adopted the compatible Podman as a replacement for Docker. It seems that a similar story is unfolding with Redis.

View on HN

NB: Docker Engine is open source. (Docker Desktop is not.)

Moby is open source. The licensing situation for Docker Engine is unclear.

How so?

https://docs.docker.com/engine/#licensing >The Docker Engine is licensed under the Apache License, Version 2.0. See LICENSE for the full license text.

The linked license file is moby's https://github.com/moby/moby/blob/master/LICENSE

Docker Engine is the name for the compiled binaries, right? The licensing situation for them must be more complicated than suggested by that LICENSE file.

> need to remove Redis from Fedora

I don't get it; does the new license prohibit it from being distributed thus, or is this a philosophical "need"?

Fedora only includes free software in it's repos:

> If it is proprietary, it cannot be included in Fedora. (Binary firmware is the only exception to this)

https://fedoraproject.org/wiki/Forbidden_items

Proprietary software is distributed through the unofficial RPM Fusion repo

Docker was only phased out in red hat distros because they don't like it and want to push Podman. Others still have docker packaged in their repos.

A bit reductionist. IIRC the main reason Docker was phased out because Red Hat wanted to push rootless, daemonless containers, which required CGroups v2, which Docker didn't want to support for the longest time. Since both versions of CGroups can't be enabled simultaneously, and no distro wanted to go without Docker (or at least Docker-like) functionality, CGroups v2 was left in permanent stasis, and so Red Hat started Podman to break the deadlock. There were a laundry list of other technical disagreements (mostly around security) but that was the primary one.

And then once Red Hat distros switched over to CGroups v2, which Podman enabled them to do, it meant that Docker wouldn't really work all that well anymore until they eventually switched to CGroups v2 also (which they eventually did a few years later). So that's why it got removed from the repos, at least originally.

It's not in Debian and their wiki straight up directs you to podman with a nice big scary warning about dockers root issue.

https://wiki.debian.org/Docker

Docker is dyeing on linux podman will be the only one that remains.

It's in Debian: https://packages.debian.org/sid/docker.io

huh well I'll be damn I thought this had already been resolved back to the mailing list it seems.

That version is so old. I just use Docker's own apt repo to not fall behind.

The page suggests podman in a small info box (one that people might skip, because it feels like the Wikipedian "this article has issues" box), but it also tells you how to install real Docker. Docker has name brand recognition, and even if it wasn't in Debian's official repos, it would be installed from Docker's own repos. This wiki isn't popular enough for this to matter anyway, people are likely googling for "docker debian" and are finding instructions for real Docker. I don't feel like Docker is dying.

And besides, that issue with root feels overblown in the era of single-user systems and servers as cattle.

> that issue with root feels overblown in the era of single-user systems and servers as cattle.

Uh. No.

No? Sorry if that's a bit cynical, but Docker is only dying in the opinion of distro maintainers. By this metric, it's been dying for the past 8 years, but everyone is still talking about Docker, not podman.

A related problem I've seen from other complaints made elsewhere is that podman does things just slightly different enough than Docker that it's not a true drop-in replacement.

We've seen that before; where distro maintainers declared software too dangerous/prematurely dead for a while. All it resulted in was community hosted repositories for the old software. (Read: this is why avconv failed.)

Yeah I don't think Docker is the type of tool the typical engineer cares enough about to go out of their way to learn something new, no matter how much better or simpler it may be. I guess it's like git; even though most devs only have a surface level knowledge, dethroning it would require convincing people to learn a new system, and that's not gonna happen no matter how good it is.

Red Hat at least had the muscle to force podman onto some people, but not everyone.

idk, I actively dropped docker as soon as I reasonably could. podman is an objectively better tool by nearly every metric and it has an almost exact 1:1 CLI tool, so there's not really a learning curve besides a few configuration differences

Sometimes I get the feeling all the folks touting podman as a drop-in replacement for docker are doing it in bad faith.

Every few years I try to replace my containers managed through docker-compose and it's always a sure miss. Before podman gained official support for the docker-compose spec, there was an unofficial podman-compose project that sort of worked save for a few podman incompatibility bugs here and there.

So I was delighted to try out the "official" docker-compose for podman. Quickly learned that there's no such package, the official podman-compose is just the same docker compose package, you just use it with podman the same way you would with docker. Despite this glaring inconsistency I decided to give podman a try (if you are going to install docker compose on your system might as well just use docker). Noped out when I tried to create a VPN with a podman container and it was failing requiring me to enable a kernel module (TAP or TUN can't remember exact error) to create a vpn.

Anyone who says podman is a drop-in replacement for docker never used docker much for anything more than running hello-world. I would only recommend podman over docker for someone who's new to containers and has never heard of docker before.

> Noped out when I tried to create a VPN with a podman container and it was failing requiring me to enable a kernel module (TAP or TUN can't remember exact error) to create a vpn.

Those are pretty standard kernel modules for enabling userspace networking, which if you were using podman in rootless mode you need (along with another userspace networking package, slirp4netns). "Drop in replacement" does not mean there's not configuration to get it set up, it means it has the same APIs as another system.

I've been using containers for almost 10 years and with almost no fanfare switched to podman 100% like a year ago. Just because you expected to have to do nothing at all doesn't mean it doesn't work.

Podman doesn't expose an interface for enabling kernel modules. The error message is intentionally intended to discourage users from doing administration on systems, just like the other similar messages you'll get about trying to use "privileged" ports (<1024).

Am sure you can get over the kernel module tun creation and other limitations by using something like --privileged but at that point, why not just use docker if you are going to run containers "insecurely".

And for the sake of this argument, drop-in replacement means I can take my tools and move them over to the alternative with little to no extra work needed on my part.

>Am sure you can get over the kernel module tun creation and other limitations by using something like --privileged but at that point, why not just use docker if you are going to run containers "insecurely".

Because at least you can tell that it's insecure, rather than insecurity being the default?

Secure defaults and containers is kind of an oxymoron.

Also the "secure" defaults don't matter much if you have to manually jump through hoops in sysctl and modprobe to get things to work. Infact I could even argue that this introduces the risk of having an insecure server by misconfiguration.

Also containerd and cri-o fit in here somewhere, too.

I could be convinced Docker-on-headless-servers has been dying a while but the desktop variants are alive and well

docker-cli is still open source (Apache 2.0) and being distributed in most flavors of Linux. Docker the company does not own all the source code. But like redis they are free to build their own non open source products around this code base.

Reply on news.ycombinator.com