4 ms·

Disclaimer: I'm not a strong containerization proponent. The good part of containers is you isolating the thing you're running. I'm very against resource waste

Disclaimer: I'm not a strong containerization proponent. The good part of containers is you isolating the thing you're running. I'm very against resource waste, but if I can spend 90MB on a container image instead of installing a complete software stack to run a task which is executed weekly and runs for 10 minutes, I'd prefer that. Plus, I can create a virtual network and storage stack around the container(s) if I need to. Case in point: I use imap-backup to backup my e-mail accounts, but it's a ruby application and I need to install the whole stack of things, plus the gems. Instead I containerize it, and keep my system clean. Nix is something different and doesn't solve "many foreign processes not seeing each-other on the same OS" problem. Heck, even Docker doesn't solve all problems, so we have "user level containers" which do not require root access and designed to be run in multitenant systems.

marcosdumay 3y ago
Linux doesn't solve that problem at all. Qubes tries to do that with a hack, that is probably sufficient, but quite complex. I'd say that we don't have good solutions to that problem. But nobody even tried our best candidates, so I'm not completely sure. (For a while, it looked like Android would finally try some. But then Google turned it into a user-hostile anti-privacy OS.)
adamgordonbell 3y ago
> many foreign processes not seeing each-other on the same OS For sure, I was thinking of the packaging nature of containers, not the 'security' nature of containers. The pivotroot part. Though I guess being able to have namespaces does make packaging clearer in certain cases. For a horrible analogy: With actual shipping containers, we don't have each shipping container be a stripped down model of a ship, so that the things in it aren't confused.
- samatman 3y ago
  Agreed, it isn't great. Shipping containers are more like tarballs: a bunch of stuff (files) bundled into one "stuff" (file) so they're easy to ship around and pieces don't get lost in the process. I don't think there is a good physical-world analogy for what containers are doing, though. Maybe takeout including utensils and napkins to "simulate a kitchen" in case you eat it on the go, so you don't have to rely on the "system" forks and napkins? Still kinda rubbish honestly.
- bayindirh 3y ago
  The packaging is generally a side-effect of isolation in my experience. I never chrooted a software because I needed a different library stack for it to run, but to isolate it from rest of the system in one way or another (for security/access reasons). Docker just made the interface more practical, and built the ecosystem around it. lxcontainers, apptainer and podman has improved upon the idea in different ways to cater different use cases. So for me containers were never simplified ships to begin with. This different perspectives happen probably because people look from different perspectives at initial contact, which is normal.
zer00eyz 3y ago
>>> To me, all that points at containers being in some way a solution to Dynamic linking. And maybe an over the top solution. ... Should we be doing more static linking? Not even depending on libc? What are the challenges with that? >> but it's a ruby application and I need to install the whole stack of things, plus the gems. Instead I containerize it, and keep my system clean. There was a bit of drama recently with the Bottles project and some Distro maintainers. With the Bottles devs saying "we only want the appimage as a distribution method". I see containers as a means of distributing software. If that ruby app was a binary, then the container would become baggage.
- bayindirh 3y ago
  > Bottles devs saying "we only want the appimage as a distribution method". Good for them having wishes, yet free software doesn't work that way in most cases. :) > I see containers as a means of distributing software That's OK. Docker is a tool, and tools can be held and used in many ways.
  - zer00eyz 3y ago
    >>> Good for them having wishes, yet free software doesn't work that way in most cases. :) Historically I would agree with you. But bottles, and the attitude of some upstream projects is one of "modern", "faster", "support the latest version only" ... Software devs who live in user space want a more "App Store" like delivery mechanism where they have control. The kernel is inclined to never break backwards compatibility. Distros are sort of stuck in the middle... >> I see containers ... > That's OK. Docker is a tool, One of these is a subset of the other... (depending on your perspective). Dockerdesktop running a linux image on a windows box is most certainly a tool... that same container being ported to lcx in production makes it a package manager. Who is a subset of whom is something we could debate but these things can be both.
    - bayindirh 3y ago
      > Software devs who live in user space want a more "App Store" like delivery mechanism where they have control. They can have control. They can say that we have flatpaks and app images we publish and support, and they only support the latest version (or the same minor version, whatever), and can say that packages got from distros may not be the latest. There's no need for a yelling match, IMHO. Distros also can do whatever they want. Like rclone. You can get the packages from rclone.org or from your distros. There's no yelling match, but trade-offs. > ...that same container being ported to lcx in production makes it a package manager. I don't think so. I have containers which work like binaries (in the form of "./binary infile outfile" fashion) and exit after processing what I give them. For me that container is a utility program as a whole. Same for the imap-backup example. When you think services which are always on, docker might be a package manager, but I pack my own containers for example, so it's more like compiling for me. So, what docker or containers is depends on your perspective, or like a chameleon which changes its color according to the landscape it's in. So, it's a tool in the end. Package managers are tools, too.

marcosdumay 3y ago

Linux doesn't solve that problem at all. Qubes tries to do that with a hack, that is probably sufficient, but quite complex. I'd say that we don't have good solutions to that problem. But nobody even tried our best candidates, so I'm not completely sure. (For a while, it looked like Android would finally try some. But then Google turned it into a user-hostile anti-privacy OS.)

adamgordonbell 3y ago

> many foreign processes not seeing each-other on the same OS For sure, I was thinking of the packaging nature of containers, not the 'security' nature of containers. The pivotroot part. Though I guess being able to have namespaces does make packaging clearer in certain cases. For a horrible analogy: With actual shipping containers, we don't have each shipping container be a stripped down model of a ship, so that the things in it aren't confused.

samatman 3y ago
Agreed, it isn't great. Shipping containers are more like tarballs: a bunch of stuff (files) bundled into one "stuff" (file) so they're easy to ship around and pieces don't get lost in the process. I don't think there is a good physical-world analogy for what containers are doing, though. Maybe takeout including utensils and napkins to "simulate a kitchen" in case you eat it on the go, so you don't have to rely on the "system" forks and napkins? Still kinda rubbish honestly.
bayindirh 3y ago
The packaging is generally a side-effect of isolation in my experience. I never chrooted a software because I needed a different library stack for it to run, but to isolate it from rest of the system in one way or another (for security/access reasons). Docker just made the interface more practical, and built the ecosystem around it. lxcontainers, apptainer and podman has improved upon the idea in different ways to cater different use cases. So for me containers were never simplified ships to begin with. This different perspectives happen probably because people look from different perspectives at initial contact, which is normal.

zer00eyz 3y ago

>>> To me, all that points at containers being in some way a solution to Dynamic linking. And maybe an over the top solution. ... Should we be doing more static linking? Not even depending on libc? What are the challenges with that? >> but it's a ruby application and I need to install the whole stack of things, plus the gems. Instead I containerize it, and keep my system clean. There was a bit of drama recently with the Bottles project and some Distro maintainers. With the Bottles devs saying "we only want the appimage as a distribution method". I see containers as a means of distributing software. If that ruby app was a binary, then the container would become baggage.

bayindirh 3y ago
> Bottles devs saying "we only want the appimage as a distribution method". Good for them having wishes, yet free software doesn't work that way in most cases. :) > I see containers as a means of distributing software That's OK. Docker is a tool, and tools can be held and used in many ways.
- zer00eyz 3y ago
  >>> Good for them having wishes, yet free software doesn't work that way in most cases. :) Historically I would agree with you. But bottles, and the attitude of some upstream projects is one of "modern", "faster", "support the latest version only" ... Software devs who live in user space want a more "App Store" like delivery mechanism where they have control. The kernel is inclined to never break backwards compatibility. Distros are sort of stuck in the middle... >> I see containers ... > That's OK. Docker is a tool, One of these is a subset of the other... (depending on your perspective). Dockerdesktop running a linux image on a windows box is most certainly a tool... that same container being ported to lcx in production makes it a package manager. Who is a subset of whom is something we could debate but these things can be both.
  - bayindirh 3y ago
    > Software devs who live in user space want a more "App Store" like delivery mechanism where they have control. They can have control. They can say that we have flatpaks and app images we publish and support, and they only support the latest version (or the same minor version, whatever), and can say that packages got from distros may not be the latest. There's no need for a yelling match, IMHO. Distros also can do whatever they want. Like rclone. You can get the packages from rclone.org or from your distros. There's no yelling match, but trade-offs. > ...that same container being ported to lcx in production makes it a package manager. I don't think so. I have containers which work like binaries (in the form of "./binary infile outfile" fashion) and exit after processing what I give them. For me that container is a utility program as a whole. Same for the imap-backup example. When you think services which are always on, docker might be a package manager, but I pack my own containers for example, so it's more like compiling for me. So, what docker or containers is depends on your perspective, or like a chameleon which changes its color according to the landscape it's in. So, it's a tool in the end. Package managers are tools, too.