Canonical Offers Up 12 Year "Everything LTS" For Docker Images

[phoronix]

Phoronix: Canonical Offers Up 12 Year "Everything LTS" For Docker Images

Ubuntu maker Canonical announced "Everything LTS" as a new initiative where for Ubuntu Pro customers they will offer up a twelve year LTS period for any open-source Docker image...

https://www.phoronix.com/news/Canonical-12Year-Everything-LTS

[bug77]

Hate Canonical all you want, but they do stand by their stuff: https://releases.ubuntu.com

[debrouxl]

Considering that relatively few projects - not just open-source projects - receive LTS beyond 5 years, and that many open-source projects do not receive any form of LTS because it's too much of a burden for their unpaid maintainers working on their projects during their free time... I haven't yet understood how anybody plans to be able to provide "12 year security maintenance of any open source app or dependencies". But maybe I will understand next time I read the article, or later

Lack of LTS for the vast majority of projects is the reason why I think that the "10 years of support" figure for Enterprise Linux (TM) distros is complete BS. Such figures sure catch the eyes of management types; the limitations behind said figures (applicability to a fairly narrow subset of packages, etc.) tend to escape them, though.

[Beryesa]

I can see articles like "The LTS bubble bursted, upgrade 'em all" in 10 years.
Can canonical really keep putting up with maintaining multiple old versions of dead software 🤔

[bug77]

Lack of LTS for the vast majority of projects is the reason why I think that the "10 years of support" figure for Enterprise Linux (TM) distros is complete BS. Such figures sure catch the eyes of management types; the limitations behind said figures (applicability to a fairly narrow subset of packages, etc.) tend to escape them, though.

It's not that hard too see how The most widespread bit (e.g. the kernel, glibc) get patched anyway. At most, you have to backport the patch if your distro's version is not taken care of upstream. And yes, some things the distro maintainers will patch themselves. And try to upstream the fix where it makes sense.
But yes, there is a reason this kind of support is always behind a paywall.

[duby229]

I can see articles like "The LTS bubble bursted, upgrade 'em all" in 10 years.
Can canonical really keep putting up with maintaining multiple old versions of dead software 🤔

I don't think so... It's not just a matter of making old code compile, it's also back porting fixes for security flaws and major bugs... Which is actually literally impossible.... Sooo, yeah....

EDIT: It's why the concept of "stable" distributions seem so stupid to me....

EDIT: But then the major problem with rolling release is it only works if everything does proper version control, but many projects refuse to do it right... XFCE being a prime example and many others, so there's that....

[sarmad]

Considering that relatively few projects - not just open-source projects - receive LTS beyond 5 years, and that many open-source projects do not receive any form of LTS because it's too much of a burden for their unpaid maintainers working on their projects during their free time... I haven't yet understood how anybody plans to be able to provide "12 year security maintenance of any open source app or dependencies". But maybe I will understand next time I read the article, or later

Lack of LTS for the vast majority of projects is the reason why I think that the "10 years of support" figure for Enterprise Linux (TM) distros is complete BS. Such figures sure catch the eyes of management types; the limitations behind said figures (applicability to a fairly narrow subset of packages, etc.) tend to escape them, though.

LTS means if there is any new release or patch made to any of those open source packages, they will pick those patches and deliver them to you in an update. It does not mean that they'll be responsible for fixing other people's projects; that's the responsibility of the project owner. If the project owner isn't responding to security holes then you should just pick an alternative.

[JMB9]

This is interesting - while after my personal experience LTS releases did not even get stable with .1,
now the notion of perfect distroless Docker image with critical CVEs fixed in less than 24 hours
seems ... interesting.
Mybe the CVEs for those images are only authorised by themselves - so they are coined when
a fix is available?
And supporting any SW ...

It must be a message from a parallel universe ... cough!
After the snap/flatpak desaster now everything will work perfectly well - it's just magic.
Especially when at the same time 6.9.4 is the latest stable kernel on their Ubuntu's
mainline PPA - but this is officially not supported, of cause;
who would like latest Linux or Mesa - we all wait 1,5 years to use a new workstation.
And even this last one (while one should expect the latest 6.9.6 released five days ago):
https://kernel.ubuntu.com/mainline/ 6.9.4 can not be installed due to libc dependencies
on the current stable 22.04.4 LTS, while the latest 24.04.0 LTS is not ripe ...
which may fulfill those dependencies - hurray!).

One can work with smartphones - or learn with them, tablets
or interactive boards;
no one wants - or needs - 8k or 16k resolution non-glare screens;
no one needs to learn programming as AI will do the job -
so one can program in any one's native language,
...
It's a beautiful world ... please don't wake me up!

[debrouxl]

Upstreams responding to security issue reports by producing new releases is one thing; upstreams maintaining LTS branches, especially for releases more than 5 or even 2 years back, is another thing.
If Canonical and other distributors don't perform backports by themselves into the pieces of software that they don't already maintain as packages in their native packaging format, they'll be missing out on lots of fixes (on average, more than they'll be missing on vulnerabilities introduced in newer releases, since the quality of software improves over time)... while possibly reinforcing the complete illusion of security that those who like to depend on LTS versions (*) have.

*: because LTS versions typically show little change, and some people think that LTS versions enable saving money by not having to deal with upgrades for a looong while. Of course, that results in "big bang" updates when they do eventually have to perform the upgrades one day, a while after the LTS versions go out of support.
It's easier for simple applications (which seem to be getting more and more infrequent as complexity and bloat rise), but for complex application setups running on full-blown distros, "big bang" updates to two or three major distro release later, after holding onto a version for 5-10 years, are lengthy and costly, sometimes more than more frequent, smoother updates...
When suddenly upgrading from RHEL 6 to RHEL 9, you get a different init system (6 -> 7), modular packages (a pain point when upgrading a custom distro from 7 to 8), a new way to define network configuration (network-scripts, which was already deprecated in 8, was removed in 9), etc.

[rclark]

because LTS versions typically show little change, and some people think that LTS versions enable saving money by not having to deal with upgrades for a looong while.

Not money... For me it is the time to update several machines. An LTS allows me to upgrade on my 'own' schedule, not a 6 month schedule... By the time 5 years rolls around, I am probably ready for new hardware. With new hardware comes the latest LTS or ... if a LTS is right around the corner, I'll update to latest version and upgrade to LTS when available (did that once already). And the web browser is 'always' up to date. Firefox is never stale even on LTS, or FreeCad (appImage) for example.