So imagine - you're relying on some piece of software released around 2005. 2.6.10 Linux kernel, ext2 (maybe reiserfs?) TLS is called SSL and you're good if your DSA key has 512 bits... This essential service your company needs had long been abandoned and all attempts to mitigate the imminent disaster have failed. (Migrate to competitor, revive the code base, run in a VM)
... Or some CTO has seriously done a bad job anticipating whatever maintenance necessary over last decade.
I appreciate that change is hard sometimes, but maaaan life is so much easier if you upgrade/migrate/rebuild every now and then with some frequency.
Well, I'm still running critical services on Solaris 10 everyday and will be running them for the foreseeable future. Granted it's on an airtight network, but still, every time I see CDE, I'm brought back 15 years ago.
I wish we could migrate to something more modern, but vendor lock-in is strong in certain instances, let alone in the embedded space.
I understand being stuck on Solaris 10, but if you don't like CDE you could theoretically install something else; didn't it even officially ship with GNOME 2 out of the box?
(This is slightly funny to me, too, because I sometimes run CDE on my shiny new Linux boxes out of a combination of nostalgia and dislike for the endless change of new things. As you say, I can install the latest CDE release, fire it up, and return to 15 years ago, if not more. Windows 11? Never heard of it. GNOME? Well Sun brands it the "Java Desktop", but whatever. CDE is the same as last time I saw it, and it will be the next time I see it. It's clunky, but that's a small price to pay for a quiet corner of the world frozen in time.)
If you’re operating critical infrastructure like a sewage treatment plant sometimes you just want stuff to work as long as possible without messing with it.
The point is that you're probably going to have to mess with it eventually, and the amount of work that takes goes up the longer you put it off.
If you're talking a completely offline system that's basically a utility and doesn't even need security patches, then how many years of support the OS provides becomes irrelevant, because you theoretically don't need those patches anyway.
But if you're concerned with staying "technically up-to-date," as in "the vendor says it's supported even though it's X years old," then there will almost certainly come a time when you reach the end of the line and have to reconcile that with everything you didn't keep up with. (It might be after you're out of there, though.)
Even today you'll see lay-persons use SSL, and some professionals refer to SSL for HTTPS and other secure connections.
Two decades ago TLS was still not in common use among common tech professionals. While TLS was released in 1999, informally many still just thought of 'SSL secured' connections, possibly using SSL / TLS certificates.
Additionally, as the Wikipedia article points out, TLS 1.0 was nearly still SSL 3.0, while 1.1 was released in 2006 and 1.2 in 2008 (which, offhand, is around the time I think the term TLS started to see more traction): https://en.wikipedia.org/wiki/Transport_Layer_Security#Histo...
""" TLS 1.0 was first defined in RFC 2246 in January 1999 as an upgrade of SSL Version 3.0, and written by Christopher Allen and Tim Dierks of Certicom. As stated in the RFC, "the differences between this protocol and SSL 3.0 are not dramatic, but they are significant enough to preclude interoperability between TLS 1.0 and SSL 3.0". Tim Dierks later wrote that these changes, and the renaming from "SSL" to "TLS", were a face-saving gesture to Microsoft, "so it wouldn't look [like] the IETF was just rubberstamping Netscape's protocol".[40] """
I started my career on the SUSE kernel team in 2007. And I used to joke that I maintained Kernel versions that were released before I even started writing kernel code in high school in 2001.
It was really exciting and sort of daunting testing and releasing kernels with Ethernet drivers I fixed to European air traffic control and stock exchanges.
Anyways. Sort of funny to think maybe code I touched right out of college is still in production and just got a life extension.
Depending on what you exactly expect from Windows Server, it has longer support due to great software compatibly Microsoft provides.
Upgrading Windows Server editions since 2008 is usually way smoother than upgrading Linux distros because basically everything keeps working more or less the same, often without needing to reconfigure them. Linux world changes things often and breaking compatibility between versions is expected.
Yeah this. I only shot an win32 c++ win32 desktop app I compiled for NT4 in 1999 about 2 years ago and that was running on Windows Server 2016 fine. It was resurrected earlier this year again. futzed a bit by someone else to fix some deprecated windows APIs, couple of bugs fixed, recompiled and is now 64 bit on windows server 2022. 150kloc took a day to fix for someone.
Perhaps the more direct comparison is RHEL with 10 years of normal support and more if you're willing to pay more ( https://www.redhat.com/en/resources/els-datasheet ) and Ubuntu with... looks like 5-12 years depending on how much you pay?
Linux distribution support lifecycle is rarely a problem in reality from experience. In fact stability at that level probably hurts you in the long run because the disparity between your old and new world is massive then.
What is a problem is quality control. A lot of "stable" Linux distributions are buggy crap which has all sorts of weird problems and they are problems which I've had for 19 years. Also there are problems with stability which is due to people only doing the sexy work like rewriting the desktop environment every 6 months rather than fixing the bugs in it.
tl;dr: please concentrate on quality and stability, not longevity.
I do wonder about these extended periods of support. Like how many eyes are they spending on comparing vulnerabilities in 18 year old versions of, to pick a random example, libdeflate. Are they backporting security fixes? If someone goes wrong, do they have expertise on how hand or are their customers just going to go bother the upstream maintainer?
I've certainly run into users expecting me to make my libraries run on old versions of Python that RHEL supports even if the PSF no longer does. Some of these users don't understand that they've paid RHEL for support and they've paid me nothing, so I have no reason to give a toss what Python version RHEL supports in LTS minus 2.
https://www.suse.com/lifecycle#suse-linux-enterprise-server-... is yet to be updated, but it does mention SP7 LTSS ending in 2031 (the article claims SP6 LTSS ending in 2038, which would be quite contradictory). Maybe we will have more clarity once SP6 is officially released.
But 19 years is so far beyond the support period of upstream projects, what happens when a bug is quantum-fuzzed out of 15yo software? Nobody from the project will care, and nobody's backporting modern fixes to software that old.
It's not enough to just apply patches as upstream releases them.
Is SUSE really going to take on full maintainership for all the software it redistributes?
this is to win contacts. they only sell this support contact option because Microsoft/sap/etc do.
clients are probably getting a better deal with suse despite what your mention (which is doubly true for closed source, but happen behind closed doors)
the answer isn't yes or no. it's meh. it will just apply patches until a paying customer requires custom code via a very painful support escalation that likely will take a year
33 comments
[ 4.8 ms ] story [ 74.3 ms ] threadSo imagine - you're relying on some piece of software released around 2005. 2.6.10 Linux kernel, ext2 (maybe reiserfs?) TLS is called SSL and you're good if your DSA key has 512 bits... This essential service your company needs had long been abandoned and all attempts to mitigate the imminent disaster have failed. (Migrate to competitor, revive the code base, run in a VM)
... Or some CTO has seriously done a bad job anticipating whatever maintenance necessary over last decade.
I appreciate that change is hard sometimes, but maaaan life is so much easier if you upgrade/migrate/rebuild every now and then with some frequency.
I wish we could migrate to something more modern, but vendor lock-in is strong in certain instances, let alone in the embedded space.
(This is slightly funny to me, too, because I sometimes run CDE on my shiny new Linux boxes out of a combination of nostalgia and dislike for the endless change of new things. As you say, I can install the latest CDE release, fire it up, and return to 15 years ago, if not more. Windows 11? Never heard of it. GNOME? Well Sun brands it the "Java Desktop", but whatever. CDE is the same as last time I saw it, and it will be the next time I see it. It's clunky, but that's a small price to pay for a quiet corner of the world frozen in time.)
If you’re operating critical infrastructure like a sewage treatment plant sometimes you just want stuff to work as long as possible without messing with it.
If you're talking a completely offline system that's basically a utility and doesn't even need security patches, then how many years of support the OS provides becomes irrelevant, because you theoretically don't need those patches anyway.
But if you're concerned with staying "technically up-to-date," as in "the vendor says it's supported even though it's X years old," then there will almost certainly come a time when you reach the end of the line and have to reconcile that with everything you didn't keep up with. (It might be after you're out of there, though.)
SSL was renamed to TLS in 1999...
Two decades ago TLS was still not in common use among common tech professionals. While TLS was released in 1999, informally many still just thought of 'SSL secured' connections, possibly using SSL / TLS certificates.
Additionally, as the Wikipedia article points out, TLS 1.0 was nearly still SSL 3.0, while 1.1 was released in 2006 and 1.2 in 2008 (which, offhand, is around the time I think the term TLS started to see more traction): https://en.wikipedia.org/wiki/Transport_Layer_Security#Histo...
""" TLS 1.0 was first defined in RFC 2246 in January 1999 as an upgrade of SSL Version 3.0, and written by Christopher Allen and Tim Dierks of Certicom. As stated in the RFC, "the differences between this protocol and SSL 3.0 are not dramatic, but they are significant enough to preclude interoperability between TLS 1.0 and SSL 3.0". Tim Dierks later wrote that these changes, and the renaming from "SSL" to "TLS", were a face-saving gesture to Microsoft, "so it wouldn't look [like] the IETF was just rubberstamping Netscape's protocol".[40] """
using USB thumb drives to move csv data into the real world where there's internet
It was really exciting and sort of daunting testing and releasing kernels with Ethernet drivers I fixed to European air traffic control and stock exchanges.
Anyways. Sort of funny to think maybe code I touched right out of college is still in production and just got a life extension.
Upgrading Windows Server editions since 2008 is usually way smoother than upgrading Linux distros because basically everything keeps working more or less the same, often without needing to reconfigure them. Linux world changes things often and breaking compatibility between versions is expected.
In government at least this is a big deal. Will binaries from 15 years ago run on SUSE Linux? Somehow I doubt it.
I've seen hardware utilities that look like pre Windows 95 programs running on modern windows? Is that sound possible?
If it is important enough, the government should demand ownership of the source code, not just take some binary and call it a day.
No glibc will not fix it and the rolling release distros are now patching their libc.
Here is the list of ABI breaking changes:
https://abi-laboratory.pro/?view=timeline&l=glibc
Also a system layer isn't just the C library. Other core Linux libraries often break their ABI too.
What is a problem is quality control. A lot of "stable" Linux distributions are buggy crap which has all sorts of weird problems and they are problems which I've had for 19 years. Also there are problems with stability which is due to people only doing the sexy work like rewriting the desktop environment every 6 months rather than fixing the bugs in it.
tl;dr: please concentrate on quality and stability, not longevity.
I've certainly run into users expecting me to make my libraries run on old versions of Python that RHEL supports even if the PSF no longer does. Some of these users don't understand that they've paid RHEL for support and they've paid me nothing, so I have no reason to give a toss what Python version RHEL supports in LTS minus 2.
It's not enough to just apply patches as upstream releases them.
Is SUSE really going to take on full maintainership for all the software it redistributes?
clients are probably getting a better deal with suse despite what your mention (which is doubly true for closed source, but happen behind closed doors)
the answer isn't yes or no. it's meh. it will just apply patches until a paying customer requires custom code via a very painful support escalation that likely will take a year