Reading the title I assumed this was a rant about how proper ops processes replaced the need for LTS releases and the demonstrably bad practices they could be seen to encourage. IMHO, this would have been a more interesting and valid point.
The current post is a straw man argument for a few reasons.
First, because vulnerabilities will be exploited whether the window of availability is 1 day, 100 days, or 1000 days (like this one) and likewise, upgrades will be missed, for various reasons, whether or not they are encouraged.
Second, the author spuriously implies that a 6 month sliding upgrade window ("one size fits all") approach is superior, easier and more appropriate for everyone through a combination of broad assumption and vague hand-waving about developer time efficiency. Rubbish.
If you want newer code, then ASAP is the go and BSD-style monolithic releases are bad... something closer to the versionless OS ideal of constant, incremental, package-wise release processes such as Gentoo's portage (BSD-inspired!) where you can even install a -9999 (git HEAD) version of many packages would be ideal. Obviously, with such an approach, stability caveats must be considered (as they are). Thus, both FreeBSD and OpenBSD actually represent a 'middle-ground' between Gentoo and commercial Linux vendor LTS, with OS wide release processes incorporating some greater collective package and package interoperability testing, combined with the package-wise release of things through the ports trees.
What's the real ideal here? A general purpose means to build working, tested, maintainable, secure systems with minimal effort for a broad audience.
How to get there? Clearly, not by whinging about external release window frequencies of volunteer-based projects, as any frequency still creates bugs, and no process is perfect. The answer, I believe, is time-honored. Careful design for failure and minimalism, and good process. Test. Measure. Remove surplus features and components. Iterate.
The current post is a straw man argument for a few reasons.
First, because vulnerabilities will be exploited whether the window of availability is 1 day, 100 days, or 1000 days (like this one) and likewise, upgrades will be missed, for various reasons, whether or not they are encouraged.
Second, the author spuriously implies that a 6 month sliding upgrade window ("one size fits all") approach is superior, easier and more appropriate for everyone through a combination of broad assumption and vague hand-waving about developer time efficiency. Rubbish.
If you want newer code, then ASAP is the go and BSD-style monolithic releases are bad... something closer to the versionless OS ideal of constant, incremental, package-wise release processes such as Gentoo's portage (BSD-inspired!) where you can even install a -9999 (git HEAD) version of many packages would be ideal. Obviously, with such an approach, stability caveats must be considered (as they are). Thus, both FreeBSD and OpenBSD actually represent a 'middle-ground' between Gentoo and commercial Linux vendor LTS, with OS wide release processes incorporating some greater collective package and package interoperability testing, combined with the package-wise release of things through the ports trees.
What's the real ideal here? A general purpose means to build working, tested, maintainable, secure systems with minimal effort for a broad audience.
How to get there? Clearly, not by whinging about external release window frequencies of volunteer-based projects, as any frequency still creates bugs, and no process is perfect. The answer, I believe, is time-honored. Careful design for failure and minimalism, and good process. Test. Measure. Remove surplus features and components. Iterate.