131–140 of 250 posts
I have recently found out you can actually run Docker containers with LXC as well. I've yet to get deep into it, but it seems to work fine*. * Manual config tweaking may be required.
Right about then systemd came along (as in, my distro at the time adopted it) and essentially required a service to monitor (some process, tcp port, or file to monitor), but my efficient little script had no service by design, because none was needed and I hate making and running anything that isn't needed to get a given job done. (Plus about that time my company went whole-hog into vmware and a managed service provider and so my infant home-grown lxc containers on colo hardware system never grew past that initial tiny poc)
I laugh so many years later reading "Hey! Check it out! You don't need no steeenkeeeng daemon to run some containers!"
I've been trying to use podman in production and it is not working very well. I'm excited for this technology but it is not ready. - podman layer caching during builds do not work. When we switched back to docker-ce, builds went from 45 minutes to 3 minutes with no changes to our Dockerfile - fuse-overlayfs sits at 100% CPU all day, every day on our production servers - podman loses track of containers. Sometimes the…
Layer caching seems to work for me. Note that rootless stores images (and everything else), in different place from rootfull. It may be that you're caching the wrong directory.
Earlier quoted context omitted.
This I entirely agree with you on but I’d expect it due to the resources available at the time were more fluent with C than rust. A shame really.
Or they want to be more platform-agnostic than rust and llvm.
Portability seems like an unlikely reason here, but I would pick memory safety over portability every single day of the week. Rust is far from the only language that offers memory safety, but it is certainly one of the most compelling ones for projects that would otherwise be written in C.
"runc" is battle tested, written almost entirely in Go, which offers memory safety, and the performance delta under discussion is only about 2x for a part of the system that seemingly only has a measurable performance impact if you're starting containers as quickly as possible.
This just isn't a very compelling use case for C.
Earlier quoted context omitted.
Grudge? You mean when Jessie Frazelle walked around dockercon with a badge saying, “I will not merge patches for systemd” just out of principal? In hindsight it is fairly obvious picking a fight at redhat summit was a very poor long term strategy from docker. It forced them to ultimately sell the orchestration parts of their business and massively limit the free tier of docker hub.
Thank you for illustrating my point perfectly. “Grudge?” (proceeds with details of grudge).
I don't think it's a stretch to look at the events as described and see them as Red Hat doing what they need to work around someone else's grudge. It could be any number of things, but I don't think the information presented so far lends itself towards Red Hat having a grudge.
Earlier quoted context omitted.
Because people can’t install non-Red Hat software due to internal policy, that’s somehow anti-competitive?
The main repos have plenty of non-rhel sw, and people can expend social capital working around IT policies, but that doesn't change it being against the grain. We are fine because we use Ubuntu for the generally better GPU support, but I don't have control over the reality of others. I repeatedly get on calls with teams where this comes up, and I feel sorry for the individuals who are stuck paying the time etc. cost…
But this is the case for all software on RHEL. It's all older and more stable. Try installing any programming language, database, etc... it's always a version or two older in the official RHEL repositories. RedHat written stuff is always going to be more "current" because they control the repositories, but this isn't any different from how any other package is treated. RHEL has always been slow to update. (Which is why Docker created their own repositories in the first place).
It makes sense though... because RHEL has to check all packages that are part of their repository. Specifically because things in their repository are safe and stable. There is only so much time to go around testing updates to packages.
Earlier quoted context omitted.
Or they want to be more platform-agnostic than rust and llvm.
Which platforms does Red Hat support Linux containers on that Rust doesn't support? Which platforms is anyone else frequently using Linux containers on that Rust doesn't support? I'm pretty sure the venn diagram here would be a single circle. Rust supports the major architectures. Portability seems like an unlikely reason here, but I would pick memory safety over portability every single day of the week. Rust is far…
If I worked for RedHat I would still seek to write as portable as possible just on general principle or for the sake of my own future self.
But I agree it's merely a possible reason and may not be a major one.
You have root in the container without having root in the host system. That takes care of a lot of issues as well.
Under the covers, both podman AND docker use runc. Redhat is writing a new version named "crun" which is lower overhead and faster: https://github.com/containers/crun
Great idea - let's rewrite the most security-critical piece of container tech in plain C! Red Hat literally took a memory safe Go program and rewrote it in C for performance, in 2020.
Earlier quoted context omitted.
Great idea - let's rewrite the most security-critical piece of container tech in plain C! Red Hat literally took a memory safe Go program and rewrote it in C for performance, in 2020.
It’s not for performance. It’s to settle an old grudge with Docker. All code coming from Docker must be erased. See also: podman; cri-o; buildah.