I am running CentOS 7 and that is still using 5.4. I am only running a forum, IRC and some other things and I don't really want to bother with third party packages.
For what it's worth I've been using PHP 5.6 via Software Collections (SCL) on my CentOS 7 system for a few years with zero problems. I think I will update to PHP 7.x soon (probably 7.2).
Exactly. These EOL dates aren't really helpful in a world where most people just use a handful of distros. WordPress keeps sending the same unhelpful message and I hate it.
Just the other day, a somewhat technical client of mine called me to ask if his PHP 7.0 installation has gaping security holes. I said no, you're using Ubuntu 16.04 LTS, you'll be fine until April 2021. If you force an upgrade now, you might run out of support even earlier.
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. Wait a sec, add another year for RHEL/CentOS 8 which is also going to support PHP 7.2 for the next 10 years. PHP 7.2 is going to outlive a whole bunch of future versions.
> 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 are committed to supporting PHP 7.2 for the next decade probably means that there will be more eyes on that particular version, and more hands to patch it, for the foreseeable future. It's a nice coincidence for people who want a bit of stability now that PHP has begun to change rather quickly.
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.
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."
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 happens on a screen patiently overwrites hacked 1.6 joomla installations by copying over an old copy and doesn't bother updating the passwords.
I am in the process of dockerizing almost everything in sight. There's pain.
I’ve just finish (yesterday night) to move old websites I host from a PHP 5.2 VM to 5.6
Some of them are more than 10 years old !
And as they represents a good share of my profits, I can’t dump them.
I think I saw a Joomla 1.5.
Those clients don’t want to pay someone to upgrade or redo their site.
There are several intranets that will not support PHP 7 because they use the old mysql_ functions...
So even I loose a lot of my semi-passive incomes, or I continue to tell them on a regular base that they should upgrade.
(For the anecdote, there were around 40 websites before I alerted my clients in April. 5 of them have migrate to last versions of Wordpress or joomla. 35 more to go...)
In addition to the shim and compat libs recommended, I've had decent luck with the converter tool (https://github.com/philip/MySQLConverterTool). It goes a bit out of its way to be compatible so one function call can get expanded into a global var + function call.
phpcs + PHPCompatibility ruleset is pretty good about finding issues as well.
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 and breaking changes.
Keep in mind that the majority of people who need PHP (and technology in general...) have far more important things to do with their time than incessant trendchasing.
The saying about "known unknowns" and "unknown unknowns" is worth remembering too. The fact that a system has stayed working for over a decade should be enough to tell you that its creators did something right.
(I am in the process of restoring an 80-year-old refrigerator. ;-)
"If it ain't broke don't fix it" is always good advice. But some ancient duct-taped WAMP situation with insecure passwords needs to just be set on fire. Jesus christ, running Windows Server 2003 alone is something he should be fired for if its connected to the internet.
> Jesus christ, running Windows Server 2003 alone is something he should be fired for if its connected to the internet.
Never look under the hood at any of the companies involved in silicon development then. Server 2003 would be an upgrade for many, many tester machines.
To get to the "why dont they update" question:
1. Proprietary hardware with a custom driver.
2. Barely functional proprietary software, good luck getting it to run on anything except Windows XP/95/3.11.
3. The tester is LONG out of support.
4. The company that makes it is either out of business or was bought up by Teradyne/Advantest
5. The software is licensed specifically for that hardware it came with(CPU/Motherboard guids/serials, MAC addresses, etc).
6. If there is even a replacement for the tester, it will cost a minimum of $500k to replace, probably $1MM or more.
7. A customer requirement is to have external access, as much as IT fights it, the tester must also have internet access so the customer can send/receive files with their own workflow.
Sometimes we got lucky and I was able to push forward multiple upgrade projects moving testers from Windows XP to Windows 10. This was the case with most anything using a National Instruments GPIB where the software wasnt also locked down. Since National Instruments makes drives compatible with Windows 10 for their PCI cards, we were able to transition to Windows 10 on an entire floor once I developed a compatibility shim to get around the non-UAC assumptions of the tester software.
Example from 2018:
A tester that runs on Windows XP meets all of the above. Capacitors on the P4 motherboard blew up, company was bought by Advantest, but they dont make that tester anymore or even have a replacement. It is one of three left on planet earth. What do we do? Replace everything we can. New RAM, SSD using an IDE to SATA bridge, PSU, etc. We sent the motherboard to one of our internal techs who replaced every single cap on the motherboard, by hand.
A few days later, it is back in action. It will remain in this condition for another decade or more, with internet access. This is normal in anything involved with manufacturing, and yes, it will all end badly. Thankfully, I am out of the Bay Area now and not at all involved with hardware manufacturing or that company, no longer supporting internet connected Windows 3.11, RHEL3, AIX4, and SunOS 2.6 machines.
Yikes. I get that there's situations where you can't get newer compatible hardware, etc. But if it's that important, you'd think security would be important enough to go through the trouble of air-gapping it.
It is worse than that, customers run their own workload on these testers using one of two methods:
1. In person.
2. Using VNC/telnet over a SSH gateway that dumps them onto the single broadcast network with all these testers.
Did I mention that changing the IP address on many of the testers is not possible without triggering a $10k+ licensing event because a change in the IP address invalidates the license file?
There is a cost-benefit-analysis at play, and even if one makes the security argument, that is "what if" talk, not concrete numbers that are coming out this year.
A $500k tester's depreciation is based on a 10+ year service life. The ones that make it past that point turn into security nightmares and profit centers at the same time.
These are large and complex machines, with hundreds or thousands of moving parts. A competent reverse engineer and driver developer likely could solve many of the driver interface issues and move things to newer platforms, but why invest hundreds of thousands per year in maybe updating something that still works? Who is going to pay for that? Oh, you want to raise your rates to pay for it? I guess they'll move all of their testing development to the competitor in Asia.
This isnt some big name you have heard of, but this is one of the places that all the big names go to to test their silicon during development.
That's very rarely the thought process in the real world when you're dealing with a production system though. Most developers who have the seniority and experience to make the call to upgrade something aren't just upgrading for the fun of it. It's more like...
"it's old and hundreds of security patches and performance improvements have been released in versions that have come along since it was current, and the core developers aren't supporting this version any more so we're in for a world of hurt if anything goes wrong, and we have the bandwidth to fix this problem right now where we might not in the future so let's change it"
"That's very rarely the thought process in the real world when you're dealing with a production system though. Most developers who have the seniority and experience to make the call to upgrade something aren't just upgrading for the fun of it."
you and i's experience varies greatly, Ive worked at a number of firms that update things based solely on age(and boredom) and nothing else... thats what happens when non-tech people steer the ship. I also see this happening a lot to justify someone existence on payroll.
You don't need it, but it certainly helps you know what your environment is so you can upgrade/patch one piece at a time without affecting everything. Need a new libc for your database? Feel free to upgrade it without worrying if your webserver or plugins will break. Also, you can more exactly replicate your production environment on your local development machine or replace production if the machine dies.
I love docker for anything where I'm not going to be running whatever is in the repository of whatever Linux distribution I'm running.
That WAMP server is serving multiple virtual hosts. We now need to be able to migrate some services living behind those hosts under different stack versions. Some services are production ready and can be deployed with a more recent LAMP stack but some can't. I don't have an infinite number of servers to put all those services on but I do have the resources for containers.
Reminder: when that WAMP server is down (which is an issue all by itself, the physical server has downtime as well), everything is down. Even static websites.
FWIW, I think the concern with "doesn't bother updating the passwords" was with respect to recovering from a hacked joomla install, not about an aging password management scheme.
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.
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.
The article you posted shows they went from 1300kWh/yr to 412kWh/yr. Amusing that it says "Some use as little as 255 kwh/year" when the article I posted mentions 244kWh/yr for the 30s Monitor-Top. (Mine is a "flat top" but has a very similar refrigeration system.) Like I said, average power consumption went up after the late 60s/early 70s, but before that they used less.
The compressor in mine draws <100W when running. A quick calculation shows that if it was running 24/7 that would be almost 900kWh/yr, but it definitely won't be running that much --- duty cycles I've found for these old ones vary from 15-20%, giving around 200kWh/yr, still very good. How often you open it and/or put warm things in probably has a higher impact on total power consumption than anything else.
This is extremely surprising, no. Motor/compressor/refrigerant/insulation design have all improved considerably.
Any insight there?
Usage patterns clearly have an impact, but I doubt they change much for a particular family across models -- some models have little doors for heavy use items to reduce air exchange, compartments probably make a big difference ('glass' shelves instead of wire).
Apart from improved insulation I don't think there's been much in the way of improvements since the late 30s --- if you look at the hermetic systems, they haven't changed much in decades.
In fact, the newer "environmentally friendly" refrigerants are less efficient than CFCs... so it's sort of a tradeoff between risking more ozone depletion when they leak, or putting more CO2 into the atmosphere from the higher power consumption...
Basic maintenance is not trend-chasing. Keeping your software up to date on a web-facing server is basic maintenance.
If you don't update your software regularly, then future updates get harder and harder. Unfortunately, future updates might include security patches that are critical. At that point your choices are both bad: do a major catch-up update under crisis mode, or decline the update and roll the dice on a security incident (which will put you into crisis mode if if happens).
Incremental LAMP stack updates are so easy... they rarely break things, and there are so many other people doing the same thing, there is tons of community advice and help. If a developer is not capable of doing that, what ARE they capable of doing?
I agree with you, don't fix what ain't broken, etc.
I won't get into details but the thing isn't stable and the last hack brought down some part of an emergency infrastructure for a whole region of a small country.
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.
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?
I didn't even think about the missing updates in the future when I wrote my comment.
It just all sounded to me like someone hating at one dude who did crappy development and then tries to solve that problem with Docker instead of a process.
In my eyes, Docker is the epitome of crappy development. "Oh we don't care anymore, we just throw all into a container and be done with it."
> In my eyes, Docker is the epitome of crappy development. "Oh we don't care anymore, we just throw all into a container and be done with it."
That's actually the plan. We need to keep it running in legacy mode until the updated and patched version of the app is ready to be deployed. Main org IT don't want EOL and unsupported pieces in its infra anymore unless it can isolate it.
Next version is going to be service based and scalable. A WAMP installation can't do that.
Am I being trolled ? Because I don't see the people bashing docker or glorifying the values of an insecure but simple setup giving alternatives.
> 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.
Somebody should fork PHP 5.6. There is a lot of Software still depending on it and it is unrealistic to expect companies to migrate millions of lines of third party code to PHP 7.
Where I work I develop a web app that's written in Rails, and it's replacing a legacy PHP 5.6 app. Now here's the thing - no-one is using the PHP app anymore, but we do still have some old data on there that we made a decision not to port over to the new app. At the time it seemed like it wouldn't be a problem - just keep an old version of the app up for those who need to view historical information.
Now I'm thinking I'll have to set aside some time to either port it to PHP 7 (which isn't really a priority) or come up with something else for viewing that historical data.
PHP 7's changes shouldn't affect most 5.6 code, and the code that is affected should not be difficult to fix. It's not supposed to be a Python 2/3 situation.
In theory, yes. However as the Germans say "the devil is in the details". The .patch file for magento 1 for PHP7 compatibility is around 1.9 MB (iirc)! In the standard PHP5 project you have literally millions of lines of third party code, that one shold not touch with a stick. Are you really going through all of this code to check if something is maybe going to break at runtime? What if the legacy project has 0 tests?
Another problem are the Docker images. The PHP project still provides Docker Images for 5.6, however to my knowledge they are not updated anymore (perhaps I'm wrong). So what about all the security vulnerabilities in the underlying linux image? (I just verified and the latest php 5.6 image is from January 2019)
What situation are you in where security vulnerabilities in the Docker image are important to fix, but updating from End-of-Life support for the language isn't?
(Or even where security of an old Docker image is important, but "has 0 tests" isn't a concern?).
That being said, using a newer underlying Linux image for a Docker image is as copying the Dockerfile and building it, isn't it?
Sure all these problems are important to address. But often there is a lack of time/interest to do it.
I think the PHP project should simply delete the 5.6 image, since it is insecure and EOL'ed. Then if somebody is interested they can provide an alternative image somewhere...
Plainly deleting the image will cause existing setups to break. Something like `cargo yank` would be more appropriate where you can still download the version for existing projects but you cannot use it in new projects anymore. Unfortunately as far as I know docker has no support for anything like that.
Magento is not exactly known for well written code, actually it is full of anti patterns and antiqued practices. PHP 7 was released in 2015, and if authors of those millions of lines of code can't be bothered to upgrade then probably their code should not be used.
There was nothing crippling about php5 when it came out, why would it matter now? Not having some nice-to-haves like null coalescing, return types, etc are not core features. The biggest php7 selling point was speed improvements, which isn't even on some lists (https://feryn.eu/blog/php-7-is-now-available-new-features-im...)
I really hope nobody does this. OS vendors backport security vulnerabilities, and that should be it.
Like the other commenter said, PHO 5.6 to 7 upgrade isn't that hard. If it is, there's a very good chance they are doing something devastatingly wrong (like using mysql_ extension).
There are companies who do this for Ruby on Rails. If someone can’t upgrade, for whatever reason, they can pay a third party for security updates. It works pretty well.
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 upgrading. One developer making new websites over a few years time isn't that crazy, so unfortunately you end up with a build-up of projects to update.
Yet while having time pressures to update, you also have pressures to continue to work on new things or fixing problems users have reported.
It usually comes down to time/money. Unfortunately dedicating time to updating things is never as high of a priority as making new things, adding new features, or fixing bugs. Because it follows the traditional mindset of it's working, why update it.
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.
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.
I miss ColdFusion. I really liked the idea of a tag based server side language. It will never have the power or expressiveness of other languages but for raw productivity of producing very simple dynamic apps with an incredibly low bar to entry for new/non-programmers, nothing else was even close.
For the past 10 years you've been able to write code in script or tags. Our application uses tag syntax for views, and script syntax for controllers, services, db model, etc.
It's Java, so it has as much power and expressiveness as Java.
Well, I'd argue that PHP and Python were roughly equally easy, although they didn't "blend" into the HTML as well (which is good or bad, depending on your viewpoint). ASP was supposed to be just as easy, but I remember some of those code bases being pretty woolly.
Nowadays, I think we actually have it easier. I haven't used many of the other front-end frameworks, but you can design/generate a back-end in a few minutes using Open API Spec, add a persistence layer in a few more minutes, and wire it up to a Vue front-end very quickly. And the kicker is that it's modular and maintainable, which a lot of CF/PHP/ASP projects certainly were not.
> "Nowadays, I think we actually have it easier...."
no, it's not even close. you'd have to learn a whole javscript framework, read the open api spec, grok backend vs frontend, and really understand the modern web before you could even get started, not to mention the fomo induced by the hundreds of other options you'd have to discard in the process. for the average human, that's a non-starter.
with tag-based coldfusion, it felt like you were learning an extension to html, rather than an entirely different (programming) language. while php/asp were somewhat easy to learn, coldfusion was extra-super-duper-easy (i taught classes back in the day). people with no prior experience could create a dynamic web page in an hour or two and feel that sense of accomplishment that drove them deeper into it.
I had the same thought. I was like that's weird that such a popular language has reached end of life. Then I clicked the article. I'm curious about your question as well.
Thanks for changing the title, whoever did it. This definitely sounded like PHP as a whole is dead. There's more than enough FUD surrounding PHP out there really.
Ha. I know that shop that played themselves into a corner many years ago by “customizing” their Doctrine installation, thereby cutting themselves off of any future upstream updates and upgrades. If they were to get up-to-date now, they would have to rewrite their entire stack, including their magic Doctrine queries. They did hire one(!) Java developer to rebuild most of it in Java, but as usual in such cases, nobody has the time to explain to him how the old tangled mess actually works.
Fwiw, I was really impressed with my hosting provider (Siteground), a couple of months ago they warned about deprecation and sent a report saying they could autoupdate PHP but a plugin on my Wordpress wasn't ready. Top service IMO.
It's [modded] cPanel hosting, with extras, so perhaps that's a cPanel thing but as a very small scale setup it helped a lot to be forewarned of incompatible plugins.
121 comments
[ 4.0 ms ] story [ 195 ms ] threadPHP 8 isn’t even out yet. How can PHP 7 already be deprecated and not even supported?
https://www.softwarecollections.org/en/scls/rhscl/rh-php72/
Just the other day, a somewhat technical client of mine called me to ask if his PHP 7.0 installation has gaping security holes. I said no, you're using Ubuntu 16.04 LTS, you'll be fine until April 2021. If you force an upgrade now, you might run out of support even earlier.
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. Wait a sec, add another year for RHEL/CentOS 8 which is also going to support PHP 7.2 for the next 10 years. PHP 7.2 is going to outlive a whole bunch of future versions.
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.
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 are committed to supporting PHP 7.2 for the next decade probably means that there will be more eyes on that particular version, and more hands to patch it, for the foreseeable future. It's a nice coincidence for people who want a bit of stability now that PHP has begun to change rather quickly.
I wonder if any of that work get up-streamed into the old versions for the benefit of other distros?
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.
And of course this in-house guru for anything that happens on a screen patiently overwrites hacked 1.6 joomla installations by copying over an old copy and doesn't bother updating the passwords.
I am in the process of dockerizing almost everything in sight. There's pain.
I'm still maintaining some code written by someone like this - though it's been mostly replaced by a new rails app I've developed.
Is it not?
> certainly not unique to PHP
Doesn't stop it from being an issue in my book, one that prevents updating to newer versions of the interpreter without breaking production.
Some of them are more than 10 years old !
And as they represents a good share of my profits, I can’t dump them.
I think I saw a Joomla 1.5.
Those clients don’t want to pay someone to upgrade or redo their site.
There are several intranets that will not support PHP 7 because they use the old mysql_ functions...
So even I loose a lot of my semi-passive incomes, or I continue to tell them on a regular base that they should upgrade.
(For the anecdote, there were around 40 websites before I alerted my clients in April. 5 of them have migrate to last versions of Wordpress or joomla. 35 more to go...)
https://github.com/dshafik/php7-mysql-shim
It won't be 100% perfect and it's definitely not something I'd want to use long term, but it can help with the initial migration to PHP 7.
While I'm using https://github.com/dshafik/php7-mysql-shim, another to look at is https://github.com/mattbit/mysql-compat
phpcs + PHPCompatibility ruleset is pretty good about finding issues as well.
It's mainly what prevents me to migrate them by myself. It's a lot of work and no one wants to pay for it.
So it remains on a VM and if it brokes, they were alerted it could happen.
Keep in mind that the majority of people who need PHP (and technology in general...) have far more important things to do with their time than incessant trendchasing.
The saying about "known unknowns" and "unknown unknowns" is worth remembering too. The fact that a system has stayed working for over a decade should be enough to tell you that its creators did something right.
(I am in the process of restoring an 80-year-old refrigerator. ;-)
Never look under the hood at any of the companies involved in silicon development then. Server 2003 would be an upgrade for many, many tester machines.
To get to the "why dont they update" question:
1. Proprietary hardware with a custom driver.
2. Barely functional proprietary software, good luck getting it to run on anything except Windows XP/95/3.11.
3. The tester is LONG out of support.
4. The company that makes it is either out of business or was bought up by Teradyne/Advantest
5. The software is licensed specifically for that hardware it came with(CPU/Motherboard guids/serials, MAC addresses, etc).
6. If there is even a replacement for the tester, it will cost a minimum of $500k to replace, probably $1MM or more.
7. A customer requirement is to have external access, as much as IT fights it, the tester must also have internet access so the customer can send/receive files with their own workflow.
Sometimes we got lucky and I was able to push forward multiple upgrade projects moving testers from Windows XP to Windows 10. This was the case with most anything using a National Instruments GPIB where the software wasnt also locked down. Since National Instruments makes drives compatible with Windows 10 for their PCI cards, we were able to transition to Windows 10 on an entire floor once I developed a compatibility shim to get around the non-UAC assumptions of the tester software.
Example from 2018: A tester that runs on Windows XP meets all of the above. Capacitors on the P4 motherboard blew up, company was bought by Advantest, but they dont make that tester anymore or even have a replacement. It is one of three left on planet earth. What do we do? Replace everything we can. New RAM, SSD using an IDE to SATA bridge, PSU, etc. We sent the motherboard to one of our internal techs who replaced every single cap on the motherboard, by hand.
A few days later, it is back in action. It will remain in this condition for another decade or more, with internet access. This is normal in anything involved with manufacturing, and yes, it will all end badly. Thankfully, I am out of the Bay Area now and not at all involved with hardware manufacturing or that company, no longer supporting internet connected Windows 3.11, RHEL3, AIX4, and SunOS 2.6 machines.
1. In person.
2. Using VNC/telnet over a SSH gateway that dumps them onto the single broadcast network with all these testers.
Did I mention that changing the IP address on many of the testers is not possible without triggering a $10k+ licensing event because a change in the IP address invalidates the license file?
A $500k tester's depreciation is based on a 10+ year service life. The ones that make it past that point turn into security nightmares and profit centers at the same time.
These are large and complex machines, with hundreds or thousands of moving parts. A competent reverse engineer and driver developer likely could solve many of the driver interface issues and move things to newer platforms, but why invest hundreds of thousands per year in maybe updating something that still works? Who is going to pay for that? Oh, you want to raise your rates to pay for it? I guess they'll move all of their testing development to the competitor in Asia.
This isnt some big name you have heard of, but this is one of the places that all the big names go to to test their silicon during development.
That's very rarely the thought process in the real world when you're dealing with a production system though. Most developers who have the seniority and experience to make the call to upgrade something aren't just upgrading for the fun of it. It's more like...
"it's old and hundreds of security patches and performance improvements have been released in versions that have come along since it was current, and the core developers aren't supporting this version any more so we're in for a world of hurt if anything goes wrong, and we have the bandwidth to fix this problem right now where we might not in the future so let's change it"
you and i's experience varies greatly, Ive worked at a number of firms that update things based solely on age(and boredom) and nothing else... thats what happens when non-tech people steer the ship. I also see this happening a lot to justify someone existence on payroll.
Why do you need Docker to run a WAMP server?
I love docker for anything where I'm not going to be running whatever is in the repository of whatever Linux distribution I'm running.
Reminder: when that WAMP server is down (which is an issue all by itself, the physical server has downtime as well), everything is down. Even static websites.
Upgrading isn't just about shiny-shiny, and keeping old stuff isn't always best.
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.
https://www.thegeoexchange.org/fridge-power-consumption/inde... - shows a saving of two-thirds by replacing a 20yo fridge with a mid-range model (they say they could have saved about 80% power use with a more expensive model).
https://www.youtube.com/watch?v=k_ysVqppaN0
The article you posted shows they went from 1300kWh/yr to 412kWh/yr. Amusing that it says "Some use as little as 255 kwh/year" when the article I posted mentions 244kWh/yr for the 30s Monitor-Top. (Mine is a "flat top" but has a very similar refrigeration system.) Like I said, average power consumption went up after the late 60s/early 70s, but before that they used less.
The compressor in mine draws <100W when running. A quick calculation shows that if it was running 24/7 that would be almost 900kWh/yr, but it definitely won't be running that much --- duty cycles I've found for these old ones vary from 15-20%, giving around 200kWh/yr, still very good. How often you open it and/or put warm things in probably has a higher impact on total power consumption than anything else.
This is extremely surprising, no. Motor/compressor/refrigerant/insulation design have all improved considerably.
Any insight there?
Usage patterns clearly have an impact, but I doubt they change much for a particular family across models -- some models have little doors for heavy use items to reduce air exchange, compartments probably make a big difference ('glass' shelves instead of wire).
Interesting. /beardStroke
In fact, the newer "environmentally friendly" refrigerants are less efficient than CFCs... so it's sort of a tradeoff between risking more ozone depletion when they leak, or putting more CO2 into the atmosphere from the higher power consumption...
If you don't update your software regularly, then future updates get harder and harder. Unfortunately, future updates might include security patches that are critical. At that point your choices are both bad: do a major catch-up update under crisis mode, or decline the update and roll the dice on a security incident (which will put you into crisis mode if if happens).
Incremental LAMP stack updates are so easy... they rarely break things, and there are so many other people doing the same thing, there is tons of community advice and help. If a developer is not capable of doing that, what ARE they capable of doing?
I won't get into details but the thing isn't stable and the last hack brought down some part of an emergency infrastructure for a whole region of a small country.
So, yeah... not stable, not safe.
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.
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.
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?
It just all sounded to me like someone hating at one dude who did crappy development and then tries to solve that problem with Docker instead of a process.
In my eyes, Docker is the epitome of crappy development. "Oh we don't care anymore, we just throw all into a container and be done with it."
That's actually the plan. We need to keep it running in legacy mode until the updated and patched version of the app is ready to be deployed. Main org IT don't want EOL and unsupported pieces in its infra anymore unless it can isolate it.
Next version is going to be service based and scalable. A WAMP installation can't do that.
Am I being trolled ? Because I don't see the people bashing docker or glorifying the values of an insecure but simple setup giving alternatives.
What should we do then ?
I just have the impression, Docker is the way if people don't really want to think about a solution.
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?
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.
Where I work I develop a web app that's written in Rails, and it's replacing a legacy PHP 5.6 app. Now here's the thing - no-one is using the PHP app anymore, but we do still have some old data on there that we made a decision not to port over to the new app. At the time it seemed like it wouldn't be a problem - just keep an old version of the app up for those who need to view historical information.
Now I'm thinking I'll have to set aside some time to either port it to PHP 7 (which isn't really a priority) or come up with something else for viewing that historical data.
Another problem are the Docker images. The PHP project still provides Docker Images for 5.6, however to my knowledge they are not updated anymore (perhaps I'm wrong). So what about all the security vulnerabilities in the underlying linux image? (I just verified and the latest php 5.6 image is from January 2019)
That being said, using a newer underlying Linux image for a Docker image is as copying the Dockerfile and building it, isn't it?
I think the PHP project should simply delete the 5.6 image, since it is insecure and EOL'ed. Then if somebody is interested they can provide an alternative image somewhere...
As are many/most PHP 5.6 projects
> Probably their code should not be used.
In reality it is - unfortunately. And many smaller companies don't have the capacity to change.
I'd be more concerned about having a Magento 1 site in the wild, than the upgrade path to PHP 7.
Like the other commenter said, PHO 5.6 to 7 upgrade isn't that hard. If it is, there's a very good chance they are doing something devastatingly wrong (like using mysql_ extension).
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.
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 upgrading. One developer making new websites over a few years time isn't that crazy, so unfortunately you end up with a build-up of projects to update.
Yet while having time pressures to update, you also have pressures to continue to work on new things or fixing problems users have reported.
It usually comes down to time/money. Unfortunately dedicating time to updating things is never as high of a priority as making new things, adding new features, or fixing bugs. Because it follows the traditional mindset of it's working, why update it.
This is a little like having the money to buy a hand-made car, but only being able to afford ever other oil change.
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.
Which also made me think - does anybody know an example of a widely used programming language that voluntarily discontinued?
https://helpx.adobe.com/coldfusion/cfml-reference/coldfusion...
It's Java, so it has as much power and expressiveness as Java.
Well, I'd argue that PHP and Python were roughly equally easy, although they didn't "blend" into the HTML as well (which is good or bad, depending on your viewpoint). ASP was supposed to be just as easy, but I remember some of those code bases being pretty woolly.
Nowadays, I think we actually have it easier. I haven't used many of the other front-end frameworks, but you can design/generate a back-end in a few minutes using Open API Spec, add a persistence layer in a few more minutes, and wire it up to a Vue front-end very quickly. And the kicker is that it's modular and maintainable, which a lot of CF/PHP/ASP projects certainly were not.
no, it's not even close. you'd have to learn a whole javscript framework, read the open api spec, grok backend vs frontend, and really understand the modern web before you could even get started, not to mention the fomo induced by the hundreds of other options you'd have to discard in the process. for the average human, that's a non-starter.
with tag-based coldfusion, it felt like you were learning an extension to html, rather than an entirely different (programming) language. while php/asp were somewhat easy to learn, coldfusion was extra-super-duper-easy (i taught classes back in the day). people with no prior experience could create a dynamic web page in an hour or two and feel that sense of accomplishment that drove them deeper into it.
Python 2
Thanks for changing the title, whoever did it. This definitely sounded like PHP as a whole is dead. There's more than enough FUD surrounding PHP out there really.
There likely are many, many proprietary languages that were officially discontinued at some time.
I upgraded a large project last month, and this found 6 changes I had to make in 20k LOC.
[0]: https://www.drupal.org/project/graphql/issues/2715609
It's [modded] cPanel hosting, with extras, so perhaps that's a cPanel thing but as a very small scale setup it helped a lot to be forewarned of incompatible plugins.