[cyphar]

I hate to engage in this petty in-fighting (especially since I want podman to succeed and actually be as secure and well-designed as rkt was but with OCI runtime support).

Unfortunately, I don't agree with this whole "it must be more secure because we broke it into bits" argument. That alone is not sufficient in order to increase security. The vast majority of the code in libpod/cri-o is very similar to (generate a config and pass it to runc) or copied directly from Docker (containers/storage, with containers/image honestly having quite a few more problems than Docker's image parsers). When I found CVE-2018-15664, not only was the libpod/cri-o stack also vulnerable but it was as vulnerable as Docker was more than 5 years ago when I fixed the original security flaw in 2014. I feel bad saying this (I don't want to blame the folks working on this, who I do respect immensely) but it really should be a serious consideration if you want to put "more secure" in your advertising.

This is why I argued for several years that we should add OCI runtime (and custom storage driver) support to rkt instead of having to redesign everything (and since we started with cri-o instead of libpod, getting rid of the daemon was a pain there too). But of course, like every other discussion I've had with Dan Walsh, it was brushed away. Whatever.

I do really like the folks behind the project. I just wish we'd spent our collective energy on improving something that already existed instead of repeating mistakes pointlessly. I'm definitely not a fan of Docker's politics either (and at the very least nobody from the cri-o/libpod project has sent me abusive emails calling me stupid and "brainwashed by Red Hat" for criticizing their project's governance model -- which Solomon Hykes did in the past when he was still the CTO of Docker).

Disclaimer: I work for SUSE and maintain runc, and have worked on containers for a depressingly long period of time. Obviously the above are my views not those of my employer (who ships both Docker and cri-o, and my team maintains it in our products). I'm just tired of all the fucking drama.

[jacques_chester]

> I'm just tired of all the fucking drama.

I wasn't aware there was any, my perspective comes from working from a different end (dockerless builds).

I know what it can be like to work in communities fraught with vendor politics and other troublesome dynamics and have come close to burning out a few times.

It always feels too important to walk away from, even temporarily, but I promise, it's not true. Your own health is important.

[cpuguy83]

Amen. There is a heap of mess from the land-grab war.

We are all on the same team, just want to make this stuff better, but people still seem intent on fighting.

[cyphar]

For the sake of balance -- I do want to clarify that there is definitely land-grabbing happening on both sides of the aisle here. cri-containerd is a good example of the "Docker side" trying to land-grab cri-o's niche.

But again, I don't like all of this stupid politics over such trivial crap. It's ridiculously draining that I have to deal with people from the Docker project demanding me to apologise for things that Dan Walsh has said (or playing dumb when someone else from the SUSE makes a snide comment about several-year-old PRs that have burned out several of our engineers -- and then asking me to try to force them to apologise for it), as well as having to deal with the issues I outlined above. All of this back-and-forth has no benefit to anyone involved (or outside) and is just a waste of our collective lives. Posting this publicly probably won't help either, but I really don't know what the solution is other than to just quit and work on something else where we aren't just collectively accelerating human entropy.

To be frank, this is the main reason I've been working more with the LXC folks in recent years -- there are more interesting problems there and I don't have to deal with this crap. They also have really brilliant engineering, but that's not the main thing that attracted me to working with them.