Warren Young schrieb:> On May 23, 2017, at 10:44 AM, hw <hw at gc-24.de> wrote: >> >> are there packages replacing the ancient perl version in >> Centos 7 with a more recent one, like 5.24? > > Since when is Perl 5.16 ?ancient?? It?s only 4 years old. > > CentOS 5 just left supported status, which shipped Perl 5.8.8 from first release to last, which means I?ll probably still be limited to Perl 5.8 features for a few years yet, since the remaining CentOS 5 boxes I?m supporting can?t be upgraded and won?t likely be turned off until they fall over dead. That makes Perl 5.10 ?the future? from my perspective.Living in the past seldwhen is a good idea.> If this sort of stance seems risible to you, you probably shouldn?t be using CentOS. This is what distinguishes a ?stable? type of OS from a ?bleeding edge? one.When a version of a software has been released 20 years ago, that doesn?t mean it?s more stable than a version of that software which is being released today. Of course, you can consider "never change the version of the software" as something making for a stable OS. But what about the bug fixes?> >> At least the state feature is required. > > According to the docs,[*] that feature has been in Perl since 5.10. This appears to confirm it: > > $ perl -e "use feature 'state'" && echo yes > > Are you looking for something else, or do you have a simple test case that shows what?s provided in CentOS 7 is insufficient?Ah, yes, that does work. Sorry, I guess it was signatures rather than state. I?m getting Feature "signatures" is not supported by Perl 5.16.3 at ... with CGI scripts. And who knows what else might cause problems. The software has been written with perl 5.20.1, which is already rather old.> > > [*]: http://perldoc.perl.org/feature.html#The-'state'-feature > > _______________________________________________ > CentOS mailing list > CentOS at centos.org > https://lists.centos.org/mailman/listinfo/centos >
> > > If this sort of stance seems risible to you, you probably shouldn?t > > be using CentOS. This is what distinguishes a ?stable? type of OS > > from a ?bleeding edge? one. > > When a version of a software has been released 20 years ago, > that doesn?t mean it?s more stable than a version of that > software which is being released today.Not "software", Warren said "OS" - it's the whole ecosystem that is more stable if the versions of the software that's within it are kept consistent.> > Of course, you can consider "never change the version of the > software" as something making for a stable OS. But what about > the bug fixes?Critical bug fixes are back ported, if appropriate, into the version of the software packaged with the OS - that is the point of the commitment by RH to support the OS.> > The software has been written with perl 5.20.1, which is already > rather old.As far as I can see it hadn't been released when RHEL7 was released, so there's no chance of it being the default version. As others have said, if you need bang up-to-date versions of software, then RHEL/CentOS is not for you. P.
Pete Biggs schrieb:> >> >>> If this sort of stance seems risible to you, you probably shouldn?t >>> be using CentOS. This is what distinguishes a ?stable? type of OS >>> from a ?bleeding edge? one. >> >> When a version of a software has been released 20 years ago, >> that doesn?t mean it?s more stable than a version of that >> software which is being released today. > > Not "software", Warren said "OS" - it's the whole ecosystem that is > more stable if the versions of the software that's within it are kept > consistent. > >> >> Of course, you can consider "never change the version of the >> software" as something making for a stable OS. But what about >> the bug fixes? > > Critical bug fixes are back ported, if appropriate, into the version of > the software packaged with the OS - that is the point of the commitment > by RH to support the OS.That?s a good thing. I thought they were more about security updates than bug fixes.>> The software has been written with perl 5.20.1, which is already >> rather old. > > As far as I can see it hadn't been released when RHEL7 was released, so > there's no chance of it being the default version. > > As others have said, if you need bang up-to-date versions of software, > then RHEL/CentOS is not for you.So far, the perl version is the only problem I?ve found. I?d prefer getting things to work with Centos rather than using multiple different distributions on the servers, including the VMs. It would make things easier.
On May 24, 2017, at 6:02 AM, hw <hw at gc-24.de> wrote:> > Warren Young schrieb: >> >> CentOS 5 just left supported status, which shipped Perl 5.8.8 from first release to last > > Living in the past seldwhen is a good idea.I don?t propose to teach you about my problems ? they are, after all, mine, and I?m coping with them quite well, thank you ? but I?ll give you a glimpse into someone else?s as a lesson: the San Francisco Bay Area Rapid Transit System was still running on PDP-8s as of several years ago, and may still be doing so. As I understand it, they were using a modified PDP-8/e, which is 1970 tech. Note that I didn?t say ?1970?s.? I mean the year nineteen hundred and seventy, A.D. The PDP-8/e is just an enhanced version of the original PDP-8 from 1965, which is itself not a huge departure from the PDP-5, from 1963. And you know what? The PDP-8/e is still well suited to the task. Trains haven?t changed that much in the intervening decades, and the construction techniques used by that era of computer mean it?s still repairable with little more than a soldering iron. We have 40-cent microcontrollers with equivalent computing power to a PDP-8/e today that run on far less power, but you?d have to pile up a bunch of I/O interfacing in front of them to make it as electrically capable and robust as a PDP-8/e, and you?d have to re-develop all the software, too. The modern tendency would not be to use one of those 40-cent micros, it would instead be to put a gigahertz class Linux PC in its place, with all the concomitant risks. Try getting a modern Internet worm into a PDP-8! Good luck not blowing the 4k word field boundary.>> If this sort of stance seems risible to you, you probably shouldn?t be using CentOS. This is what distinguishes a ?stable? type of OS from a ?bleeding edge? one. > > When a version of a software has been released 20 years ago,Eleven: https://dev.perl.org/perl5/news/2006/perl-5.8.8.html ?which makes it younger than the C89 standard some still stick to over in C land. And younger than C99. And younger than C++-98. And C++-93. By your lights, the C/C++ world is positive decrepit for not immediately tossing everything and insisting on C11 and C++-14.> that doesn?t mean it?s more stable than a version of that > software which is being released today.Actually, it does, provided it?s still being maintained, as Perl 5.8.8 was up to a few months ago. Software that gets no new features also gets no new bugs. Therefore, the overall bug count can only go down. The distinction you may be looking for is that there is a fine line between ?stable? and ?moribund.? RHEL/CentOS rides that line much closer than some other OSes, but it actively stays on the good side of the line. After that end-of-support date, sometimes all it takes to slip over to the bad side of the line is a new exploit or similar, but decades-old exploit targets are very rare. More commonly, something changes in the environment to make the old software unsuitable, as happened with BIND 4 and Apache 1.3. You couldn?t drag either of those forward into the modern world without major rework, so people running on them were forced to transition. I don?t see that happening with Perl 5.8. It was an uncommonly good release of a language that was already quite stable by that point. It is, after all, the fourth major version after Perl 5.0. You?d *expect* it to be stable by that point. The only question then, is whether you can live without the new features. I can.> what about the bug fixes?Red Hat was backporting them up until a few months ago. Now we just get to see how fast it bit-rots without Red Hat?s support. I don?t expect it to do so quickly.> Feature "signatures" is not supported by Perl 5.16.3 at ?Again, see the docs: https://perldoc.perl.org/perlsub.html#Signatures I note that this feature is still marked experimental and subject to removal. ?And you?re lecturing me about stability?
On Wed, May 24, 2017 8:46 am, Warren Young wrote:> On May 24, 2017, at 6:02 AM, hw <hw at gc-24.de> wrote: >> >> Warren Young schrieb: >>> >>> CentOS 5 just left supported status, which shipped Perl 5.8.8 from >>> first release to last >> >> Living in the past seldwhen is a good idea. > > I don???t propose to teach you about my problems ??? they are, after all, > mine, and I???m coping with them quite well, thank you ??? but I???ll give > you a glimpse into someone else???s as a lesson: the San Francisco Bay > Area Rapid Transit System was still running on PDP-8s as of several years > ago, and may still be doing so.Warren, thanks a lot for this long and extremely instructive post!! I'm with you on all counts. Valeri> > As I understand it, they were using a modified PDP-8/e, which is 1970 > tech. Note that I didn???t say ???1970???s.??? I mean the year nineteen > hundred and seventy, A.D. The PDP-8/e is just an enhanced version of the > original PDP-8 from 1965, which is itself not a huge departure from the > PDP-5, from 1963. > > And you know what? The PDP-8/e is still well suited to the task. Trains > haven???t changed that much in the intervening decades, and the > construction techniques used by that era of computer mean it???s still > repairable with little more than a soldering iron. > > We have 40-cent microcontrollers with equivalent computing power to a > PDP-8/e today that run on far less power, but you???d have to pile up a > bunch of I/O interfacing in front of them to make it as electrically > capable and robust as a PDP-8/e, and you???d have to re-develop all the > software, too. > > The modern tendency would not be to use one of those 40-cent micros, it > would instead be to put a gigahertz class Linux PC in its place, with all > the concomitant risks. > > Try getting a modern Internet worm into a PDP-8! Good luck not blowing > the 4k word field boundary. > >>> If this sort of stance seems risible to you, you probably shouldn???t >>> be using CentOS. This is what distinguishes a ???stable??? type of OS >>> from a ???bleeding edge??? one. >> >> When a version of a software has been released 20 years ago, > > Eleven: https://dev.perl.org/perl5/news/2006/perl-5.8.8.html > > ???which makes it younger than the C89 standard some still stick to over > in C land. And younger than C99. And younger than C++-98. And C++-93. > > By your lights, the C/C++ world is positive decrepit for not immediately > tossing everything and insisting on C11 and C++-14. > >> that doesn??t mean it??s more stable than a version of that >> software which is being released today. > > Actually, it does, provided it???s still being maintained, as Perl 5.8.8 > was up to a few months ago. Software that gets no new features also gets > no new bugs. Therefore, the overall bug count can only go down. > > The distinction you may be looking for is that there is a fine line > between ???stable??? and ???moribund.??? RHEL/CentOS rides that line much > closer than some other OSes, but it actively stays on the good side of the > line. > > After that end-of-support date, sometimes all it takes to slip over to the > bad side of the line is a new exploit or similar, but decades-old exploit > targets are very rare. > > More commonly, something changes in the environment to make the old > software unsuitable, as happened with BIND 4 and Apache 1.3. You > couldn???t drag either of those forward into the modern world without > major rework, so people running on them were forced to transition. > > I don???t see that happening with Perl 5.8. It was an uncommonly good > release of a language that was already quite stable by that point. It is, > after all, the fourth major version after Perl 5.0. You???d *expect* it > to be stable by that point. > > The only question then, is whether you can live without the new features. > I can. > >> what about the bug fixes? > > Red Hat was backporting them up until a few months ago. > > Now we just get to see how fast it bit-rots without Red Hat???s support. > > I don???t expect it to do so quickly. > >> Feature "signatures" is not supported by Perl 5.16.3 at ??? > > Again, see the docs: > > https://perldoc.perl.org/perlsub.html#Signatures > > I note that this feature is still marked experimental and subject to > removal. > > ???And you???re lecturing me about stability? > _______________________________________________ > CentOS mailing list > CentOS at centos.org > https://lists.centos.org/mailman/listinfo/centos >++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
Warren Young schrieb:> On May 24, 2017, at 6:02 AM, hw <hw at gc-24.de> wrote: >> >> Warren Young schrieb: >>> >>> CentOS 5 just left supported status, which shipped Perl 5.8.8 from first release to last >> >> Living in the past seldwhen is a good idea. > > I don?t propose to teach you about my problems ? they are, after all, mine, and I?m coping with them quite well, thank you ? but I?ll give you a glimpse into someone else?s as a lesson: the San Francisco Bay Area Rapid Transit System was still running on PDP-8s as of several years ago, and may still be doing so. > > As I understand it, they were using a modified PDP-8/e, which is 1970 tech. Note that I didn?t say ?1970?s.? I mean the year nineteen hundred and seventy, A.D. The PDP-8/e is just an enhanced version of the original PDP-8 from 1965, which is itself not a huge departure from the PDP-5, from 1963. > > And you know what? The PDP-8/e is still well suited to the task. Trains haven?t changed that much in the intervening decades, and the construction techniques used by that era of computer mean it?s still repairable with little more than a soldering iron. > > We have 40-cent microcontrollers with equivalent computing power to a PDP-8/e today that run on far less power, but you?d have to pile up a bunch of I/O interfacing in front of them to make it as electrically capable and robust as a PDP-8/e, and you?d have to re-develop all the software, too. > > The modern tendency would not be to use one of those 40-cent micros, it would instead be to put a gigahertz class Linux PC in its place, with all the concomitant risks. > > Try getting a modern Internet worm into a PDP-8! Good luck not blowing the 4k word field boundary. >Trains are a technology well over a hundred years old. If they can be driven by technology about 50 years old and if there?s no better alternative and if you can keep it working, then why not. Still living in the past seldwhen is a good idea.>>> If this sort of stance seems risible to you, you probably shouldn?t be using CentOS. This is what distinguishes a ?stable? type of OS from a ?bleeding edge? one. >> >> When a version of a software has been released 20 years ago, > > Eleven: https://dev.perl.org/perl5/news/2006/perl-5.8.8.htmlIt doesn?t matter how many years exactly it was.> > ?which makes it younger than the C89 standard some still stick to over in C land. And younger than C99. And younger than C++-98. And C++-93. > > By your lights, the C/C++ world is positive decrepit for not immediately tossing everything and insisting on C11 and C++-14. > >> that doesn?t mean it?s more stable than a version of that >> software which is being released today. > > Actually, it does, provided it?s still being maintained, as Perl 5.8.8 was up to a few months ago. Software that gets no new features also gets no new bugs. Therefore, the overall bug count can only go down.Bug fixes may also introduce new bugs. Usually, derelict versions of software are not being maintained anymore but replaced by more recent versions.> The distinction you may be looking for is that there is a fine line between ?stable? and ?moribund.? RHEL/CentOS rides that line much closer than some other OSes, but it actively stays on the good side of the line. > > After that end-of-support date, sometimes all it takes to slip over to the bad side of the line is a new exploit or similar, but decades-old exploit targets are very rare. > > More commonly, something changes in the environment to make the old software unsuitable, as happened with BIND 4 and Apache 1.3. You couldn?t drag either of those forward into the modern world without major rework, so people running on them were forced to transition. > > I don?t see that happening with Perl 5.8. It was an uncommonly good release of a language that was already quite stable by that point. It is, after all, the fourth major version after Perl 5.0. You?d *expect* it to be stable by that point. > > The only question then, is whether you can live without the new features. I can. > >> what about the bug fixes? > > Red Hat was backporting them up until a few months ago. > > Now we just get to see how fast it bit-rots without Red Hat?s support. > > I don?t expect it to do so quickly. > >> Feature "signatures" is not supported by Perl 5.16.3 at ? > > Again, see the docs: > > https://perldoc.perl.org/perlsub.html#Signatures > > I note that this feature is still marked experimental and subject to removal.I?m aware of that, and the docs do not say that it will be removed, only that it may. That is no more and no less what is usually being said about experimental features in perl.> ?And you?re lecturing me about stability?Not at all; it seems to me that you are the one wanting to lecture about stability. It doesn?t matter. I do not want to rewrite the software to accomodate an ancient version of perl that has already been replaced by several more recent versions. You wouldn?t rewrite the software that runs your trains either despite hardware which is already 50 years old my be removed in the future with more certainty than the feature signatures from perl. Understanding "stability" as "not changing over long periods of time" is certainly one possible understanding. Stability of that kind is simply not feasible within an environment that continues to change, sometimes on a daily basis, and entities that do not change simply die out.
On Wed, May 24, 2017 at 6:02 AM, hw <hw at gc-24.de> wrote:> > Ah, yes, that does work. Sorry, I guess it was signatures rather > than state. I?m getting > > > Feature "signatures" is not supported by Perl 5.16.3 at ... > > > with CGI scripts. And who knows what else might cause problems. > > The software has been written with perl 5.20.1, which is already > rather old.?From perldoc perlsub: Signatures WARNING: Subroutine signatures are experimental. The feature may be modified or removed in future versions of Perl. ? ?And according to perldelta the signature syntax did change between 5.20 and 5.24. This is bleeding edge. My perl code is deployed on CentOS, but I also test it on Fedora to ensure an upgrade path. ?I think you should have a talk with your developers or software vendor about the supported deployment environment and path for perl and system upgrades.