WTF Ubuntu?

They're totally asleep at the wheel, it's malpractice. The pitch for RHEL is highly competent maintenance you can't get elsewhere

I believe RHEL/Alma/Rocky has released patches today. I have a notice about they have done so.

Yeah, their lack of a satisfactory response is the final nail in their coffin. This incident escalates my consulting advice about Ubuntu from “not recommended” to “switch immediately”.

Some of my clients may be surprised by this change, as I once advocated for Ubuntu as a good choice for a development and deployment platform. While that has not been true for quite a while, they have now jumped the shark into eel-infested waters; I cannot take them seriously any longer.

The more I look at this the angrier I get. This is a CVE that Anthropic claims can get a Remote Code Execution on vulnerable systems, which includes default Ubuntu installs running any sort of Go server like Caddy. Bad enough that I shut down my personal website and self-hosted tools (sorry for any typos, my grammar checker is also down).

And this is how Ubuntu describes the vulnerability to sysadmins:

  In the Linux kernel, the following vulnerability has been resolved:
  ipv4: free inet_opt and ireq_opt after an RCU grace period
  tcp_v4_syn_recv_sock() transfers ownership of ireq->ireq_opt to the
  child socket (newinet->inet_opt) without copying it.
  Another cpu can concurrently process a retransmitted SYN for the same
  request socket, and send a SYNACK from tcp_check_req().
  tcp_v4_send_synack() and inet_csk_route_req() read ireq->ireq_opt
  under rcu_read_lock() only, and ip_build_and_send_pkt() and
  ip_options_build() then read opt->optlen twice.
  Note that the SYNACK timer itself is not an issue: it holds a
  reference on its request socket, and inet_csk_reqsk_queue_drop()
  calls timer_delete_sync() before the child can be freed.
  Since commit 079096f103fa (“tcp/dccp: install syn_recv requests
  into ehash table”), request sockets are processed without holding
  the listener lock, so nothing prevents the child socket from being
  freed while the SYNACK is still being built. TCP child sockets do
  not have SOCK_RCU_FREE, and inet_sock_destruct() frees inet_opt
  with a plain kfree(), leading to a use-after-free in
  ip_options_build().
  A similar issue exists with request socket migration
  (net.ipv4.tcp_migrate_req=1, or a BPF_SK_REUSEPORT_SELECT_OR_MIGRATE
  program). reqsk_timer_handler() clones the request socket with
  inet_reqsk_clone(), so that the old request socket and its clone
  share the same ireq_opt, then reqsk_migrate_reset() clears the
  pointer in the old one. Another cpu holding a reference on the old
  request socket can still be using these options (sending a SYNACK,
  or creating a child in tcp_v4_syn_recv_sock()) when the clone is
  freed, and tcp_v4_reqsk_destructor() also uses a plain kfree().
  Readers already use RCU, and other paths replacing inet_opt
  (do_ip_setsockopt(), cipso_v4_sock_setattr()...) already use
  kfree_rcu(). Use kfree_rcu() in inet_sock_destruct() and
  tcp_v4_reqsk_destructor() as well.
  IPv6 is not affected by the first issue, because tcp_v6_syn_recv_sock()
  duplicates the options. tcp_v6_reqsk_destructor() has the same
  migration issue with ipv6_opt, which is only set by CALIPSO. This
  will be addressed in a separate patch.

How is this in any way, shape, or form acceptable two weeks after the CVE was published?

Is RHEL really unpatched still? Looks like patches came yesterday: https://access.redhat.com/security/cve/cve-2026-98432

I use NixOS btw

Moved to Debian few years back and never looked back. We used Ubuntu for a bunch of clients and unfortunately had to let them know they will have to migrate to Debian or similar. It's such a shame because I really used to love Ubuntu until Canonical started turning slowly into your typical everyday corporate.

As far as I know the only working exploit is working on machine with MultiTCP enabled. Redhat also downgraded the issue to "high" and also did not release a patch yet. I would have preferred a patch but I accept that they know better than me what they are doing.

I don't think this is fair. They don't do a good job of pointing you at their rationale which is in their security score here[0]. I ultimately had to have claude translate the kernelese in to something my small brain could understand but this is a bug that could crash your system but is unlikely to expose your confidential system data to attackers or degrade data on the system. Especially given that the exploit can only be done if packets with IP options. IP options are commonly dropped or removed from packets on the open web. You not only need a vulnerable system but a vulnerable request path through the internet which you would only know by trying this attack which is very timing dependent with the SYN,Retransmitted SYN and Reset all happening very close together. A motivated attacker could probably do this on your network but over the internet ... It sounds unlikely.

[0]https://ubuntu.com/security/CVE-2026-98432#impact-score

> I already had a bad feeling the first time I saw "Get more security updates through Ubuntu Pro" on `apt upgrade`

To be clear, Ubuntu Pro doesn't have the fix yet either, in case anyone's confused.

> I already had a bad feeling the first time I saw "Get more security updates through Ubuntu Pro" on `apt upgrade`, this is now the kick I needed to move to a different distro.

To be clear, Ubuntu Pro doesn't have the fix yet either.

https://news.ycombinator.com/item?id=50337869

Your comment should be higher. Most indignant comments here are variants of "Tell me you don't know about CVE triage and Linux kernel releases without telling me you don't know about them". I mean, I also don't know a lot about them, but Canonical's security record has been exemplary in my experience, and I see no solid reason to doubt their process in this instance.

First, if this CVE did truly put every Ubuntu machine on the Internet at risk, we'd know about mass compromises by now, and there haven't been any reports. It means the CVE is not trivially exploited.

Second, the gravity of the CVE dictates the security release cycle. Emergency kernel patches carry risks of their own, and it would be worse to hurry a non-critical patch and crash a part of their massive user base.

Edit: I've been enjoying this comment going up and then into the negatives, what a roller coaster.

> You can pull them down with a "-t" added to your apt-get (but will not appear by default).

How does that look like exactly?

I'm not seeing CVE-2026-98432 included in the changelog for any of the new kernels on the 28th.

It has severe regressions like https://bugs.launchpad.net/ubuntu/+source/linux-oracle/+bug/...

> The post gives no details about what this vulnerability is, how critical it is, how it is impacting them personally, how vulnerable their servers are, how they are working around it.

Yes it does? And Ubuntu is selling security subscriptions and doing a poor job of it, These aren't open source volunteers, this is a paid product.

>The post gives no details about what this vulnerability is, how critical it is

what? the literal first paragraph says:

"In case you missed it: CVE-2026-98432 is a critical (CVSS 9.8) bug in the Linux kernel's TCP code. It's been there since 2016, so virtually every Linux server on the planet has it, and it can be hit remotely"

But Ubuntu is not some small distro maintained by unpaid volunteers; they are a corporation that offers paid support. I think it reasonable to be disconcerted when a company that you are paying for security updates is this negligent, especially when other distros have fixed this issue far more expediently.

But Ubuntu is not the embodiment of "open source". It's a business. With managers...

The post is making 0 demands, they're made a valid statement and moving off Ubuntu.

> This “I demand to speak to the manager” energy should be kept out of open source.

This. You are welcome to publish patches and demonstrate how people can fix their own machines out of band with what Ubuntu does. This costs you... 10 minutes with AI help?

While it's easier than ever to complain this year, I'm patching all the things while on a walk or not at my computer, it's great!

Welcome to the world of tomorrow

It's a large international corporation with hundreds of millions in revenue from enterprise contracts. There is in fact a manager to speak to and I do in fact demand to speak to them.

Very helpful information, thanks!

This is a major failure on Ubuntus part. The constructive feedback they deserve is literally the title of the article.

The post gives enough detail, there is a vulnerability that allows root access on servers on the TCP stack, so literally accessible if you are running any service. There are exploits in the wild. Debian has the patched kernel, Ubuntu does not 2 weeks after the CVE is known.

> how critical it is,

9.8 out of 10 btw.

> how it is impacting them personally,

They are clearly rather upset by the lack of an appropriate response.

> how vulnerable their servers are,

They are literally open to anyone with an AI subscription.

> how they are working around it.

They are migrating off Ubuntu.

> at least be constructive about it

I think the proposed solution here is pretty clear. Patch the bug.

With Open Source / Free Software we're trying an alternate economic model, shooting to overtake the standard model. We rely on volunteers. It creates an awkward situation where we can't be unappreciative of effort (no matter the quality of output), but we also have to have expectations or this model is just not going to work.

So we should respectfully expect better than this. (With the caveat that Canonical is a business. I'm using Ubuntu Pro for free so I won't be berating them, but I think I paying customers perhaps should be.)

I also think that we should consider a sort of an "SLA" concept. If you say "I got you covered" and you drop the ball, I think I do have a grievance in that I could have chosen another option, and now I have to take the time to adjust. On the other hand sometimes people don't actually say "I got you covered" they say "This is a cool thing I'm working on". So something like an "SLA" could clear that up.

I believe you will have a ton of factual page about that. The purpose of this one is exactly what you criticise: rage. With a small error of margin a justified rage. I believe this was the reason it was chosen for submission: to show the rage.

> The post gives no details about what this vulnerability is

It is a very famous vulnerability that has been all over tech news sites. Sometimes it is ok to assume the audience has the slightest bit of background knowledge about the topic at hand.

The whole point of paying for Ubuntu enterprise services is you don't have to worry about all this nonsense. It's one thing if you're using Ubuntu for free, it's another thing when you're paying them for a specific service.

> It’s okay to have criticism, but at least be constructive about it.

Nah, if you're dropping the ball after you said you wouldn't and I trusted that, I'm going to get angry and loud when you drop the ball. That's just reality, and Ubuntu isn't some Johnny-come-lately volunteer organization. They're one of the most well-funded Linux organizations in the world.

I had the same question about the actual exploit on another thread: https://news.ycombinator.com/item?id=50319143

It’s only recently I realised that a lot of these very clever vulnerabilities are often not actually exploitable, except in quite specific conditions.

As the days pass the probability of it being actually used is increasing. The EPSS score is clearly just an estimate, and according to the nist cve database, attack complexity is low so I would take the EPSS score with a grain of salt.

This really needs to be hot fixed and just fast tracked to release. It’s for sure costing Canonical’s image and makes it difficult to continue to consider Ubuntu for serious server deployments going forward.

Why are the relevant packages not available in the main or even security repos?

Three weeks is plenty of time.

The fix is available in the -proposed pocket for users who perform their own kernel acceptance tests. Under our unified two-week kernel SRU cycle, in the first week we build and smoke-test kernels and publish them to -proposed. In the second week we run certification and regression tests on Ubuntu Certified hardware. Once that testing completes, the kernels are released to the -updates and -security pockets. We keep this step to avoid regressions, and we think it’s the right balance between speed and reliability.

If you had to manage what has become critical infrastructure around the globe using something like Launchpad, you'd understand.

It's not optional.

CVSS in general is not the best proxy for "real world impact". You could have a 10 on a software thats only deployed once and the impact would be tiny. In this case, multipath is not used that much (except by go).

If someone does a v2 let's hope they make sure it's actually exploitable when they set it up so they don't leave hundreds of people with the assumption that the cve is not a big deal when the CTF was just misconfigured and the system got pwned in less than 2 hrs after they fixed it

I think it's less of a concern over the internet because the kind of packet necessary for the exploit tends to be filtered out, but it's pretty scary as an escalation mechanism from e.g. an end-user device to a core server.

Much like with PHP2Shell, it doesn't need to be utterly trivially exploitable to be a big concern.

I think the official CTF is up here:

https://ubuntu.com/security

server: nginx/1.14.0 (Ubuntu)

Contrast this with: "The Gift of It's Your Problem Now"

We keep doing this to ourselves. Heads should roll at Ubuntu. Start that process right now? You can't. You see, nobody is directly available to sue. It does seem that nobody ever truly cared about that. The insecure codebase and tech debt shall continue to grow because that is the gift.

https://apenwarr.ca/log/20211229-the-gift-of-its-your-proble...

Yeah that literally is in "does not compute" territory for me. That page literally opens with "Ubuntu priority High [..] 9.8 · Critical [..] Publication date 15 October 2026 [..] Last updated 30 October 2026" which is exactly why "WTF Ubuntu" is the right response here.

> Rocky Linux 10

Does Rocky use their own community-built packages, or does it use RHEL's?

Because I don't think Red Hat have released patches yet either?

14.04 LTS trusty is not vulnerable fyi.

I don't quite understand this page. I thought the kernel binary was in the `linux-image-` packages in Ubuntu.

For example, I have linux-image-generic installed, description "Generic Linux kernel image This package will always depend on the latest generic kernel image available." and then "Depends: linux-image-6.8.0-147-generic, linux-modules-extra-6.8.0-147-generic, linux-firmware, intel-microcode, amd64-microcode"

Why isn't there linux-image or linux-modules-* listed as an affected package?

First I thought it was the source package / binary package distinction, but e.g. linux-image-7.0.0-38-generic says "Source: linux-signed-hwe-7.0", and linux-signed-hwe-7.0 isn't listed as an affected package either.

So what's going on here?

Have a look at the bug page for jammy

https://bugs.launchpad.net/kernel-sru-workflow/+bug/2171802

It seems to have passed everything but testing?

They could use better communication, but if they arent happy with testing a kernel update for something that hasnt been exploited in the wild a few more days making sure its not going to brick a bunch of servers is probably a good thing.

Why Rocky and not Alma?

Because that doesn't allow for sensationalizing the frustration.

Because you shouldn't have to do mitigations for this level of severity while waiting weeks for OS patch. I did that, but now I'm waiting for patch to unwind my mitigations.

Talking of which, is there a link to the temporary fix?

Why do you ask such simple and obvious questions!? :-P

nft add table ip cve_2026_98432

nft add chain ip cve_2026_98432 pre '{ type filter hook prerouting priority -300; }'

nft add rule ip cve_2026_98432 pre meta l4proto tcp ip hdrlength gt 5 counter drop

This is what I want more information on, especially before we start pitchforking ubuntu or whoever

I think they shipped patches yesterday. Which is still a long wait.

https://access.redhat.com/security/cve/cve-2026-98432

maybe this was the plan all along.

maybe they also use 8 stages and several months for their security fix process. Just to be sure... ;)

It was bad in 2015. I have watched people leave and come back though, which says something.

I wish I could work at Canonical. Unfortunately my high school math scores were too low.

Which makes it more people actually working on Ubuntu than most other distros.

It's the default for my VPS provider

I would need to reinstall OS on my laptop and deal with all time-consuming migration stuff for everything that changed and to configure Debian where it is doing weird things

> What is Ubuntu offering that Debian doesn't provide?

I have it right now at zero additional effort

1. Faster and predictable release cadence. New releases every six months, April and October (hence x.04 and x.10). New LTS releases every April on even years (26.04, 28.04, 30.04, etc).

2. The LTS releases are supported by Canonical for at least five years on the free tier, and up to fifteen years with paid support contracts.

I think it's just brand, ubuntu was what I knew from using it as a personal desktop and then it's the default/most obvious option for a lot of providers, I think even 10+ years ago AWS EC2 defaulted to it above Debian, digital ocean too I think?

I don't remember why exactly but it was definitely just 'linux VPS = Ubuntu' for a long time. I think they got reputation as being the 'just works' option because they were happier to include some non-free graphics drivers etc where Debian was the more pure option but most end users didn't care

But since they added snap and I started running into issues with trying to install Docker etc a few years ago I default to Debian now and most of the time I don't even know which it is.

Inertia, I'm guessing. I have a couple of older on-prem servers still on Ubuntu LTS. Newer ones are on Debian stable.

Ubuntu is a Debian distribution that releases more often. A faster update cycle for their packages is basically their entire reason for existing.

I may be biased as a Debian user, but if Ubuntu now reacts slower than Debian this may push some people to reconsider their choice.

Their kernel is vastly superior when dealing with buggy enterprise hardware.

They have more kernels, more support for modern hardware etc... good luck running Debian on a modern laptop.

Ubuntu kernels are not the one that Debian uses. The latest stable Debian is based on a 2 years old Kernel ( 6.12 ).

For me it's just because I've been using Ubuntu full time since 2008 and has served me well my entire career, I think it's fair to say it's the flagship desktop OS that introduced many to Linux.

I feel like we're close to a post-distro era of operating systems though. My ansible playbook customizes so much already it wouldn't take too much more to just start from debian tbh.

How is the gaming experience on Debian? I'm genuinely asking, not a snark.

I use desktop Ubuntu because it's up to date and it just works for me, and I can play the latest games in it with Steam + Proton. I don't have to tweak it or do any additional downloading of stuff besides the Nvidia drivers (I actually don't remember how I installed them).

Can I do this with Debian, in a no fuss way? (I know this can be done in any distro, that's why I'm stressing "no fuss").

On the desktop, Debian is pretty weak.

> What is Ubuntu offering that Debian doesn't provide?

I'm on an nvidia jetson which comes out of the box with Ubuntu pre-installed (it's slightly more complicated but that's the gist). You can run other OSes but it is a messy experience and you can easily run into problems.

Yes, it is shitty from nvidia that they do it this way. But it is also convenient.

It's the default that a bunch of vendors package. For example, Nvidia's official CUDA images used to only be provided for Ubuntu (they have since expanded their offerings somewhat)

The traditional answer is that Debian is a bit slower-moving in both the Linux kernel and userland, so people who want current versions of popular software often find that they have to do some extra work in Debian.

A gradually increasing number of popular userland applications have been publishing their own apt repositories however so this is less of a problem now than it used to be.

Over the years though I've found that I much prefer Debian's relative stability and more thoughtful, if slightly plodding, release cadence.

Just that it’s already installed, and I haven’t tried a new distro in over a decade.

But 15-20 years ago it was easier to install the nonfree stuff on ubuntu, like drivers and DVD playback and stuff. I don’t know if its still like that.

I never understood ubuntu as a server over debian, but for a desktop it was a nicer experience for a while.

For desktop use, new-ish user-facing packages without any hoops (such as backports) jumped. Especially where collaboration is involved it can be a major issue when a program lags behind its commercial OS counterparts by several months or years in terms of features and behavior.

I don’t use Ubuntu but use Fedora (and its derivatives) partially for that reason.

Back when I used Ubuntu it was because I was tired of being excited about a new feature and not getting to use it until it made its way to Debian 5 years later.

Ubuntu is the gateway drug to Debian, in a lot of ways. You get used to GNU/Linux with Ubuntu, then you find out that there are more refined options and go for those, and a not-insignificant part of that crowd likely goes to Debian because of how familiar it is.

Ubuntu has a timeline for how long they will provide updates for a given long term distribution release. I moved over to Ubuntu back when CentOS was converted in to a Fedora type release without a long term commitment to providing security fixes.

I might be moving over to Rocky Linux 10.

For me, habit. A habit I'm getting tempted to break by exactly the grumble in this post. This has been an awful ~two weeks for maintaining infrastructure and the ubuntu lag on this specific issue is contributing to the awfulness.

ROS, which is not officially supported on Debian. Not using it myself, but users here do use it.

Debian's ancient packages and kernel.

"Ubuntu" is an ancient African word meaning "I can't configure Debian."

> What is Ubuntu offering that Debian doesn't provide?

Surprised how many answers here are on "social" reasons, and ignoring that Ubuntu does provide genuine additions to Debian.

Ubuntu includes additional proprietary drivers to Debian. So there are legitimate hardware cases were Ubuntu will work out the box and Debian won't. I can't speak for how many people need those drivers, and how much of choice is down to defaults/inertia etc.

From hearing interviews with PopOS folk, I think this is also a big reason people choose Ubuntu as a base for a lot of Distros instead of Debian.

They test run a little more tests on their backports (and have the manpower to actually look into what is failing) and they have really far out EoL once the kernel release is selected at fixed intervals. So if you managed to get the capabilities that you care about in their tests, there is a low probability that applying updates will cause some catastrophic outage or data loss over the next 10 years. Which can be improved further by fine-tuning phased update rollouts.

Unfortunately, they did in recent history manage to still break iptables, zfs, nilfs and a bunch of machines with weird (arguably broken) firmware anyway, so my personal comparison between Debian (or simply directly the Kroah-Hartman/Levin stable upstream) and the Ubuntu backports is not exactly in favor of Ubuntu.

I use it as default for WSL2, because it's a default

AFAIK with Debian you remain on older versions of packages (unless you are on Debian testing).

Increased safety with Rust utilities. /s

Suppose you are an enterprise paying large amount of money to NVidia to buy their AI hardware to run AI workloads locally. Are you going to say we will refuse the default OS (https://docs.nvidia.com/dgx/dgx-os-7-user-guide/introduction...) on such hardware and lose hardware support, or are you going to stick with the supported OS for your hardware?

Enterprises care far more about vendor support than the typical Linux hacker at home.

ZFS.

I have a company laptop that came with Ubuntu from the factory, Debian wasn’t an option.

much newer software, kernel, default setup is much more user friendly

At my company, it’s the pateena of “enterprise”. I came to th company with strong open source bias. The more traditional/conservative IT guys were all about Microsoft and RedHat. When I lobbied hard for some Debian assets, Canonical was the compromise. But I think we’re real close now to seeing the next round of allocations be straight Debian.

Proprietary drivers, desktop first experience similar to how Mandrake used to be, or SuSE, and the most relevant, in regards to proprietary software on Linux distributions, it tends to be either Ubuntu or Red-Hat.

Debian doesn't have any of the Ubuntu Pro features, e. g. Kernel live patching.

If your infrastructure doesn't use landscape, kernel hot patching, JuJu or similar Canonical technology, or doesn't have its own Snap storefront, there's no need to install Ubuntu. Rest is just momentum.

Debian used to move a bit slow in terms of userspace, and that's true, but for servers, that's a non-issue for the last 20 years or so (from my experience).

On the Desktop side, Fedora and Ubuntu moves faster on the userspace front, but if your system is behind a NAT, and you know what you're doing, Debian Testing is just as good, more stable and it's rolling (except when it's feature freeze, but a stable workhorse is better than a shiny but breaking one).

Debian allows me to sleep well at night, provides guaranteed updates, and works rock solid all-round, so I won't be touching Ubuntu for the foreseeable future. Esp, with controversial choices like uutils, etc.

I find major version upgrades a lot more reliable on Ubuntu. Every time I've done that on Debian something big broke.

Because every where you used to go on the internet you read that debian is “slow” on updates but stable as a trade off, if you are after certain new packages you have to use Ubuntu, also, some use cases (say jetson boards) have ubuntu by default plus nvidia drivers.

Consumer-centric customizations and non-free package options. It’s somewhat akin to answering “How can I add stuff like OneDrive to Linux and not have to configure/self-host everything?”

I used to like Ubuntu and Canonical products and these days I’m more indifferent towards them. Their products have a place, but I wish Canonical would stop killing off some of the more interesting side projects.

I used Debian on my machines (after I got past their ideological view on drivers and found I could get them separately and made it work) ... until a patch came out and WiFi was broken on my machines. I went back to Ubuntu, have not had issues like that. Ubuntu works reliably, from my experience, on real world machines.

Ubuntu did what Debian failed at. Better LTS, More features including drivers, available by default by most providers, lot more branding/documentation and in the early days, easier distribution. I am old enough to remember distro like SuSe Linux etc and when Ubuntu came on scene, it became the de facto.

It’s the default offered by most cloud providers, so in some sense it’s pure inertia.

I really don’t care what I run on, as long as it’s some flavour of Linux, it works reliably, and it’s secure.

Desktop Ubuntu purely because of the drivers. Normally used Debian for my own servers, but haven't done that in so long, and Ubuntu is often default on cloud providers so yeah.

It's just the default target. For backend stuff, you're right that there's really very little true value. But client software just has a lot of complexity. If you run binaries from wherever, they're probably built and tested on Ubuntu first. Like, your vendors won't support distros officially, install scripts and AppImage integrations are going to tend to assume stuff. Driver/runtime integration for things like binary GPU stacks are going to document Ubuntu first. If someone makes an assumption about Python version (a personal peeve -- LOTS of python software ends up lagging the tip, it's not a super compatible ecosystem), it's going to be that you're running Ubuntu LTS version "one before latest", etc...

Are those fatal flaws? No. But lots of people just don't want to deal with it. And there's a market for that.

"Ubuntu" is an ancient Swahili word meaning "I can't install Debian".

Mostly:

1. Hardware generally just works

2. Videos that use patented formats just play without fiddling

3. Proprietary closed-source software, if they even support Linux, usually releases Ubuntu binaries before anything else

Ubuntu offers a path from free use to paid first party support. For me, that makes it very attractive for a startup or small business that may want to add a support contract later. Ubuntu makes it a lot easier than Red Hat. Paid support for Debian is via third parties. Ubuntu is a solid distro, although I think Debian is a better one if paid support isn't an important feature to have.

Speaking as somebody who stayed on it way too long (until 10 years ago, maybe) it was because people constantly told me scare stories about how difficult it was to configure into something usable.

I had to go through the torturous path of Ubuntu -> Mint -> Mint Debian -> Debian. The last step was after I used a Debian live disk to do something and I could see that the stories were nonsense; just something that had adhered to the word Debian in my mind through repetition.

The two worst parts about it were 1) that I had long left Ubuntu on servers and had been using Debian there for years - I was just afraid of the desktop for some reason, and 2) that if I had just listened 15-20 years ago when people told me that FrankenDebians were nothing but problems, I would have never been caught in the net.

I've never been a fan of Ubuntu's business practices, but I'm just generally not into Debian derivatives anymore. If I were to leave Debian, it would be for an entirely different (and philosophically different) distro. I probably make an exception for Devuan, because it's only trying to change one thing (that I think of as the biggest threat to Linux, the final boss evil spawn of RedHat.) Devuan is an escape hatch for when the rugpull happens.

For some reason I had feeling that Ubuntu more "serious" than Debian. I mean they're asking for money from people. So it's basically Debian with paid services. Can't be worse than Debian and probably is better, maybe they paid some engineer with these money to patch things faster.

That's just some rough reasoning in my head.

Also when you install third-party software, 100% of them will support Ubuntu. That's more about workstation usage, though. But having tested platform matters.

Paid support. Doesn't look like it's worth it, though.

Historically, Debian didn't ship proprietary wireless firmware in the installer (because it was proprietary software, and Debian doesn't do proprietary), so you couldn't install it on most laptops without plugging them into wired Ethernet to download the wireless firmware packages from non-free.

They changed that a few years ago, but plausibly the underlying prioritization of end-user experience is still lower than Ubuntu's degree of user focus.

I still wish Mark would rename his company "Ubuntu". He's a great guy, the company does great work, but I keep getting undeserved credit for it because we wouldn't sell him the domain name.

Enterprise support contracts for Linux and the compliance legal liability. No large commercial companies would run purely contributor supported systems because of the lack of those two things.

Back in the day in 2008, Linux was niché.

It had issues all the time, and finding solutions required searching online, manually. Time consuming, difficult process. Very un-beginner-friendly.

From the throve of all possible distros, one stood out. Ubuntu. Very popular. Askubuntu Forums (with coffee beans denoting ranks) was the place when, 9/10 times, the answer to your problem could be found.

So when your fedora friend cried trying to get his camera and sound working, you either found the solutions already, or asked for them and got them. Usually the former.

That was the biggest advantage of Ubuntu. Big community and wealth of troubleshooting knowledge already available. And it had the opinion of a beginner friendly system. Which made the community grow and created a large market/userbase for help threads/tutorials.

Add to that, that people are creatures of habit and 'voila - you have a lot of people sticking to Ubuntu just because they never got so pissed at them that they would change their distro.

More recent packages

For me, it's not so much "what does Ubuntu have that Debian doesn't" and more that "just use Ubuntu" has only bitten me twice.

It's 2009 or so and I want to try Linux. "Just try Ubuntu" they say, and I have a good time. I see that many "How to use X on Linux" guides, or FOSS software, often build for only Debian, and sometimes only Ubuntu. This is fine until snaps give me huge problems in 2018, and so I completely stop using Ubuntu desktop.

Now in 2026, I manage three servers (two on Ubuntu), one Raspberry Pi (on Ubuntu), and two Linux desktop installations. I stopped using Ubuntu desktop in 2018 but snaps are less problematic for my server workflows, so now I have three Ubuntu server installs. On my desktops and my one non-Ubuntu server, I find myself sometimes missing Ubuntuland. (These aren't Debian though, so I might just be missing Debianland.)

"Just use Ubuntu" is now something that has bitten me in using servers. Two bites in 17 years is a fantastic track record. But this slow response to a CVE fix has me looking at Debian, and this has shaken my faith in canonical. "Do they pull in upstream security fixes quickly" is one of my first questions for any FOSS I use.

But my servers aren't Nix or IaC or whatever, and so... Taking them down and putting them up would take a lot of time and risk, which are two things I'm not so willing to spend. Maybe it's 10 minutes, or maybe there's a bandaid fix I have from 2023 that I forgot about and would need an hour to re-derive. So, I find myself taking the security gamble instead.

Software, such as AMD Vivado, tends to support Ubuntu more than Debian by testing against Ubuntu only. Nvidia's Jetson stack supports Ubuntu.

Please suggest a better alternative for a cloud server? (Genuine question, where do I move?)

Debian by default has had ancient versions of stuff, and if you want third party software, Ubuntu has more mindshare so it was more likely to be tested - anything from graphics card drivers to Steam games.

They probably don't know Mint was based on Kubuntu. Or that they all - like DSL, Knoppix and others are all based on Debian and if you're brave, you can pivot to Sid from each of them.

When I worked at Canonical, the funnel I observed was Gamer Culture and the Chronically Online. They don't know from Debian.

All my servers were debian until I brought some Raspberry Pi 5 boards. Debian still does not have tested images for them today.

[for clarity, I am not talking about servers]

When a non-technical person asks me “which Linux?” I recommend Ubuntu because it is about as gentle an experience as Linux is going to be. The install is friendly and the culture is less RTFM than anything else.

Those are the same reasons I run Ubuntu on my laptops that aren’t running Windows…I prefer low friction to arguable technical superiority. I’ve looked at other distros in the past and decided they weren’t worth the bother…To Me.

But that’s me, not you or anyone else. And my use case not yours or someone else’s.

I'm not a Linux user, but occasionally self-host some stuff. One time I tried Debian instead of Ubuntu, it was a lot of "this is not installed" & "this is not set up" errors during setup process of software I wanted. In the end I succeeded in doing what I wanted, but I also wasted time on doing things I never have to do when using Ubuntu.

FIPS mode? It's a pretty niche requirement, but I was under the impression that options are somewhat limited for FIPS-compliant crypto (both disk and networking)?

>What is keeping people on Ubuntu instead of just using Debian?

1. It uses much newer packages and people want shiny

2. It was marketed as one of the easiest to use linux distributions maybe 15yr ago or whatever, so a lot of new people and then tutorials went to it because newer software and features just worked.

3. What is keeping them on it now? Familiarity. Inertia.

Familiarity. Many Ubuntu people(who were introduced to Linux via Ubuntu) never change horses. I am speaking about IT people not common folks.

You and I know Debian isn't much different, they don't know cuz some never investigated. I say some because they landed in a role with a company that is Ubuntu and never had reason to learn anything else.

Install Ubuntu and you get 10-15 years of support of your current software stack.

Install Debian and you get 3-5 years of support.

Ubuntu also invests a lot into their desktop experience while Debian is closer to stock Gnome. That's more of a preference thing, though.

Debian has also traditionally been a pain to use with proprietary software. Nvidia drivers, WiFi firmware, you name it. It got better in the past years but it's hard to shake the bad name.

In my case, I started using Ubuntu like 10 years ago because the desktop experience was much more polished.

For example, the fonts and the font rendering in Ubuntu and its derivatives were noticeably better than on stock Debian/Arch/etc.

MySQL. You can make a totally valid argument that sites should just switch to Maria DB instead, but there's also no doubt that dropping MySQL support from Debian cost it a lot of LAMP servers. That, combined with Debian's release cadence which made it difficult to run numerous PHP apps basically pushed LAMP servers to Ubuntu.

Approx. two years ago I saw a teacher at my IT school trying to install Debian on a students virtual machine, side by side to a Windows 11. Just for fun, while watching them, I installed Ubuntu side by side on my virtual machine. These two were not done after three sessions and ultimately failed to install Debian. The installation GUI was full of cryptic words I never heard of and looked like from the year 2000. Meanwhile, the Ubuntu installation went flawless. it was done in under 15 minutes, the GUI looked modern and sexy. All I had to do was enter a nick and password, and drag a slider to tell the procedure how much space I want to reserve for Ubuntu.

I hope that answers your question.

    ¯\_(ツ)_/¯

I only run Debian personally, but my dayjob company runs on SQL Server, and the officially supported options there are Windows Server, Ubuntu, or RHEL. It's not worth the effort dealing with management/auditors/etc. to try to run our prod DB on a non-supported platform.

Ubuntu's remote OS upgrade feature exists and works pretty well in practice. I am not saying this is enough to stay but it does exist.

For servers, livepatch, latest ZFS and ZFS-on-root supported ootb, faster release cadence

For desktops, gaming and commercial software support, "it just works" (my fresh install of 26.04 with Wayland, recent WiFi, HDR+VRR, i didn't have to fuss with anything)

For laptops, I've routinely had issues in the past where Fedora or Mint wouldn't work ootb when Ubuntu did.

And then since it's what I'm used to on my server and my desktop, i just use it on my Pis and WSL installs for consistency.

I still try out other distros occasionally and i do run Debian on some specific VMs for various things, but I've just had relatively few issues with Ubuntu, been using it for >10 years, and don't see any reason to switch.

I always assumed the software is newer. You can update to a LTS more often, if your server needs that. For example, I think podman adoption is hampered by Debian's slow release cycle. Trixie finally supports quadlets.

Debian often ends up as Frankendebian, or with custom repos added. How do you run e.g. Nextcloud on Debian? Where do you get the new php version required for the upgrade from? Right, there is a community repo somewhere...

> Why anyone would prefer Ubuntu over Debian, which is a purer, higher quality, more mature distro, is beyond me.

For me, I view Ubuntu as the "higher quality, more mature distro" which I value over "purity".

Revision: It seems like catching the race condition is not that hard, but the root exploit is very unlikely. But still, the fact we haven't seen lots of services going down indicates to me that this is overblown.

> Also, `dnf` is simpler and more stable than the mess of `apt-get` and `unattended-upgrades`.

I'm not saying you're wrong. I am saying that this is a new sentiment I've never heard expressed before. Perhaps Ubuntu's done something to make it flaky, but the upstream Debian apt tooling is famously stable and boring. I'm saying this very seriously: I don't recall a single time, ever, in about 30 years of using Debian-and-friends, that I've ever been bitten by a bug in apt-get or apt. I have also never been hit with a dependency bug when I wasn't using dodgy third-party package sources. In the many situations where I've deployed pure Debian (or pure Ubuntu) servers, `apt update && apt upgrade` has worked 100% of the time.

I do not claim that no one's had problems with this. The world's large. I'm certain there are people out there who have nothing but trouble with apt and friends. I do claim that I've never personally seen that our been in a conversation with people who have.

I have one Ubuntu Pro server and it has not received the fix yet. Fedora would have been preferable but that is "not supported" and I had to have Ubuntu.

I think this is the important question. To everyone who is complaining while using Ubuntu for free: People whose software you use for free don't owe you anything.

Nope

I don't like ads, and I didn't like logging into SSH and seeing a nag to update to Ubuntu Pro because I had the balls to keep running 20.04 in 2023. I've seen this before on previous releases (and know how to remove the message), but seeing it again was the straw the broke the camel's back.

AlmaLinux is "boring" in the best possible way, and it works really well in WSL too. Their extended support for x86-64 v2 has also been useful on one my old computers.

+1, switched to Debian with 13 since it got plasma 6 earlier. Much better experience- no snaps, gnu utils, stable. It's everything I want from the OS.

Substantially worse in my experience. They build the whole OS in CI which is slow and unreliable, and as a result it can take 2+ days for updates that other distros have out in under an hour. You can try mix packages from smash or unstable builds but for stuff like kernels that’s not simple.

Yes, NixOS has already patched this.

NixOS also makes it much easier than ubuntu to install your own patches and version of the linux kernel.

For example, assuming NixOS had not yet released the fixed linux version, 6.18.56 (though it has), you could upgrade to it before NixOS did it upstream with this one line:

    boot.kernelPackages = pkgs.linuxPackagesFor (pkgs.linux_6_18.override {argsOverride = {src = pkgs.fetchurl {url = "mirror://kernel/linux/kernel/v6.x/linux-6.18.56.tar.xz"; }; version = "6.18.56"; modDirVersion = "6.18.56";};});

You could add the patch yourself if you needed to with:

    boot.kernelPatches = [{ patch = ./cve-patch.patch; }];

And then you'd be updated.

The debian and redhat based distros all make it so configuring what packages are installed ('apt install' / 'yum install') is a different operation from configuring the packages themselves.

On NixOS, the specification of how to build a package, what package is installed, patches, etc are all in the same language, and so it's a lot more natural to patch things as needed.

And also, LLMs are pretty good at generating working nix, so you can have an agent apply patches to your kernel package with NixOS quite easily. Agents can also do this for ubuntu or redhat, but in my experience they're much worse at it, and it's harder to undo mistakes if they mess up.

(~10 years NixOS user, and committer.)

It depends.

Mostly on how much rebuilding it needs (e.g. if it's a "leaf" package, or one many packages depend on).

The merging of security fixes is usually very good, also because it is so easy for anyone to just make a PR.

The security team also seems pretty competent and fast.

As a sibling commenter says, it is also extremely easy to just apply patches to your own system in general, usually with a few line of easy code max. So you can fix systems without dependence on distro maintainers.

In contrast to e.g. patching a `.deb`, you can declare the code such that the patch will still be used even if the distro releases a new package; you can carry the patch forward, and don't need to choose between {not having the patch because the distro lacks it} and {not having future security fixes because you pinned your custom .deb version}. NixOS will rebuild any future update, applying your patch to it. That's a big benefit, because it makes "out-of-tree" custom patches very maintainable.

Due to declarativeness, you can easily roll out your fix on lots of machines.

Also, the "SBOM" (software bill of materials) part is quite good in NixOS. It's very easy to determine which package uses what dependencies.

The only real drawback is CI build time when a high-dependency package needs fixing.

Due to the way Nix works with its immutable hash DAG of package dependencies, a package change will trigger a full rebuild of all packages that recursively depend on it.

For example, if you change 1 line in glibc, or libpng, or curl, or (recently) brotli, the entire distro needs to be recompiled from source ("rebuild the world"). Some of the packages, such as Chromium, can take many hours to rebuild individually. Rebuilding all-of-NixOS can take days.

In distros that can mutate packages without triggering dependency rebuilds, updating 1 line in e.g. glibc, will only rebuild that package, allowing to theoretically distribute such security updates within minutes (if done, see Ubuntu counter-example).

The mass-rebuilding is done by NixOS's binary-cache build farm. A new NixOS update is generally only released once the build farm has fully built all dependents. (One can also opt into a "small" channel that releases as soon as only a few core packages are built, which gives you security updates faster for those. But if you do that, your computer will next start compile all huge packages such as Chromium, in parallel to the NixOS build farm already doing that. So usually people don't.)

For the recent brotli CVE-2026-111497, the timline was:

    2026-10-21       node.js releases its fix for node2shell (caused by brotli)
    2026-10-21 19:27 https://github.com/google/brotli/releases#release-v1.2.1
    2026-10-22       brotli CVE-2026-111497 gets published
    2026-10-22 06:51 PR "brotli 1.2.1" https://github.com/NixOS/nixpkgs/pull/577208
    2026-10-22 08:25 PR merged to "staging" that will become rolling "nixos-unstable" in the future
    2026-10-23       created https://tracker.security.nixos.org/suggestions/by-id/60353
    2026-10-23       created https://github.com/nixos/nixpkgs/issues/577796
    2026-10-28       CI has built a nixos-26.05 update that includes it:
                     https://hydra.nixos.org/build/351243680
                     This is the point where users can install it.
    2026-11-02       CI for rolling-release nixos-unstable is still not built, 2 weeks later:
                     https://github.com/NixOS/nixpkgs/pull/577208#issuecomment-6573335016

So in summary:

    The PR got made within 7 h
    Review and merge happened within 2 h
    CI took additional 6 days for stable NixOS 26.05
    CI for rolling nixos-unstable is still not finished after 10 days post-merge

For our startup, I rebuilt the slice of the world we use on a 16-core CPU within a day or so, without waiting on the NixOS build farm to build all of NixOS, so we got the update significantly faster.

Also note that just patching a library in your distro is often not enough. For brotli, lots of upstream package vendor brotli's code. NixOS contributors seem to be quite good at looking at underlying issues, e.g. there's this issue "Tracking vendored Brotli decoders" (https://github.com/NixOS/nixpkgs/issues/578375) to track that. I am not aware of other distros making such efforts.

Thus:

In NixOS, security updates are great and fast for leaf packages such as the kernel, but can be slow for many-dependents packages. Much of that can be mitigated by building things yourself, which is easy.

Hope this helps.

Good question... I run ubuntu on servers because the LTS has clear 5 years of security fix.

I use arch linux for my NAS because it's fun and I don't care if it occasionally goes down but I wouldn't use it for production (on my NAS it's mostly stable but has gone down a few times)

So what's next? Centos is a rolling upgrade, nixos?

As always, it depends on how and what you're managing on it.

VPS/VM? Debian is a great choice. Use it as base and run your software via systemd+podman if you want the most up to date stuff, Debian tends do lag a bit. It is very low maintenance.

Bare metal? Fedora Atomic is awesome. It does require an update every other week since it keeps packages closer to upstreams, but this is where the immutable base shines, any issue is an easy reboot to revert. Also systemd+podman for your own software.

I wouldn't recommend Arch on servers.

Edit: clarified Fedora immutable spins are called Fedora Atomic.

Debian stable of course.

After painful Ubuntu upgrades in the past, I moved to Alma Linux and have been very happy. It takes a small adjustment to dnf instead of apt, but realistically I was over that hump in 30 to 60 minutes and this was before AI. With AI to translate and test install scripts and the like, it might be a 5 minute task depending on how much automation you already have in place. Though even an entirely un-automated setup that is just a README.md, claude wrote me an Alma Linux version of a very ubuntu specific project that gave instructions for Alma instead of Ubuntu, and it worked almost perfectly first time and AI was able to (with prompting) see the issue and quickly found a workaround. We're a small org, but at some point when we hit scale and have compliance requirements, a migration to RHEL is also largely trivial if/when the time comes.

I like Alpine but I’m not a serious person.

I use Arch for servers too, for almost a decade, and to my memory only once I had an issue. That was booting off an encrypted RAID and some change which needed some investigation and then reconfiguring. I am planning to run them servers on Arch for as long as I can. It’s a bliss to never upgrade my system (only update it).

This is like switching from a bicycle to a TARDIS. With all the upsides and downsides.

I keep Snap disabled on my systems:

cat /etc/apt/preferences.d/nosnap.pref

Package: snapd Pin: release a=* Pin-Priority: -10

There are a lot of Ubuntu boxen in production out there. It is basically the default for Linux VMs in Azure, the UX sort of pushes you that way unless you have a particular preference otherwise. I do have a preference, for Debian which I've used at home for many years, but in DayJob Unbuntu is close enough and seems to make others more comfortable (in part due to the impression some have that it is better supported in Azure). I'm surprised MS aren't nagging Ubuntu to pull their finger out for this reason (maybe that are, behind the scenes, but if so it isn't working).

This is misinformation.

The Anthropic PoC used MPTCP, but the underlying bug does not need MPTCP to be enabled.

Canonical isn't a publicly traded company

It’s been nearly two weeks, a bit more than “a few days”

Why use Rocky or Alma when you can use openSUSE?

Don't expect closed source to protect you. LLMs are very happy to analyse binaries and decompile functions you need. It's barely harder to deal with software you don't have the source for. I did both security and reveng work with LLMs and they don't slow down.

All other Linux distros have the same gpu drivers.

And you can have an ubuntu userland setup and any package necessary to run cuda in mere seconds on any linux distro thanks to toolbox and distrobox.

That's not what's happening here though. The haven't provided any patches for pro subscribers either!

Pretty much every OS I can think of has had one of these vulnerabilities. Microsoft had a bad one not so long ago that affected IPv6 packets, not even at TCP level. Dedicated RTOS packages that run Mars rovers have had network-level code execution exploits.

Network routing is complex enough from a management point of view, doing it fast and safely is very hard. Formal verification sounds nice, but the network stack is more than a dumb pipe.

For bugs like this, I hope the addition of Rust to the kernel will lessen the UAF vectors, but I'm sure it'll be years before that happens. The binder folks did a safe rewrite and encountered downstream companies hooking kernel tracepoints for state determination, I can't even begin to guess what they'll do to the network stack and how that'll affect adoption.

I'm not too surprised, it feels more like a way to help promote Anthropic than what it tries to appear to be.

It's really not that easy - for a human - to write a weaponized exploit for a bug like that one.

To pre-empt any replies: yes, I absolutely prefer BSDs over Linux any day. But even those are flawed and I really think we missed the Symbolics golden era. THAT would be the age of "own and live in the system". OpenBSD gets closest there. At least the codebase is hackable enough.

Linux went off the fucking rails. What the fuck is that over engineered yes command?!

Edit: https://github.com/coreutils/coreutils/blob/master/src/yes.c

270 loc for a tool that prints "y" in a loop. WTF?!

Meanwhile this exists: https://github.com/openbsd/src/blob/master/usr.bin/yes/yes.c

Slackware is a cool distribution. I really love that it's maintained by Patrick and I enjoy the simplicity and the stubbornness of it's opinionated decisions.

I stopped using it back in 2004 when Patrick had health problems. It seems to be a passion project and it stopped getting updates while he recovered. There is a community behind it but it may mainly be driven forward by him.

It looks like it's fairly slow to get updates, generally, as the last release was Slackware 15 in 2022. Maybe that reflects it's dictator (his word not mine) or maybe it reflects it's stability.

Yet, despite all that, Slackware got this security fix around 10 days ago.

That is with the implicit assumption that the mptcp exploit of this ipv4 tcp bug is the only exploit that will be found. I don't think that assumption will hold true.

Ubuntu is a for profit product by a commercial company, Canonical.

People are paying money for Ubuntu, though. I suppose if only the free versions were unpatched we could consider the ethics and merits of who is allowed to complain about what, but when the paying customers are also being left out in the cold I don't think your argument has much merit.

Plus snap & Amazon

It's the first commit listed in the 7.2.10 changelog. The CVE number isn't mentioned in the commit message, but you can verify that this is the fix by cross-referencing the CVE announcement.

https://cdn.kernel.org/pub/linux/kernel/v7.x/ChangeLog-7.2.1...

https://git.kernel.org/pub/scm/linux/security/vulns.git/plai...

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux...

Go programs listening on TCP have multipath enabled.

the best answer to this is... why not?

It was like that when I got here. The servers at my work were all Ubuntu, so that's what I keep using. And if the servers are Ubuntu, I'll use that on my machine too.

or maybe, just maybe, entertain for a second that upstream (linux kernel) shipped the original patch commit on October 1st with rollout to mainline on October 9th and disclosure on October 15th.

People with affected systems have been waiting ever since for canonical to ship ... something, anything. Or maybe communicate the blockers. Crickets, though.

It gets all the more egregious if you're a paying customer for Ubuntu Pro (which thank god, our company is not).

It is absolutely taking the proberbial piss when you put it into context of their bold shiny new ambitions posted on September 23rd on their official blog (https://canonical.com/blog/accelerating-delivery-of-cve-fixe...) ... failing every single listed requirement in that announcement, now 14+ days, after initial CVE disclosure.

No need for a tin-foil hat here at all. Ubuntu has a large installbase. Part of which hosts servers. And if I had to take a wild guess that userbase is about to shrink dramatically going forward.

Why are you lying so much?

>no snap nonsense where you can't turn off upgrades

You can disable AND uninstall snap entirely. You can also disable automatic update of the specific snaps you have installed.

>stays close to upstream LTS kernels

Same as Ubuntu, which uses 7.3 on its latest release as of today.

>does not carry around some ridiculous kernel patch set

Custom kernel patches for hardware compatibility is a very good thing, and why Ubuntu works on a lot of machines compared to other distros.

>no irritating adware on login

There is not a single ad on login, and even after. You are an ugly liar.

Having to get the client into call just so they go and click authorisation for adding some signing keys on VMs (as it was in pre-boot stage) just to add some driver wasn't fun

What an awful system

> Everyone is just using Ubuntu for free of charge for the most part. You get what you pay for.

That ignores those paying for Ubuntu Pro. They are not getting what they paid for.

You get what you pay for? Honestly this is so very disrespectful of the work thousands of people have and continue to put into Free Software including all Linux distros (Ubuntu too) as well as other operating systems and software. Really really disrespectful.

Probably Debian.

Meanwhile, Debian lol

"If you're not paying, you're the product-" hey jerks, the analogy doesn't always work

<animation of DHH in a race car driving bits and bytes to Linux machines>

Arch patched the vulnerability, yes. Dotfiles don't change that.

The obvious difference is that version N-1 has a known vulnerability that could potentially be exploited, and everyone now knows about it.

Probably right next to your reading glasses, my dude.

Maybe grab those first, though.

This doesn't work in practice. That's not really how OSS works; it's a naive interpretation. I can go into details if you'd like, but first: Have you taken this approach before? What were the results? I find it usually ends up in discussions/arguments with the owners, and it doesn't get merged. And I see the other side too; reviewing PRs is a burden, and the submitters often will fix their own problem, while introducing complexity or problems elsewhere. Also, it's generally MUCH easier for a maintainer/owner to update software than a rando who wants a bug fixed.

Their main point is that Canonical do in fact charge for security updates (they charge some companies for support), and yet are not providing them.

Getting commit rights for kernel to "just fix the issue" in a corporate led dev project.

Let's see you do it.

Two weeks late is hardly “enterprise level”

If they don’t have the resources to handle this, they should be recruiting more help from their community

> "The free operating system that I use is not giving me enterprise level security updates"

Canonical absolutely is marketing enterprise security updates (at least for those who pay). I don't see this in the paid ESM updates channel yet either?

The most famous not-free-as-in-beer OS that specifically marks enterprise as their target market actually only fixed this yesterday... whatever you may want to take from that.

Ubuntu is one of the larger companies in the OS space and advertises themselves as providing long term support with rapid security fixes. AFAIK they haven't released a fix for their paying customers either. If they were complaning about arch or debian then I think you would have a strong point, when those distros have fast fixes but ubuntu doesn't I'm not so sure they that criticism of ubuntu is unwarranted.

(Also, ubuntu already has the fix. What they're dragging their feet on is releasing the updated version. I don't think anyone outside ubuntu can help with that process)

> The free operating system

Ubuntu Pro is $500 per machine for enterprise.

Canonical ltd is a multinational tech company with hundreds of millions of dollars in revenue from enterprise contracts

From the article:

> Oh and btw, distros run by volunteers (Debian, Arch, Alpine...) hve shipped the fix. Meanwhile Ubuntu, made by a company that sells security subscriptions, hasn't. This is true as of 2026-11-02 14:48 UTC.

No updates for paying users of Ubuntu Pro either

Ubuntu is not a small open source project ran by maintainers, Canonical is a full fledged b2b company with 600+ employees.

The code that fixes the issue has already been published: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

Just not picked up by this distribution which advertises itself as having “Enterprise-grade support and integration”. https://ubuntu.com/desktop#:~:text=Enterprise%2Dgrade%20supp...