4 ms·

> PPAs are a thing of the past, I think. A much better way forward would be to implement a truly transactional and functional packaging system (a la nix/guix),

> PPAs are a thing of the past, I think. A much better way forward would be to implement a truly transactional and functional packaging system (a la nix/guix), where updates could be rolled back seamlessly. Exactly, and this is what CoreOS does. I see this as the role that containers fill. Systemd already supports what you describe, via systemd-nspawn, which allows native containerization, and with btrfs, which allows either persistent or ephemeral containers to be built off of a "template"[0]. Systemd is already able to run Docker images and even pull them directly from the Docker registry, so I'd rather see containers adopted as the new model of vendoring[1] rather than PPAs. And since Debian already uses systemd now, this should be very easy to integrate. [0] I put "template" in quotation marks because I'm using the term loosely here; nspawn uses the word template to refer to something different. [1] Let's be frank: while PPAs can do more, 90% of the PPAs I was asked to add when I used Ubuntu were basically aimed at solving vendoring and/or versioning issues.

nextos 12y ago
I know. It's very nice. That's what I use everyday on Arch. Still, I feel functional package managers buy you a few more advantages. The whole package tree doesn't need to be in sync, and package hashes mean you have pretty strong guarantees things won't break due to dependency mismatches.
falcolas 12y ago
> Systemd is already able to run Docker images and even pull them directly from the Docker registry, so I'd rather see containers adopted as the new model of vendoring[1] rather than PPAs. After having dug into Docker containers for a few weeks to identify what we have to be aware of as we roll out to them at work, I would rather not. NAT overhead, asymmetric TCP routes, devicemapper inefficiencies, 400+mb images, new toolsets for debugging, unsigned images (though at least the foundation to support them exists now)... Until these bumps are sorted out I'm more than happy to deal with a few rare incompatibilities from package upgrades.
- chimeracoder 12y ago
  > After having dug into Docker containers for a few weeks to identify what we have to be aware of as we roll out to them at work, I would rather not. > NAT overhead, asymmetric TCP routes, devicemapper inefficiencies, 400+mb images, new toolsets for debugging, unsigned images (though at least the foundation to support them exists now)... You don't have to use Docker images (and systemd actually handles all of the issues you point out better than Docker anyway). I only mentioned Docker because it allows people to use existing Docker images without any extra work.

nextos 12y ago

I know. It's very nice. That's what I use everyday on Arch. Still, I feel functional package managers buy you a few more advantages. The whole package tree doesn't need to be in sync, and package hashes mean you have pretty strong guarantees things won't break due to dependency mismatches.

falcolas 12y ago

> Systemd is already able to run Docker images and even pull them directly from the Docker registry, so I'd rather see containers adopted as the new model of vendoring[1] rather than PPAs. After having dug into Docker containers for a few weeks to identify what we have to be aware of as we roll out to them at work, I would rather not. NAT overhead, asymmetric TCP routes, devicemapper inefficiencies, 400+mb images, new toolsets for debugging, unsigned images (though at least the foundation to support them exists now)... Until these bumps are sorted out I'm more than happy to deal with a few rare incompatibilities from package upgrades.

chimeracoder 12y ago
> After having dug into Docker containers for a few weeks to identify what we have to be aware of as we roll out to them at work, I would rather not. > NAT overhead, asymmetric TCP routes, devicemapper inefficiencies, 400+mb images, new toolsets for debugging, unsigned images (though at least the foundation to support them exists now)... You don't have to use Docker images (and systemd actually handles all of the issues you point out better than Docker anyway). I only mentioned Docker because it allows people to use existing Docker images without any extra work.