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

Mon Jul 11 02:09:37 -05 2011

Michael,
thank you for your support and for your words on PHP compatibility.

After reading your post i've done some research on PHP.net site to find 
out big changes from 5.1.6 to 5.3 and i've only found the changelog. Do 
you know if there are resources that can give us some extra informations 
on it? Also on the PHP 6 roadmap... just to write php6-ready code...

Thank you in advance
SImone Capra

_______________________________________________________
Simone Capra
E.R. WEB - s.r.l.
P.zza Risorgimento,12
13100 - Vercelli

tel. +39 0161 210090
mob. +39 335 5257182

Mail: capra at erweb.it
http://www.erweb.it

Michael Stauber wrote:
> 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.
>
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.blueonyx.it/pipermail/blueonyx/attachments/20110711/4aa1ff50/attachment.html>