5 ms·

Oh yeah. Systemd and containers. Two technologies certain militant technical users love to complaint about :-) Do we really need a non-OCi image format and too

Oh yeah. Systemd and containers. Two technologies certain militant technical users love to complaint about :-) Do we really need a non-OCi image format and tool chain here?! I get immutability benefits, district benefits, and isolation. having a completely separate toolchain makes no sense to me... Containers will be in this role, but fragmentation will only make that process slower and more painful. I for one salute our future k8s kubelet overlords.

TheDong 8y ago
> Do we really need a non-OCi image format and tool chain here? This doesn't use a new competing image format, but rather uses disk images or tarballs, which have existed longer than OCI has. The toolchain also predates OCI since the underlying technology is really basically nspawn (and various other systemd.service options), which have been a part of systemd since before OCI stabilized. This is simply a new coat of paint on something that has been there for a while. > Containers will be in this role, but fragmentation will only make that process slower and more painful. Sure, so we shouldn't have let docker do anything and instead used LXC, since LXC already did containers, already had its own format and toolchain, etc. That's the exact same argument you're making now. OCI is also not really a good standard. It has exactly one usable implementation (and only in Go, not even C where it's easy to link against and use it from other languages), and since systemd has already defined various things for services (such as seccomp filters etc) which overlap with what OCI does, it makes almost no sense for systemd to begin using it.
- cyphar 8y ago
  I actually think more people should have adopted LXC. The engineering behind LXC is beyond remarkable and it's a shame that it got such a bad wrap in the early days of Docker. I've worked with some of the LXC folks and they're all incredibly sharp and have a much wider breadth of work than just LXC. With regards to image formats, I actually think that we do need to improve the image format significantly and not just stick to tried and tested stuff. Tarballs are (quite frankly) simply the most awful format to use for container images (disk images are a close second). It's a shame that everyone uses them. I am working on a blog post to better explain what I mean by this. And yeah, runc being written in Go is probably one of the most frustrating things about working on it. I often say that one of the worst things you could decide to write in Go is a container runtime -- it's a little bit odd that people keep doing exactly that. runc actually isn't entirely written in Go -- it has to have a fairly substantial amount of C because the Go runtime cannot play well with the delicate dance required to set up a container properly. All of that being said, containers really did need to be standardised otherwise the container wars wouldn't have ended as nicely as they did. But that's not to say that the OCI doesn't have issues. It definitely does, but I'm hoping they can be fixed over time. [ I am one of the maintainers of the "exactly one usable" OCI implementation, and have been working on OCI stuff since its inception. ]
  - CameronNemo 8y ago
    Something to note about LXC developers: they don't just provide a wide array of usable interfaces to containers (daemon with a RESTful API, command line tools, and a library with many language bindings). They also are some of the most active contributors to the underlying container technology in the kernel, including namespaces and cgroups.
    - cyphar 8y ago
      > They also are some of the most active contributors to the underlying container technology in the kernel, including namespaces and cgroups. This is what I was referring to when talking about their breadth of work. I've collaborated with them quite a bit, and it's always amazing working with them on a hard problem.
  - InTheArena 8y ago
    We implemented a LXC based container system on a platform that I architected. It was not easy ;-)
jdc 8y ago
Shit, all this time I thought the problem was with things marketed as containers that _do not_ contain.
StreamBright 8y ago
Trying to treat people who does not agree with the broken software and systems engineering practices like a child is obviously won't help. Systemd and docker has legitimately bad engineering practices.

TheDong 8y ago

> Do we really need a non-OCi image format and tool chain here? This doesn't use a new competing image format, but rather uses disk images or tarballs, which have existed longer than OCI has. The toolchain also predates OCI since the underlying technology is really basically nspawn (and various other systemd.service options), which have been a part of systemd since before OCI stabilized. This is simply a new coat of paint on something that has been there for a while. > Containers will be in this role, but fragmentation will only make that process slower and more painful. Sure, so we shouldn't have let docker do anything and instead used LXC, since LXC already did containers, already had its own format and toolchain, etc. That's the exact same argument you're making now. OCI is also not really a good standard. It has exactly one usable implementation (and only in Go, not even C where it's easy to link against and use it from other languages), and since systemd has already defined various things for services (such as seccomp filters etc) which overlap with what OCI does, it makes almost no sense for systemd to begin using it.

cyphar 8y ago
I actually think more people should have adopted LXC. The engineering behind LXC is beyond remarkable and it's a shame that it got such a bad wrap in the early days of Docker. I've worked with some of the LXC folks and they're all incredibly sharp and have a much wider breadth of work than just LXC. With regards to image formats, I actually think that we do need to improve the image format significantly and not just stick to tried and tested stuff. Tarballs are (quite frankly) simply the most awful format to use for container images (disk images are a close second). It's a shame that everyone uses them. I am working on a blog post to better explain what I mean by this. And yeah, runc being written in Go is probably one of the most frustrating things about working on it. I often say that one of the worst things you could decide to write in Go is a container runtime -- it's a little bit odd that people keep doing exactly that. runc actually isn't entirely written in Go -- it has to have a fairly substantial amount of C because the Go runtime cannot play well with the delicate dance required to set up a container properly. All of that being said, containers really did need to be standardised otherwise the container wars wouldn't have ended as nicely as they did. But that's not to say that the OCI doesn't have issues. It definitely does, but I'm hoping they can be fixed over time. [ I am one of the maintainers of the "exactly one usable" OCI implementation, and have been working on OCI stuff since its inception. ]
- CameronNemo 8y ago
  Something to note about LXC developers: they don't just provide a wide array of usable interfaces to containers (daemon with a RESTful API, command line tools, and a library with many language bindings). They also are some of the most active contributors to the underlying container technology in the kernel, including namespaces and cgroups.
  - cyphar 8y ago
    > They also are some of the most active contributors to the underlying container technology in the kernel, including namespaces and cgroups. This is what I was referring to when talking about their breadth of work. I've collaborated with them quite a bit, and it's always amazing working with them on a hard problem.
- InTheArena 8y ago
  We implemented a LXC based container system on a platform that I architected. It was not easy ;-)

jdc 8y ago

Shit, all this time I thought the problem was with things marketed as containers that _do not_ contain.

StreamBright 8y ago

Trying to treat people who does not agree with the broken software and systems engineering practices like a child is obviously won't help. Systemd and docker has legitimately bad engineering practices.