3 ms·
Software should be reliable, but I'm not fond of LTS. As a developer, I'm fine with 3 years of support, security or otherwise. The decade of (security) fixes (
by pipo234 3y ago
Software should be reliable, but I'm not fond of LTS. As a developer, I'm fine with 3 years of support, security or otherwise.
The decade of (security) fixes (free or otherwise) smells like neglect. This is probably fine with 80s or even 90s software. But for internet connected devices I think it's bonkers to expect others to maintain and support the foundation of your software.
That is, assuming the software is functionally done, finished and no longer maintained. If whatever you meant to build, is still maintained and actively supported, it should not be too much to expect the OS to evolve with it. Upgrade to the latest platform every now and then.
Yes, migrations can be painful, but grow up: test thoroughly and get your ducks in a row. If that's too much to ask, you're simply lifting beyond your weight.
- j1elo 3y ago> assuming the software is functionally done, finished and no longer maintained This ties in very well with a discussion that happened a couple days ago about whether the concept of "finished software" even exists: https://news.ycombinator.com/item?id=36877363 https://news.ycombinator.com/item?id=36877363
- RetroTechie 3y ago> As a developer, I'm fine with 3 years of support, security or otherwise. There's the problem: developers primarily think of themselves, expecting end users to be power users not unlike developers. That doesn't hold. Developers can handle change & a rapid upgrade cycle. End users... not so much. Or not at all. The only updates end users care for are risk-free, invisible, hassle-free (as in: automatic) updates that plug security holes, correct broken functionality, or minor feature updates that don't interfere with anything already there. For example drivers that support new hardware which uses existing system bus w/ existing software infrastructure. Update can't fit into this frame? Then put it in next, feature-breaking release. Not in currently-stable, supported one. Imho, Linux currently has a pressing need for community maintained distro with 10y+ LTS cycle. Or existing distro that offers 10y+ support on selected releases. Such distro could easily send RHEL into obscurity.
- jimhefferon 3y agoI'll add that even for developers or power users, very few are in that category for more than a couple of areas. There are some things I know about but that leaves 99 percent of my box where I'm relying on others.
- jart 3y agoWhat you're basically saying is you want developers to volunteer to give up their ability to advance their own careers writing features, and only fix security bugs in old junk that isn't entirely broken instead. You'd have better luck getting them to volunteer to be maids. If you want long-term community-driven support, then you'll stand a better chance getting it from developers focusing on making new things that are backwards compatible, rather than asking maintainers to keep old stuff alive forever. For example, Cosmopolitan Libc uses modern GCC11 to build binaries that support running on every distro all the way back to RHEL5, and I think that's the thing you actually want, except it's something you'll never see happen from distros, because they operate by a different set of incentives.
- tsimionescu 3y agoSure, and that's what most do. But they don't actually derive any value from it - it's just busy work because others want the new features. If we could have 50 years of secure Windows XP or Linux 3.something, lots of software teams would be freed from periodic migrations to just building more features.
- happymellon 3y agoWindows XP was essentially an LTS as it did get 12 years of support. However there were plenty of severe flaws that couldn't be fixed without some fundamental changes. What people appear to want is all the problems fixed, but none of the hassle of actually having anything change to accommodate these fixes.