3 ms·

I think most people would be better off abandoning Apt or RPM and use containers, Snap, AppImage or switch to a distro like Arch/Alpine.

gjulianm 7y ago
Package managers and containers are fairly different things. For internal distribution of software, for example, apt can be better (less disk usage, less configuration issues, better integration with other programs...). Recommending one or the other in such a broad way is just misguided and will cause problems.
- onei 7y ago
  I also find myself reaching for apt/yum/dnf/apk for standard tools when creating a container rather than building everything from scratch. It seems odd to me to waste time doing what someone else does well already.
  - techntoke 7y ago
    If you trying building a package for Arch/Alpine you'll understand why I recommend it over APT/RPM. Also, caching is much easier with Arch/Alpine.
Spivak 7y ago
How do you dependency management inside the container?
- techntoke 7y ago
  There are multiple ways. I think the general solution is to compile statically, however for libraries you can bind mount what you need. I don't think Docker provides a complete solution, but I pretty much prefer anything over RPM/DEB packages.
alrs 7y ago
This notion is completely upside-down. Distro packaging means that global teams of developers are backporting bug and security fixes all day, every day, and running them through massive CI systems that have been in existence for decades. Containers are great for scaling, and terrible for software distribution. Done right, they need to be rebuilt daily to pick up the latest fixes in the underlying OS. Snap and AppImage mean you're on the hook for care and feeding of every library you bring in, yourself. Rolling distros mean that you need a staff to integrate all the changes that are happening with no cadence other than "apparently today's update broke X". More likely, it would be a team dedicated to "apparently Y has been broken for a week, we found the problem, we're trying to upstream it, but now service X relies on the new functionality, so we're doing a conference call with them tomorrow to find out if they can roll back that change."
- techntoke 7y ago
  > Distro packaging means that global teams of developers are backporting bug and security fixes all day, every day, and running them through massive CI systems that have been in existence for decades. I said nothing against distros, but I said I preferred Alpine/Arch. If you look for these massive CI systems, they don't exist for any retail-based distro like Ubuntu/RHEL. Why would you even need to backport fixes if you have a CI system that builds from source? The only systems doing massive CI are distros like Arch/Alpine/Void/etc because there package manager is designed with it in mind. Apt is better than RPM, but it still has shortfalls when it comes to creating and maintaining packages. > Containers are great for scaling, and terrible for software distribution. Done right, they need to be rebuilt daily to pick up the latest fixes in the underlying OS. That isn't called building right. If your package has that many dependencies, then you could just bind mount the tool. No need to rebuild the container at all, however most of the time you don't need to rebuild that often, especially for Go. > Snap and AppImage mean you're on the hook for care and feeding of every library you bring in, yourself. They have a simple YAML setting that does this for you > Rolling distros mean that you need a staff to integrate all the changes that are happening with no cadence other than "apparently today's update broke X". More likely, it would be a team dedicated to "apparently Y has been broken for a week, we found the problem, we're trying to upstream it, but now service X relies on the new functionality, so we're doing a conference call with them tomorrow to find out if they can roll back that change." Rolling distros doesn't require that you upgrade a package, and I've never had a problem rolling back using my cached repo or one of the mirrors that caches packages daily.

gjulianm 7y ago

Package managers and containers are fairly different things. For internal distribution of software, for example, apt can be better (less disk usage, less configuration issues, better integration with other programs...). Recommending one or the other in such a broad way is just misguided and will cause problems.

onei 7y ago
I also find myself reaching for apt/yum/dnf/apk for standard tools when creating a container rather than building everything from scratch. It seems odd to me to waste time doing what someone else does well already.
- techntoke 7y ago
  If you trying building a package for Arch/Alpine you'll understand why I recommend it over APT/RPM. Also, caching is much easier with Arch/Alpine.

Spivak 7y ago

How do you dependency management inside the container?

techntoke 7y ago
There are multiple ways. I think the general solution is to compile statically, however for libraries you can bind mount what you need. I don't think Docker provides a complete solution, but I pretty much prefer anything over RPM/DEB packages.

alrs 7y ago

This notion is completely upside-down. Distro packaging means that global teams of developers are backporting bug and security fixes all day, every day, and running them through massive CI systems that have been in existence for decades. Containers are great for scaling, and terrible for software distribution. Done right, they need to be rebuilt daily to pick up the latest fixes in the underlying OS. Snap and AppImage mean you're on the hook for care and feeding of every library you bring in, yourself. Rolling distros mean that you need a staff to integrate all the changes that are happening with no cadence other than "apparently today's update broke X". More likely, it would be a team dedicated to "apparently Y has been broken for a week, we found the problem, we're trying to upstream it, but now service X relies on the new functionality, so we're doing a conference call with them tomorrow to find out if they can roll back that change."

techntoke 7y ago
> Distro packaging means that global teams of developers are backporting bug and security fixes all day, every day, and running them through massive CI systems that have been in existence for decades. I said nothing against distros, but I said I preferred Alpine/Arch. If you look for these massive CI systems, they don't exist for any retail-based distro like Ubuntu/RHEL. Why would you even need to backport fixes if you have a CI system that builds from source? The only systems doing massive CI are distros like Arch/Alpine/Void/etc because there package manager is designed with it in mind. Apt is better than RPM, but it still has shortfalls when it comes to creating and maintaining packages. > Containers are great for scaling, and terrible for software distribution. Done right, they need to be rebuilt daily to pick up the latest fixes in the underlying OS. That isn't called building right. If your package has that many dependencies, then you could just bind mount the tool. No need to rebuild the container at all, however most of the time you don't need to rebuild that often, especially for Go. > Snap and AppImage mean you're on the hook for care and feeding of every library you bring in, yourself. They have a simple YAML setting that does this for you > Rolling distros mean that you need a staff to integrate all the changes that are happening with no cadence other than "apparently today's update broke X". More likely, it would be a team dedicated to "apparently Y has been broken for a week, we found the problem, we're trying to upstream it, but now service X relies on the new functionality, so we're doing a conference call with them tomorrow to find out if they can roll back that change." Rolling distros doesn't require that you upgrade a package, and I've never had a problem rolling back using my cached repo or one of the mirrors that caches packages daily.