This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.
Subject: Re: tracking down why a module was loaded?;
From: ed <artlore@sirius.com>
Date: Tue, 26 Sep 2000 16:50:35 -0400
Gunther Birznieks wrote:
> I unfortunately have to agree.
> <snip>
> And in the end, the salaries for mod_perl programmers
> are pretty high right now because of it -- so will a system really cost
> less to develop in mod_perl than in Java if Java programmers are becoming
> less expensive than mod_perl programmers?
> </snip>
Mod_perl programmers are more expensive as individuals,
because mod_perl is more powerful, and allows you access
to the Apache API; mod_perlers are more saavy.
One or two mod_perlers could do the
work of a java shop of ten in half the time. Still a savings.
Not to mention the hardware that goes with Java by fiat!
ed
Subject: Re: tracking down why a module was loaded?;
From: ed <artlore@sirius.com>
Date: Tue, 26 Sep 2000 16:50:35 -0400
Gunther Birznieks wrote:
> I unfortunately have to agree.
> <snip>
> And in the end, the salaries for mod_perl programmers
> are pretty high right now because of it -- so will a system really cost
> less to develop in mod_perl than in Java if Java programmers are becoming
> less expensive than mod_perl programmers?
> </snip>
Mod_perl programmers are more expensive as individuals,
because mod_perl is more powerful, and allows you access
to the Apache API; mod_perlers are more saavy.
One or two mod_perlers could do the
work of a java shop of ten in half the time. Still a savings.
Not to mention the hardware that goes with Java by fiat!
===
Subject: Re: tracking down why a module was loaded?;
From: Matthew Byng-Maddick <mbm@colondot.net>
Date: Wed, 27 Sep 2000 10:43:56 +0100 (BST)
On Wed, 27 Sep 2000, Gunther Birznieks wrote:
> At 10:28 PM 9/26/2000 +0200, Alexander Farber (EED) wrote:
> >Doug MacEachern wrote:
> > > > modperl is the best kept secret on the net. Shame!
> > > seems to generate plenty of list traffic for a "secret" ;)
> >Don't you all think, that mod_perl isn't promoted enough and
> >this will kill it someday, despite its technical goodness?
Perl in general too, although I disagree with Stas on this one. (we
discussed it in the pub on the first night of the conference).
> >- There are no articles in the "mainstream" computer press
> > (like cnet.com, www.ix.de, etc) about mod_perl.
True, but then you need to explain the apache phenomenon first, and too
many corporates want to deal only with corporates, making them feel a need
to use IIS (with no mod_perl :/ )
> >- There are no benchmarks, comparing to Java/Coldfusion/whatever.
None of these give you anything like the hooks that mod_perl gives you,
though, so in general they are uncomparable. CF is pig-slow, and java -
well. :)
> >- I work at a big telco, and no one cares/knows here about
> > mod_perl (except our intranet-webmaster, who still prefers
> > PHP, since it makes him less trouble).
Again, not comparable. I have written a quick hack auth system that hooks
into uri translation, try doing that under any other system.
> >- People, who have heard about mod_perl, are looking for servlet/
> > JSP-programmers, because mod_perl-coders are hard to find.
perhaps. Mod_perl jobs are hard to find too... :/
> I unfortunately have to agree.
perhaps.
> Depending on where you go Perl programmers may be easier to find that Java
> programmers, but finding an existing mod_perl programmer is not easy. It's
> doable, but not easy. And in the end, the salaries for mod_perl programmers
> are pretty high right now because of it -- so will a system really cost
> less to develop in mod_perl than in Java if Java programmers are becoming
> less expensive than mod_perl programmers?
I have yet to see companies in this country really advertising for
mod_perl jobs. The company where I currently work mentions it, but we're
not really looking for it very hard, and if they've done any perl, we
mostly teach them about the templating system we use (yes, yet another
one, and going on CPAN soon.... :)
> We all have to do our part to evangelize mod_perl more. I think ISPs are
> really key here as I think I may have mentioned before. If you get the ISPs
Well, I can tell you for a fact that mod_perl is running on
http://www.bluepet.co.uk/
http://www.freedomjewellery.com/
http://www.londontransport.co.uk/
http://www.swisslife.com/
http://www.sciencephoto.com/ (the current version uses PerlRun, but the
new version will be all mod_perl)
> supporting and evangelizing mod_perl (and pre-installed mod_perl
> applications) then you will get users using it and liking it. How many ISPs
Yes, but the way it runs does raise problems for security....
> advertise support for mod_perl? How many without charging like US$100 more
> a month on top of the normal account fees?
This is difficult, due to the security issues. If you have client cgi, you
can always use something like suEXEC or even something as complex as userv
to run your cgi scripts. With mod_perl, the plugged in scripts can do
anything that the webserver can, and you can (by writing a module that
doesn't compile) break the entire webserver.
> PHP comes with a lot of ISP accounts for free with no extra cost. Java does
> not yet, but I've started seeing ISPs starting to support Java in the low
> end shared server accounts...
Wow. I'm surprised, for the security reasons I've outlined above. But then
I don't know much about PHP, really.
MBM
===
Subject: Re: tracking down why a module was loaded?;
From: Matt Sergeant <matt@sergeant.org>
Date: Wed, 27 Sep 2000 10:54:17 +0100 (BST)
On Wed, 27 Sep 2000, Matthew Byng-Maddick wrote:
> > We all have to do our part to evangelize mod_perl more. I think ISPs are
> > really key here as I think I may have mentioned before. If you get the ISPs
Actually I think the people we need to get involved are the web site
builders - the larger companies offering dynamic web content creation. We
also need some more mainstream tools, the oft-requested "Zope-a-like" in
Perl. And it needs to be trivial to install (I'm not sure how likely that
is to be yet).
> > advertise support for mod_perl? How many without charging like US$100 more
> > a month on top of the normal account fees?
>
> This is difficult, due to the security issues. If you have client cgi, you
> can always use something like suEXEC or even something as complex as userv
> to run your cgi scripts. With mod_perl, the plugged in scripts can do
> anything that the webserver can, and you can (by writing a module that
> doesn't compile) break the entire webserver.
>
> > PHP comes with a lot of ISP accounts for free with no extra cost. Java does
> > not yet, but I've started seeing ISPs starting to support Java in the low
> > end shared server accounts...
>
> Wow. I'm surprised, for the security reasons I've outlined above. But then
> I don't know much about PHP, really.
PHP can runs as a normal CGI, using suExec. So it's like advertising Perl
support.
What would help mod_perl is a working sandboxing system, based on Safe and
SafeHole. I've advocated that idea before, but still don't have the time
to go and build it. With that sort of system, and ISP could easily trap or
prevent whatever they need to, and we could work with them to build up
secure proffessional installations.
However, I'm honestly not sure if the whole of mod_perl is "right" for the
majority of small fee ISP's. What the ISP's need is perhaps one of the
mod_perl modules, like Mason, Embperl or AxKit, or something like
that. Rather than letting users write PerlInitHandlers! Unfortunately I
have no idea how you might secure one of these modules, even though one is
my own.
===
Subject: Re: tracking down why a module was loaded?;
From: Matthew Byng-Maddick <mbm@colondot.net>
Date: Wed, 27 Sep 2000 10:59:09 +0100 (BST)
On Wed, 27 Sep 2000, Matt Sergeant wrote:
> On Wed, 27 Sep 2000, Matthew Byng-Maddick wrote:
> Actually I think the people we need to get involved are the web site
> builders - the larger companies offering dynamic web content creation. We
> also need some more mainstream tools, the oft-requested "Zope-a-like" in
> Perl. And it needs to be trivial to install (I'm not sure how likely that
> is to be yet).
This is roughly the kind of company I work for, so agreed.
> > > PHP comes with a lot of ISP accounts for free with no extra cost. Java does
> > > not yet, but I've started seeing ISPs starting to support Java in the low
> > > end shared server accounts...
> > Wow. I'm surprised, for the security reasons I've outlined above. But then
> > I don't know much about PHP, really.
> PHP can runs as a normal CGI, using suExec. So it's like advertising Perl
> support.
Right.
> What would help mod_perl is a working sandboxing system, based on Safe and
> SafeHole. I've advocated that idea before, but still don't have the time
> to go and build it. With that sort of system, and ISP could easily trap or
> prevent whatever they need to, and we could work with them to build up
> secure proffessional installations.
Schwern and I were discussing a new mechanism for a sandbox in Perl6, but
unfortunately, I'm not sure how trivial it would be for Perl5, and also,
you have to wonder whether any improvement will take away any performance
advantage that mod_perl gives you.
> However, I'm honestly not sure if the whole of mod_perl is "right" for the
> majority of small fee ISP's. What the ISP's need is perhaps one of the
> mod_perl modules, like Mason, Embperl or AxKit, or something like
> that. Rather than letting users write PerlInitHandlers! Unfortunately I
> have no idea how you might secure one of these modules, even though one is
> my own.
With difficulty. :) that wasn't helpful - but we really need a perl
sandboxing mechanism. (perhaps if you can use safe to restrict open(),
socket(), creat() etc, then you're doing the right thing....)
===
Subject: Re: tracking down why a module was loaded?;
From: Greg Cope <gjjc@rubberplant.freeserve.co.uk>
Date: Wed, 27 Sep 2000 13:44:22 +0000
Matt Sergeant wrote:
>
> On Wed, 27 Sep 2000, Matthew Byng-Maddick wrote:
>
> > > We all have to do our part to evangelize mod_perl more. I think ISPs are
> > > really key here as I think I may have mentioned before. If you get the ISPs
>
> Actually I think the people we need to get involved are the web site
> builders - the larger companies offering dynamic web content creation. We
> also need some more mainstream tools, the oft-requested "Zope-a-like" in
> Perl. And it needs to be trivial to install (I'm not sure how likely that
> is to be yet).
Hum - most commercial companies that I know in London (few I know),
either use ASP (the M$ version) or PHP. The best solution for them is
often not what is technically the best, but the compromise of staff cost
/ availability, and hence development cost. e.g. I have a few friends
whom work in ASP shops whom know little about the web in terms of
cookies, sessions, headers, but they all know how to set a session in
ASP, and hence get the job done. Their employers get the job done, at a
lower cost (IMHO ASP programmers are paid less than perl ones). The
fact that they often get stuck when trying to do something a little out
of the ordinary does not appear to matter much!
As for a "Zope-a-like" or similar, I agree that there are few mod_perl
applications out there, and judging by the number of PHP apps on
freshmeat there's allot of competition. A (or many) flagship
application(s) would help evangelise mod_perl allot.
On the easy to install front, I think that's due to programmer being
lazy. I know there are issues, but making a module install using h2xs
stuff is easy (both for programmer and end user). Supplying example
httpd.conf files is also easy - it just takes time.
> > > advertise support for mod_perl? How many without charging like US$100 more
> > > a month on top of the normal account fees?
> >
> > This is difficult, due to the security issues. If you have client cgi, you
> > can always use something like suEXEC or even something as complex as userv
> > to run your cgi scripts. With mod_perl, the plugged in scripts can do
> > anything that the webserver can, and you can (by writing a module that
> > doesn't compile) break the entire webserver.
> >
> > > PHP comes with a lot of ISP accounts for free with no extra cost. Java does
> > > not yet, but I've started seeing ISPs starting to support Java in the low
> > > end shared server accounts...
> >
> > Wow. I'm surprised, for the security reasons I've outlined above. But then
> > I don't know much about PHP, really.
>
> PHP can runs as a normal CGI, using suExec. So it's like advertising Perl
> support.
>
> What would help mod_perl is a working sandboxing system, based on Safe and
> SafeHole. I've advocated that idea before, but still don't have the time
> to go and build it. With that sort of system, and ISP could easily trap or
> prevent whatever they need to, and we could work with them to build up
> secure proffessional installations.
>
> However, I'm honestly not sure if the whole of mod_perl is "right" for the
> majority of small fee ISP's. What the ISP's need is perhaps one of the
> mod_perl modules, like Mason, Embperl or AxKit, or something like
> that. Rather than letting users write PerlInitHandlers! Unfortunately I
> have no idea how you might secure one of these modules, even though one is
> my own.
Because mod_perl is so far entrenched into apache it is difficult to
sandbox it. I've looked at running it for a hosting service and it was
less than easy, nor eligant to allow users access to mod_perl.
I agree with Matt's last point that mod_perl may not be
right for the mainstream "free ISP's". After all with performance comes
power, and in an ISP's world do you want your webserver going wild due
to a badly written bit of perl ?
mod_perl is ideal for single use servers that host one application,
tailor made for that client (as in customer not http). IMHO mod_perl
cannot be beaten on performance or flexibilty in this scenario.
Should we not promote mod_perl as a web platform for the 'cognisenti'.
9After all, all the 'best' things are usually not the most popular, but
most people know they are the best. Perhaps this last bit is where the
mod_perl 'marketing machine' is failing.
===