Ubuntu Lts Releases to 15 Years with Legacy Add-on

Not all jobs are fun, but they can be bearable if meaningful enough (whether that being useful for other people, or even just provide a living wage to support your family)

Clear mission, a well set up team and autonomy in execution can make most jobs fun to do? Stress (due to), lack of autonomy, lack of clear mission and bad teams and management I think are the root of unhappy work?

> IBM kinda screwed it up when they created CDE out of it though.

Could you please elaborate?

Search YouTube for "gog noclip documentary", without quotes. Right up your alley.

That there are so many indicates to me the opposite. There are lots of people who want to work on that kind of thing, just they all have slightly different opinions as to which part is the part they’re fighting against, hence so many different forks.

The forks are all volunteer projects (except Ubuntu), so having slightly different opinions isn’t considering capitalism as a driving force.

> I imagine that they are going to have problems with accurately determining vulnerability in older code bases where code is similar, but not the same.

That sounds like a fun job actually.

If no one is posting CVE that affects these old Ubuntu versions then Canonical doesn’t have to fix them. I realize that’s not your point, but it almost certainly is a part of Canonical’s business plan for setting the cost of this feature.

The Pro subscription isn’t free and clearly Canonical think they will have enough uptake on old versions to justify the engineering spend. The market will tell them if they’re right soon. It will be interesting to watch. So far it seems clear they have enough Pro customers to think expanding it is profitable.

> I'd say that a forked, LTS apache2 (just an example) on a 15 year old LTS is likely used by 17 people and someone's dog.

Likewise, the number of black hats searching for vulnerabilities in these versions is probably zero, since there isn't a deployment base worth farming.

Unless you're facing something targeted at you that an adversary is going to go to huge expense to try to find fresh vulnerabilities specifically in the stack you're using, you're probably fine.

I agree with your sentiment that no known vulnerabilities doesn't mean no vulnerabilities, but my point is that the risk scales down with the deployment numbers as well.

And always keeping up with the newest thing can be more dangerous in this regard: new vulnerabilities are being introduced all the time, so your total exposure window could well be larger.

> "just do it, its easy"

If its that easy, then why aren't they doing it instead of you? Yeah, I thought so.

We can SSH in? X and Wayland forward comfortably? Their windows integrate with e.g. KDE? How about sharing files with the host os? USB devices such as cameras or Android devices?

So the problem you’re running into is the question of whether support for old architectures should indefinitely hold back the adoption of new features or languages in future kernel versions. Rust in the kernel was added as a way for developers to explore whether the tradeoff between not supporting all future capabilities and adopting a more modern programming language works out. Nothing in the kernel core uses and relies on Rust so far, and to the best of my knowledge, no adoption of Rust in any of these places is planned as of today. So the use of Rust is limited to places which are of zero interest to older architectures. And it’s also not like the old kernel versions are going away. It’s perfectly viable for maintainers of old hardware to remain on older versions of the kernel.

OTOH, there is a desire from a group of kernel developers to implement to implement the code they contribute to the project in Rust. The want new shit to be working, and write support for it in a language they consider suitable for implementing the support faster, more maintainable and safer than in C. Should those people be held back by architecture support for architectures that haven’t seen new hardware in decades? Would that imply that the kernel developers cannot decide to drop support for old architectures? What would any such requirement mean for the long term future of the Linux kernel?

doesnt matter because windows can run even dos software out of the box

its compability its one of the best

> Even Azure, the new major revenue stream of Microsoft is built on Linux!

Exactly, and has been for some time now. MS wasn’t asleep at the wheel, they just stopped caring about your infra. The money’s in the cloud now, especially the SaaS you neither own nor control.

My question was if these large companies moving away from Windows are just clearing the last remnants of the OS rather than just now shifting their sizable Windows footprint to Linux.

I’m trying to understand what was OP reporting. On the user side almost nobody is moving their endpoints to Linux, on the DC side almost nobody has too many Windows machines left to move to Linux after years of already doing this. The trend was apparent for years and years.

Azure has circa 60% of VMs running Linux, however the underlying infrastructure is built on Windows.

Why not think of it a different way; why do we need to put up with breaking changes at all?

I'd much rather stand up a replacement system adjacent to the current one, and then switch over, than run the headache of debugging breaking changes every single release.

To me, this is the difference between an update and an upgrade. An update just fixes things that are broken. And upgrade adds/removes/changes features from how they were before.

I'm all for keeping things up to date. And software vendors should support that as much as possible. But forcing me to deal with a new set of challenges every few weeks is ridiculous.

This idea of rapid releases with continuous development is great when that's the fundamental point of the product. But stability is a feature too, and a far more important one in my opinion. I'd much rather a stable platform to build upon, than a rickety one that keeps changing shape every other week that I need to figure out what changed and how that impacts my system, because it means I can spend all of my time _using_ the platform rather than fixing it.

This is why bleeding edge releases exist. For people who want the latest and greatest, and are willing to deal with the instability issues and want to help find and squash bugs. For the rest of us, we just want to use the system, not help develop it. Give me a stable system, ship me bug fixes that don't fundamentally break how anything works, and let me focus on my specific task. If that costs money, so be it, but I don't want to have to take one day per week running updates to find something else is broken and have to debug and fix it. That's not what I'm here to do.

And as for cleaning the house - we always have the option of hiring a cleaner. That costs us money, but they keep the house cleanliness stable whilst we focus on something else to make enough money to cover the cleaner's cost plus some profit.

I've lost count of how many Ubuntu upgrades resulted in some weird problem (network interfaces renamed, lost default route, systemd timeouts taking 5 minutes, etc.)

There is an argument for staying on the latest stable version.

Considering "upgrading" to be "cleaning" is very odd. Same with "rotting".

Perhaps this is a side effect of dealing with software development ecosystems with huge dependency trees?

There's a lot of software not like that at all. No dependencies. No internet connection. No multi kilobyte lock files detailing long lists of continual software churn and bug fixes.

Why would the same exact software be considered “unclean” or “rotten” a few years down the line when it previously wasn’t? What has changed? Did it need to?

> Why do you need to clean your house every week/couple of weeks ? Why not clean only once a year ?

OS is not a physical house with life waste.

Rest of your message doesn’t make any sense for majority of industry. For anything dealing with manufacturing stability is much more important that marginal performance gains. Any downtime is losing money.

It didn't need to be this way. It's a choice made by companies who stand to gain from the continuous churn.

Why don't you move house every 6 months?

Why not force everyone to upgrade their cars every 2 to 3 years?

Not that you’ll agree, but cleaning the house sounds more like running rm -rf /tmp and docker system prune than upgrading from idk, bullseye to bookworm. Let’s call that a bathroom remodel? So sometimes you live in a historic house and the bathroom cannot be remodeled or changed because it’ll fall through the floor or King Louis the XV used it once. In software, the historic house could be the PLLc firmware controlling the valves in your nuclear reactor cooling loop.

I do chores regularly, and I apply security patches regularly.

Major operating system version upgrades can be more akin to upgrading all the furniture and electronics in my house at the same time.

You keep using this analogy, but it is not comparable, and it is a horrible analogy.

Yes, this is the key distinction: old software that works vs old software that sucks.

The one that sucks was a so-so compromise back in the day, and became a worse and worse compromise as better solutions became possible. It's holding the users back, and is a source of regular headaches. Users are happy to replace it, even at the cost of a disruption. Replacing it costs you but not replacing it also costs you.

The one that works just works now, but used to, too. Its users are fine with it, feel no headache, and loathe the idea to replace it. Replacing it is usually costly mistake.

You're talking about software. The other person is talking about OS. Big difference.

Sounds like that is a different issue. I prefer to avoid spending a few weeks migrating software that i understand and support to a new OS when i dont have to. Some of it is 30 years old, but it has had all the bugs worked out.

> I am employed by a multi-billion company (which has more than 100k people)

In my personal experience, this could mean that you're really good or that you're completely incompetent and unaware that computers need to be plugged to a power outlet to function.

Not at all, it depends on the level of public exposure of the service.

In a factory, access is the primary barrier.

It's like an onion, outer surface has to be protected very well, but as you get deeper in the zone where less and less services have access then the risk / urgency is usually lowered.

Many large companies are consciously running with security issues (even Cloudflare, Meta, etc).

Yes, on the paper it's better to upgrade, in the real world, it's always about assessing the risk/benefits balance.

Sometimes updates can bring new vulnerabilities (e.g. if you upgrade from Windows 2000 to the "better and safer" Windows 11).

In your example, you have the guarantee to down the factory floor (for an unknown amount of time, what if PostgreSQL does not reboot as expected, or crashes during runtime in the updated version).

This is essentially an (hopefully temporary) self-inflicted DoS.

Versus an almost non-existent risk if the machine is well isolated, or even better, air-gapped.

Kernel live patching takes care of everything.

There's a difference between old software and old OS. Unless you've got new hardware, chances are you never really need a new OS.

I don't understand this comment. What exactly do you think LTS is?