[BlueOnyx:07654] Re: Solarspeed PHP 5.2.x pkg

[Michael Stauber]

Hi Chuck,

> Are you saying Michael - that they've made so many changes in PHP that code
> written under 5.1 and 5.2 won't run under 5.3?  What absolute STUPIDITY is
> that?

Hard to say. Ask the guys and gals over at php.net. :o)

I also think that some of the changes in PHP-5.3 are a bit on the stupid side 
of things. Others are uncomfortable, but the reasoning behind it is 
understandable. Like being forced to switch from Register_Globals "on" to 
"off". That change (and the need for it) has been anounced years ago and 
finally there is a PHP version that leaves you little choice and forces people 
to adapt.

I have less understanding for deprecating all the POSIX functionality such as 
the old ereg_replace(), ereg(), eregi_replace(), eregi(), split() and spliti() 
functions and forcing people to switch to the respective PCRE compliant 
counterparts.

Some changes are simply nuts - such as deprecating split(). Am still shaking 
my head over that one.

All in all the changes that PHP-5.3 has forced on BlueOnyx weren't really 
funny. It took weeks to go through the code and to find and replace all the 
deprecated functions with their modern counterparts, so I understand your 
pain.

The roadmap for PHP6 outlines another set of massive changes, which I'm also 
not really looking forward to.

> I'm angry with whoever is in charge of the PHP efforts!  Why in the world
> would they update later versions of PHP so they won't run older scripts? 
> Wouldn't that seem to be a base function of any upgrade development -
> "Don't break what's already out there while trying to improve it!"

Well, PHP is always evolving and they're of course trying to stay at the 
forefront of things and to offer new functionality and more advanced features. 
At the same time there is the constant need to make things more secure and to 
tweak a little more performance out of the existing engine. If one would keep 
all the "old baggage" and would make everything 100% downwards compatible, it 
would hurt performance and would increase code maintenance efforts. And some 
things (Register_Globals) were never a good idea to begin with. If that 
wouldn't have been outright dropped from PHP (as it will be), people would 
just configure their PHP in a downward compatible fashion and would continue 
to run the old and unsecure scripts, which invite abuse and exploits.

Programmers are often a lazy bunch. If something works, then why change the 
code? For years I've thrown all scripts away which forced me to run my PHP 
with "Register_Globals = On", because if a programmer really insisted on that, 
there certainly were other surprises in the code which I wouldn't like either.

Likewise the guys at php.net can't and won't maintain several branches of 
their code for all eternity. So while they're working on PHP-6 and PHP-5.4, 
PHP-5.3 is the current "stable" version. So that's already three different 
code branches that need to be maintained, which is a hell of a lot of work.

PHP-5.2 has already been earmarked as "no longer supported". So it joins the 
fate of PHP-5.1, PHP-5.0 and PHP-4, which all are since long phased out.

This kind of forces OS vendors who still ship older versions of their OS with 
older PHP versions to mind their own business with patching vulnerabilities in 
the respective PHP versions that they may include. Which is nothing new. 
RedHat for example has done this for years.

> UUHHHGGGG!!  More admin work for me - just to keep separate boxes for
> different PHP support!!
> 
> Any ideas or suggestions??

Unfortunately the best approach there is to stay on top of things and 
personally I wouldn't spend too much effort into maintaining various boxes 
with different PHP versions. Personally I'm already getting uneasy with 
running PHP-5.2 for much longer, as it's now unsupported. Still running it may 
be fine for a little while longer, but sooner or later it'll have to be 
retired from production boxes.

Vulnerabilities in old PHP scripts are one of the more common attack vectors 
for defacements and hacks. Likewise, bugs in older PHP versions may also 
eventually surface and may lead to openings that one would rather not have.

So if you use popular scripts such as phpBB, Joomla, Typo3 and all their 
cousins, you are kind of forced to stay on top with updates of said scripts. 
Because often if there is a critical vulnerability, a lot of malicious people 
will do automated drive by attacks to deface of hack as many sites as possible 
all over the place.

Most of the more popular PHP projects keep track with the iffy goings at 
php.net and make sure that their newest scripts also run on the newest stable 
PHP versions. And usually newer versions of those scripts also add new 
features, or fix stuff that didn't work right before. So you can always "sell" 
such an update as "feature" update to your clients to sweeten the transition.

If you run all those scripts for yourself, this extra maintenance can 
sometimes burn a hole into your pocket, as you may have to set aside some time 
every couple of weeks or months to make sure you stay fully updated.

But if it's custom code, or code from some inactive project, or something your 
client(s) pieced together themselves, then it sure can become a support 
nightmare and/or may lead to client dissatisfaction.

Typically I tend to say: If a client requires me to configure my server in an 
undesireable (unsafe) fashion, or requires me to run unsafe or horribly 
outdated software (such as PHP-4 for example), then I would exile him onto a 
dedicated box that he accepts 100% responsibility at an extra price. At the 
same time I'd make sure that the box gets backed up twice as often as any 
other box. But that's just my solution and it may not work for everyone. :o)

Not staying on top of things for the sake of simplicity will otherwise hurt in 
the long run. Sooner or later the technological gap between what you need to 
run (i.e.: old code!) and where you can run it will be unbridgeable.

-- 
With best regards

Michael Stauber