> shortly after Hardy, and there were issues with both web-based and other
> services that had drifted past the support in Dapper's packages (Gaim, I
> think, but there was another that I can't now recall that's used by a
> bunch of the Distributed Proofreaders gang that was an annoyance) well
> before the next LTS came along.
That's the exactly kind of experience I am after -- long-term support means supporting even beyond the upstream end-of-support, and that means backporting. And backporting means *a lot of* work. Extreme case if RHEL2.1 which has IIAC kernel 2.4.9. But even RHEL3 (which is five years old, so Canonical would still support it) has kernel 2.4.2*. I really wonder whether Canonical will find volunteers to dig into this archeological excavations if the need arises.
Posted Oct 19, 2008 13:21 UTC (Sun) by maney (subscriber, #12630)
[Link]
Well, I misspoke - Cally says she'd had no issues with Gaim. It was a thing named psi, which had in common that it was an instant messaging client and not much else, that got to be lagging. And that provides no evidence one way or the other, as psi wasn't (and still isn't, in Hardy) promised support, as it's from the universe section. My own earlier migration away from Dapper had more varied reasons, but desktop programs with deeply tangled library version needs and non-supported packages were the motivations I can recall; nor were those two categories non-overlapping (backporting a newer psi for Cally foundered on library version clashes, for example - I remember trying that).
Frankly, if I had it to do over again I'd have stayed on the six month upgrade cycle - it's more frequent than I'd like to have to deal with fixing the inevitable rough bits (if nothing else, making sure none of the non-supported packages haven't gone missing), but that's less annoying than waiting two years for a supported upgrade path. And yes, I've experienced the unsupported way - easier just to reinstall IME. Been there, done both, neither is fun. etc-keeper may help somewhat with restoring local configs - remains to be seen.
Ttwo years seems overlong, and five years sheer madness, given the current volatility of the Linux desktop environment - you either destabilise by trying to introduce new versions/backports (which by definition has changed the behavior somehow, otherwise you not have done it), or else you're so moribund you get wiped for a fresh install of something usable. Now servers are a little different, but I can't say anything about using Ubuntu there - mine are all running Etch. :-)
Fedora\\\\\\ Ubuntu and long term support
Posted Oct 19, 2008 22:16 UTC (Sun) by ceplm (guest, #41334)
[Link]
One small terminology reach to other distro culture (having been in past member of both, I hope I can at least work towards more understanding). There are two quite different meanings of the word "backport". In Debian world it means porting of packages from unstable to be used on stable with old libraries, etc. In the Fedora/Red Hat world it means (if I am not mistaken) is to patching old version of the package to fix for bugs fixed in the later package which is not part of the concerned release of the distribution (i.e., stuff Debian and Red Hat maintainers do for Debian/stable and RHEL respectively).
Fedora\\\\\\ Ubuntu and long term support
Posted Oct 19, 2008 22:20 UTC (Sun) by ceplm (guest, #41334)
[Link]
> Two years seems overlong, and five years sheer madness, given the current
> volatility of the Linux desktop environment
Did you notice, that RHEL 5.2 included rebase of all substantial desktop applications (e.g., OOo and gecko-related stuff)? Of course, it is in CentOS as well.