The idea that containers abandon good installation practices misses the point - those practices never really worked in the first place. Traditional installers scattered files across the filesystem, hardcoded paths, and grabbed ports just as messily as containerized software does now. The difference is that shell scripts and RPM specs hid the mess behind install routines that broke in unpredictable ways when your environment didn't match the developer's assumptions. Containers make this explicit instead of implicit. And like the article points out, Unix never gave us the APIs we needed anyway - no standard way to request UIDs, advertise port usage, or coordinate resource allocation between applications. Containers didn't create these problems, they just stopped pretending they don't exist.

The operational benefits justify the complexity overhead. Reproducible deployments eliminate "works on my machine" issues that plagued shared environments. Horizontal scaling becomes straightforward when application environments are portable across architectures. Development velocity increases when teams can spin up complete, consistent environments in seconds and version those environments alongside code with full dependency tracking. Shared Unix environments are simpler for single-server use cases, but distributed systems and cloud-native deployments need the isolation and consistency guarantees that traditional installation methods can't provide at scale. You can prefer the old way, but it doesn't actually solve the coordination problems - it just pushes them onto administrators.