Canonical gives administrators the chance to drag their feet a bit more on Ubuntu upgrades There was good news today for administrators looking nervously at their aging Ubuntu boxes. A few more years of support is now on offer as Canonical brings 14.04 and 16.04 LTS into the 10-year fold. Users still running on 14.04 LTS (Trusty Tahr), released back in April 2014, now have until April 2024 (up from 2022) to make the …
Mainly things which relied on Python 2 which are now missing or broken, but the increasing reliance on snaps ("Hey! Let's use up much more disk space with stuff which doesn't update automatically even if the developer remembers to check for and include updated version of every single dependency! Say goodbye to troubling consistence and security!") is a pisser too.
The killer for me - for which I don't particularly blame Ubuntu - is that the Citrix NetScaler Gateway VPN client won't run on it.
What I don't like about snaps are all the loopback mounts that fill up the mount table.
It's an elegant way of doing things, but only if you have a relatively small number of snaps installed. I wonder just how many loopback mounts the system can have, because if you were to ship everything that installs as an RPM as a snap, my primary system would need several hundred loopback mounts.
The other thing that I'm not sure about is the memory overhead. By design, snaps defeat the shared-library functionality of Linux. What this means is that even if you have multiple snaps with the same versions of their libraries shipped, to maintain independence, each snap will end up loading it's own copy of each of the potentially shared libraries into memory.
It's possible that the snap may include a statically linked binary, which would somewhat limit the memory use if you run multiple versions of the binary, but even this is likely to be heavier on memory use than if they were using the system supplied versions of the shared library.
Maybe we should go back to just having statically linked binaries for everything, and draw the line at the system call divide to maintain compatibility, as we did last century.
You have to either buy access to this program, or if you are using it for personal reasons, become an "Official Ubuntu Community Member", which requires you to show how you have contributed to the Ubuntu community.
Although I have been a flag waver for Ubuntu for over 15 years (although not so much since Unity and their stance on systemd), nothing I have done qualifies me to apply for this recognition, so I'm not banking on getting ESM for any of my systems.
My personal main laptop is still running 16.04, because I don't particularly like some of the changes introduced in 18.04 and later, but many of these are not Ubuntu problems but issues that have come downstream from Debian which are taking Linux away from mainstream Unix (if that is still a thing).
If you think that Ubuntu 14.04 or 16.04 are the same as they were when they were released in 2014 and 2016 respectively, then you don't understand what a Long Term Support release is all about.
There have been plenty of patches while they were mainstream, and will be additional security patches if you enroll in the ESM program. These systems do not have to beun-patched.
There are many reasons (like systemd which changes the behavior of significant parts of Linux quite drastically) why people don't want to go beyond 14.04, and others introduced after 16.04 that many like me don't like.
There are also organizations that are not wanting to put the effort into all the regression testing required to ensure that their systems will operate as they want at a later release. As I said, things change with newer releases which break other things.
Many minor security issues still go unfixed relative to what upstream resolves, especially so if the vulnerabilities are only locally exploitable. Always try to use the newest releases where possible if you can and keep an eye on the Ubuntu (and Debian) security trackers to know what is known but not fixed.
I wonder how many systems you look after?
If you are using third party software on a Linux server, the cost of regression testing that software against later major OS releases can be quite considerable, and may well depend on whether the software is checked by the supplier against the newer releases.
I know that it would be convenient to assume that all software suppliers will check, but something I've learned over 30+ years of system administration and support is that suppliers go bust, drop upgrade support for software package, or charge significant additional fees for updates necessary to run on later OS releases. This means that checking does not always happen.
So having an OS release step that more closely matches the asset life of software and hardware components is just how many organizations want to work. Every 5 years or so, they kick off a project that will replace hardware, OS and if necessary replace or update application software. And LTS and ESM OS releases allow this to happen. You need ESM is your projects are not in step with LTS releases, to allow you to get to the point where you kick off your replacement projects.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
