Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PHP 5 and 7.0 end of life

hackertarget.com

Post reply on HN
Print view View original

101–110 of 122 posts

Re: PHP 5 and 7.0 end of life

#101

Post by bovermyer »

Fogest wrote: post #55
bovermyer wrote: post #32

Earlier quoted context omitted.

PHP 5 has been deprecated for several years now. PHP 7.0 was released in 2015, almost five years ago. The current version is PHP 7.3. While upgrading from PHP 5.4 or lower to 7 can be... interesting, it's not all that difficult or time-consuming. PHP 5.5 or higher to 7 is much easier.

We personally struggle to just keep Ubuntu updated with LTS releases, let alone managing all the updates to ensure software works on the new packages installed on whatever LTS version. The issue is that when you have smaller companies with small web development departments you end up with a lot of differents sites/tools made over time. So now when it comes upgrade time you have a large pile of stuff that needs upgrad…

I get it. I'm a consultant, so I'm familiar with code bases that are a little...well-worn.

If the business decides the risk is acceptable, then that's fine. As an engineer, you're supposed to communicate and document the risks associated with technical decisions. After that, if your employer decides Technology X.Y is good enough, then accept it and move on. You made your case, and the business considered it and made a choice.

Re: PHP 5 and 7.0 end of life

#102

Post by Fogest »

bovermyer wrote: post #101
Fogest wrote: post #55

Earlier quoted context omitted.

We personally struggle to just keep Ubuntu updated with LTS releases, let alone managing all the updates to ensure software works on the new packages installed on whatever LTS version. The issue is that when you have smaller companies with small web development departments you end up with a lot of differents sites/tools made over time. So now when it comes upgrade time you have a large pile of stuff that needs upgrad…

I get it. I'm a consultant, so I'm familiar with code bases that are a little...well-worn. If the business decides the risk is acceptable, then that's fine . As an engineer, you're supposed to communicate and document the risks associated with technical decisions. After that, if your employer decides Technology X.Y is good enough, then accept it and move on. You made your case, and the business considered it and made…

The risks are usually known, the problem is more that it's a slow process to get everyone to update their stuff and have it ready for new versions of whatever languages and tools they are using.

Re: PHP 5 and 7.0 end of life

#103

Post by userbinator »

pbhjpbhj wrote: post #48
userbinator wrote: post #34

Earlier quoted context omitted.

Besides the "doesn't bother updating the passwords" point, this sort of "it's old so let's change it" attitude is unfortunately so pervasive in the software industry and I find it massively irritating because it's the same reason why a lot of software has gotten increasingly unstable over time. Instead of making only fixes and bringing a platform towards maturity they do the exact opposite, adding plenty of new bugs…

I'm well in to repairing and longevity, but that 80yo fridge is going to be inefficient and badly thermally insulated I imagine (and if it's electric it's probably hazardous too). Upgrading isn't just about shiny-shiny, and keeping old stuff isn't always best.

You'd be surprised how efficient they are; give this article a read:

https://www.greenbuildingadvisor.com/article/choosing-an-ene...

What most people consider "old" for a fridge is probably late 70s/early 80s, and those ones did use a lot of power for some reason or other (usually defrost heaters); but the ones much older than that used far less.

I'm restoring it, which does mean rewiring and putting better insulation in the cabinet, but other than that the refrigeration system itself is still original and sealed (that's why they can last almost indefinitely.) If anything, it would likely make it even more efficient.

Re: PHP 5 and 7.0 end of life

#104

Post by [deleted] »

Spivak wrote: post #92
tomxor wrote: post #73

Earlier quoted context omitted.

> My go-to version for production right now is PHP 7.2. I'm going to ignore all warnings about its EOL until 2028, when support for Ubuntu 18.04 runs out. I'm not sure you can just hide behind the LTS assurance of the OS, they can't guarantee every single package in their repos will remain safe. Plenty of packages in Ubuntu LTS releases reach EoL far far before OS EoL.

I mean 'guarantee' is a pretty strong word in the world of security. Better phrasing might be "is committed to backporting security fixes for the lifetime of the OS."

[deleted]

Re: PHP 5 and 7.0 end of life

#105

Post by tomxor »

kijin wrote: post #91
tomxor wrote: post #73

Earlier quoted context omitted.

> My go-to version for production right now is PHP 7.2. I'm going to ignore all warnings about its EOL until 2028, when support for Ubuntu 18.04 runs out. I'm not sure you can just hide behind the LTS assurance of the OS, they can't guarantee every single package in their repos will remain safe. Plenty of packages in Ubuntu LTS releases reach EoL far far before OS EoL.

True, but PHP tends to be looked after fairly well given its importance to the web ecosystem. Ubuntu for example has a pretty good track record of backporting PHP security fixes. PHP 7.0 in Ubuntu 16.04 has been getting updates every few weeks despite the EOL last winter, and I remember observing the same with PHP 5.5 in 14.04 until the OS itself reached EOL earlier this year. The fact that both Red Hat and Canonical…

Interesting, that's quite a lot of effort to keep the old versions safe.

I wonder if any of that work get up-streamed into the old versions for the benefit of other distros?

Re: PHP 5 and 7.0 end of life

#106

Post by kijin »

tomxor wrote: post #105
kijin wrote: post #91

Earlier quoted context omitted.

True, but PHP tends to be looked after fairly well given its importance to the web ecosystem. Ubuntu for example has a pretty good track record of backporting PHP security fixes. PHP 7.0 in Ubuntu 16.04 has been getting updates every few weeks despite the EOL last winter, and I remember observing the same with PHP 5.5 in 14.04 until the OS itself reached EOL earlier this year. The fact that both Red Hat and Canonical…

Interesting, that's quite a lot of effort to keep the old versions safe. I wonder if any of that work get up-streamed into the old versions for the benefit of other distros?

Ubuntu and CentOS are maintaining versions that upstream has already EOL'd, so there's no upstream to push patches to. Most other distros (hello, Fedora) have much shorter support cycles so they don't really need those patches, either. There might be some sharing between Ubuntu and Debian LTS.

The majority of patches still come from upstream. If a new vulnerability is found in PHP 7.1 or 7.2, chances are the same bug exists in 7.0. So the maintainers check if their versions are also vulnerable, and if so, backport the fixes. As time goes on and differences accumulate, patches from upstream will become less relevant. It looks like Red Hat largely gave up on maintaining PHP 5.3 in RHEL/CentOS 6 after about 7 years. We'll have to see how long they actually stand behind PHP in CentOS 7 and 8.

Re: PHP 5 and 7.0 end of life

#107

Post by rleigh »

johnchristopher wrote: post #96
k__ wrote: post #67

Earlier quoted context omitted.

lol, you had me until "dockerizing".

What do you mean ?

He's exactly the same as the other guy. Under the guise of modernisation, he's introducing even more technical debt and gratuitous overcomplexity.

Look at it this way. In 15 years time, that ancient docker setup may well be as insecure, unmaintainable and poorly-regarded as PHP5 is today. And another generation of admins and developers will repeat the cycle all over again with the new hotness of day.

Re: PHP 5 and 7.0 end of life

#108

Post by johnchristopher »

meritt wrote: post #68
johnchristopher wrote: post #6

Yeah, yeah. Go tell that to my 10x php self-taught guy who's still running php 5.4 on a windows server 2003 in a wamp installation. He upgraded the bundled mysql with mariadb last year by dropping the executable in the folder (edit: just checked out, and the drop-in has been reverted back to mysql 5.0 because the upgrade path is impossible because apache 2.2). And of course this in-house guru for anything that happen…

> I am in the process of dockerizing almost everything in sight How many other individuals in this clearly legacy organization have the knowledge and experience to take over your "superior" variant of technical debt once you get sick of the job and move to something trendier?

There are 12 people in the IT team of the main org with two admin supervisor. They run Kubernetes for the regional infrastructure. I am bringing the 10x engineer and his printer tech guy from our local org up to speed with the new stack (hypervisor + docker + some linux tools) and documenting how to manage it.

If they don't learn the soft way now they are going to learn the hard way later when the main org take away their admin privileges from their hands and restrict them to the php app.

The IT team is quite fed up with the incessant problems of this server (mail gateway got blacklisted for instance with the last incident). That server should have been retired but our resident guru has hit a mental roadblock regarding the migration.

I can't format the word enough so here it is with capital letters: DOCUMENTING.

> take over your "superior" variant of technical debt

Clearly the current server situation (one guy knows how to run it) is vastly superior to documenting it for others and not patching security holes is okay.

At least now we'll be able to shut down a particular service instead of shutting down the whole dept. next time that server hiccups.

Re: PHP 5 and 7.0 end of life

#109

Post by johnchristopher »

rleigh wrote: post #107
johnchristopher wrote: post #96

Earlier quoted context omitted.

What do you mean ?

He's exactly the same as the other guy. Under the guise of modernisation, he's introducing even more technical debt and gratuitous overcomplexity. Look at it this way. In 15 years time, that ancient docker setup may well be as insecure, unmaintainable and poorly-regarded as PHP5 is today. And another generation of admins and developers will repeat the cycle all over again with the new hotness of day.

> Look at it this way. In 15 years time, that ancient docker setup may well be as insecure, unmaintainable and poorly-regarded as PHP5 is today.

Surprise, surprise, when you don't maintain and update your stack it becomes unmaintainable and insecure. News at 11.

Why the heck are you implying that updating it now means we don't manage and update it for the next 15 years ?

What do you suggest, then ? Keep things as is ? I remind you that the thing is insecure as fuck and it becomes hard to add features or patch the app because it's running on an old version of apache/php/mysql.

Re: PHP 5 and 7.0 end of life

#110

Post by neurostimulant »

rleigh wrote: post #107
johnchristopher wrote: post #96

Earlier quoted context omitted.

What do you mean ?

He's exactly the same as the other guy. Under the guise of modernisation, he's introducing even more technical debt and gratuitous overcomplexity. Look at it this way. In 15 years time, that ancient docker setup may well be as insecure, unmaintainable and poorly-regarded as PHP5 is today. And another generation of admins and developers will repeat the cycle all over again with the new hotness of day.

Actually, php with docker is really nice and simpler compared to the old "install Apache/nginx to your server" method. Upgrading is easy, just pull new images and restart the containers. Horizontal scaling is also a lot easier using stuff like glusterfs as volume driver. It even easier if your app is modern and don't need ability to self-modify source code as you don't need fancy volume driver.

If you decide to drop dockerized setup in the future, I imagine it should be easy to do so as all you need is move the source code to the new host, is it not?

Post reply on HN