Menu
▾
▴
astlinux-devel
|
From: Michael K. <mic...@ip...> - 2019-08-13 07:50:17
|
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. Regards Michael Knill |
|
From: Lonnie A. <li...@lo...> - 2019-08-13 15:25:05
|
> 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 |
|
From: David K. <da...@ke...> - 2019-08-13 16:56:21
|
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 > |
|
From: Michael K. <li...@mk...> - 2019-08-13 17:06:17
|
> Am 13.08.2019 um 18:56 schrieb David Kerr <da...@ke...>: > > 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. +1 > 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 Michael http://www.mksolutions.info |
|
From: Michael K. <mic...@ip...> - 2019-08-15 00:13:12
|
+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...<mailto:li...@lo...>> wrote: > On Aug 13, 2019, at 2:50 AM, Michael Knill <mic...@ip...<mailto: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...<mailto:Ast...@li...> https://lists.sourceforge.net/lists/listinfo/astlinux-devel |
|
From: Lonnie A. <li...@lo...> - 2019-08-15 01:13:13
|
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 |
|
From: Michael K. <mic...@ip...> - 2019-08-15 04:38:20
|
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
|
|
From: Lonnie A. <li...@lo...> - 2019-08-15 14:29:34
|
Hi Michael, > On Aug 14, 2019, at 11:38 PM, Michael Knill <mic...@ip...> wrote: > > 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. It could be the bottleneck you describe is lighttpd spawning php requests rather than the actual PHP code execution. If you have a test situation where "they (phones) are all hammering the startup PHP script", you could run "htop" in AstLinux and see if any cores are near CPU max ... if not (low'ish CPU usage) it is probably a lighttpd/network bottleneck. There are lighttpd tweaks an optional /mnt/kd/lighttpd.conf could provide. Lonnie > 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 > > > > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel |
|
From: Lonnie A. <li...@lo...> - 2019-08-15 20:37:48
|
OK, I tried PHP 7.3.8 ... it requires pcre2 and libzip which we don't include (we use pcre and libz) I then tried PHP 7.2.21 ... still works with pcre and libz just fine. The best news is the ext/date/lib/timezonedb.h format has not changed, in fact we have offer a newer version than what comes with 7.2.21 . Oh, and it is faster :-) On an APU2: -------------------------------------- | PHP BENCHMARK SCRIPT | -------------------------------------- Start : 2019-08-15 14:15:15 CPU : AMD GX-412TC SOC PHP version : 5.6.40 Platform : Linux -------------------------------------- test_math : 12.422 sec. test_stringmanipulation : 12.333 sec. test_loops : 6.945 sec. test_ifelse : 4.169 sec. -------------------------------------- Total time: : 35.869 sec. ... and ... -------------------------------------- | PHP BENCHMARK SCRIPT | -------------------------------------- Start : 2019-08-15 14:26:29 CPU : AMD GX-412TC SOC PHP version : 7.2.21 Platform : Linux -------------------------------------- test_math : 2.585 sec. test_stringmanipulation : 3.859 sec. test_loops : 2.145 sec. test_ifelse : 2.180 sec. -------------------------------------- Total time: : 10.769 sec. DDG researching, most general benchmark tests show PHP 7 is 2x the speed of PHP 5.6 Though PHP 7.2 is bigger (both with our same custom built timezonedb.h) PHP 5.6.40 -rwxr-xr-x 1 root root 3580688 Aug 12 11:35 /usr/bin/php PHP 7.2.21 -rwxr-xr-x 1 root root 3921344 Aug 15 14:12 /usr/bin/php Note: without our custom built timezonedb.h, the 7.2.21 binary size is 4360256 I do like the idea of OpenSSL 1.1 support built-in without having to add a patch. So far, testing is going good, the can-of-worms is under control :-) If you can test, I committed it here: https://github.com/astlinux-project/astlinux/commit/91892424b43818e5f78e1068c14dd05a835a3d7e 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 |
|
From: Michael K. <mic...@ip...> - 2019-08-15 20:50:16
|
Great thanks Lonnie.
Looks promising!
Regards
Michael Knill
On 16/8/19, 6:37 am, "Lonnie Abelbeck" <li...@lo...> wrote:
OK, I tried PHP 7.3.8 ... it requires pcre2 and libzip which we don't include (we use pcre and libz)
I then tried PHP 7.2.21 ... still works with pcre and libz just fine.
The best news is the ext/date/lib/timezonedb.h format has not changed, in fact we have offer a newer version than what comes with 7.2.21 .
Oh, and it is faster :-)
On an APU2:
--------------------------------------
| PHP BENCHMARK SCRIPT |
--------------------------------------
Start : 2019-08-15 14:15:15
CPU : AMD GX-412TC SOC
PHP version : 5.6.40
Platform : Linux
--------------------------------------
test_math : 12.422 sec.
test_stringmanipulation : 12.333 sec.
test_loops : 6.945 sec.
test_ifelse : 4.169 sec.
--------------------------------------
Total time: : 35.869 sec.
... and ...
--------------------------------------
| PHP BENCHMARK SCRIPT |
--------------------------------------
Start : 2019-08-15 14:26:29
CPU : AMD GX-412TC SOC
PHP version : 7.2.21
Platform : Linux
--------------------------------------
test_math : 2.585 sec.
test_stringmanipulation : 3.859 sec.
test_loops : 2.145 sec.
test_ifelse : 2.180 sec.
--------------------------------------
Total time: : 10.769 sec.
DDG researching, most general benchmark tests show PHP 7 is 2x the speed of PHP 5.6
Though PHP 7.2 is bigger (both with our same custom built timezonedb.h)
PHP 5.6.40
-rwxr-xr-x 1 root root 3580688 Aug 12 11:35 /usr/bin/php
PHP 7.2.21
-rwxr-xr-x 1 root root 3921344 Aug 15 14:12 /usr/bin/php
Note: without our custom built timezonedb.h, the 7.2.21 binary size is 4360256
I do like the idea of OpenSSL 1.1 support built-in without having to add a patch.
So far, testing is going good, the can-of-worms is under control :-)
If you can test, I committed it here:
https://github.com/astlinux-project/astlinux/commit/91892424b43818e5f78e1068c14dd05a835a3d7e
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
|
|
From: Michael K. <li...@mk...> - 2019-08-15 21:41:58
|
> Am 15.08.2019 um 22:37 schrieb Lonnie Abelbeck <li...@lo...>: > > OK, I tried PHP 7.3.8 ... it requires pcre2 and libzip which we don't include (we use pcre and libz) > > I then tried PHP 7.2.21 ... still works with pcre and libz just fine. > > The best news is the ext/date/lib/timezonedb.h format has not changed, in fact we have offer a newer version than what comes with 7.2.21 . > > Oh, and it is faster :-) > > On an APU2: > > -------------------------------------- > | PHP BENCHMARK SCRIPT | > -------------------------------------- > Start : 2019-08-15 14:15:15 > CPU : AMD GX-412TC SOC > PHP version : 5.6.40 > Platform : Linux > -------------------------------------- > test_math : 12.422 sec. > test_stringmanipulation : 12.333 sec. > test_loops : 6.945 sec. > test_ifelse : 4.169 sec. > -------------------------------------- > Total time: : 35.869 sec. > > ... and ... > > -------------------------------------- > | PHP BENCHMARK SCRIPT | > -------------------------------------- > Start : 2019-08-15 14:26:29 > CPU : AMD GX-412TC SOC > PHP version : 7.2.21 > Platform : Linux > -------------------------------------- > test_math : 2.585 sec. > test_stringmanipulation : 3.859 sec. > test_loops : 2.145 sec. > test_ifelse : 2.180 sec. > -------------------------------------- > Total time: : 10.769 sec. > > DDG researching, most general benchmark tests show PHP 7 is 2x the speed of PHP 5.6 > > Though PHP 7.2 is bigger (both with our same custom built timezonedb.h) > > PHP 5.6.40 > -rwxr-xr-x 1 root root 3580688 Aug 12 11:35 /usr/bin/php > > PHP 7.2.21 > -rwxr-xr-x 1 root root 3921344 Aug 15 14:12 /usr/bin/php > > Note: without our custom built timezonedb.h, the 7.2.21 binary size is 4360256 > > I do like the idea of OpenSSL 1.1 support built-in without having to add a patch. > > So far, testing is going good, the can-of-worms is under control :-) > > If you can test, I committed it here: > https://github.com/astlinux-project/astlinux/commit/91892424b43818e5f78e1068c14dd05a835a3d7e > > > Lonnie Hi Lonnie, great work. I tested it on my office PBX and everything seems to work fine: incl. Monit, NetStat, phpLiteAdmin, Shellinabox, FOP2. Cool! >> 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 Michael http://www.mksolutions.info |
|
From: Lonnie A. <li...@lo...> - 2019-08-16 19:45:11
|
Yesterday I reported some best case PHP 7 speed improvements using a PHP benchmark script. Today I made a real-world test of the web interface speed, and as probably expected, not much change... Box: Jetway NF9HG-2930, time to load Status tab with Prefs "Show NTP Time Sources" unchecked -- time curl -k https://localhost/status.php -- PHP 5.6.40 real 0m0.264s PHP 7.2.21 real 0m0.259s Since our web interface does not heavily use PHP, the system calls to gather data and lighttpd network stack plays more into the processing time. Though some special cases like the CDR Log, SQL-Data and LDAP-AB tabs should benefit from PHP 7's improved speed. Here is a "CDR Log" tab test example: -- time curl -k --user admin:secret https://localhost/admin/cdrlog.php -- PHP 5.6.40 real 0m0.122s PHP 7.2.21 real 0m0.097s Lonnie > On Aug 15, 2019, at 3:37 PM, Lonnie Abelbeck <li...@lo...> wrote: > > OK, I tried PHP 7.3.8 ... it requires pcre2 and libzip which we don't include (we use pcre and libz) > > I then tried PHP 7.2.21 ... still works with pcre and libz just fine. > > The best news is the ext/date/lib/timezonedb.h format has not changed, in fact we have offer a newer version than what comes with 7.2.21 . > > Oh, and it is faster :-) > > On an APU2: > > -------------------------------------- > | PHP BENCHMARK SCRIPT | > -------------------------------------- > Start : 2019-08-15 14:15:15 > CPU : AMD GX-412TC SOC > PHP version : 5.6.40 > Platform : Linux > -------------------------------------- > test_math : 12.422 sec. > test_stringmanipulation : 12.333 sec. > test_loops : 6.945 sec. > test_ifelse : 4.169 sec. > -------------------------------------- > Total time: : 35.869 sec. > > ... and ... > > -------------------------------------- > | PHP BENCHMARK SCRIPT | > -------------------------------------- > Start : 2019-08-15 14:26:29 > CPU : AMD GX-412TC SOC > PHP version : 7.2.21 > Platform : Linux > -------------------------------------- > test_math : 2.585 sec. > test_stringmanipulation : 3.859 sec. > test_loops : 2.145 sec. > test_ifelse : 2.180 sec. > -------------------------------------- > Total time: : 10.769 sec. > > DDG researching, most general benchmark tests show PHP 7 is 2x the speed of PHP 5.6 > > Though PHP 7.2 is bigger (both with our same custom built timezonedb.h) > > PHP 5.6.40 > -rwxr-xr-x 1 root root 3580688 Aug 12 11:35 /usr/bin/php > > PHP 7.2.21 > -rwxr-xr-x 1 root root 3921344 Aug 15 14:12 /usr/bin/php > > Note: without our custom built timezonedb.h, the 7.2.21 binary size is 4360256 > > I do like the idea of OpenSSL 1.1 support built-in without having to add a patch. > > So far, testing is going good, the can-of-worms is under control :-) > > If you can test, I committed it here: > https://github.com/astlinux-project/astlinux/commit/91892424b43818e5f78e1068c14dd05a835a3d7e > > > 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 > > |
|
From: Lonnie A. <li...@lo...> - 2019-08-17 13:38:05
|
A curious bit of info, this links shows active WordPress users and what versions of PHP (and other packages) are used on their systems... https://wordpress.org/about/stats/ PHP 5.6 is the most common, but PHP 7.2 comes in 2'nd at the time of this post. Lonnie > On Aug 16, 2019, at 2:44 PM, Lonnie Abelbeck <li...@lo...> wrote: > > Yesterday I reported some best case PHP 7 speed improvements using a PHP benchmark script. > > Today I made a real-world test of the web interface speed, and as probably expected, not much change... > > Box: Jetway NF9HG-2930, time to load Status tab with Prefs "Show NTP Time Sources" unchecked > -- > time curl -k https://localhost/status.php > -- > > PHP 5.6.40 > real 0m0.264s > > PHP 7.2.21 > real 0m0.259s > > Since our web interface does not heavily use PHP, the system calls to gather data and lighttpd network stack plays more into the processing time. > > Though some special cases like the CDR Log, SQL-Data and LDAP-AB tabs should benefit from PHP 7's improved speed. > > Here is a "CDR Log" tab test example: > -- > time curl -k --user admin:secret https://localhost/admin/cdrlog.php > -- > > PHP 5.6.40 > real 0m0.122s > > PHP 7.2.21 > real 0m0.097s > > Lonnie > > > >> On Aug 15, 2019, at 3:37 PM, Lonnie Abelbeck <li...@lo...> wrote: >> >> OK, I tried PHP 7.3.8 ... it requires pcre2 and libzip which we don't include (we use pcre and libz) >> >> I then tried PHP 7.2.21 ... still works with pcre and libz just fine. >> >> The best news is the ext/date/lib/timezonedb.h format has not changed, in fact we have offer a newer version than what comes with 7.2.21 . >> >> Oh, and it is faster :-) >> >> On an APU2: >> >> -------------------------------------- >> | PHP BENCHMARK SCRIPT | >> -------------------------------------- >> Start : 2019-08-15 14:15:15 >> CPU : AMD GX-412TC SOC >> PHP version : 5.6.40 >> Platform : Linux >> -------------------------------------- >> test_math : 12.422 sec. >> test_stringmanipulation : 12.333 sec. >> test_loops : 6.945 sec. >> test_ifelse : 4.169 sec. >> -------------------------------------- >> Total time: : 35.869 sec. >> >> ... and ... >> >> -------------------------------------- >> | PHP BENCHMARK SCRIPT | >> -------------------------------------- >> Start : 2019-08-15 14:26:29 >> CPU : AMD GX-412TC SOC >> PHP version : 7.2.21 >> Platform : Linux >> -------------------------------------- >> test_math : 2.585 sec. >> test_stringmanipulation : 3.859 sec. >> test_loops : 2.145 sec. >> test_ifelse : 2.180 sec. >> -------------------------------------- >> Total time: : 10.769 sec. >> >> DDG researching, most general benchmark tests show PHP 7 is 2x the speed of PHP 5.6 >> >> Though PHP 7.2 is bigger (both with our same custom built timezonedb.h) >> >> PHP 5.6.40 >> -rwxr-xr-x 1 root root 3580688 Aug 12 11:35 /usr/bin/php >> >> PHP 7.2.21 >> -rwxr-xr-x 1 root root 3921344 Aug 15 14:12 /usr/bin/php >> >> Note: without our custom built timezonedb.h, the 7.2.21 binary size is 4360256 >> >> I do like the idea of OpenSSL 1.1 support built-in without having to add a patch. >> >> So far, testing is going good, the can-of-worms is under control :-) >> >> If you can test, I committed it here: >> https://github.com/astlinux-project/astlinux/commit/91892424b43818e5f78e1068c14dd05a835a3d7e >> >> >> 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 >> >> > > > > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X