SUSE upgrades its distros with 19 years of support – no other Linux comes close
zdnet.com
zdnet.com
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.
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.
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.
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
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.
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.
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