SUSE Upgrades Its Distros With 19 Years of Support (zdnet.com) 36
An anonymous reader quotes a report from ZDNet: At SUSECon in Berlin, SUSE, a global Linux and cloud-native software leader, announced significant enhancements across its entire Linux distribution family. These new capabilities focus on providing faster time-to-value and reduced operational costs, emphasizing the importance of choice in today's complex IT landscape. SUSE Linux Enterprise Server (SLES) 15 Service Pack (SP) 6 is at the heart of these upgrades. This update future-proofs IT workloads with a new Long Term Service (LTS) Pack Support Core. How long is long-term? Would you believe 19 years? This gives SLES the longest-term support period in the enterprise Linux market. Even Ubuntu, for which Canonical recently extended its LTS to 12 years, doesn't come close.
You may ask yourself, "Why 19 years?" SUSE General Manager of Business Critical Linux (BCL) Rick Spencer, explained in an interview that the reason is that on 03:14:08 Greenwich Mean Time (GMT, aka Coordinated Universal Time) Tuesday, January 19, 2038, we reach the end of computing time. Well, not really, but Linux, and all the other Unix-based operating systems, including some versions of MacOS, reach what's called the Epoch. That's when the time-keeping code in 32-bit Unix-based operating systems reaches the end of the seconds it's been counting since the beginning of time -- 00:00:00 GMT on January 1, 1970, as far as Linux and Unix systems are concerned -- and resets to zero. Just like the Y2K bug, that means that all unpatched 32-bit operating systems and software will have fits. The Linux kernel itself had the problem fixed in 2020's Linux 5.6 kernel, but many other programs haven't dealt with it. Until then, though, if you're still running SLES 15 SP6, you'll be covered. I strongly suggest upgrading before then, but if you want to stick with that distro to the bitter end, you can. The new SLES also boasts enhanced security features like confidential computing support with encryption in memory, utilizing Intel TDX and AMD SEV processors, along with remote attestation via SUSE Manager. Additionally, SLES for SAP Applications 15 SP6 offers a secure and reliable platform for running mission-critical SAP workloads, incorporating innovations from Trento to help system administrators avoid infrastructure issues.
You may ask yourself, "Why 19 years?" SUSE General Manager of Business Critical Linux (BCL) Rick Spencer, explained in an interview that the reason is that on 03:14:08 Greenwich Mean Time (GMT, aka Coordinated Universal Time) Tuesday, January 19, 2038, we reach the end of computing time. Well, not really, but Linux, and all the other Unix-based operating systems, including some versions of MacOS, reach what's called the Epoch. That's when the time-keeping code in 32-bit Unix-based operating systems reaches the end of the seconds it's been counting since the beginning of time -- 00:00:00 GMT on January 1, 1970, as far as Linux and Unix systems are concerned -- and resets to zero. Just like the Y2K bug, that means that all unpatched 32-bit operating systems and software will have fits. The Linux kernel itself had the problem fixed in 2020's Linux 5.6 kernel, but many other programs haven't dealt with it. Until then, though, if you're still running SLES 15 SP6, you'll be covered. I strongly suggest upgrading before then, but if you want to stick with that distro to the bitter end, you can. The new SLES also boasts enhanced security features like confidential computing support with encryption in memory, utilizing Intel TDX and AMD SEV processors, along with remote attestation via SUSE Manager. Additionally, SLES for SAP Applications 15 SP6 offers a secure and reliable platform for running mission-critical SAP workloads, incorporating innovations from Trento to help system administrators avoid infrastructure issues.
Finally! (Score:5, Funny)
Re: (Score:2)
It depends how good their long term support is. For example, Ubuntu 18 LTS was supposed to be supported up to last year, but in reality if you installed it so much was broken that it was practically useless.
Part of it was infrastructure at Ubuntu like software repos going away, and part of it was that they didn't upgrade important applications like openvpn so they became incompatible with modern networks. Compatibility with VMs was another issue.
If you just want to keep a server running for 19 years and are
Re: (Score:3)
I've been paid quite a lot in my career for just such support. "We don't want a new license, just use the old one" makes me wince, but has gotten me a lot of billable hours of work.
Re: (Score:3)
In some arenas, the upgrade is prohibitively expensive, as much as buying all new product plus support plus migration costs. Ie, if we sell a 20 year support contract, some customers want that. Most will update hardware before then though. Others will delay. Firmware updates go out, but by necessity they're backwards compatbie as much as they can be. Thus, it makes sense to pay someone to maintain it until it becomes too expensive to do so, then gently encourage the painful process of upgrading to some
My first Linux distro (Score:1)
I remember back in 1993 getting a CD in the back of an OpenSUSE book, and spending many hours exploring the code. You could modify a file to describe the modules and config you wanted, then run a few commands to compile an entire distro kernel and all, and install it.
Fascinating stuff!
Re: (Score:3)
I remember back in 1993 getting a CD in the back of an OpenSUSE book, and spending many hours exploring the code. You could modify a file to describe the modules and config you wanted, then run a few commands to compile an entire distro kernel and all, and install it.
Fascinating stuff!
Compiling was even more fun. Once you made it through 'make menconfig' to configure your kernel options/modules, I think it was 'make zImage' or something like that to actually start the kernel compile. On an old 486SX with little ram, it would run for 3-4 days.
Re: (Score:2)
That rather surprises me, I used to run the SuSE version of the day on a 386SX - possibly with 4MB - back in the late 1990s. Compiling the kernel was something which I'd do overnight and I remember it as having been substantially complete by the time I got into work the next morning. If it had been as slow as you are indicating, it would have been something which had to be run at weekends.
I can't remember if the machine ran with 20MHz or with 25 but it was pretty slow. I ran it as a (very) small Samba an
Re: (Score:1)
Mine took like a half an hour to compile the kernel. I use to try every combination of modules or static linking.
Re: (Score:1)
Mine was a 486SX, too, first PC I bought for myself. A Packard Bell. What a piece of shit. :D
Re: (Score:2)
"I think it was 'make zImage' or something like that to actually start the kernel compile. On an old 486SX with little ram, it would run for 3-4 days"
"make zImage" would have built a compressed kernel so that may explain why such a long build time was necessary.
even on my old crap PC I don't think i ever needed more than 3 hours to build a kernel but the last time I tried would have been when I got my 1st dual CPU AMD so probably 2006
Re: (Score:2)
should have been "even on my OLDEST crap PC"
Re: (Score:2)
You could modify a file to describe the modules and config you wanted, then run a few commands to compile an entire distro kernel and all, and install it.
Fascinating stuff!
"You could modify a file to describe the modules and config you wanted", yeah that's how compiling a kernel in any distro still works today.
Re: (Score:1)
I kind of figured it did.
Re: (Score:2)
I kind of wondered what was the relation with suse 1993 nostalgia since it's the same nowadays and it was the same on my 1993 Slackware distro. I used to build my own kernels without modules until ~2005. Enabling modules in a kernel is kind of a security risk but what can you do nowadays? Some stuff now come only as modules. Still, for hyper-critical stuff, I'd probably build a kernel without module support if possible.
A lot can happen.... (Score:2)
Re: (Score:1)
Indeed. In perspective, the first release of Ubuntu was 19y ago.
Re: (Score:2)
So much has changed since then. BUT ALSO so much has not changed even slightly since then.
Re: (Score:2)
Especially since you are practically guaranteed that other projects such as OpenSSH will have deprecated many ciphers and key exchange protocols in that 19 years. Is SUSE going to backport every one of those changes for 19 years in order to make it even possible to make a relevant connection to this thing in 2043?
Re: (Score:2)
Support guarantees usually to not cover changes in protocols. Those are "new features" and would require an upgrade of firmware, software, or hardware. Long term support means you get bug fixes and security updates. If a security update requires certs that also require a new cypher algorithm or a different time format, then that falls under "new feature".
Of course there is mitigation. Send out advisories to use longer certificate expiration dates rather than a yearly replacement, for example. For many
Why not wait until SLES 16? It's anybody's guess (Score:2)
With SLES 15 (SP6) they are fixed into a bunch of old kernel and drivers, and setting themselves up to a buch of backporting on already old kernels. Ditto for the userland stuff.
Waiting until SLES 16 means a new base to start over, carefully choosing the Kernel and userland that makes most sense for such a long support window. Prhaps one of those 10 year kernels built on top of the 2 year LTS supported by the embedded manufacturers.... Ditto for the userland.
But alas, it is what it is. I guess some manager
Tough Lift (Score:2)
I guess this hinges on definitions but between now and then there will be some vulnerability that is very difficult to "just fix" without a lot of kernel work that will happen between now and then.
Good luck!
It does not reset to 0 (Score:5, Informative)
On Tue 19 Jan at 03:14:08 UTC a signed 32 bit integer time does not reset to 0 it reaches 0x80000000 which is -2147483648, interpreted as the number of seconds since 1970-01-01 00:00:00 UTC this is Fri 13 Dec 20:45:52 UTC 1901. It is possible that some systems may tick over to 0 instead of going to 1901 but most signed 32 bit calculations will not do this. See https://en.wikipedia.org/wiki/... [wikipedia.org]
Re: (Score:2)
It's actually undefined behaviour for a signed value to overflow in C. While every CPU I've ever looked at in any detail does overflow to the lowest negative number possible to by stored in that many bits, in theory anything could happen.
Anyone know of any CPUs, or even C compilers, that behave differently?
64-bit time_t on 32-bit archs (Score:2)
Re: (Score:3)
Linux had 64-bit time_t support since 5.1, or around 2019 universally. It had earlier support for it - 64-bit architectures that supported a 64-bit long would have a 64-bit time_t, but officially in 5.1 it was 64-bit across the board for all architectures.
Of
I wish SLES were more common in the enterprise... (Score:3)
I wish SLES were more common in businesses. It seems to have all the needed things for STIGs, and the security items that Red Hat brings to the table, except that they didn't bet the house on stratis and other items, so offer things like btrfs [suse.com] which Red Hat doesn't seem to bother having.
Overall, it is a mature OS, and it really needs a wider audience.
The End Of ? (Score:2)
written by someone who wasn't alive in 1970 (Score:1)
Re: (Score:2)
The article states
so what's your beef?
Re: (Score:2)
The "Unix epoch" is the point in time corresponding to 0 seconds, not 2**31 seconds. That's his beef: the Unix epoch was at the start of 1970 (GMT).
Re: (Score:2)
That's his beef. The Unix Epoch is 00:00:00 GMT on January 1, 1970. Not 00:00:00 GMT on January 1, 1970 + 2^31 seconds.
His beef was that the author was factually incorrect.
discussion (Score:1)