[lmm]

Even for servers, debian-style package management is increasingly inadequate. Linux package management was designed for the C era of a small number of large libraries with infrequent releases. Distribution maintainers are unable or unwilling to adapt their processes to support the model that most modern software ecosystems are converging on: large numbers of small libraries with frequent releases. (Frankly, they're often hostile to the idea that they should support it, despite this model being preferred by both developers and users). Yet they're also hostile to the idea of getting out of the way and letting ecosystem-specific package managers handle ecosystems that need more frequent releases.

In the era of servers that were hand-tended by a BOFH who upgraded only rarely (and screw the users who want to use something newer), the distro/repo system worked. But even servers are not generally maintained that way anymore. I honestly think we're going to see that model fade away in the next decade or so.

[erik_seaberg]

Just because parts of the ecosystem are constantly cranking out small changes doesn’t mean my employer wants my team to spend time alpha testing all of them at the risk of downtime.

I’m fine with an author saying “I no longer want bug reports from that version,” and I’d like someone with the distro to act on those instead.

[lmm]

Most effective employers I've worked for have found that staying close to upstream's rolling releases saved more time and effort in the long run compared to leaving a bigger gap between upgrades (which, sure, saves time if nothing breaks, but the worst case becomes a lot worse).