Live data from Hacker News

Podman: A Daemonless Container Engine

podman.io

221–230 of 250 posts

Re: Podman: A Daemonless Container Engine

#221
post #165
post #158

Earlier quoted context omitted.

> Excellent question, especially since the code is copy-pasted without crediting the original authors. That seems like a serious allegation. Can you back that up?

It’s right there in the repo history. Start from the first commits. I don’t know how serious of an allegation it is: copy-pasting open-source code without crediting it properly is rude, but not illegal.

It is actually against copyright law, and redhat legal would take any allegations very seriously. What in specific do you think is copy and pasted code?

Re: Podman: A Daemonless Container Engine

#222
post #220
post #190

Earlier quoted context omitted.

I understand what you’re saying but it is incorrect. Docker was in fact the originator of OCI in every way that matters. They made the decision to create it; drafted the founding documents and went back and forth with Linux Foundation on the content; chose the names (initially OCF, then later OCI); negotiated with LF the governance structure and initial board composition; negotiated the list of external maintainers w…

Well thanks for your input, and I stand corrected. I liked Solomon and he always seemed like a super nice guy when I met him, but it did seem that there was a bit of a crisis when Docker Inc realized, "Oh shit, we have to make money for these VCs!" and then it got really awkward. I was sad to see it happen as Dan Walsh and Solomon are both really good peeps to me.

Yeah the tensions were really unfortunate. In the long run it resulted in more competition which benefits all of us; but in the short term it made people’s lives more stressful than they needed to be.

I actually have a slightly different explanation of what set it off. I don’t buy the “docker is suddenly under pressure to make money” explanation. Docker was a VC funded startup since 2010. They already had a business when they pivoted to Docker. As far as I know they kept the same investors and board. So it seems unlikely that they suddenly remembered that they needed to make money. More likely they planned to make Docker as ubiquitous a platform as they could, at which point there are many known avenues to monetize. Also, the CEO they brought on board, Ben Golub, had just spent a year at Red Hat after selling his previous startup to them. So he was certainly familiar with Red Hat’s business and strategy, and probably on friendly terms with their leadership (this is speculation on my part).

And in the early days Red Hat and Docker were in fact partners. Docker engineers even implemented features specifically to please Red Hat; for example devicemapper support and storage drivers, which were developed by Docker for Red Hat.

The problem is that the partnership was built on a misunderstanding. Docker was hoping for a distribution deal between the two businesses, with revenue share etc. and intended to keep control of their open-source project. Whereas Red Hat was hoping to make Docker their “new Linux” which involved no partnership with Docker and instead taking or at least sharing control of the project as they did with Linux. Each side was slow to realize the true intentions of the other, whether by naivete or deception I don’t know. This still surprises me because both side’s intentions were rational and entirely predictable. I think a lot of wishful thinking, and possibly some individual incompetence in leadership were involved. For example Red Hat has never actually partnered with a smaller startup and shared revenue with them in the way Docker was hoping, so I’m not sure what made them so confident it would happen. In any case, when the fog lifted, bitterness and conflict quickly followed.

In the end Red Hat shifted gears to Kubernetes as their “new Linux” which was a much better match for them. Then proceeded to rewrite history to minimize Docker’s role; which is unfortunate but understandable, I guess. I know a lot of Docker employees are personally hurt by it, to this day. It doesn’t feel good to see your work swept under the rug for reasons of competition and ego.

Re: Podman: A Daemonless Container Engine

#223
post #222
post #220

Earlier quoted context omitted.

Well thanks for your input, and I stand corrected. I liked Solomon and he always seemed like a super nice guy when I met him, but it did seem that there was a bit of a crisis when Docker Inc realized, "Oh shit, we have to make money for these VCs!" and then it got really awkward. I was sad to see it happen as Dan Walsh and Solomon are both really good peeps to me.

Yeah the tensions were really unfortunate. In the long run it resulted in more competition which benefits all of us; but in the short term it made people’s lives more stressful than they needed to be. I actually have a slightly different explanation of what set it off. I don’t buy the “docker is suddenly under pressure to make money” explanation. Docker was a VC funded startup since 2010. They already had a business…

Alexander Larsson did the lions share of the work on device mapper, and here are 29 PRs to show it (including the very first with the devicemapper label):

https://github.com/moby/moby/pulls?page=2&q=is%3Apr+is%3Aclo...

In fact, Solomon's own words from https://github.com/moby/moby/pull/2609 "Integrate lvm/devicemapper implementation by @alexlarsson into a driver", so unless you're more knowledgeable about the history than Solomon, I'm going to have to discount your take on this entire thing.

Regardless, I think things are at a much better place now. It is unfortunate that there were tensions and more so that Solomon had such a tough time through it all. He's a super nice guy. But this is tech, and there will always be lots of personality conflicts. It is one of the precious few constants.

Re: Podman: A Daemonless Container Engine

#224
post #223
post #222

Earlier quoted context omitted.

Yeah the tensions were really unfortunate. In the long run it resulted in more competition which benefits all of us; but in the short term it made people’s lives more stressful than they needed to be. I actually have a slightly different explanation of what set it off. I don’t buy the “docker is suddenly under pressure to make money” explanation. Docker was a VC funded startup since 2010. They already had a business…

Alexander Larsson did the lions share of the work on device mapper, and here are 29 PRs to show it (including the very first with the devicemapper label): https://github.com/moby/moby/pulls?page=2&q=is%3Apr+is%3Aclo... In fact, Solomon's own words from https://github.com/moby/moby/pull/2609 "Integrate lvm/devicemapper implementation by @alexlarsson into a driver", so unless you're more knowledgeable about the history…

It is absolutely not correct that Larsson did the lion’s share. What he did was implement a Go wrapper for libdevmapper, which exposes a very low-level API. It is the Docker team that implemented devmapper-based container storage, as well as the whole storage plugin system which was now required to support more than one storage method. The original devmapper lib is utterly undocumented and Larsson’s wrapper did not fix that. So getting that feature to work was an all-consuming task and it is the Docker team that did the bulk of it.

You can see all this from the early history of the devmapper directory: https://github.com/alexlarsson/docker/commits/a14496ce891f1f...

Re: Podman: A Daemonless Container Engine

#225
post #206

Earlier quoted context omitted.

Are you saying that every project written in C has suffered from a memory leak issue at some point? Most C/C++ code I've personally written doesn't even use the heap. I work on avionics and we use C/C++ now and then. We have a ton of rules regarding memory management (pretty much everything stays on the stack) and I can't recall anything I've ever been involved with suffering from a memory leak.

If basically everything stays on the stack, you’ll have a much lower chance of seeing a memory leak, by definition.

Exactly. Using C/C++ doesn't have to mean using the heap.

Re: Podman: A Daemonless Container Engine

#226
post #143
post #98

Earlier quoted context omitted.

This is C, not C++. Modern C++ is kind of a mess with how much stuff they’ve added to the language. This is not relevant.

> Modern C++ is kind of a mess with how much stuff they’ve added to the language. This is not relevant. Yeah and C++ would be a way better language to write critical system daemon in 2020 than C. Both safer and more productive while keeping the exact same portability and performance as C when necessary. Most safety issues of C (buffer overflows, use-after-free, stack smash) are not a problem anymore in modern C++. Ye…

It's not feasible nor desireable to abandon C. Rather it is better to incrementally move to things like checked C, apply static analysis and perform formal proofs of correctness through Frama C and other tools.

Do not use C++. Use Ada or Rust.

GCC did not move to C++ for safety, but for the convenience C++ can provide. C++ is a very problematic language. It does not replace C due to its complexity.

Re: Podman: A Daemonless Container Engine

#227

Earlier quoted context omitted.

With root it's easy to mess up the system badly ("I'll just fix that small error") and/or let all systems slowly diverge. And if something fails on my workstation, it will fail on many others as well and needs a coordinated solution. Also, giving every dev root is a security liability, especially when there is absolutely no work reason that requires us to become root. So only a few "core IT" people have root access.…

Developing anything without root in your own machine these days must be an absolute nightmare. If I may ask, what stack are you using? I can imagine Java, but that's about it. Go, Python, Node, etc, all of them I've needed root access to test some packages, for instance. I would guess developers must be using a lot of "workarounds" without management's knowledge.

C++. And it's no problem :) I don't need privileged ports, and I don't need write access to the OS.

Only thing that annoyed me was when I did some work on an internal web tool (php+js) and had no php-fpm & httpd. But by now I've got a container for that.

Re: Podman: A Daemonless Container Engine

#228
post #82

Earlier quoted context omitted.

This. SO MUCH THIS. We use docker for our CI, which is mostly okay. But we devs don't have root on our workstations, so we can't just load the docker image and test stuff in the CI env. Enter podman: I've written a small perl wrapper around it and now everyone can just call `ci-chroot` to drop to a CI-equivalent shell. They can get virtual root (default) or normal user (--user), and the script takes care of everythin…

I'm intrigued that you must run Manjaro and kind of want work with you because of it. :) Manjaro is great. Best Linux experience I've had so far. It's good that people recognize it.

It's just great. But I also like Arch@home.

Re: Podman: A Daemonless Container Engine

#229
post #73

Earlier quoted context omitted.

But not Buildkit and docker-compose.

Podman v3 is compatible with docker-compose (but not yet swarm mode, FWIU), has a socket and a daemon that services it. Buildah (`podman buildx`, `buildah bud --arch arm64`) just gained multiarch build support; so also building arm64 containers from the same Dockerfile is easy now. https://github.com/containers/buildah/issues/1590 IDK what BuildKit features should be added to Buildah, too?

> IDK what BuildKit features should be added to Buildah, too?

Cache mounts are what we rely on for incremental rebuilds.

Re: Podman: A Daemonless Container Engine

#230

Earlier quoted context omitted.

Developing anything without root in your own machine these days must be an absolute nightmare. If I may ask, what stack are you using? I can imagine Java, but that's about it. Go, Python, Node, etc, all of them I've needed root access to test some packages, for instance. I would guess developers must be using a lot of "workarounds" without management's knowledge.

C++. And it's no problem :) I don't need privileged ports, and I don't need write access to the OS. Only thing that annoyed me was when I did some work on an internal web tool (php+js) and had no php-fpm & httpd. But by now I've got a container for that.

Well, I suppose if your dependencies are very locked down it might work in C++.

I would guess, though, that having to change the prefix and default locations in all tarballs you download must be quite a pain. You can't install DEBs or any other tools either?

Post reply on HN