← Back to context

Comment by rolosa

6 hours ago

This is such a clusterfuck. I use so many containers in my home lab and various local installations and stuff. Honestly, I have no idea what I'm even supposed to do at this point because I'm not a full time developer.

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.

  • 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.

      2 replies →

  • 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!

For me, this comment actually bolsters the argument for containers imo. It's a lot easier to rebuild a system image and redeploy it out across a bunch of apps than it is to update a bunch of VMs (maybe ansible/puppet makes it moot). Idk

Examples of what you can do:

* Take the containers offline for the time being until you know what to do

* If it's important for your that they keep running, still take them offline and put them in a VPN this weekend

* Use renovate in the future to automatically update your containers

Python environment was so brittle, that a solution was found: pack dependencies into "envs" of various kinds. Disk space is cheap, after all (ahem). Now it's time to pay the bill for that approach...

don't worry. if you're in this situation with this attitude, you're likely running out of date container base images and whatnot.

i highly suggest you forget about containers, learn about systemd unit file hardening, and then you only have to play sysadmin to your base os and the binary for the program you want to run.

"Hey claude this is the cve I need you to fix [link]"

Takes about 20 seconds. Depending if you need to hit enter.

  • cool cool cool. Don't understand what you're doing, and keep not understanding what you're doing. the agents are infallible after all, and who cares about properly verifying certs anyway? that's nerd shit.

    • We're in October 2026. Updating packages is the easiest thing Claude can do. For me, I asked and received:

      Node 26.3 → 26.12.1 Homebrew’s CA bundle, certifi and OpenSSL are updated, and so are Python 3.13 and 3.14 (3.13.17 and 3.14.9). uv 0.10.9 → 0.13.5. python.org Python 3.13: pip 26.2.2, installed from PyPI’s wheel with its checksum checked, then certifi 2026.10.19.

      It also checked some of the other recent vulnerabilities like LiteLLM (already updated).

      1 reply →

  • Yeah, at some point I gave up and asked AI to do patching for me. It was a good call because it found affected certificates in places where I wouldn't look (e.g. aws-cli or Libre Office).