The Debian Long Term Support (LTS) Team hereby announces that Debian 10 “buster” support will reach its end-of-life on June 30, 2024, nearly five years after its initial release on July 6th, 2019.
Starting in July, Debian will not provide further security updates for Debian 10. A subset of “buster” packages will be supported by external parties. Detailed information can be found at Extended LTS.
The Debian LTS Team will prepare afterwards the transition to Debian 11 “bullseye”, the current oldstable release. Thanks to the combined effort of different teams including the Security Team, the Release Team, and the LTS Team, the Debian 11 life cycle will also encompass five years. To make the life cycle of Debian releases easier to follow, the related Debian teams have agreed on the following schedule: three years of regular support plus two years of Long Term Support. The LTS Team will take over support from the Security and the Release Teams on August 14, 2024, three years after the initial release on August 14, 2021. The final point update release for “bullseye” will be published soon after the final Debian 11 Security Advisory (DSA) will be issued.
Debian 11 will receive Long Term Support until August 31, 2026. The supported architectures remain amd64, i386, arm64 and armhf.
As much flak as they catch, you gotta hand it to Ubuntu for offering up to 12 years of support to companies willing to pay for it. It doesn’t make sense for anything but a paid service, but dang is it impressive.
The problem with that is that the rest of the ecosystem keeps moving on, and the more time passes the more left behind you are. So you stick with old versions of whatever you use and when the time comes to upgrade it hurts even more because it’s not just the OS that works differently but also all the software you’re using including Python, Ruby, PHP, NodeJS or whatever your software stack is built on. So you have to upgrade all of that code too. At some point you might as well start over from scratch which just makes it even harder and daunting to tackle to you increasingly push it further until you hit the 12 years and you’re forced to do it with time constraints
The proper solution to critical systems you’re too afraid to upgrade is to… upgrade and redeploy them more often in test environments so you’re not afraid of upgrading the system. And the very companies that would pay for the 12 years of support are the ones that really should have the whole thing fully automated and fully tested.
I could see an argument for companies that work with healthcare or government that have to have systems / software specifically audited / vetted / approved before use. But yeah you’re absolutely right, getting that far behind the times sounds like a nightmare when it does finally go EOL.
The linger you wait the harder it is
So basically, as
veryoldoldstableit will be kept alive for another five years.