The person having to maintain this must be in a world of hurt. Unless they found someone who really likes doing this kind of thing? Still, maintaining such an old codebase while the rest of the world moves on...ugh...
As someone who actively maintains old rhel, the development environment is something you can drag forward.
The biggest problem is fixing security flaws with patches that dont have 'simple' fixes. I imagine that they are going to have problems with accurately determining vulnerability in older code bases where code is similar, but not the same.
On the other hand: dealing with 14.04 is practically cutting edge compared to stuff still using AIX and HPUX, which were outdated even 20 years ago lol
Not all jobs are fun, but they can be bearable if meaningful enough (whether that being useful for other people, or even just provide a living wage to support your family)
> Unless they found someone who really likes doing this kind of thing?
There are more people like that than one might think.
There's a sizable community of people who still play old video games. There are people who meticulously maintain 100 year old cars, restore 500 year old works of art, and find their passion in exploring 1000 year old buildings.
The HN front page still gets regular posts lamenting loss of the internet culture of the 80s and 90s, trying to bring back what they perceive as lost. I'm sure there are a number of bearded dudes who would commit themselves to keeping an old distro alive, just for the sake of not having to deal with systemd for example.
> There's a sizable community of people who still play old video games.
I went to the effort of reverse engineering part of Rollercoaster Tycoon 3 to add a resizeable windowed mode and fix it's behaviour with high poll rate mice... It can definitely be interesting to make old games behave on newer platforms.
I'm now deploying all my projects in Incus container (LXC). My base system is upgradeable, ZFS-based, in future will be IncusOS but now just Ubuntu. Incus is connected in cluster so I can: backup/copy projects, move between machines etc.
Containers reuse host system's new kernel, while inside I get Ubuntu 22.04. I don't see a good reason, if 22.04 will get 15-year life support, to upgrade it much. It's a perfect combination for me, keeping the project on 22.04 essentially forever, as long as my 22.04 build-container can still build the new version.
Isn't Incus/LXD separate from and running on top of LXC?
People sometimes seem to use the names interchangeably which can be annoying because I run just plain LXC but when looking stuff up and come across "this is how you do XYZ on LXC" they are actually talking about LXD and it doesn't really apply.
I can't recall what is was last time, but this has happened a couple of times already...
From what a quick google search told me, RHEL caps out at 13 years.[0] I'm curious what caused Canonical to offer 2 more years of lts support than Red Hat?
It doesn't seem unreasonable to me if you have the resources. If I could've paid Apple to somehow just support OS X 10.6 forever I'd probably still be a Mac/Hackintosh user lol
There’s at least one customer somewhere willing to pay $1 million for that.
Plus adding a general feeling of confidence to the product as a whole. And safety knowing that you can upgrade for an extra 5 years of support if you need it.
I've used Canonical's free 3-seat extended service mantainence (ESM) support on my one 14.04 LTS machine for a long time. It's so nice having a stable target for more than decade for my personal projects. I have so much software defined radio software that absolutely does break in ways I can't fix on a newer version of any Debian-alike. The ESM program has been a provider of peace of mind when still leaving that SDR machine connected to the internet and running javascript.
>30-day trial for enterprises. Always free for personal use.
>Free, personal subscription for 5 machines for you or any business you own
This "Pro" program also being free is a suprise to be sure, but a welcome one.
That is the last 2.7 patch from PSF. Other reputable organizations keep making new patch releases for as long as there are paying customers. Not just the big legacy distros.
The person having to maintain this must be in a world of hurt. Unless they found someone who really likes doing this kind of thing? Still, maintaining such an old codebase while the rest of the world moves on...ugh...
You're not adding new features and such like that. Just patching security vulnerabilities in a forked branch.
Sure, you won't get the niceties of modern developments, but at least you have access to all of the source code and a working development environment.
As someone who actively maintains old rhel, the development environment is something you can drag forward.
The biggest problem is fixing security flaws with patches that dont have 'simple' fixes. I imagine that they are going to have problems with accurately determining vulnerability in older code bases where code is similar, but not the same.
On the other hand: dealing with 14.04 is practically cutting edge compared to stuff still using AIX and HPUX, which were outdated even 20 years ago lol
Some people just want a job, they don’t wrap up their sense of self worth in it.
Nothing to do with self worth, it is a meaningful job, but a fun one?
Not all jobs are fun, but they can be bearable if meaningful enough (whether that being useful for other people, or even just provide a living wage to support your family)
Most people I know don’t like chasing the latest framework that everyone will forget about in 6 months.
> Unless they found someone who really likes doing this kind of thing?
There are more people like that than one might think.
There's a sizable community of people who still play old video games. There are people who meticulously maintain 100 year old cars, restore 500 year old works of art, and find their passion in exploring 1000 year old buildings.
The HN front page still gets regular posts lamenting loss of the internet culture of the 80s and 90s, trying to bring back what they perceive as lost. I'm sure there are a number of bearded dudes who would commit themselves to keeping an old distro alive, just for the sake of not having to deal with systemd for example.
> There's a sizable community of people who still play old video games.
I went to the effort of reverse engineering part of Rollercoaster Tycoon 3 to add a resizeable windowed mode and fix it's behaviour with high poll rate mice... It can definitely be interesting to make old games behave on newer platforms.
Search YouTube for "gog noclip documentary", without quotes. Right up your alley.
I'm now deploying all my projects in Incus container (LXC). My base system is upgradeable, ZFS-based, in future will be IncusOS but now just Ubuntu. Incus is connected in cluster so I can: backup/copy projects, move between machines etc.
Containers reuse host system's new kernel, while inside I get Ubuntu 22.04. I don't see a good reason, if 22.04 will get 15-year life support, to upgrade it much. It's a perfect combination for me, keeping the project on 22.04 essentially forever, as long as my 22.04 build-container can still build the new version.
The 15 year support is paid not free.
Sell it to me! Why not docker?
Isn't Incus/LXD separate from and running on top of LXC? People sometimes seem to use the names interchangeably which can be annoying because I run just plain LXC but when looking stuff up and come across "this is how you do XYZ on LXC" they are actually talking about LXD and it doesn't really apply. I can't recall what is was last time, but this has happened a couple of times already...
From what a quick google search told me, RHEL caps out at 13 years.[0] I'm curious what caused Canonical to offer 2 more years of lts support than Red Hat?
[0]https://access.redhat.com/support/policy/updates/errata
I know that there is still rhel6 customers in contract, that was 2010.
Nice.
Should be mandatory for home automation systems. Support must outlive the home warranty.
How many customers did this take? Wow...
It could just have been one with a very large check.
It doesn't seem unreasonable to me if you have the resources. If I could've paid Apple to somehow just support OS X 10.6 forever I'd probably still be a Mac/Hackintosh user lol
There’s at least one customer somewhere willing to pay $1 million for that.
Plus adding a general feeling of confidence to the product as a whole. And safety knowing that you can upgrade for an extra 5 years of support if you need it.
The level of confidence is pretty incredible. Coming from someone who got hurt by CentOS.
One of the dirty secrets is that you don't need to back up confidence to sell it if you don't plan to be around when it falls apart.
These kinds of demands are becoming more common in b2b software.
I've used Canonical's free 3-seat extended service mantainence (ESM) support on my one 14.04 LTS machine for a long time. It's so nice having a stable target for more than decade for my personal projects. I have so much software defined radio software that absolutely does break in ways I can't fix on a newer version of any Debian-alike. The ESM program has been a provider of peace of mind when still leaving that SDR machine connected to the internet and running javascript.
>30-day trial for enterprises. Always free for personal use. >Free, personal subscription for 5 machines for you or any business you own
This "Pro" program also being free is a suprise to be sure, but a welcome one.
Its unclear if this legacy patch will be free for personal use.
This gives me a good sense of how old these versions are:
https://documentation.ubuntu.com/ubuntu-for-developers/refer...
14.04 LTS has Python 3.4 as well as Python 2.7.
The last patch for Python 2.7 was released in 2020 (https://www.python.org/downloads/release/python-2718/)
That is the last 2.7 patch from PSF. Other reputable organizations keep making new patch releases for as long as there are paying customers. Not just the big legacy distros.
E.g. https://github.com/ActiveState/cpython
There are others.