Re: [Astlinux-devel] PHP 5.6 EoL

[Michael K. <mic...@ip...>]

Its not really an issue per se. You can always just throw more resources at it.
Its more when you have a big phone reset and they are all hammering the startup PHP script.
We also have a duress alarm script which struggles under load.

Its also going to be better from a development perspective for us as we are doing quite a bit in PHP now.

Regards
Michael Knill

On 15/8/19, 11:13 am, "Lonnie Abelbeck" <li...@lo...> wrote:

    AFAIK, the only improvement for us in PHP 7 is it's improved execution speed.  Probably not noticeable with our web interface.
    
    Michael (Knill) you mentioned you have some PHP based custom apps, can you provide any info on how much CPU they are currently consuming ? Maybe via "htop" or are they a short transaction based app ?
    
    In other words, a practical feel on how the execution speed of 5.6 is an issue.
    
    Lonnie
    
    
    > On Aug 14, 2019, at 7:12 PM, Michael Knill <mic...@ip...> wrote:
    > 
    > +1 from me
    >  
    > Regards
    > Michael Knill
    >  
    > From: David Kerr <da...@ke...>
    > Reply to: AstLinux Developers Mailing List <ast...@li...>
    > Date: Wednesday, 14 August 2019 at 2:56 am
    > To: AstLinux Developers Mailing List <ast...@li...>
    > Subject: Re: [Astlinux-devel] PHP 5.6 EoL
    >  
    > This feels like something that we should create a GitHub branch for and take our time over.  Since moving our source to GitHub we really have not taken advantage of its development features.  We don't use branches, issues, pull requests, etc.
    >  
    > I propose creating a branch specifically to work the can of worms.  Leave Master branch stable, continue to apply fixes to it, etc.  But fork a branch into which we place PHP 7 and then a small group of us can thrash on that to uncover all the worms and incrementally commit fixes for them.  Once thoroughly tested we merge everything back into the master.
    >  
    > We'll need to the same at some point for the kernel upgrade to 4.x (or, gulp, 5).
    >  
    > David
    >  
    > On Tue, Aug 13, 2019 at 11:25 AM Lonnie Abelbeck <li...@lo...> wrote:
    >> 
    >> 
    >> > On Aug 13, 2019, at 2:50 AM, Michael Knill <mic...@ip...> wrote:
    >> > 
    >> > Hi Devs
    >> >  
    >> > Just wondering if/when we would be looking to go to PHP 7.x considering 5.6 was EoL at the beginning of this year?
    >> > I understand that PHP 7 is much faster than 5.6 so it will make some of my busy XML apps a little better.
    >> 
    >> Hi Michael,
    >> 
    >> Indeed, this is a can-of-worms.
    >> 
    >> 1) Sadly, there is no LTS version of PHP to latch on to, the PHP release cycle is to introduce a new version every year, with new bugs ... fixes for two years plus security-only fixes for a year.  Rinse and repeat.
    >> 
    >> https://www.php.net/supported-versions.php
    >> 
    >> Our current 5.6 version was the closest to LTS they have offered.  Note a LTS series is of higher quality since it is scrutinized for a longer period of time. PHP 5.6.x has had 41 x-releases, whereas PHP 7.3.x is currently at 9 x-releases.
    >> 
    >> BTW, each new PHP release is not 100% backward compatible.
    >> 
    >> 
    >> 2) Sadly, PHP includes the timezone data within the php binary rather than using the Linux /usr/share/zoneinfo data.  This is extra bloat for standard 32-bit (pre-Year 2038 problem) as well it includes 64-bit transition data, more significant extra bloat.
    >> 
    >> Bug #69652 5.5.24 -> 5.5.25 binary is 13.6 % larger
    >> https://bugs.php.net/bug.php?id=69652
    >> 
    >> We currently work around this by compiling our own 32-bit only "timezonedb.h" using the same scripts "Derick Rethans" (the timezonedb maintainer) used.  This keeps the PHP 5.6 timezone data in sync with the latest Linux zoneinfo data.
    >> 
    >> It appears later PHP versions use the same timezonedb.h file, though some details may have changed.
    >> 
    >> 
    >> 3) A jump to PHP 7.3 would no doubt introduce some backward incompatibilities with the web interface, warnings at the very least.
    >> 
    >> 
    >> 4) We also include "phpLiteAdmin" which at a quick glance has some PHP 7 issues, but fixes could be cherrypicked from upstream phpLiteAdmin.
    >> 
    >> 
    >> That is a summary for the can-of-worms.
    >> 
    >> Fortunately with AstLinux, PHP is not exposed to untrusted users by default, and it is highly recommended to not expose HTTP/HTTPS to anything other than trusted endpoints ... thereby limiting PHP's security exposure.
    >> 
    >> BTW, a historical note, Manuel Kasper's fantastic "m0n0wall" project had a PHP security exposure much like AstLinux does, and he extend PHP 4.4.9 six years beyond its EOL.
    >> --
    >> m0n0wall PHP 4.3.x -> 4.4.x from years 2003 -> 2008(EOL) -> 2014
    >> --
    >> 
    >> At some point we will need to make a version jump of PHP, but we are currently on solid ground and somewhat uncertain how we might land if we made the jump.
    >> 
    >> As always, open to comments.
    >> 
    >> Lonnie
    >> 
    >> 
    >> 
    >> _______________________________________________
    >> Astlinux-devel mailing list
    >> Ast...@li...
    >> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
    > _______________________________________________
    > Astlinux-devel mailing list
    > Ast...@li...
    > https://lists.sourceforge.net/lists/listinfo/astlinux-devel
    
    
    
    _______________________________________________
    Astlinux-devel mailing list
    Ast...@li...
    https://lists.sourceforge.net/lists/listinfo/astlinux-devel