PHP 8.0 End of Life Is Today, November 26, 2023 (sysadminafterdark.com) 40
Slashdot reader sysadminafterdark writes:
Released on November 26, 2020, PHP 8 brought many optimizations and powerful features to the language.Fast forward to today, and PHP 8 is getting the boot in favor of 8.1, 8.2, and 8.3 with 8.4 in development. This leaves some websites at risk of breaking and potential security issues. Hearing of this news, I upgraded my own blog and wrote an article on how to add the Remi repository and update. I run Enterprise Linux (The best distro out there) so if you are standing up new boxes, just keep in mind the PHP in the repo is deprecated.
Well, that's not exactly right (Score:5, Informative)
"... so if you are standing up new boxes, just keep in mind the PHP in the repo is deprecated."
Most enterprise Linux distributions backport any security fixes to the version of PHP they settled on at launch*. So no, you probably don't need to worry about the fact that your Linux distribution still installs PHP 8.0.
That's pretty much the whole point of an enterprise Linux - it gives companies a stable target platform they can count on being maintained for several years.
* This is true of any package included in the distro, not just PHP.
Re: (Score:1)
Indeed. Replacing your system-provided and patched/backported packages, with those from some random project isn't a move up in terms of security. And then there's all the fun random compatibility issues and breakages it'll inevitably bring. This article is just terrible advice.
Re: Well, that's not exactly right (Score:4, Informative)
Remi's repo is essentially the "official" source of PHP for RHEL-based distros. Pretty much no one uses RH's, and Remi is the one everyone uses. I'm pretty sure Remi works for RH, but he supports modern PHP in his free time.
Re: (Score:2)
LOL! java 1.8. released in 2014 still receives updates. Some people like it the hard way I guess, namely with Python and PHP /s
End of Public Updates (Free)
April 2019 for Oracle
July 2026 for Amazon Corretto[11]
November 2026 for Eclipse Temurin[12]
November 2026 for Red Hat[7]
December 2030 for Azul[9]
End of Extended Support (Paid)
December 2030 for Oracle
Re: (Score:2)
I have my doubts many people other than hobbyists actually do this.
If I wanted to support a non-default version of PHP, Python, etc. on RHEL 8 or above, I'd do it the official way - using Application Streams [redhat.com].
Just speaking for myself, obviously, but - the only time I've added an external / unofficial repo is when I've needed software that RHEL doesn't offer *at all*. Shibboleth, for instance.
Re: Well, that's not exactly right (Score:2)
The number of hobbyists using RHEL-based distros is probably pretty small. Hobbyists tend towards Deb-based systems or more exotic distros like Arch.
You could be correct that RH customers rarely use third party repos, but most boxes running RHEL-based distros (like CentOS of yesteryear) are probably not RH customers.
Re: (Score:1)
Pretty much no one uses RH's, and Remi is the one everyone uses.
That is factually and demonstrably incorrect.
Please stop making general statements about things where you only have anecdotal knowledge.
Re: Well, that's not exactly right (Score:2)
As someone with 20 years experience in PHP shops and a moderate disgust for using third party repos, my anecdotes far outway your AC shit-posting response.
Re:Well, that's not exactly right (Score:4, Insightful)
"... so if you are standing up new boxes, just keep in mind the PHP in the repo is deprecated."
The main point of that statement was scare tactics. Developers hate seeing older versions of their code in use. Much less supporting it. Even if the "support" only amounts to repeating the phrase "complain on your distro's bug tracker." So regardless of whether or not you run an Enterprise Linux distro, Developers try to push their bleeding edge on everyone using any means necessary.
Side Note:
"Deprecated" should be a dirty word in software development. It means the developers failed to consider future developments / maintainability when writing the code originally, and are absolutely refusing to provide backwards compatibility to end-users who have become dependent on said code. To put it another way, Declaring something "deprecated" is a public admission that you've failed as a software developer, and should be sufficient cause for self-reflection and improvement. Not something to be used on a regular basis as an excuse for laziness post release.
Re: (Score:2)
Your post explains well why I fking hate it.
Famous abusers:
_Python
_Chrome
_Windows
etc...
All have sinned and fall short of His glory (Score:2)
Everybody has failed as a software developer. Software maintenance is the art of managing inevitable human imperfection. This includes giving adequate notice that the team will remove footguns, or features that had been making the language and/or its standard library worse by their very presence.
Re: (Score:2)
Totally. Even PHP 7.4 will continue to be semi-supported (at least security patches) on most "server" distros at least through 2024, even though the PHP devs stopped officially supporting it already. Upgrading for the sake of upgrading is never a good practice, though it's never good to be left high and dry either...
Re:Well, that's not exactly right (Score:4, Interesting)
I host some vm for those, a reverse proxy with mod_security properly (custom) configured for those apps is a must to mitigate risk as much as possible! I even have some vms running PHP 5.6.40-58+0~20220614.65+debian9~1.gbpc40f11 (cli) with developers having vanished since a long time and customers not wanting to pay to upgrade it.
PHP is a pain to upgrade from version to version while I still run some apps developed for java 1.0 with recent versions of java. Cake PHP framework used to have a class named "String" then, php implemented a class named "String" in later versions screwing Cake up. Namespace anybody?
mydomain.myproject.String vs java.lang.String
Is name space finally implemented in php? Seriously asking...
Re: (Score:3)
Migrating PHP versions isn't *that* bad... If you're lucky enough to have not used stuff that gets changed... I have code I've carried all the way from 3 to 8. There were a lot of gotchas: basic behaviors that changed. Insane things like changing parameter order for built-ins and syntax changes for working with arrays(!) Most of the changes have been "good" in terms of making the language less bad, but no fun if you have to maintain (really) old code.
PHP has had "namespaces" since 5.3, though I've never
Re: (Score:2)
Thanks!
Walking on thin ince (Score:3)
The amount of work you had to put in is probably okay for a hobby project or an open source library. However, for real business code, this is unacceptable.
Really, the developers of PHP are making it difficult to make this language attractive for long-term stable development. Nobody at 'PHP headquarters' is going to give any guarantuee that even a minor update from 8.0 to 8.1 won't break things. They put the burden of checking & modifying your code, with every version update, on you, the developer. On al
Re: (Score:3)
I agree that PHP (still) sucks, but the alternative is to completely rewrite legacy PHP applications in another language, which isn't practical, especially for time-tested, reasonably well-written code. It's (much) easier to keep on top of breaking changes in the language than it is to start from scratch, especially when dealing with only a few thousand lines of (more or less) modular code, since starting from scratch is going to create a lot more bugs than renaming/rearranging a few function calls. Most o
Re: (Score:2)
Though to be fair, when I look at the landscape of "popular" languages today, I'm not sure I'd want to use any of them. I'd probably want to use Perl 5.
I'm right with you on that. The problem is, though, it's getting rather hard to find web developers who are both familiar with modern web practice/design and also have even a modicum of perl knowledge.
I'm running into this issue right now, actually. So now I'm looking at people who know something else (typically PHP, since the expression syntax is rather similar) and seem savvy enough where I think they can develop a passable knowledge of perl - even if it's just to rewrite stuff into their preferred langua
Re: (Score:2)
I host some vm for those, a reverse proxy with mod_security properly (custom) configured for those apps is a must to mitigate risk as much as possible! I even have some vms running PHP 5.6.40-58+0~20220614.65+debian9~1.gbpc40f11 (cli) with developers having vanished since a long time and customers not wanting to pay to upgrade it.
PHP is a pain to upgrade from version to version while I still run some apps developed for java 1.0 with recent versions of java. Cake PHP framework used to have a class named "String" then, php implemented a class named "String" in later versions screwing Cake up. Namespace anybody?
mydomain.myproject.String vs java.lang.String
Is name space finally implemented in php? Seriously asking...
Namespaces were introduced in PHP 5.3.0 about 12 years ago. PHP does not force your directory structure to match your namespace hierarchy, and there are no builtin autoloaders.
Re: (Score:2)
Totally. Even PHP 7.4 will continue to be semi-supported (at least security patches) on most "server" distros at least through 2024, even though the PHP devs stopped officially supporting it already. Upgrading for the sake of upgrading is never a good practice, though it's never good to be left high and dry either...
I'll argue the other side. With every upgrade that fixes bugs, it is just a matter of time before those bugs are turned into CVEs that require upgrading.
As such, developers need to design their code to work with shifting versions of dependencies, and CI/CD systems need to be designed so that they can adequately test code so that they can reliably run updates in an automated manner. If you fail to do that, your software will eventually be viewed as unusable by internet connected computers.
I misread as "PHP is end of life" (Score:3, Funny)
Re: (Score:2)
Which one?
Re: (Score:1)
Re: (Score:2)
Do you write server side web applications in C?
Re: (Score:3, Insightful)
Re: (Score:2)
Ah, just curious. I worked with a fellow who wrote all his server side stuff in C++ as Apache modules. Very strange way of doing it. His apps were fast, and it was on a bare metal server, but I shudder to think of how vulnerable that whole setup was.
Re: Somebody should tell the users (Score:1)
Re: (Score:3)
More impressive is seeing modules that were last compiled in the 60's still running. (Energy company)
Might have been written in more stable and maintained languages although /s
My neighbor is fatter, why should I lose weight? (Score:5, Informative)
Why does it matter? Banks are still running on code written in the 1960s.
If my neighbor is 200lbs fatter than me and still alive, does that mean I can live off pizza and beer and stop exercising? Just because one organization hasn't collapsed yet, doesn't mean ignoring best practices is a good idea.
.NET came out on *NIX far too late. If Sun had been less idiotic, Java could have shipped with cheap hosts and Linux distros and been installable automatically...which would have meant it dominated the *NIX business sphere and the low-budget space, but as a result, we ended up with PHP dominating the low-budget shops and Java dominating *NIX shops with a budget. COBOL and FORTRAN are still alive because they are expensive products and the code was usually written by well trained engineers who took the job very seriously. If there was any COBOL/FORTRAN code written by script-kiddies, it probably was removed decades ago.
Also banks are mostly running COBOL, which is well-supported and TMK statically typed. It is a commercial product designed by entities to support the businesses it ran on, with a particular focus on the big spenders back then, like finance, military, and gov.
PHP is an open-source afterthought not particularly optimized for any use case which became a phenomenon primarily because it was superior to Perl, Java did that idiotic asinine licensing bullshit which made it illegal to distribute with Linux, and
Many small shops started with PHP and moved to something else once they started getting paying users and a decent budget.
In general, I'd avoid any language without strict typing for serious app development. Sure, you're smart and can write good code in any language, but a good app will outlive you. Good programmers have a habit of getting promoted or getting better jobs elsewhere. A good app needs to be maintainable and static typing is essential to that. PHP has never really grown out of the starter language category.
A low-end legacy webapp on a cheapo host?...sure, PHP is good enough...for a serious enterprise making money?...you'll probably be better served moving to a more appropriate language...especially as your original authors move on, retire, get promoted, or change teams. For my Java work, I keep finding out that code I wrote 20 years ago is still in use and actively maintained by people I've never met who had the work handed off to them by people I've never met. I am confident some of my code will still be sitting on a server 20 years from now maintained by someone I've never met. Why? because I worked for big spenders who demanded my team follow best practices and took the entire process very seriously. I don't think most PHP shops can say the same.
Re: (Score:2)
I general I agree with your sentiment - PHP suxors - but Wordpress is big business, and it's PHP. WP is not aimed at enterprise sized applications, but it's reach is huge and it ain't going away anytime soon.
Re: (Score:2)
I general I agree with your sentiment - PHP suxors - but Wordpress is big business, and it's PHP. WP is not aimed at enterprise sized applications, but it's reach is huge and it ain't going away anytime soon.
WordPress and WordPress plugins are a major headache to anyone trying to keep a modern version of PHP. There are plugins in use on over 100,000 sites which aren't compatible with PHP 8.1
Really annoyed at quick deprecation trend (Score:2)
I know the argument that distribs backport but there should be longer support, especially since there are constant syntax changes in minor versions that might break things. This is valid for python, php and a bunch of other languages.
Sure, in shiny startups willing to break things using the shiniest objects it's not an issue but in practice there may be other constraints
and "just let the distrib maintainers handle it through backports" is not imho the best advice
Re: (Score:2)
"The best distro out there" (Score:2)
A line of praise immediately followed by the fact that there's an obvious flaw in the repo pushing outdated software.
This just goes to show distribution choice is an emotional attachment rather than a meaningful data backed decision.
And, well, fuck, even Facebook doesn't use PHP (Score:2)
PHP8? (Score:2)
And here I'm still on 7.4 since my server doesn't support later versions... Stop the madness!!!!!!!!!
PHP only gets 2 years of support (Score:3)
For any point release. The platforms I work on require ten or more years of stable code bases. This absolutely rules out PHP as a development language. For a personal blog, sure, but I wouldn't trust PHP to any commercial or industrial application.