Hi,
are there packages replacing the ancient perl version in Centos 7 with a more recent one, like 5.24? At least the state feature is required.
On Tue, 23 May 2017, m.roth@5-cent.us wrote:
hw wrote:
are there packages replacing the ancient perl version in Centos 7 with a more recent one, like 5.24? At least the state feature is required.
Perl 5.24 is available in SCL, in the centos-sclo-rh repository.
[root ~]# yum info rh-perl524-perl Name : rh-perl524-perl Arch : x86_64 Epoch : 4 Version : 5.24.0 Release : 379.el7 Size : 6.0 M Repo : centos-sclo-rh/x86_64 Summary : Practical Extraction and Report Language
Paul Heinlein schrieb:
On Tue, 23 May 2017, m.roth@5-cent.us wrote:
hw wrote:
are there packages replacing the ancient perl version in Centos 7 with a more recent one, like 5.24? At least the state feature is required.
Perl 5.24 is available in SCL, in the centos-sclo-rh repository.
[root ~]# yum info rh-perl524-perl Name : rh-perl524-perl Arch : x86_64 Epoch : 4 Version : 5.24.0 Release : 379.el7 Size : 6.0 M Repo : centos-sclo-rh/x86_64 Summary : Practical Extraction and Report Language
Thanks, I tried rh-perl, and it worked for a test. It does not replace the existing perl installation. You have to explicitly use that version.
I�m not sure if that�s possible for CGI. I do get 5.24 after running 'scl enable rh-perl524 bash'. Is there a way to get that for CGI?
Thanks, I tried rh-perl, and it worked for a test. It does not replace the existing perl installation. You have to explicitly use that version.
Yes, that's how SCL works. A lot of system software uses perl (and python and gcc) so replacing the installed version without testing the effect it might have on the system is not advisable. i.e. things will break. The whole point of the RHEL/CentOS is that the versions of software are stable (strong and stable even) and that everything is exhaustively tested to make sure things work.
Im not sure if thats possible for CGI. I do get 5.24 after running 'scl enable rh-perl524 bash'. Is there a way to get that for CGI?
All (!) that the 'scl enable' command does is to set environment variables for things like PATH and LD_LIBRARY_PATH. If you can do that for the CGI environment, then it will pick up the correct perl version. But don't ever be tempted to make updated versions the default.
P.
Pete Biggs schrieb:
Thanks, I tried rh-perl, and it worked for a test. It does not replace the existing perl installation. You have to explicitly use that version.
Yes, that's how SCL works. A lot of system software uses perl (and python and gcc) so replacing the installed version without testing the effect it might have on the system is not advisable. i.e. things will break. The whole point of the RHEL/CentOS is that the versions of software are stable (strong and stable even) and that everything is exhaustively tested to make sure things work.
Im not sure if thats possible for CGI. I do get 5.24 after running 'scl enable rh-perl524 bash'. Is there a way to get that for CGI?
All (!) that the 'scl enable' command does is to set environment variables for things like PATH and LD_LIBRARY_PATH. If you can do that for the CGI environment, then it will pick up the correct perl version. But don't ever be tempted to make updated versions the default.
Apparently that doesn�t work because apache uses mod_perl, which keeps it stuck at the ancient version of perl.
But there is a package 'rh-perl524-mod_perl'. It pulls in 'httpd24-httpd' and other things. Now if I can figure out how to use that, it�ll probably work ...
P.
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On May 24, 2017, at 7:05 AM, hw hw@gc-24.de wrote:
apache uses mod_perl
mod_perl was dropped from Apache in 2.4, and Red Hat followed suit with RHEL 7.
But there is a package 'rh-perl524-mod_perl’.
That must be someone’s backport. As someone who migrated a mod_perl based app off of mod_perl several years ago, I recommend that you do not use it, unless you have old mod_perl based software that you cannot migrate to newer technologies like FastCGI, Plack, etc.
I hope this does not strike you as inconsistent with respect to my prior posts, since that would be to construct a false equivalence between abandoned software and maintained stable software that is getting no new features.
Also, you speak of CGI. CGI is not at all the same thing as mod_perl. You use one or the other, not both together. You’d know it if you were using mod_perl.
Warren Young schrieb:
On May 24, 2017, at 7:05 AM, hw hw@gc-24.de wrote:
apache uses mod_perl
mod_perl was dropped from Apache in 2.4, and Red Hat followed suit with RHEL 7.
What is it using instead?
The rh-httpd24 does not seem to use a more recent version of perl.
But there is a package 'rh-perl524-mod_perl’.
That must be someone’s backport. As someone who migrated a mod_perl based app off of mod_perl several years ago, I recommend that you do not use it, unless you have old mod_perl based software that you cannot migrate to newer technologies like FastCGI, Plack, etc.
Migrating it is one thing I need look into.
I hope this does not strike you as inconsistent with respect to my prior posts, since that would be to construct a false equivalence between abandoned software and maintained stable software that is getting no new features.
Not at all --- the point is that software usually becomes abandoned once a more recent version becomes available.
Also, you speak of CGI. CGI is not at all the same thing as mod_perl. You use one or the other, not both together. You’d know it if you were using mod_perl.
I never really cared what it´s using because it simply works. Only it doesn´t work on Centos because the perl version it uses is too old.
Since I don´t want to rewrite the software, what else can I do but look for a way to get it to work before concluding that Centos is not suited for this purpose.
On May 24, 2017, at 9:38 AM, hw hw@gc-24.de wrote:
Warren Young schrieb:
On May 24, 2017, at 7:05 AM, hw hw@gc-24.de wrote:
apache uses mod_perl
mod_perl was dropped from Apache in 2.4, and Red Hat followed suit with RHEL 7.
What is it using instead?
There are various options. We use mod_fcgid + Plack here.
And atop that, Dancer, if you care. http://perldancer.org/ Join me on the Dancer ML if you want to talk further about it.
I hope this does not strike you as inconsistent with respect to my prior posts, since that would be to construct a false equivalence between abandoned software and maintained stable software that is getting no new features.
Not at all --- the point is that software usually becomes abandoned once a more recent version becomes available.
And that’s what we keep trying to tell you: in the RHEL/CentOS world, that simply is not the case, because there is a multibillion-dollar entity ensuring that it is not so.
All hail the benefactors!
Warren Young wrote:
On May 24, 2017, at 9:38 AM, hw hw@gc-24.de wrote:
Warren Young schrieb:
On May 24, 2017, at 7:05 AM, hw hw@gc-24.de wrote:
apache uses mod_perl
mod_perl was dropped from Apache in 2.4, and Red Hat followed suit with RHEL 7.
What is it using instead?
There are various options. We use mod_fcgid + Plack here.
I need to look into that when I have time. Test have shown that lighttpd apparently is somewhat faster than apache2, and I´m planning to use it instead of apache for what apache is doing atm.
And atop that, Dancer, if you care. http://perldancer.org/ Join me on the Dancer ML if you want to talk further about it.
I hope this does not strike you as inconsistent with respect to my prior posts, since that would be to construct a false equivalence between abandoned software and maintained stable software that is getting no new features.
Not at all --- the point is that software usually becomes abandoned once a more recent version becomes available.
And that’s what we keep trying to tell you: in the RHEL/CentOS world, that simply is not the case, because there is a multibillion-dollar entity ensuring that it is not so.
That´s a good thing, though it can be difficult to run systems using ancient software.
On 2/6/2017 2:05 μμ, hw wrote:
That´s a good thing, though it can be difficult to run systems using ancient software.
You may want to check the following paradigm (from another open source perl-based application) to create a Perl environment within your system, avoiding to tamper with it:
https://metacpan.org/pod/App::Netdisco#Installation
We are running it in production for years and has been great in maintenance and operation (despite my initial fears).
Alternatively, you can use a container. See for example:
https://linuxcontainers.org/ http://www.itzgeek.com/how-tos/linux/centos-how-tos/setup-linux-container-wi... http://www.perlmonks.org/index.pl?node_id=1034720
Cheers, Nick
Nikolaos Milas wrote:
On 2/6/2017 2:05 μμ, hw wrote:
That´s a good thing, though it can be difficult to run systems using ancient software.
You may want to check the following paradigm (from another open source perl-based application) to create a Perl environment within your system, avoiding to tamper with it:
That´s for network monitoring.
We are running it in production for years and has been great in maintenance and operation (despite my initial fears).
Alternatively, you can use a container. See for example:
https://linuxcontainers.org/ http://www.itzgeek.com/how-tos/linux/centos-how-tos/setup-linux-container-wi... http://www.perlmonks.org/index.pl?node_id=1034720
Containers are a bit quirky; I´m running two at home and one of them every now and then gets its /dev/null deleted on reboots, which causes trouble. I wouldn´t want that to happen here. Networking capabilities are also limited.
Other than that, I agree that it would probably be better to use a container for the purpose rather than another VM.
On Jun 2, 2017, at 5:05 AM, hw hw@gc-24.de wrote:
Warren Young wrote:
There are various options. We use mod_fcgid + Plack here.
I need to look into that when I have time.
I wonder if it wouldn’t have been faster to just backport the app to Perl 5.16? How hard could it be? It’s not like Perl 5.16 is a hopelessly lame and incapable language.
The recommendation to replace mod_perl with mod_fcgid comes from the RHEL 7 release notes: http://goo.gl/fZxHw9
After sending that message, I remembered that we rejected that option once we found out that when you build your app under Plack, it serves content via a Perl web server using a standard interface called PSGI. That Perl web server normally binds to localhost on a high-numbered TCP port, so we just stood Apache up in front of it as a reverse proxy. That avoids the security hassles of binding to TCP port 80, and it lets us foist the static content serving load off on Apache, so that the Perl layer serves only dynamic content.
There are many PSGI-aware web servers:
The default used by Plack is HTTP::Server::Simple, which is probably fast enough for your purposes if CGI remains appropriate for your app.
If you were already trying to get off CGI to make the app faster, many of the alternatives in that list will get you that speed.
The mod_fcgid method may be easier to port to, since you’re already using CGI, however.
Test have shown that lighttpd apparently is somewhat faster than apache2
This is generally true only at fairly high loads, up in the thousands of connections per second. Distinguishing this also requires that the bottleneck be in the web server, not in the web app it’s serving.
Since your app is currently running via CGI, one of two conditions is true:
1. You have chosen well: CGI is appropriate for your application, in which case all web servers with the features you need are interchangeable, because the bottleneck is CGI, not the web server.
2. You have chosen poorly: CGI is slowing your app down enough that end users notice the speed hit, in which case you need to get off CGI before you start chasing nonstandard web servers, because speeding up the web server won’t solve the primary bottleneck.
(“Nonstandard” meaning that lighttpd is not in the stock CentOS 7 repos. You have to reach out to EPEL to get it.)
This is not to say that different web servers don’t have advantages even in the CGI case. I run nginx in one extra-small VPS because I don’t have the RAM to run Apache. I couldn’t put enough load on that server to tell any speed difference between Apache and nginx without running it out of CPU or network bandwidth first.
it can be difficult to run systems using ancient software.
“You keep using that word. I do not think it means what you think it does.”
— Inigo Montoya
Warren Young wrote:
On Jun 2, 2017, at 5:05 AM, hw hw@gc-24.de wrote:
Warren Young wrote:
There are various options. We use mod_fcgid + Plack here.
I need to look into that when I have time.
I wonder if it wouldn’t have been faster to just backport the app to Perl 5.16? How hard could it be? It’s not like Perl 5.16 is a hopelessly lame and incapable language.
It would be possible. There are reasons to use that feature, though, and those reasons remain.
The recommendation to replace mod_perl with mod_fcgid comes from the RHEL 7 release notes: http://goo.gl/fZxHw9
After sending that message, I remembered that we rejected that option once we found out that when you build your app under Plack, it serves content via a Perl web server using a standard interface called PSGI. That Perl web server normally binds to localhost on a high-numbered TCP port, so we just stood Apache up in front of it as a reverse proxy. That avoids the security hassles of binding to TCP port 80, and it lets us foist the static content serving load off on Apache, so that the Perl layer serves only dynamic content.
There are many PSGI-aware web servers:
http://plackperl.org/#serversThe default used by Plack is HTTP::Server::Simple, which is probably fast enough for your purposes if CGI remains appropriate for your app.
If you were already trying to get off CGI to make the app faster, many of the alternatives in that list will get you that speed.
The mod_fcgid method may be easier to port to, since you’re already using CGI, however.
I have no idea. I´m not a web developer, so I´m using CGI as a simple means for the users to use the programs, with a few of the advantages a web browser offers for displaying stuff. There are less than 10 users.
Perl is pretty fast, and most of the work is being done by the database, so I´m not sure how using an alternative to CGI could make things go faster. Apparently it´s possible to save the overhead of compiling the perl programs and of opening connections to the database for every request. Currently, it is questionable if things would go so much faster as to be worthwhile spending days or weeks on changing and debugging a working system.
Test have shown that lighttpd apparently is somewhat faster than apache2
This is generally true only at fairly high loads, up in the thousands of connections per second. Distinguishing this also requires that the bottleneck be in the web server, not in the web app it’s serving.
I simply had the impression that responses came faster, with me being the only user. So what would speak against using lighttpd?
Since your app is currently running via CGI, one of two conditions is true:
You have chosen well: CGI is appropriate for your application, in which case all web servers with the features you need are interchangeable, because the bottleneck is CGI, not the web server.
You have chosen poorly: CGI is slowing your app down enough that end users notice the speed hit, in which case you need to get off CGI before you start chasing nonstandard web servers, because speeding up the web server won’t solve the primary bottleneck.
(“Nonstandard” meaning that lighttpd is not in the stock CentOS 7 repos. You have to reach out to EPEL to get it.)
I consider Centos as pretty much unusable without software from additional sources. It´s not like all its advantages disappear when using such software, and it´s not like all the required software is included. It´s also not like such software doesn´t work.
There isn´t an ideal solution, either, so why not use Centos for its significant advantages and adjusting it according to what´s needed. So far, it´s working great.
This is not to say that different web servers don’t have advantages even in the CGI case. I run nginx in one extra-small VPS because I don’t have the RAM to run Apache. I couldn’t put enough load on that server to tell any speed difference between Apache and nginx without running it out of CPU or network bandwidth first.
See above, it was merely my impression, not a relevant test. If it works as well and if users get the same impression, it´s fine. If it doesn´t work, I can still use apache.
it can be difficult to run systems using ancient software.
“You keep using that word. I do not think it means what you think it does.”
— Inigo Montoya
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On Jun 3, 2017, at 4:13 AM, hw hw@gc-24.de wrote:
I´m using CGI as a simple means for the users to use the programs...There are less than 10 users.
If we’re talking less than one full page hit per second, then it doesn’t much matter what technology you use. You won’t be able to tell from the end user’s perspective.
(“One” meaning the page and all its static assets, not the inflated count from all the PNGs, JS files, etc. that may be pulled in by the page proper.)
Perl is pretty fast, and most of the work is being done by the database, so I´m not sure how using an alternative to CGI could make things go faster.
There are many reasons CGI is relatively slow.
1. If you have many connections per second, you need a parallelizable technology to make things go fast. If everything chokes down to a single thread, you’ve got a serious bottleneck when the CPS count gets high enough.
2. CGI re-launches the cgi-bin/* programs on every page hit. Since Perl doesn’t leave behind “compiled” forms of the program as some other dynamic languages do (e.g. *.pyc in Python, *.beam in Erlang) it has to do the entire re-compilation over again.
With FastCGI or Plack, the app remains running once launched, serving hit after hit using the same instance.
3. A follow-on advantage from the above is that you also don’t have to re-establish other runtime resources like DB connections, file handles, application state, etc. You can just keep it in RAM and access it repeatedly on each hit.
But again, down below about 1 CPS, the differences cease to matter, unless you’ve got the sort of app where the difference between a response time of 50 vs 100 ms matters.
Test have shown that lighttpd apparently is somewhat faster than apache2
This is generally true only at fairly high loads, up in the thousands of connections per second. Distinguishing this also requires that the bottleneck be in the web server, not in the web app it’s serving.
I simply had the impression that responses came faster, with me being the only user.
Not really. With only 10 clients, you likely have 1 or 0 concurrent hits at any one time, which means any web server is probably fast enough. You could probably swap out Apache for HTTP::Server::Simple and still not notice the speed hit.
So what would speak against using lighttpd?
If you had to serve thousands of CPS or needed to serve the app in very little RAM, it might be worth switching from Apache to nginx or lighttpd, but since neither applies in your case, you might as well stick with Apache, since that’s the standard web server in CentOS.
On 6/5/2017 7:21 AM, Warren Young wrote:
On Jun 3, 2017, at 4:13 AM, hw hw@gc-24.de wrote:
Perl is pretty fast, and most of the work is being done by the database, so I´m not sure how using an alternative to CGI could make things go faster.
There are many reasons CGI is relatively slow.
If you have many connections per second, you need a parallelizable technology to make things go fast. If everything chokes down to a single thread, you’ve got a serious bottleneck when the CPS count gets high enough.
CGI re-launches the cgi-bin/* programs on every page hit. Since Perl doesn’t leave behind “compiled” forms of the program as some other dynamic languages do (e.g. *.pyc in Python, *.beam in Erlang) it has to do the entire re-compilation over again.
With FastCGI or Plack, the app remains running once launched, serving hit after hit using the same instance.
- A follow-on advantage from the above is that you also don’t have to re-establish other runtime resources like DB connections, file handles, application state, etc. You can just keep it in RAM and access it repeatedly on each hit.
But again, down below about 1 CPS, the differences cease to matter, unless you’ve got the sort of app where the difference between a response time of 50 vs 100 ms matters.
Along these lines, SpeedyCGI forms an interesting middle ground between apache-layer perl runtimes and simple CGI re-execution.
If your perl scripts are already mod_perl-safe or have been written with persistency in mind (properly preparing SQL statements, reusing handles, clean variables, etc.), a simple shebang exchange can give you quite a large performance boost, as you're trading an entire perl compilation and execution for a small C wrapper that connects to an existing perl runtime.
Although upstream hasn't had any changes to it in nigh 15 years, it's still right there and available in EPEL 7 as perl-CGI-SpeedyCGI. I'd suggest giving it a shot.
HTH, -jc
On Wed, 24 May 2017, hw wrote:
Paul Heinlein schrieb:
On Tue, 23 May 2017, m.roth@5-cent.us wrote:
hw wrote:
are there packages replacing the ancient perl version in Centos 7 with a more recent one, like 5.24? At least the state feature is required.
Perl 5.24 is available in SCL, in the centos-sclo-rh repository.
Thanks, I tried rh-perl, and it worked for a test. It does not replace the existing perl installation. You have to explicitly use that version.
Not replacing the existing system Perl is a feature, not a bug. It allows the 'Enterprise' side of CentOS to keep going with no unexpected surprises.
I?m not sure if that?s possible for CGI. I do get 5.24 after running 'scl enable rh-perl524 bash'. Is there a way to get that for CGI?
It all depends on how you launch your CGI, but in general there shouldn't be a problem beginning your script with
#!/opt/rh/.../perl
Paul Heinlein schrieb:
On Wed, 24 May 2017, hw wrote:
Paul Heinlein schrieb:
On Tue, 23 May 2017, m.roth@5-cent.us wrote:
hw wrote:
> are there packages replacing the ancient perl version in
Centos 7 with a more recent one, like 5.24? At least the state feature is required.
Perl 5.24 is available in SCL, in the centos-sclo-rh repository.
Thanks, I tried rh-perl, and it worked for a test. It does not replace the existing perl installation. You have to explicitly use that version.
Not replacing the existing system Perl is a feature, not a bug. It allows the 'Enterprise' side of CentOS to keep going with no unexpected surprises.
I?m not sure if that?s possible for CGI. I do get 5.24 after running 'scl enable rh-perl524 bash'. Is there a way to get that for CGI?
It all depends on how you launch your CGI, but in general there shouldn't be a problem beginning your script with
#!/opt/rh/.../perl
It seems that lighttpd uses the perl version that is assigned in the configuration while ignoring the LIBRARY_PATH variable set with mod_setenv, causing the perl version not to find a library it requires.
Even with a shell script as wrapper that sets and exports LIBRARY_PATH, perl can not find the library. Trying to set LIBRARY_PATH for lighttpd through systemd also doesn�t work.
Why is the LIBRARY_PATH always being ignored? When I run perl from the shell, it works just fine, so it�s not perl itself ignoring the path.
On May 24, 2017, at 1:58 PM, hw hw@gc-24.de wrote:
It seems that lighttpd uses the perl version that is assigned in the configuration
This is one of the advantages of Plack vs mod_perl, by the way: decoupling the Perl version from the web server version.
while ignoring the LIBRARY_PATH variable set with mod_setenv
Are you certain you don’t mean LD_LIBRARY_PATH here?
https://stackoverflow.com/questions/4250624/
Even with a shell script as wrapper that sets and exports LIBRARY_PATH, perl can not find the library. Trying to set LIBRARY_PATH for lighttpd through systemd also doesnīt work.
Beware that some layers of the OS actively redefine LD_LIBRARY_PATH in order to avoid security exploits. I wouldn’t be surprised if systemd did that in some cases, for good cause.
Warren Young wrote:
On May 24, 2017, at 1:58 PM, hw hw@gc-24.de wrote:
It seems that lighttpd uses the perl version that is assigned in the configuration
This is one of the advantages of Plack vs mod_perl, by the way: decoupling the Perl version from the web server version.
while ignoring the LIBRARY_PATH variable set with mod_setenv
Are you certain you don’t mean LD_LIBRARY_PATH here?
https://stackoverflow.com/questions/4250624/
I was looking at the output of 'env' when perl524 was enabled and verified that when having LIBRARY_PATH set in the shell, the library is being found.
It would require further testing to find out if setting LD_LIBRARY_PATH makes a difference.
However, I even created a symlink to the library and it still couldn´t be loaded, so this is just weird.
Even with a shell script as wrapper that sets and exports LIBRARY_PATH, perl can not find the library. Trying to set LIBRARY_PATH for lighttpd through systemd also doesnīt work.
Beware that some layers of the OS actively redefine LD_LIBRARY_PATH in order to avoid security exploits. I wouldn’t be surprised if systemd did that in some cases, for good cause.
It needs to at least present a warning it decides to override things explicitly set by the admin, like in a unit file.
Anyway, I´ve given up on this, and the current plan is to use a VM or another machine with a different distribution to provide the service. That will probably be Debian, and we have a VM running Debian anyway, so I might just use that.
Am 23.05.2017 um 18:56 schrieb m.roth@5-cent.us:
hw wrote:
are there packages replacing the ancient perl version in Centos 7 with a more recent one, like 5.24? At least the state feature is required.
Don't call it ancient, boy, or I'll beat you with my cane!
Have you checked the Software Collections?
https://www.softwarecollections.org/en/scls/rhscl/rh-perl524/
-- LF
On May 23, 2017, at 10:44 AM, hw hw@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.
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.
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?
[*]: http://perldoc.perl.org/feature.html#The-%27state%27-feature
Warren Young schrieb:
On May 23, 2017, at 10:44 AM, hw hw@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 yesAre 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.
CentOS mailing list CentOS@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@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@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#SignaturesI note that this feature is still marked experimental and subject to removal.
â¦And youâre lecturing me about stability? _______________________________________________ CentOS mailing list CentOS@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@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#SignaturesI 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@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.
On 05/23/2017 11:44 AM, hw wrote:
Hi,
are there packages replacing the ancient perl version in Centos 7 with a more recent one, like 5.24? At least the state feature is required.
As a side note, here is why RHEL (and therefore CentOS, since we rebuild RHEL source code to create our base OS) has old software:
https://access.redhat.com/security/updates/backporting
If you just spent $5,000,000.00 on a new Point of Sales software for a couple thousand stores, you might want to keep it in production for a bit longer than 6 months on a linux install. You also would like to make sure the system is secure, etc.
There are 2 concepts for updating .. RHEL/CentOS provides a secure OS that works for 10 years without major changes to ABI/API server related systems .. other distros do updates every 6 months, etc. If you are looking for latest and greatest/cutting edge type functionality .. CentOS is likely not the OS you want.
If you are looking for an OS that runs like you installed it for 10 years and remains secure, then CentOS is the OS you want.
Johnny Hughes schrieb:
On 05/23/2017 11:44 AM, hw wrote:
Hi,
are there packages replacing the ancient perl version in Centos 7 with a more recent one, like 5.24? At least the state feature is required.
As a side note, here is why RHEL (and therefore CentOS, since we rebuild RHEL source code to create our base OS) has old software:
https://access.redhat.com/security/updates/backporting
If you just spent $5,000,000.00 on a new Point of Sales software for a couple thousand stores, you might want to keep it in production for a bit longer than 6 months on a linux install. You also would like to make sure the system is secure, etc.
There are 2 concepts for updating .. RHEL/CentOS provides a secure OS that works for 10 years without major changes to ABI/API server related systems .. other distros do updates every 6 months, etc. If you are looking for latest and greatest/cutting edge type functionality .. CentOS is likely not the OS you want.
If you are looking for an OS that runs like you installed it for 10 years and remains secure, then CentOS is the OS you want.
The problem is that the expensive POS software doesn´t run on Centos because the perl version Centos uses is too old. It is so old that you don´t need to look for the greatest or latest software to run into problems; it suffices when you look for something that works.
Since there is a recent perl version available, there has to be some way to use it.
On Wed, May 24, 2017 at 10:16:15PM +0200, hw wrote:
Johnny Hughes schrieb:
On 05/23/2017 11:44 AM, hw wrote:
Hi,
are there packages replacing the ancient perl version in Centos 7 with a more recent one, like 5.24? At least the state feature is required.
[snip]
The problem is that the expensive POS software doesn´t run on Centos because the perl version Centos uses is too old. It is so old that you don´t need to look for the greatest or latest software to run into problems; it suffices when you look for something that works.
Since there is a recent perl version available, there has to be some way to use it.
Another path to explore is to ask the expensive software producer, as they make a Linux version, why they do not offer a version certified for RHEL?
jl
On Wed, 2017-05-24 at 16:35 -0400, Jon LaBadie wrote:
On Wed, May 24, 2017 at 10:16:15PM +0200, hw wrote:
Johnny Hughes schrieb:
On 05/23/2017 11:44 AM, hw wrote:
Hi,
are there packages replacing the ancient perl version in Centos 7 with a more recent one, like 5.24? At least the state feature is required.
I think you are looking for centos software collections: https://wiki.centos.org /AdditionalResources/Repositories/SCL
# yum install centos-release-scl # yum install rh-perl524
Mark
The problem is that the expensive POS software doesn´t run on Centos because the perl version Centos uses is too old.
Life is a compromise. If the expensive POS software isn't designed to run on RHEL/CentOS then you will need to run it on a different OS. I know your desire is to keep everything the same, but that's the compromise.
Since there is a recent perl version available, there has to be some way to use it.
No doubt there is - but the compromise is the amount of work necessary to get it functioning in a satisfactory and stable way.
I wonder if you might be better of using something like Fedora since it's relatively close in structure to CentOS - it really depends on how many machines you need to support and if the 6 month upgrade cycle is going to be too onerous. If nothing else it might tide you over until RHEL 8 - which might well be based on Fedora 26 or 27 if you look at other upgrade cycles.
P.
On 05/24/2017 03:16 PM, hw wrote:
Johnny Hughes schrieb:
On 05/23/2017 11:44 AM, hw wrote:
Hi,
are there packages replacing the ancient perl version in Centos 7 with a more recent one, like 5.24? At least the state feature is required.
As a side note, here is why RHEL (and therefore CentOS, since we rebuild RHEL source code to create our base OS) has old software:
https://access.redhat.com/security/updates/backporting
If you just spent $5,000,000.00 on a new Point of Sales software for a couple thousand stores, you might want to keep it in production for a bit longer than 6 months on a linux install. You also would like to make sure the system is secure, etc.
There are 2 concepts for updating .. RHEL/CentOS provides a secure OS that works for 10 years without major changes to ABI/API server related systems .. other distros do updates every 6 months, etc. If you are looking for latest and greatest/cutting edge type functionality .. CentOS is likely not the OS you want.
If you are looking for an OS that runs like you installed it for 10 years and remains secure, then CentOS is the OS you want.
The problem is that the expensive POS software doesn´t run on Centos because the perl version Centos uses is too old. It is so old that you don´t need to look for the greatest or latest software to run into problems; it suffices when you look for something that works.
Since there is a recent perl version available, there has to be some way to use it.
Not if the developers were developing on Enterprise Linux .. which they would be.
In all seriousness, you might want to checkout openshift-origin from the PAAS SIG:
https://wiki.centos.org/SpecialInterestGroup/PaaS/OpenShift
Openshift can be used to create both development/testing and production environments where you can easily deploy docker containers with specific SCL software installed together. It can also be configured so that the developers can deploy their own test instances, etc.
There is a supported path by Red Hat for production deployments and even free development available at https://openshift.io/ .
It is fairly easy to have multiple dev environments, etc. using some combination of openshift.io, openshift-origin (the community upstream) on CentOS, or openShift Container Platform (the supported version from Red Hat).
-
Christian, Mark -
hw -
James Szinger -
Japheth Cleaver -
Johnny Hughes -
Jon LaBadie -
Leon Fauster -
m.roth＠5-cent.us -
Nikolaos Milas -
Paul Heinlein -
Pete Biggs -
Valeri Galtsev -
Warren Young