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. ;-)

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.

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.

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.

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.

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

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.

phpcs + PHPCompatibility ruleset is pretty good about finding issues as well.

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.

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.

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.

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.