6 ms·

I strongly believe that both flatpak and docker both went about the wrong way of building images. they should have leveraged the package model that linux distr

I strongly believe that both flatpak and docker both went about the wrong way of building images. they should have leveraged the package model that linux distributions already have and viewed them as mix and matchable layers much like packages are mix and matchable. with full dependency resolution. i.e. creating an "apache" container image should be as easy as "apt-get install apache" but without actually installing anything. just creating a manifest that references the packages/layers that are needed. simple upgrades a container image is then just upgrading the set of layers in the container image, and unlike docker where even if 2 layers are exactly the same content, if a layer "above" them is different, they are different layers, in a package -> layer concept that's unnecessary. In fact, this is what I published and created the notion of container images that are defined by a file system that is created by composing a set of shared layers together, but Docker took the easy way out and punted on that. this would also make it simple(r) to do security analysis on container images as well as compose multiple images together. https://www.usenix.org/legacy/events/atc10/tech/tech.html#Potter https://www.usenix.org/legacy/events/atc10/tech/tech.html#Po... https://www.usenix.org/legacy/events/lisa11/tech/#Potter https://www.usenix.org/legacy/events/lisa11/tech/#Potter (which also goes to my in joke that I'm the only one who can get a job that requires 10+ years of docker experience ;) )

cheph 6y ago
Sometimes the easy way is all that there is capacity for. So I agree there are potentially better ways but IMO the world is better off with flatpak and docker than without them and we are free to still investigate and try better ways with all the time we save with docker and flatpak. I for example use conan(.io) for some binaries - and there you can compose arbitrary packages - and theoretically it can serve as the basis for a package based approach to composition.
- pjmlp 6y ago
  HP-UX Virtual Vault was a thing back in 1999, among other examples I can reach for. Sometimes before getting the capacity, one should learn from what already was achieved in the past.
- compsciphd 6y ago
  I agree, I don't fault them for taking the easy way, I do think it was wrong though. I created tools tools for converting debian packages into layers (in my research I stored these layers on a shared file system (either a multi-attach (in practice would need an fs that can have a single writer and multiple readers, which might simplify things) on a san or nfs. But, debian packages aren't really made for this directly, as they have their pre/post install/remove scripts. My "hack" was to treat every package as an dpkg --unpack version (i.e. not configured) and then at image "build" time (i.e. each image is really a layer that is a manifest of dependent layers + data created at image build time), we would dpkg --configure --pending all the composed layers (with a bit of magic happening behind the scenes to make dpkg realize that the packages were unpacked but not configured yet). This mostly worked well, but you could have some ordering issues. A bigger issue is because debian doesn't expect this to happen, it creates encryption at install time (say for ssh), not at first run time. So for example, if one created an ssh daemon image, any instance run from it would have the same key. not a great idea. Of course, its possible to engineer my way out of this (simple case would be to write tooling to recognize these cases and inject it into the created images), but it goes to why a direct conversion from debian packges into layer wasn't a silver bullet solution. I had the thought that perhaps an Ubuntu type approach would work, where some packages are wholesale imported from Debian into Unbutu without any changes but "important" packages ae modified to fit Ubuntu better could work. As an aside, the 2 papers referenced above were my "job talk" for my post doc at IBM Research, and got me the job. I tried to get support to continue this line of work there, but that never happened (and then my manager left, and I was left working on unrelated cloud stuff for the last 1.5 years there). Of course, this is now important to IBM (see Red Hat purchase). I wasn't approaching this from the pet/cattle metaphor, so I also gave my system the ability to upgrade instances in place by mark removeding layers as unlinked (i.e. ignored by readdir/lookup), and adding new layers. A big advantage here over traditional package management is that this made upgrades "atomic". For example, when you upgrade libc in the traditional package managed world, your system is temporarily "broken", in the sense that any executable that tries to run in between old libc removal and new libc installation will fail as its not on the file system. However, in the cattle world of containers, this is probably unnecessary complexity.
  - ece 6y ago
karmakaze 6y ago
My problem with "the package model that linux distributions already have" is that it's not one model and each one often comes out a bit different for unintended/unknown reasons.
- compsciphd 6y ago
  when I say package model, its short hand for a dependency graph model between packages where packages can easily be installed and upgraded independently with whatever dependencies that they need to be installed along with them. If one really wants to simplify it, I'd say "Debian's package model" as that's what I have the most direct experience with.
  - karmakaze 6y ago
    Funny you should mention that as it's exactly what I've had problems with. Even though Debian and Ubuntu use the same package model/format but having separate repositories use differently made packages with varying default settings for example. Because of this I've found that less popular software in Debian repositories are less crowd-tested. Flatpack fixes this. I would like to freely choose the best package and use it on the best distribution for my purposes.

cheph 6y ago

Sometimes the easy way is all that there is capacity for. So I agree there are potentially better ways but IMO the world is better off with flatpak and docker than without them and we are free to still investigate and try better ways with all the time we save with docker and flatpak. I for example use conan(.io) for some binaries - and there you can compose arbitrary packages - and theoretically it can serve as the basis for a package based approach to composition.

pjmlp 6y ago
HP-UX Virtual Vault was a thing back in 1999, among other examples I can reach for. Sometimes before getting the capacity, one should learn from what already was achieved in the past.
compsciphd 6y ago
I agree, I don't fault them for taking the easy way, I do think it was wrong though. I created tools tools for converting debian packages into layers (in my research I stored these layers on a shared file system (either a multi-attach (in practice would need an fs that can have a single writer and multiple readers, which might simplify things) on a san or nfs. But, debian packages aren't really made for this directly, as they have their pre/post install/remove scripts. My "hack" was to treat every package as an dpkg --unpack version (i.e. not configured) and then at image "build" time (i.e. each image is really a layer that is a manifest of dependent layers + data created at image build time), we would dpkg --configure --pending all the composed layers (with a bit of magic happening behind the scenes to make dpkg realize that the packages were unpacked but not configured yet). This mostly worked well, but you could have some ordering issues. A bigger issue is because debian doesn't expect this to happen, it creates encryption at install time (say for ssh), not at first run time. So for example, if one created an ssh daemon image, any instance run from it would have the same key. not a great idea. Of course, its possible to engineer my way out of this (simple case would be to write tooling to recognize these cases and inject it into the created images), but it goes to why a direct conversion from debian packges into layer wasn't a silver bullet solution. I had the thought that perhaps an Ubuntu type approach would work, where some packages are wholesale imported from Debian into Unbutu without any changes but "important" packages ae modified to fit Ubuntu better could work. As an aside, the 2 papers referenced above were my "job talk" for my post doc at IBM Research, and got me the job. I tried to get support to continue this line of work there, but that never happened (and then my manager left, and I was left working on unrelated cloud stuff for the last 1.5 years there). Of course, this is now important to IBM (see Red Hat purchase). I wasn't approaching this from the pet/cattle metaphor, so I also gave my system the ability to upgrade instances in place by mark removeding layers as unlinked (i.e. ignored by readdir/lookup), and adding new layers. A big advantage here over traditional package management is that this made upgrades "atomic". For example, when you upgrade libc in the traditional package managed world, your system is temporarily "broken", in the sense that any executable that tries to run in between old libc removal and new libc installation will fail as its not on the file system. However, in the cattle world of containers, this is probably unnecessary complexity.
- ece 6y ago

karmakaze 6y ago

My problem with "the package model that linux distributions already have" is that it's not one model and each one often comes out a bit different for unintended/unknown reasons.

compsciphd 6y ago
when I say package model, its short hand for a dependency graph model between packages where packages can easily be installed and upgraded independently with whatever dependencies that they need to be installed along with them. If one really wants to simplify it, I'd say "Debian's package model" as that's what I have the most direct experience with.
- karmakaze 6y ago
  Funny you should mention that as it's exactly what I've had problems with. Even though Debian and Ubuntu use the same package model/format but having separate repositories use differently made packages with varying default settings for example. Because of this I've found that less popular software in Debian repositories are less crowd-tested. Flatpack fixes this. I would like to freely choose the best package and use it on the best distribution for my purposes.