On Thu, October 22, 2015 11:20 am, Juan Bernhard wrote:
>
> El 22/10/2015 a las 12:48 p.m., Valeri Galtsev escribió:
>> On Thu, October 22, 2015 10:40 am, Jim Perrin wrote:
>>> On 10/22/2015 10:31 AM, Andrew Holway wrote:
>>>> Hi,
>>>> So, it seems that the current version of PHP in Centos 7 is PHP
5.4.16
>>>> however this version of PHP stopped getting security support from the
PHP
>>>> people one month ago [1].
>>>> Now, our developers want to use the new and shiny PHP because they want
>>>> to
>>>> use the latest version of Zend. They are proposing using this package
[2]
>>>> but I never heard of this repo.
>> For me it sound like an example of the difference between "bleeding edge"
>> and "enterprise" systems. The first is what developers most often like,
the second is what humble sysadmins prefer as they have to keep
something
>> developed long ago running for as long as possible - and without crashed,
>> daemons dying etc (== "bleeding" which always accompanies "bleeding edge"
>> anything). Sorry for venting my own usual pain here...
>> Valeri
>
> PHP 5.4 is in EOL, it get no more security updates from PHP
> developers... its may be a security risk to use this in in long term.
centos should change the php version more ofthen. I dont uderstand
centos 6, its still using php 5.3, who got EOL a year ago... I had to
switch to another repo to get this (to not get the headache by compile
by hand).
> If you want to change to a log term support, you should use php 5.6,
this is under active development now.
> centos packagers mantainers should listen the PHP developers in this
topic, they are the ones who really knows PHP
> http://php.net/supported-versions.php
>
This yet once more exemplifies the point I was trying to make. If I build
new system (with new components of end point software using, say PHP),
then I would pick the latest stable version of PHP. Exactly as you are
point out. And I prefer to roll new box out with all latest stable
everything. From this point on, once I have the box in production, I often
have no luxury (when time goes by) to upgrade some components other stuff
needs to run with. Like PHP that will be latest stable 3 years down the
road will be several minor versions up, and some of my end components may
not run with it as some internals may have changed. At this point it is
exactly what I am trying to stress: either I break things that I have no
newer version that works with latest version of PHP, or I can stay with
older version of PHP - if at all possible. This is basically the
difference between, say, Debian (and clones) style of updates/upgrades
(when update bring you new version of package) and RH Enterprise Linux
which keeps older version (thus preserving all internals), and [doing
tremendous job of] backporting security and bug fixes implemented in new
version to older version. At least this is what we loved about RHEL - not
quite sure to what extent it still is true recently.
The best example of really troublesome compatibility would be python and
modules for it. To my python developers and users I call python a "sneaky
snake". Whoever worked with python and modules written for it knows what I
talk about: you always beed to match versions of modules rather rigorously
the version of python itself, or things will not work. There is, however
excellent "Enterprise" piece of software written in python: mailman. I
really never had any trouble of any kind with mailman. This is what I
figure Mark meant when he said you can write software which will work with
big range of different versions of whatever it depends on - he is (was?)
developer, he knows what he is talking about.
Valeri
++++++++++++++++++++++++++++++++++++++++
Valeri Galtsev
Sr System Administrator
Department of Astronomy and Astrophysics
Kavli Institute for Cosmological Physics
University of Chicago
Phone: 773-702-4247
++++++++++++++++++++++++++++++++++++++++
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
