This was a followup to Packagers don't know best [https://news.ycombinator.com/item?id=5920921]. I think the writer, who received considerable criticism here on HN, really just dug his trench a little deeper with this. The whole theme - and the fundamental us-vs-them tone of the article, as though packagers weren't themselves developers (they very often are) - really intensifies a divide that the DevOps movement tries to resolve; moreover, the example of bundler, shrinkwrap et al simply demonstrates the unfortunate case of NIH that many developers have about packaging: they are, in an echo of Greenspun's tenth rule, doomed to reinvent it.
The fact is that application publishers cannot be relied upon to maintain upstream currency of bundled components, and this is the motivation for disaggregation. System administrators are always more interested in maintaining the integrity of their servers and reliability of their services - especially the security facets thereof - than in pandering to a developer who, experience tells us, has a decent chance of not being around in a year's time.
The best integration I have yet seen of language-specific and OS-level packaging is in FreeBSD's BSDPAN framework for Perl, where language-installed modules automatically appear in the package database so that their lifecycle can be properly managed. That's a much more constructive solution that actually tries to bridge the divide, and I would like to see more of it.
The fact is that application publishers cannot be relied upon to maintain upstream currency of bundled components, and this is the motivation for disaggregation. System administrators are always more interested in maintaining the integrity of their servers and reliability of their services - especially the security facets thereof - than in pandering to a developer who, experience tells us, has a decent chance of not being around in a year's time.
The best integration I have yet seen of language-specific and OS-level packaging is in FreeBSD's BSDPAN framework for Perl, where language-installed modules automatically appear in the package database so that their lifecycle can be properly managed. That's a much more constructive solution that actually tries to bridge the divide, and I would like to see more of it.