PHP packages for Ubuntu EOL releases put under paywall | Hacker News Reader

PHP packages for Ubuntu EOL releases put under paywall

github.com

21 pointsbezout17 comments

I don't understand the post title. Ondřej does this in his free time, you're not entitled to his labor. LTS only lasts 5 years, you shouldn't be building out new systems on such an out of date OS. If your business processes depend on 18.04, then paid support makes sense.

No one is entitled to his labor. But they are entitled to complain about a dick move. After doing his labor, he's choosing to do extra labor (going out of his way to delete old packages) for the sole reason of preventing people from accessing the packages he already built and deployed previously. This would be like Python foundation deleting the download links for Python 2.7 from python.org, or npm unpublishing old packages. Why?

And FYI, not everyone has a need to stay on a supported distro. We don't all run public-facing web services. A system on a secure LAN could run for the next 200 years and it wouldn't matter that Canonical or PHP stopped releasing security updates.

Unless there's a size limit to his Launchpad repos I'm not aware of, he simply has no excuse other than being an arrogant authoritarian.

I'm totally onboard with not providing new packages for an EOL OS, but trying to memoryhole the old ones is horrific. Imagine if everything deleted itself the day it went EOL.

Throwaway for obvious reasons.

I can sympathise the maintainer thoughts but only up to a certain degree. In a perfect world we would all be able to plan and upgrade accordingly on time and without any hiccups but this is not always the case.

We've actually been bitten by this and scrambling to find a solution as we are still running Ubuntu 18.04 on AWS OpsWorks (this is actually EoL and will be shut down next year).

Migrations steps are being planned but we still need to retain some services until we are done. This PPA worked just fine a couple of days ago, so paying Freexian just for the time we need for completing the migration seems kind of a stretch, for lack of a better word.

Does anyone know where to find a mirror of this (or even .deb files)? We could self host it for our own internal use until the migration is complete.

Thank you.

Am I misreading this, or would you have to pay €250?

If so, why wouldn't you just pay?

I can see it being a question for the higher tiers where it's €10k or more.

We are actually considering to pay them but we still need to justify the expense and ask for approval to our finance team. It might take a while (both our side and probably theirs too).

Setting up a mirror would be trivial instead. I'm not asking by any means any support or time from him, even a ZIP file hosted on GitHub Releases (where bandwidth is "free") would've worked.

Paying the €250 is surely cheaper than any amount of you or your teams time to set up your own mirror of the old files? And would be done in a few minutes compared to multiple hours or days.

If you still have running instances you may be able to pull the packages from apt's cache in /var/cache/apt/archives/*.deb.

From there you could host your own private repo. I've used Aptly to do this easily.

Yeah, that was my original idea but that folder is actually empty on our instances.

Not sure why, my best guess is that Chef is automatically cleaning that up as a last step.

Same boat here. OpsWorks had been communciating with us that support for 20.04 was being worked on up until the entire service was EOL’d.

We have long had working builds for 20.04 but can’t run them on OpsWorks, and now we can’t build OpsWorks images.

This will get interesting. Any idea what service you’re transitioning to?

There's actually a guide for migrating to SSM Application Manager but I'm not a fan of that (or Chef at all anyway): https://docs.aws.amazon.com/opsworks/latest/userguide/migrat...

We're just working on containerizing everything and then migrate to ECS or EKS.

I think the only way to get some people to notice an EOL is to actually make a system stop working.

This is so ingrained that I've actually heard of project managers having specific post-shutdown plans to transition users who only then notice that something happened.

This is pretty much how it's always been, LTS gets 5 years of support, then after it goes EOL you can pay Canonical for backported security updates to important packages.

What I'm not clear on is the relationship(s) between:

* Canonical's LTS lifecycle/extended support scheme,

* the linked deb.sury.org repository,

* and https://www.freexian.com/lts/php/

It sounds like deb.sury.org is voluntarily halting _their_ PHP packaging for the EOL Ubuntu release, and recommending this alternative vendor Freexian instead (why not recommend Canonical ESM, do they not do PHP?)

The claim being that "it's not possible to build the packages any more" but I'm not sure why this would be, necessarily. More a technicality because the upstream distro will be gone/paywalled so a downstream PPA can't reasonably provide support? But then how is the other vendor doing it?

(Looking closer, Freexian's PHP packager appears to be the same guy running deb.sury.org so while it _is_ turtles all the way down, none of this seems unreasonable to me)

Canonical proudly advertises that your system is vulnerable but can be patched with a subscription. They overly monetize insecurity, a user-hostile dark pattern. Ubuntu is best avoided entirely because of their insane, unreasonable leadership.

Bad title

Yeah the title reeks of editorializing to ride the coattails of the rhel drama.

This is just the already known EOL policy acting as expected.

No it's not editorialized. When something goes EOL, you're not supposed to delete the existing packages to force people to pay for new ones, as this guy did.

If people could still access the already-released free packages, then you'd have a point.

Reply on news.ycombinator.com