The major argument you get from "why are you using Windows 7" is exactly this, companies in infrastructure argue that they still get a supported operating system in return (despite the facts, despite EOL, despite reality of MS not patching actually, and just disclosing new vulnerabilities).
And currently there's a huge migration problem because Microsoft Windows 11 is a non-deterministic operating system, and you can't risk a core meltdown because of a popup ad in explorer.exe.
I have no idea why Microsoft is sleeping at the wheel so much, literally every big industry customer I've been at in Europe tells me the exact same thing, and almost all of them were Windows customers, and are now migrating to Debian because of those reasons.
(I'm proponent of Linux, but if I were a proponent of Windows I'd ask myself wtf Microsoft is doing for the last 10 years since Windows 7)
It's good while the software you run on it still supports that OS, for example the big one would be anything build upon Chromium (or electron) framework which deprecated win7 support when Microsoft ended ESU support (EOL +3 years).
The person having to maintain this must be in a world of hurt. Unless they found someone who really likes doing this kind of thing? Still, maintaining such an old codebase while the rest of the world moves on...ugh...
Maybe I'm the odd one out but I love doing stuff that has long term stability written all over it. In fact the IT world moving as fast as it does is one of my major frustrations. Professionally I have to keep up so I'm reading myself absolutely silly but it is getting to the point where I expect that one of these days I'll end up being surprised because a now 'well known technique' was completely unknown to me.
> I love doing stuff that has long term stability written all over it
I also love doing stuff that has long term stability written all over it. In my 20 year career of trying to do that through various roles, I've learnt that it comes with a number of prerequisites:
1. Minimising & controlling your dependencies. Ensuring code you own is stable long term is an entirely different task to ensuring upstream code continues to be available & functional. Pinning only goes sofar when it comes to CVEs.
2. Start from scratch. The effort to bring an inherited codebase that was explicitly not written with longevity in mind into line with your own standards may seem like a fun challenge, but it becomes less fun at a certain scale.
3. Scale. If you're doing anything in (1) & (2) to any extent, keep it small.
Absolutely none of the above is remotely applicable to a project like Ubuntu.
I agree. We are going as far as being asked to release our public app on self-hosted kube cluster in 9 months, with no kube experience and nobody with a CKA in a 2.5 person ops team. "Just do it it's easy" is the name of the game now, if you fail you're bad, if you offer stability and respect delivery dates you are out-fashioned, and the discussion comes back every week and every warning and concern is ignored.
I remember a long time ago one of our client was a bank, they had 2 datacenters with a LACP router, SPARC machines, Solaris, VxFS, Sybase, Java app. They survived 20 years with app, OS and hardware upgrades and 0 second of downtime. And I get lectured by a 3 years old developer that I should know better.
The unfortunate problem is that, the more popular software is, the more it gets looked at, its code worked on. But forked branches as they age, become less and less likely to get a look-at.
Imagine a piece of software that is on some LTS, but it's not that popular. Bash is going to be used extensively, but what about a library used by one package? And the package is used by 10k people worldwide?
Well, many of those people have moved on to a newer version of a distro. So now you're left with 18 people in the world, using 10 year old LTS, so who finds the security vulnerabilities? The distro sure doesn't, distros typically just wait for CVEs.
And after a decade, the codebase is often diverged enough, that vulnerability researchers, looking at newer code, won't be helpful for older code. They're basically unique codebases at that point. Who's going through that unique codebase?
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. So one might ask, would you use software which is a security concern, let's say a http server or what not, if only 18 people in the world looked at the codebase? Used it?
And are around to find CVEs?
This is a problem with any rarely used software. Fewer hands on, means less chance of finding vulnerabilities. 15 year old LTS means all software is rare.
And even though software is rare, if an adversary finds out it is so, they can then play to their heart's content, looking for a vulnerability.
As someone who actively maintains old rhel, the development environment is something you can drag forward.
The biggest problem is fixing security flaws with patches that dont have 'simple' fixes. 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.
> 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.
On the other hand: dealing with 14.04 is practically cutting edge compared to stuff still using AIX and HPUX, which were outdated even 20 years ago lol
Well I look at it from the relativistic perspective. See, AIX or HPUX are frozen in time and there is no temptation whatsoever within those two environments.
Being stuck in Ubuntu 14.04 you can actually take a look out the window and see what you are missing by being stuck in the past. It hurts.
It's because they stopped development in the late 90s. Before Windows 95 (Chicago) came out, HP-UX with VUE was really cutting edge. IBM kinda screwed it up when they created CDE out of it though.
And besides the GUI, all unixes were way more cutting edge than anything windows except NT. Only when that went mainstream with XP it became serious.
I know your 20 year timeframe is after XP's release, but I just wanted to point out there was a time when the unixes were way ahead. You could even get common software like WP, Lotus 123 and even internet explorer and the consumer outlook (i forget the name) for them in the late 90s.
VUE was really "happy", clean. Sans-serif fonts. Cool colours. Funny design like a HP logo and on/off button on the dock.
IBM made it super suit and tie. Geriatric colour schemes with dark colours, formal serif fonts and anything cool removed.
Functionally it was the same (even two or three features were added) but it went from "designed for people" to "designed for business". Like everything that IBM got their hands on in those days (these days they make nothing of consequence anymore anyway, they're just a consulting firm).
It was really disappointing to me when we got the "upgrade". And HP was really dismissive of VUE because they wanted to protect their collaboration deal.
I think 10.30 was peak HP-UX. 11 and 11i were the decline.
When I'm writing new software, I kinda hate having to support old legacy stuff, because it makes my life harder, and means I cannot depend on new library or language features.
But that's not what happens here, this is probably mostly backporting security fixes to older version. I haven't done that to any meaningful amount, but why wouldn't you find a sense of purpose in it? And if you do, why wouldn't it be fun?
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?
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)
I'm wondering how the maintenance effort would be organised.
Would it be existing teams in the main functional areas (networking, file systems, user space tools, kernel, systemd &c) keeping the packages earmarked as 'legacy add-on' as they age out of the usual LTS, old LTS, oldold LTS and so on?
Or would it in fact be a special team so people spending most of their working week on the legacy add-on?
Does Canonical have teams that map to each release, tracking it down through the stages or do they have functional teams that work on streams of packages that age through?
IME (do note, the things I've dealt with were obsolete for a much shorter time), such work isn't particularly ugly even though the idea of it is. Some of it will feel like cheating because you just need to paraphrase a fix, some of it will be difficult because critical parts don't exist yet. Maybe you'll get to implement a tiny version of a new feature.
> Unless they found someone who really likes doing this kind of thing?
There are more people like that than one might think.
There's a sizable community of people who still play old video games. There are people who meticulously maintain 100 year old cars, restore 500 year old works of art, and find their passion in exploring 1000 year old buildings.
The HN front page still gets regular posts lamenting loss of the internet culture of the 80s and 90s, trying to bring back what they perceive as lost. I'm sure there are a number of bearded dudes who would commit themselves to keeping an old distro alive, just for the sake of not having to deal with systemd for example.
> I'm sure there are a number of bearded dudes who would commit themselves to keeping an old distro alive, just for the sake of not having to deal with systemd for example.
I don't think so: there are Debian forks that aspire to fight against the horrors of GNOME, systemd, Wayland and Rust, but they don't attract people to work on them.
> There's a sizable community of people who still play old video games.
I went to the effort of reverse engineering part of Rollercoaster Tycoon 3 to add a resizeable windowed mode and fix it's behaviour with high poll rate mice... It can definitely be interesting to make old games behave on newer platforms.
I'm now deploying all my projects in Incus container (LXC). My base system is upgradeable, ZFS-based, in future will be IncusOS but now just Ubuntu. Incus is connected in cluster so I can: backup/copy projects, move between machines etc.
Containers reuse host system's new kernel, while inside I get Ubuntu 22.04. I don't see a good reason, if 22.04 will get 15-year life support, to upgrade it much. It's a perfect combination for me, keeping the project on 22.04 essentially forever, as long as my 22.04 build-container can still build the new version.
Isn't Incus/LXD separate from and running on top of LXC?
People sometimes seem to use the names interchangeably which can be annoying because I run just plain LXC but when looking stuff up and come across "this is how you do XYZ on LXC" they are actually talking about LXD and it doesn't really apply.
I can't recall what is was last time, but this has happened a couple of times already...
It's a container with full os: systemd, journald, tailscale, ssh inside. No need to learn new docker world, just install the deb with your software inside
In a cluster mode, you can move container into another machine without downtime, back it up in full etc., also via one command.
In theory when using ZFS or btrfs you can do incremental backup of the snapshot (send the diff only), but I never tried it.
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?
LTS releases are great. I only use LTS releases on my servers. Problem is, if you need PCI compliance (credit card industry requirements, largely making no sense), some credit card processors will tell you to work with companies like SecureMetrics, who "audit" systems.
SecureMetrics will scan your system, find an "old" ssh version and flag you for non-compliance, even though your ssh was actually patched through LTS maintenance. You will then need to address all the vulnerabilities they think you have and provide "proof" that you are running a patched version (I've been asked for screenshots…).
That’s normal in any compliance process, and why you typically want to vet the vendor that does the compliance monitoring. And auditor (some auditors are really overzealous).
From what a quick google search told me, RHEL caps out at 13 years.[0] I'm curious what caused Canonical to offer 2 more years of lts support than Red Hat?
Nice, that means the latest Ubuntu LTS release (24.04) can be supported beyond the date of the Year 2038 Problem. Although theoretically now solved using 64-bit time_t, I wonder how robustly it’s been tested in real world deployments.
I've used Canonical's free 3-seat extended service mantainence (ESM) support on my one 14.04 LTS machine for a long time. It's so nice having a stable target for more than decade for my personal projects. I have so much software defined radio software that absolutely does break in ways I can't fix on a newer version of any Debian-alike. The ESM program has been a provider of peace of mind when still leaving that SDR machine connected to the internet and running javascript.
>30-day trial for enterprises. Always free for personal use.
>Free, personal subscription for 5 machines for you or any business you own
This "Pro" program also being free is a suprise to be sure, but a welcome one.
It doesn't seem unreasonable to me if you have the resources. If I could've paid Apple to somehow just support OS X 10.6 forever I'd probably still be a Mac/Hackintosh user lol
There’s at least one customer somewhere willing to pay $1 million for that.
Plus adding a general feeling of confidence to the product as a whole. And safety knowing that you can upgrade for an extra 5 years of support if you need it.
That is the last 2.7 patch from PSF. Other reputable organizations keep making new patch releases for as long as there are paying customers. Not just the big legacy distros.
Translation: Ubuntu has customers willing to pay up to avoid using the latest "oxidized" versions of Ubuntu, and for a decade an a half, at that. And this was in the works before Cloudflare's Rust-rewrite took down half the internet.
This is a good thing, despite my own concerns.
The major argument you get from "why are you using Windows 7" is exactly this, companies in infrastructure argue that they still get a supported operating system in return (despite the facts, despite EOL, despite reality of MS not patching actually, and just disclosing new vulnerabilities).
And currently there's a huge migration problem because Microsoft Windows 11 is a non-deterministic operating system, and you can't risk a core meltdown because of a popup ad in explorer.exe.
I have no idea why Microsoft is sleeping at the wheel so much, literally every big industry customer I've been at in Europe tells me the exact same thing, and almost all of them were Windows customers, and are now migrating to Debian because of those reasons.
(I'm proponent of Linux, but if I were a proponent of Windows I'd ask myself wtf Microsoft is doing for the last 10 years since Windows 7)
because Windows LTSC is still good
It's good while the software you run on it still supports that OS, for example the big one would be anything build upon Chromium (or electron) framework which deprecated win7 support when Microsoft ended ESU support (EOL +3 years).
The person having to maintain this must be in a world of hurt. Unless they found someone who really likes doing this kind of thing? Still, maintaining such an old codebase while the rest of the world moves on...ugh...
Maybe I'm the odd one out but I love doing stuff that has long term stability written all over it. In fact the IT world moving as fast as it does is one of my major frustrations. Professionally I have to keep up so I'm reading myself absolutely silly but it is getting to the point where I expect that one of these days I'll end up being surprised because a now 'well known technique' was completely unknown to me.
> I love doing stuff that has long term stability written all over it
I also love doing stuff that has long term stability written all over it. In my 20 year career of trying to do that through various roles, I've learnt that it comes with a number of prerequisites:
1. Minimising & controlling your dependencies. Ensuring code you own is stable long term is an entirely different task to ensuring upstream code continues to be available & functional. Pinning only goes sofar when it comes to CVEs.
2. Start from scratch. The effort to bring an inherited codebase that was explicitly not written with longevity in mind into line with your own standards may seem like a fun challenge, but it becomes less fun at a certain scale.
3. Scale. If you're doing anything in (1) & (2) to any extent, keep it small.
Absolutely none of the above is remotely applicable to a project like Ubuntu.
I agree. We are going as far as being asked to release our public app on self-hosted kube cluster in 9 months, with no kube experience and nobody with a CKA in a 2.5 person ops team. "Just do it it's easy" is the name of the game now, if you fail you're bad, if you offer stability and respect delivery dates you are out-fashioned, and the discussion comes back every week and every warning and concern is ignored.
I remember a long time ago one of our client was a bank, they had 2 datacenters with a LACP router, SPARC machines, Solaris, VxFS, Sybase, Java app. They survived 20 years with app, OS and hardware upgrades and 0 second of downtime. And I get lectured by a 3 years old developer that I should know better.
You're not adding new features and such like that. Just patching security vulnerabilities in a forked branch.
Sure, you won't get the niceties of modern developments, but at least you have access to all of the source code and a working development environment.
The unfortunate problem is that, the more popular software is, the more it gets looked at, its code worked on. But forked branches as they age, become less and less likely to get a look-at.
Imagine a piece of software that is on some LTS, but it's not that popular. Bash is going to be used extensively, but what about a library used by one package? And the package is used by 10k people worldwide?
Well, many of those people have moved on to a newer version of a distro. So now you're left with 18 people in the world, using 10 year old LTS, so who finds the security vulnerabilities? The distro sure doesn't, distros typically just wait for CVEs.
And after a decade, the codebase is often diverged enough, that vulnerability researchers, looking at newer code, won't be helpful for older code. They're basically unique codebases at that point. Who's going through that unique codebase?
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. So one might ask, would you use software which is a security concern, let's say a http server or what not, if only 18 people in the world looked at the codebase? Used it?
And are around to find CVEs?
This is a problem with any rarely used software. Fewer hands on, means less chance of finding vulnerabilities. 15 year old LTS means all software is rare.
And even though software is rare, if an adversary finds out it is so, they can then play to their heart's content, looking for a vulnerability.
As someone who actively maintains old rhel, the development environment is something you can drag forward.
The biggest problem is fixing security flaws with patches that dont have 'simple' fixes. 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.
> 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.
On the other hand: dealing with 14.04 is practically cutting edge compared to stuff still using AIX and HPUX, which were outdated even 20 years ago lol
Well I look at it from the relativistic perspective. See, AIX or HPUX are frozen in time and there is no temptation whatsoever within those two environments.
Being stuck in Ubuntu 14.04 you can actually take a look out the window and see what you are missing by being stuck in the past. It hurts.
It's because they stopped development in the late 90s. Before Windows 95 (Chicago) came out, HP-UX with VUE was really cutting edge. IBM kinda screwed it up when they created CDE out of it though.
And besides the GUI, all unixes were way more cutting edge than anything windows except NT. Only when that went mainstream with XP it became serious.
I know your 20 year timeframe is after XP's release, but I just wanted to point out there was a time when the unixes were way ahead. You could even get common software like WP, Lotus 123 and even internet explorer and the consumer outlook (i forget the name) for them in the late 90s.
> IBM kinda screwed it up when they created CDE out of it though.
Could you please elaborate?
VUE was really "happy", clean. Sans-serif fonts. Cool colours. Funny design like a HP logo and on/off button on the dock.
IBM made it super suit and tie. Geriatric colour schemes with dark colours, formal serif fonts and anything cool removed.
Functionally it was the same (even two or three features were added) but it went from "designed for people" to "designed for business". Like everything that IBM got their hands on in those days (these days they make nothing of consequence anymore anyway, they're just a consulting firm).
It was really disappointing to me when we got the "upgrade". And HP was really dismissive of VUE because they wanted to protect their collaboration deal.
I think 10.30 was peak HP-UX. 11 and 11i were the decline.
When I'm writing new software, I kinda hate having to support old legacy stuff, because it makes my life harder, and means I cannot depend on new library or language features.
But that's not what happens here, this is probably mostly backporting security fixes to older version. I haven't done that to any meaningful amount, but why wouldn't you find a sense of purpose in it? And if you do, why wouldn't it be fun?
Some people just want a job, they don’t wrap up their sense of self worth in it.
Nothing to do with self worth, it is a meaningful job, but a fun one?
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?
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)
I'm wondering how the maintenance effort would be organised.
Would it be existing teams in the main functional areas (networking, file systems, user space tools, kernel, systemd &c) keeping the packages earmarked as 'legacy add-on' as they age out of the usual LTS, old LTS, oldold LTS and so on?
Or would it in fact be a special team so people spending most of their working week on the legacy add-on?
Does Canonical have teams that map to each release, tracking it down through the stages or do they have functional teams that work on streams of packages that age through?
Most people I know don’t like chasing the latest framework that everyone will forget about in 6 months.
I guess they are betting that AI can semi-auto patch this distro for 15 years.
IME (do note, the things I've dealt with were obsolete for a much shorter time), such work isn't particularly ugly even though the idea of it is. Some of it will feel like cheating because you just need to paraphrase a fix, some of it will be difficult because critical parts don't exist yet. Maybe you'll get to implement a tiny version of a new feature.
> Unless they found someone who really likes doing this kind of thing?
There are more people like that than one might think.
There's a sizable community of people who still play old video games. There are people who meticulously maintain 100 year old cars, restore 500 year old works of art, and find their passion in exploring 1000 year old buildings.
The HN front page still gets regular posts lamenting loss of the internet culture of the 80s and 90s, trying to bring back what they perceive as lost. I'm sure there are a number of bearded dudes who would commit themselves to keeping an old distro alive, just for the sake of not having to deal with systemd for example.
> I'm sure there are a number of bearded dudes who would commit themselves to keeping an old distro alive, just for the sake of not having to deal with systemd for example.
I don't think so: there are Debian forks that aspire to fight against the horrors of GNOME, systemd, Wayland and Rust, but they don't attract people to work on them.
> There's a sizable community of people who still play old video games.
I went to the effort of reverse engineering part of Rollercoaster Tycoon 3 to add a resizeable windowed mode and fix it's behaviour with high poll rate mice... It can definitely be interesting to make old games behave on newer platforms.
Search YouTube for "gog noclip documentary", without quotes. Right up your alley.
I'm now deploying all my projects in Incus container (LXC). My base system is upgradeable, ZFS-based, in future will be IncusOS but now just Ubuntu. Incus is connected in cluster so I can: backup/copy projects, move between machines etc.
Containers reuse host system's new kernel, while inside I get Ubuntu 22.04. I don't see a good reason, if 22.04 will get 15-year life support, to upgrade it much. It's a perfect combination for me, keeping the project on 22.04 essentially forever, as long as my 22.04 build-container can still build the new version.
> I don't see a good reason [...] to upgrade it much
Imagine the world of pain when the time comes to upgrade the software to Ubuntu 37.04.
Isn't Incus/LXD separate from and running on top of LXC? People sometimes seem to use the names interchangeably which can be annoying because I run just plain LXC but when looking stuff up and come across "this is how you do XYZ on LXC" they are actually talking about LXD and it doesn't really apply. I can't recall what is was last time, but this has happened a couple of times already...
Maybe, I'm a noob for now. Meaning Incus, LXC being the underlying tech.
The 15 year support is paid not free.
Sell it to me! Why not docker?
It's a container with full os: systemd, journald, tailscale, ssh inside. No need to learn new docker world, just install the deb with your software inside
In a cluster mode, you can move container into another machine without downtime, back it up in full etc., also via one command.
In theory when using ZFS or btrfs you can do incremental backup of the snapshot (send the diff only), but I never tried it.
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?
LTS releases are great. I only use LTS releases on my servers. Problem is, if you need PCI compliance (credit card industry requirements, largely making no sense), some credit card processors will tell you to work with companies like SecureMetrics, who "audit" systems.
SecureMetrics will scan your system, find an "old" ssh version and flag you for non-compliance, even though your ssh was actually patched through LTS maintenance. You will then need to address all the vulnerabilities they think you have and provide "proof" that you are running a patched version (I've been asked for screenshots…).
_if_ you're using ubuntu,
there's the CVE tracker you can use to ~argue~ establish that the versions you're using either aren't affected or, have been patched.
https://ubuntu.com/security/cves
https://ubuntu.com/security/CVE-2023-28531
that said, we've also had the same auditor ask us to remove the openssh version upon telnet (which by RFC 4253, is not possible)
so ymmv
That’s normal in any compliance process, and why you typically want to vet the vendor that does the compliance monitoring. And auditor (some auditors are really overzealous).
Took us a while to find the right ones.
Nice.
Should be mandatory for home automation systems. Support must outlive the home warranty.
From what a quick google search told me, RHEL caps out at 13 years.[0] I'm curious what caused Canonical to offer 2 more years of lts support than Red Hat?
[0]https://access.redhat.com/support/policy/updates/errata
I know that there is still rhel6 customers in contract, that was 2010.
Nice, that means the latest Ubuntu LTS release (24.04) can be supported beyond the date of the Year 2038 Problem. Although theoretically now solved using 64-bit time_t, I wonder how robustly it’s been tested in real world deployments.
I've used Canonical's free 3-seat extended service mantainence (ESM) support on my one 14.04 LTS machine for a long time. It's so nice having a stable target for more than decade for my personal projects. I have so much software defined radio software that absolutely does break in ways I can't fix on a newer version of any Debian-alike. The ESM program has been a provider of peace of mind when still leaving that SDR machine connected to the internet and running javascript.
>30-day trial for enterprises. Always free for personal use. >Free, personal subscription for 5 machines for you or any business you own
This "Pro" program also being free is a suprise to be sure, but a welcome one.
Its unclear if this legacy patch will be free for personal use.
How many customers did this take? Wow...
It could just have been one with a very large check.
It doesn't seem unreasonable to me if you have the resources. If I could've paid Apple to somehow just support OS X 10.6 forever I'd probably still be a Mac/Hackintosh user lol
There’s at least one customer somewhere willing to pay $1 million for that.
Plus adding a general feeling of confidence to the product as a whole. And safety knowing that you can upgrade for an extra 5 years of support if you need it.
The level of confidence is pretty incredible. Coming from someone who got hurt by CentOS.
I don't understand your point, CentOS never had paying customers?
One of the dirty secrets is that you don't need to back up confidence to sell it if you don't plan to be around when it falls apart.
These kinds of demands are becoming more common in b2b software.
I wonder how much this legacy addon costs. Is it available to consumers?
This gives me a good sense of how old these versions are:
https://documentation.ubuntu.com/ubuntu-for-developers/refer...
14.04 LTS has Python 3.4 as well as Python 2.7.
The last patch for Python 2.7 was released in 2020 (https://www.python.org/downloads/release/python-2718/)
That is the last 2.7 patch from PSF. Other reputable organizations keep making new patch releases for as long as there are paying customers. Not just the big legacy distros.
E.g. https://github.com/ActiveState/cpython
There are others.
Translation: Ubuntu has customers willing to pay up to avoid using the latest "oxidized" versions of Ubuntu, and for a decade an a half, at that. And this was in the works before Cloudflare's Rust-rewrite took down half the internet.
What's the only HN user group that's more annoying than the Rust evangelical strike force: the anti-Rust butthurt crusade.