Need help to install configure mod_perl
I have O.S Windows Vista ActivePerl5.8 Apache 2.2.11 Installed. C:\ ppm install mod_perl-2.0 ppm install failed: Can't find any package that provides mod_perl-2.0 C:\ ppm install http://theoryx5.uwinnipeg.ca/ppms/mod_perl.ppd ppm install failed: 500 can't connect to theoryx5.uwinnipeg.ca/ppms/mod_perl.ppd Bad hostname ' theoryx5.uwinnipeg.ca' I am trying to install mod_perl, but it gives above error? Thanks, Sandhya.
Re: decline and fall of modperl?
Alexandr Ciornii wrote: PHP, C#, Java are much more prefered, because the programs created with them can hide the source code much better, while this is not possible with Perl. This is a big reason why the software companies that create custom programs for their clients prefer to use those languages and not perl. Not because perl is bad. I would like to add that it seems ridiculously simple to decompile Java classes. I find this a bad argument. My company - admittedly small - sells services and software to customers. 90% of our software is written in Perl, and we supply it in source format. None of our customers in their right mind would even think of stealing the code, although it is extremely well-commented throughout. If they had the time to do that, then they would not have asked us to supply the service in the first place. Ultimately, and back to the OP's orginal question, these are the two or three main arguments in this debate, mainly already provided by other contributors : 1) if you have a customer and you provide a good service to this customer, and you have provided it for years, and you provide it at a fair price, then why should they listen to a fresh-landed consultant instead of listening to you ? If they listen to the consultant and ignore your advice, then the problem is not in the programming language you use. 2) it is easy for anyone to use words like obsolete, but what to these words really mean ? is something that hasn't much changed in 10 years automatically obsolete ? if yes, then the WWW is obsolete, and the decision-maker at your customer company is also obsolete. Something becomes really obsolete the day when something else is available, and it performs the same function better and at a lower cost. Is that the case here ? 3) it is true that perl has somehow become less in vogue, consistently over the last few years. The (apparently aging) perl community is largely aware of the fact and deplores it. The critics to perl always seem to rehash the same things (the funny variable prefixes, the possibility of writing bad code, the write-only aspect - you can never re-read the code, and so on). Mostly these critics are people who do not really know the language. But it is not because there are comparatively fewer perl programmers available that perl is an inferior language. There are thousands of so-called MS-Windows or PHP experts available, yet you have to hire ten and then fire nine, to keep the one who is really competent. That's always more expensive than getting the right person from the start. Anyway, I am not so sure that there are really less perl programmers, and less perl-based projects or sites. It may just be that whatever those people do, they do it quietly, competently and without fuss; and that the projects or sites which are based on perl are less in the news because they don't crash and don't overrun their budgets. It seems a bit like turning things on their head. I mean if there are a lot of job adverts for PHP or Java developers, it must mean that PHP or Java projects need a lot of manpower, no ? So conversely..
RE: decline and fall of modperl?
Hi, if nobody did already, please have a look at the Perl Miths presentation by Tim Bunce: http://timbunce.files.wordpress.com/2008/03/perl-myths-200802-with-notes.pdf Now my personal view: I'm committed to perl since 1996, and, although I work since that date in a quite big software company (250 employees, and Microsoft certified partner), I remember to have had very seldom problems convincing customers about technology issues like which language to use. Regarding your experience, I would not confuse the future of Mason with the future of perl in the web programming sector at large. There are similar experiences in other technologies: in the J2EE domain, Jetspeed is almost dead, this doesn't mean J2EE is dead (but it really means you will have problems convincing a system architect to adopt Jetspeed for the next web portal). I'm involved in web programming since 1999 and at that time there were really little choices. We started building our own LAMP (Linux+Apache+ModPerl !) framework that now is the backbone of our solutions anytime the customer gives us the freedom to choose. Sometimes the customer has other technologies in mind, but we always convince him with an unbeatable time-to-market using our own tools. In spite of being a 'simple scripting language' we do not see major problems in mantaining and evolving our framework of 500+ perl modules. Moreover I mind you that there are sectors where perl is still one of the best choice to pick (Natural Language Processing, web crawling, data mungling at large...). The long history of Perl means also that it is much more common to find it at your customers sites than what you could immagine. Some times I talk about Perl admittedly with a little fear, only to find that most of the clients know it already and have already used it at least in the past. So personally I still love Perl and I'm still happy to have learnt it some 13 years ago, and I'm happy that now it is seen as an 'obsolete' technology: for me it only means that is rock solid and that I learnt once in the past, exploiting my knowledge for several years without the need to switch. I think this goes for the most of perl programmers out there. The problem is that Perl is not able to attract new programmers as other tecnologies (Java/.NET) are. One issue being the lack of a common and powerfull development framework as other technology have (MS Visualstudio/NetBeans). And, of course, the not-so-fast transition between Perl 5 and Perl 6 could also be an issue. Finally, regarding the issue of not being forced to deploy the source code: sometimes we deployed perl bytecode for the ByteLoader, and I found the level of security is almost the same than with java bytecode (if you know how to deparse one, you are able to find how to do with the other...). Best, Marco. - Original Message - From: Louis-David Mitterrand [mailto:vindex+lists-modp...@apartia.org] To: modperl@perl.apache.org Sent: Mon, 23 Mar 2009 14:07:31 +0100 Subject: decline and fall of modperl? Hi and sorry for the provocative title of my post :) One of our customers is doing a detailed review of a mason/modperl ERP app we've built for them since 2001. Prodded by some buzzword-compliant consultants they are expressing concerns that the app's underlying technologies - perl, modperl and mason - are becoming obsolete. They feel that a web application framework must have 'rails' or some other buzzword in its name. But their main argument is that perl is declining as a web developement language. Also they rightly feel that competent perl developers are becoming harder to find. What arguements could I use to address these concerns and convince them that their initial investement in perl is still safe and won't be obsolete in 10 years? The client's local developers (who maintain the app we've built) feel that mason gives too much freedom to write messy code and badly structure a web app. Indeed mason has very little constraints, maybe just slightly more than straight modperl. So it requires experienced, self-disciplined devs, which are few and far between. So my second question is, what perl web development framework should we recommend to our client? Catalyst looks like a winner, but maybe there are others? Thanks for your insights,
Re: decline and fall of modperl?
Marilyn Burgess schrieb: From a fellow lurker to another, I would be interested in reading your perspective. - Marilyn me too, Axel
Re: decline and fall of modperl?
André Warnier wrote: I would like to add that it seems ridiculously simple to decompile Java classes. Agreed. With the popularity of bytecode languages such as Java and .Net, suddenly nobody talks about the ease of obtaining source code in the flesh. As Andre mentioned, it's trivial to decompile .Net DLLs. I tried to recover an old perl app packaged by ActivePerl some time back. It was impossible to do this, and the good guys at AP verified my pain. If anything I'd say that I feel confident my (AP-packaged) products will not fare any worse than any commercial Java/ .Net executables in the wild.
Re: who's putting that pre tag in the output...?
Hi Torsten,
An ErrorDocument is an internal redirect. These REDIRECT_... environment
variables are copied from the previous ($r-prev) request's
$r-subprocess_env just by copying everything and prepending REDIRECT_
to each key. So if the original request has an environment variable
named REQUEST_URI the error document should have a REDIRECT_REQUEST_URI,
see rename_original_env() in httpd-x.y/modules/http/http_request.c.
Since REQUEST_URI is the standard CGI environment variable (see
ap_add_cgi_vars() httpd-x.y/server/util_script.c) I'd take
REDIRECT_REQUEST_URI.
As it turned out, I was (entirely) wrong when I thought it is
working. It was wishfull thinking - but not a real solution - neighter one
of the REQUEST_URI, REDIRECT_URL and/or REDIRECT_QUERY_STRING environment
variables seemed to be good enough for a mod_rewrite solution, or at least
I was unable to build one. (I just made some errors in testing and
repeatedly out- and out-out-commenting various httpd.conf setting, but it
wasn't _really_ working whein I thought it would).
Summing up what I have so far ( which might be incomplete or even wrong):
looking for a cheap/good/working solution for a way to solve what
http://httpd.apache.org/docs/2.2/rewrite/rewrite_guide_advanced.html
describes under the title Redirect Failing URLs to Another Web Server,
but with the (it seems important) difference that I want to hide the new
server from the eyes of the customers and as such _proxy_ the failing
requests instead of redirecting, the given receipt
RewriteEngine on
RewriteCond %{REQUEST_URI} !-U
RewriteRule ^(.+) http://webserverB.dom/$1
shows up to NOT work when I attempted to make it
RewriteEngine on
RewriteCond %{REQUEST_URI} !-U
RewriteRule ^(.+) http://webserverB.dom/$1 [P]
Neither was I able to use the Error_Document trick you sugegsted and use
Rewrite on/with it.
I've given up my first attempt - the earlier in the thread shown
PerlResponse handler - as I was unable to output the Content-Type header
as 'text/html'; I haven't however tried the solution suggested with adding
an extra filter for the end phase to substitute the 'text/plain' that I
was seeing and which actually generated the initial question for this
thread and it's subject.
I finally went the 'standard way' [?] and added
ErrorDocument 404 /cgi-bin/404_to_oldserver.pl
in httpd.conf, making /cgi-bin/404_to_oldserver.pl to be
#!/usr/bin/perl
use LWP::UserAgent;
my $ua = LWP::UserAgent-new;
my $url = $ENV{'REQUEST_URI'};
$url = http://OLD.SERVER.COM/$url; ;
my $response = $ua-get( $url );
my $body = $response-content;
my $h = $response-{'_headers'};
$h-push_header( 'Status' = $response-code );
my $header = $h-as_string;
print $header;
print \n;
print $body;
1;
---
This way might have it's own special problems too, but at least it seems
to work OK so far and give me a start.
I'm still [a bit] convinced that a mod_perl solution might or should be
available and be both better and more effective, but I wasn't able to get
it working - even after spending much more effort than I thought initially
that it will take - and gave up for now.
Many thanks to all those that offered advice or help.
Iosif Fettich
PS. Firebug once again proved to be an invaluable resource in helping
understand what's up and find a solution.
Re: Apache 2.2, perl 5.10, Windows XP, Apache-DBI-cache
On Mon, Mar 23, 2009 at 5:20 PM, andynic andynic...@yahoo.com wrote: I would like to write a cgi script using a persistent database connection. I have read that I need For database persistent connections: http://cpan.uwinnipeg.ca/dist/Apache-DBI-Cache No, you don't. You don't need anything other than DBI with connect_cached, but you can optionally use the extra features in Apache::DBI. - Perrin
Re: Apache 2.2, perl 5.10, Windows XP, Apache-DBI-cache
Thanks for this. I pretty new at this stuff. I will give it a try. Andynic. andynic wrote: Hi, I have installed on my Windows XP computer: Apache 2.2 Perl 5.10, mod_perl 2 MySql 5.10. I would like to write a cgi script using a persistent database connection. I have read that I need For database persistent connections: http://cpan.uwinnipeg.ca/dist/Apache-DBI-Cache There I find downloads but not for Windows which requires a ppm version. Would anyone know where I can find the Apache-DBI-Cache for the above-mentioned set of software for installation via ppm on Windows XP. Thanks for your help. Andynic. -- View this message in context: http://www.nabble.com/Apache-2.2%2C-perl-5.10%2C-Windows-XP%2C-Apache-DBI-cache-tp22669395p22679396.html Sent from the mod_perl - General mailing list archive at Nabble.com.
Re: Apache 2.2, perl 5.10, Windows XP, Apache-DBI-cache
Concerning Rany's reply: I was able to install it with the following command: C:\ppm install http://trouchelle.com/ppm10/Apache-DBI-Cache.ppd Downloading Apache-DBI-Cache-0.08...done Unpacking Apache-DBI-Cache-0.08...done Generating HTML for Apache-DBI-Cache-0.08...done Updating files in site area...done 7 files installed -- View this message in context: http://www.nabble.com/Apache-2.2%2C-perl-5.10%2C-Windows-XP%2C-Apache-DBI-cache-tp22669395p22679473.html Sent from the mod_perl - General mailing list archive at Nabble.com.
Re: Need help to install configure mod_perl
sandhya pawar wrote: I have O.S Windows Vista ActivePerl5.8 Apache 2.2.11 Installed. C:\ ppm install mod_perl-2.0 ppm install failed: Can't find any package that provides mod_perl-2.0 C:\ ppm install http://theoryx5.uwinnipeg.ca/ppms/mod_perl.ppd ppm install failed: 500 can't connect to theoryx5.uwinnipeg.ca/ppms/mod_perl.ppd http://theoryx5.uwinnipeg.ca/ppms/mod_perl.ppd Bad hostname 'theoryx5.uwinnipeg.ca http://theoryx5.uwinnipeg.ca' Does that link work in a browser from the computer you're trying to install on? I have no experience with mod_perl on windows, but http://theoryx5.uwinnipeg.ca/ppms/mod_perl.ppd does load for me. Adam
Re: decline and fall of modperl?
Perrin Harkins wrote: On Mon, Mar 23, 2009 at 11:30 AM, Octavian Râsnita orasn...@gmail.com wrote: ...and in most parts of the world it is hard to find competent perl programmers. ...The job listings for Perl are strong. They're huge compared to those for Ruby. Of course Java is massively more popular than either of them, but that doesn't make the perl market small. I wouldn't use the word 'most', but here in Southeast Asia it's a real challenge to find a Perl developer with significant experience in Perl/ modperl. Those who do use it as a minor scripting tool in their unix administration. Having run a Perl and Java based technology company in Singapore myself for a chunk of time in the early 2000s, I agree that there is some truth to that. We did run into that as an issue and did end up importing Perl and mod_perl talent overseas including some people who post here relatively regularly who were able to enjoy a stay in SE Asia. However, some markets are going to be a bit different. I think what you are saying reflects also what a search of a Singaporean jobs database has in it. Whereas in USA and Europe PHP = Perl in # of jobs, even in Singapore, the number of Perl jobs is less than half of PHP and both small than Java. From jobstreet.com.sg, Perl:18, PHP:51, Java: 210 With that said, that forms a relatively small n looking at one country -- although I imagine there should be little difference in Malysia etc. At the risk of sounding American-centric, the number of jobs in America and Europe is nonetheless a good chunk of the technology development in the world so I believe the statistics are still compelling on those job sites about relative use of the technology -- Gunther
Fw: Re: decline and fall of modperl?
I have received a fair amount of affirmatives. So here goes Let me first begin by stating that my observations are anecdotal. They are however based on direct conversations with hiring managers / senior developers at my clients/prospects. I have also interviewed well over 400 perl/oo perl/mod_perl developers in the last 4 years. I have an extremely detailed code vetting process that allows an accurate skill level rating. I am sure there will be plenty of situational disparity between what I write and what you may have personally experienced. The “job” market… Most large scale shops (more than a few perl/oo perl/mod_perl developers) have code bases that where developed in the late 90’s (hence a resistance to moved towards more robust but yet unproven versions). These companies have survived the dot com blowup and grown in their respective market places, usually internet/web commerce centric. Most new startups/companies (there are exceptions) are not perl/oo perl/mod_perl shops. The jobs are literally spread across the country. In each geographical area, shops know most of the “local” perl/oo perl/mod_perl developers/coders. They have already worked with these coders or interviewed them at some point in time. In some cases they have current employees that have worked with and know of them. For whatever reasons they are deemed not technically or chemistry qualified. When they do talk to Java/J2ee / MS .net developers (who accept perl only as a procedural language used for the most part by Linux sysads) it is very rare there will be any ship jumping. It’s like the McCoys and the Hatfields. In other words the talent pool doesn’t expand. The Southern Ca market has the highest geographical concentration of large scale perl/oo perl/mod_perl shops (although relatively quite at the moment in terms of hiring). It is arguably the center of the universe as it relates to media/content/advertising and the merging of these with web portals. Southern Ca is also a relocation destination. This lends itself to more “local” talent and therefore more perl/oo perl/mod_perl start ups. The hidden message here is “the more available senior developers, the more likely available jobs”, an expanding talent pool will lead to an expanding job market. In my humble opinion the perl community needs to embrace the concept of self propagation. For the most part perl/oo perl/mod_perl developers are self taught. Junior or mid level talent (a majority of the talent pool) is passed over as not enough experience. Perhaps this is because they do not push themselves or the roles they come from are User Interface or system ops, people that did not make it in those roles. This where as an investment of time and effort can go a long way into building the pool of perl/oo perl/mod_perl developers. Too often everyone is looking for the instant gratification of a senior level skill set. Believe it or not, there is a perception that senior perl/oo perl/mod_perl developers do not play well with others. An active mentoring role played by senior developers and gurus needs to be taken. Reach out and take a junior person under your wing and actively work to raise their level of coding skill set. Perl/oo perl/mod_perl’s community and your future may depend on it. --- On Mon, 3/23/09, Mike Bourdon perl_fin...@yahoo.com wrote: From: Mike Bourdon perl_fin...@yahoo.com Subject: Re: decline and fall of modperl? To: Louis-David Mitterrand vindex+lists-modp...@apartia.org Cc: modperl@perl.apache.org Date: Monday, March 23, 2009, 7:26 PM Very interesting topic, byline and responses. For the last 5 years I have been Perl recruiter (24 years overall as a technical headhunter) based out of Southern Ca. Many on this list have talked/worked with me, most however would not recognize this screen name. I would be more than happy to share my insights as it relates to the job / candidate market conditions. If there are enough affirmative replies I will in the near future post a more detailed dissertation. If not, I will continue to lurk in the shadows. Long live PERL --- On Mon, 3/23/09, Louis-David Mitterrand vindex+lists-modp...@apartia.org wrote: From: Louis-David Mitterrand vindex+lists-modp...@apartia.org Subject: decline and fall of modperl? To: modperl@perl.apache.org Date: Monday, March 23, 2009, 6:07 AM -Inline Attachment Follows- Hi and sorry for the provocative title of my post :) One of our customers is doing a detailed review of a mason/modperl ERP app we've built for them since 2001. Prodded by some buzzword-compliant consultants they are expressing concerns that the app's underlying technologies - perl, modperl and mason - are becoming obsolete. They feel that a web application framework must have 'rails' or some other buzzword in its name. But their main argument is that perl is declining as a web developement language. Also they
Re: Fw: Re: decline and fall of modperl?
Mike Bourdon wrote: In my humble opinion the perl community needs to embrace the concept of self propagation. For the most part perl/oo perl/mod_perl developers are self taught. Junior or mid level talent (a majority of the talent pool) is passed over as not enough experience. Perhaps this is because they do not push themselves or the roles they come from are User Interface or system ops, people that did not make it in those roles. This where as an investment of time and effort can go a long way into building the pool of perl/oo perl/mod_perl developers. Too often everyone is looking for the instant gratification of a senior level skill set. Believe it or not, there is a perception that senior perl/oo perl/mod_perl developers do not play well with others. An active mentoring role played by senior developers and gurus needs to be taken. Reach out and take a junior person under your wing and actively work to raise their level of coding skill set. Perl/oo perl/mod_perl’s community and your future may depend on it. I completely agree with what you're saying here. At my previous employer (i changed jobs in august) we found it pretty much impossible to find entry/mid level perl people, so what we did was hire entry level people straight out of school that had maybe a little bit of perl, but displayed the chops to be able to learn what we needed them to learn. This worked out great for us, and i know it's been the way that at least a couple of other small perl shops in Toronto have been building their teams. If you can find a good programmer, it easy to turn them into a good perl programmer if they are willing. Right now, in Toronto if you're looking to hire a senior level perl programmer you're looking at 75K plus CAD. There are a couple of well funded shops in the city that will throw 6 figures at the right candidate. The mentoring thing is huge though. Perl generally isn't taught in schools, and if you're building a team from the ground up, you're going to have to teach. Which is in a lot of ways actually a good thing, because you can hopefully teach people Modern Perl, instead of the formmail.pl style perl ;) This is part of the reason why i'd love to see more tutorial style documentation on perl.apache.org. Adam
Re: Fw: Re: decline and fall of modperl?
In my humble opinion the perl community needs to embrace the concept
of self propagation. For the most part perl/oo perl/mod_perl
developers are self taught. Junior or mid level talent (a majority
of the talent pool) is passed over as not enough experience.
It is interesting for me to hear that developed countries are also
having difficulties finding Perl-savvy developers out of the varsities.
I do agree that not being able to find 'Perl-ready' graduates should not
be a deterrant - I myself being a brainwashed Java advocate for a while
before stumbling onto Perl.
In my local context, deciding on Perl/ PHP/ Ruby requires a great deal
of support on the business side:
1. The average turnover rate is about 3 years. That means every 3 years
you have to retrain a new guy to take over relatively established code.
Since we have to accept the fact that it's extremely difficult to hire
an experienced Perl dev, the quality and experience of the dev team
halts at about 5-6 years.
- New strategies will be have to be formed to distinguish the core
engine from the customisable. The company must recognise the business
viability in retaining the core team, while accepting that the mediocre
will move on in time. The core team itself has to develop good mentoring
and training skills to induct the new intake.
2. Selling to clients who only understand .NET and Java ('modern'
languages) will be a challenge. Governments and large enterprises
generally (and mistakeably) associate other languages to be an
investment risk.
- Nobody asks about the innards of an appliance or a product. As long as
it runs, runs well and affordably, it's good enough.
Sounds reasonable enough, but it's a lot work to get there...
