[Dylan16807]

> They have three concurrent LTS releases when they need one. Maybe two. 18.04 is the python2 of distributions. Let it go.

> Having worked in several places that relied on it... ESM is being the bad kind of enabler.

The business proposition is 10 years of support with minimal package changes. Are you asking them to just stop selling that product?

Fewer LTS releases wouldn't change that core question, since if they never had a 2018 LTS release those users would be on the 2016 release instead.

[bravetraveler]

I suppose I doubt the proposition of '10 year support' - admittedly I haven't done anyone else's job for them.

I don't know if that necessarily means stop selling the product... but tighten up the terms, I guess? Anyone choosing to stay on something that old has chosen those gremlins.

The build of systemd and firewalld on 18.04 are both categorically broken. I don't know whatever people are solving with that old release (and Canonical in support)... but it's less than what those two things do for me when working properly.

The illusion of support for something so decrepit creates more problems than it solves in my experience. Either bite the bullet and modernize/upgrade... or keep playing with the unsupported sands of time

[Dylan16807]

> The build of systemd and firewalld on 18.04 are both categorically broken.

Were they categorically broken back in 2018? What would you have recommended companies do around that time frame, if they wanted to use Ubuntu?

If it was acceptable at the time, then it's not a reason to rush off onto a new release where something else might be categorically broken. Even if it sucks, you already figured out how to deal with it during the first couple years you had it deployed.

If it was completely unacceptable at the time, then what do you do? You can't not have servers.

> something so decrepit

Most server code is not going to get very out of date over the course of several years. It's not significantly more decrepit than the day it was deployed.

Node.js code would be one of the things outside this "most". Though I don't know if those users would have had the distro version of node to begin with.

[bravetraveler]

> Were they categorically broken back in 2018? What would you have recommended companies do around that time frame, if they wanted to use Ubuntu?

They were and still are. The irony: the fix need not be breaking/demand a new major release.

> Most server code is not going to get very out of date over the course of several years. It's not significantly more decrepit than the day it was deployed.

That's my point. It was broken from the beginning.

Reminder: 'firewalld' is a management daemon for N firewalls. You use it exactly because you don't care about implementation details like the backend. It's not even part of the default Ubuntu install. Just offered.

Most users wouldn't see it, I don't judge that. I judge how Canonical behave{s,d}.

I would have recommended they, the integrator/procurer of the distribution, avoid the 'iptables' backend for 'firewalld'... a release or two before 18.04. Not even this one. It was well on the way out already/communicated/ignored.

If they wanted to fix it 'breaking upgrade' style, they had at least two chances. They could also avoid the rake-kickflip of the '--wait' option.

Final point being: I'm not here to do their work. A distribution is a collection of software. They chose to offer it, not me.

Just because I - the seasoned administrator can find/fix the problem - I shouldn't have to. I like a compelling experience too. This odd mixing isn't it.

I will fully admit to seeking out the problem in... asking to install firewalld. Not offering the packages at all, instead of poorly joined, would be an improvement. I'm not without options. I don't need poor ones.

To be clear: I'm not yelling into the void. This was reported to their bug tracker in at least 2019. I escalated it to them through $EMPLOYERS. Several. Canonical's support means jack to me.

"Vendor support" is largely a Bogeyman and compliance racket IMO. I've, outside this wild thread, otherwise moved on to nicer pastures!

[Dylan16807]

> That's my point. It was broken from the beginning.

They already put it into production though, so that's not very relevant to deciding when they move off of it.

You have a valid complaint, I just don't think it has much to do with service life.

[bravetraveler]

> They already put it into production though, so that's not very relevant to deciding when they move off of it.

It's one of those "if a tree falls in the woods" scenarios, though. It's not a default-install package.

People who selected it already dealt with it or keep running into it. Changing the backend won't even affect them; config edits are preserved.

To add (one final poor point): they're a tiny minority! This production is like... nothing.

Fixing it/changing course/introducing 'breakage' (a correction) is less adversarial than leaving it broken IMO.

There were several ways to approach this, some more user visible than others...

The 'proper' thing, changing the backend, would've been felt. Patching the errant argument use was also entirely an option. They even had several actual LTS' to do this in!

The 'service life', like the cake, is a lie. While we debate best practices - they fail to execute them!

I appreciate you putting up with my rambling though