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.html It 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.