Hacker News Reader

Comment by ahartmetz | Hacker News Reader

Well, that is what people who have been around the block a few times have been saying about containers since just about forever. "I don't want to be an admin for my n software packages, I'll use containers!" - now you are the admin of n containers, except with worse tools than your distro and no upstream support.

View on HN

And since before that, when we started turning to additional packages managers installed with package managers. Pip etc. mean that an “apt upgrade” isn’t enough, when it really “should” be (used to be) in a well managed system.

Then we layered _another_ level of package management on top with Flatpak etc.

I don’t think anyone has _really_ been - in practice - able to understand how many versions of Python (or shells or ruby or Perl etc…) are installed on any system for a decade or two now.

[Edit to add: and I forgot entirely about venvs (and other language’s equivalents). We put package managers into packages! Now there can be a different version of every package for every script on your system. In every container. And Python even has more than one venv system to choose from!]

[Yes, I use all these things - it’s so hard _not_ to and still use modern software or participate in modern software development…]

It's funny that no one seems to even consider using the distro package manager when it's time to complain about Python package management again. The deployment environment is usually well-known thus scriptable, and developers can be expected to know how to install packages on their own distros. And, of course, if the package is deployed as part of a distro, everything is taken care of by the distro people.

Flatpak is somewhere in the middle because it can and does centrally update dependencies, though they are packaged in larger boxes and it's tempting to include more exotic stuff in the app package instead of creating and maintaining a separate Flatpak shared with other dependees.

Only one company I've worked at maintained their own distro packages for deploying services. That was 13+ years ago. Every company since then had a containerized deployment strategy, some better than others. My most recent employer went through a massive effort to implement "golden base images" and tooling to ensure when the base image is updated all the dependents are rebuilt and redeployed. Most don't do that.

Nobody seriously considers it because usually, especially in enterprise distros, the major versions are years out of date and missing many features. And many smaller packages just won't be available. Even for something as major as Django it just wasn't viable to use the OS package manager when I tried it in the Debian 8 and then 9 days.

I've had Python software that just expected certain packages several times at different $work and it's also how I use KDE's kde-builder, which can helpfully suggest package names for a few popular distros and maybe also for pip. I guess these people just don't know that they are doing it wrong /s.

Imagine the problem that required virtualenvs (or containers). Distro packages don't work well with that. Plus the packages are already outdated most of the time. Unless by "distro package" you mean packaging an entire environment as a distro package, but you'd run into the same problems of multiple installs there.

I use some rules and a few generated scripts and have a LLM handle the management of the containers. Security through a ssh gateway, allows them to deploy/remove containers and then the rule is to stay at least two weeks behind on releases, unless the latest release is security related, which it figures out by reading the release notes.

I ran watchtowerr before, but I think this is a smarter way to do it.

One could say comeuppance is a dish best served cold. So cold people don’t even know it’s been served. All the old sys admins remember!

Reply on news.ycombinator.com