I have a non root user that I use for all of my software builds (called
build strangely enough). All elements (apache, perl, mod_perl) were
built as this user. I just tried building as root as the email
suggested. It would not run apache as root, but tried to use
nobody(which did not work no mat
I'm about to start work on a web application which will collect information
from the user and return a document based on that information.
I'm trying to point out the advantages of mod_perl over a solution based on
Java servlet technology to my client. Can anyone provide any quick links/
informat
> "Eric" == Eric Lenio <[EMAIL PROTECTED]> writes:
Eric> I'm trying to point out the advantages of mod_perl over a
Eric> solution based on Java servlet technology to my client. Can
Eric> anyone provide any quick links/ information to help me out?
Well, well-designed mod_perl as a technology
Of all the languages I've had dealings with over the years... perl took
the cake for ease-of-development.
CPAN is by far the greatest asset I've ever had in the programming
world.
For those who may play down perl's power (especially with mod_perl), lay
some smack down using notes from Stas' tuto
> "Kreimendahl," == Kreimendahl, Chad J <[EMAIL PROTECTED]> writes:
Kreimendahl> For those who may play down perl's power (especially with
Kreimendahl> mod_perl), lay some smack down using notes from Stas'
Kreimendahl> tutorial at OSCON.
My notes from my "intro to mod_perl" at OSCON 2004 are
Kim Goldov wrote:
Philippe M. Chiasson wrote:
Does the following patch solve the problem for you ?
? make.log
Index: lib/Apache/PerlSections.pm
===
RCS file: /home/cvs/modperl-2.0/lib/Apache/PerlSections.pm,v
retrieving revision 1.5
d
On Monday 9 August 2004 07:01 pm, Stuart Johnston wrote:
> Would you be willing to add other modules to your benchmark? I would be
> interested to see how HTTP::Date and DateTime::Format::HTTP (which uses
> HTTP::Date) compare.
Again for a 10,000 iteration test:
Date::Parse::str2time
> -Original Message-
> From: Kreimendahl, Chad J [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, August 10, 2004 8:32 AM
> To: Eric Lenio
> Cc: [EMAIL PROTECTED]
> Subject: RE: advantages of mod_perl over java servlets
>
>
> Of all the languages I've had dealings with over the years...
>
Sorry about empty post {had just replied to Chad and was meaning to send to
mod_perl as well}
My story:
I started off with javascript/coldfusion Quickly had to move to asp, then
on to java
Java held me for quite a period of time until I was forced to use perl, I
resisted until I realized how th
On Aug 10, 2004, at 15:56, Eric Lenio wrote:
I'm about to start work on a web application which will collect
information
from the user and return a document based on that information.
I'm trying to point out the advantages of mod_perl over a solution
based on
Java servlet technology to my client
On Aug 10, 2004, at 19:12, Xavier Noria wrote:
On Aug 10, 2004, at 15:56, Eric Lenio wrote:
I'm about to start work on a web application which will collect
information
from the user and return a document based on that information.
I'm trying to point out the advantages of mod_perl over a solution
the reason I'm asking is because the client is really more attuned to the java
hype/buzzwords that exists out there. having done just a smattering of java, I
am somewhat at a loss as to tell them exactly why a perl solution is better.
this client does already have some investment in java, but no p
eWeek has reviewed Bricolage, the mod_perl-powered, PostgreSQL-backed
open-source content management system. The article was published last
week. An excerpt:
Bricolage is quite possibly the most capable enterprise-class
open-source application available. The Web content management
application
On Aug 10, 2004, at 21:28, Eric Lenio wrote:
the reason I'm asking is because the client is really more attuned to
the java
hype/buzzwords that exists out there. having done just a smattering
of java, I
am somewhat at a loss as to tell them exactly why a perl solution is
better.
this client doe
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tuesday 10 August 2004 21:28, Eric Lenio wrote:
> the reason I'm asking is because the client is really more attuned to the
> java hype/buzzwords that exists out there. having done just a smattering
> of java, I am somewhat at a loss as to tell the
On Tue, 2004-08-10 at 16:24, Xavier Noria wrote:
> I am confident too, Slashdot runs on Perl for instance
Slashdot, although of great interest to techies like us, is tiny.
Amazon runs on Perl. Yahoo runs a lot of Perl. Ticketmaster is all
mod_perl. IMDB is Perl. All of these get tons more tra
We need to back up a bit. I tried something different just for giggles
because I thought we might be on the wrong track with setuid. I wrote a
little script that this
#!/bin/bash
/usr/opt/httpd-2.0.49/bin/httpd -d t -f conf/httpd.conf -DAPACHE2
-DONE_PROCESS -DNO_DETATCH > stdout 2>&1 &
tusc -p
Perrin Harkins <[EMAIL PROTECTED]> wrote in another
post:
> APR::Base64 and APR::URI look pretty
> useful too.
>
What are some practical uses of APR::Base64? Encoding
credit card nums before storing in DB? Passwords?
The doc at
http://perl.apache.org/docs/2.0/api/APR/Base64.html#Synopsis
On Tue, 2004-08-10 at 19:00, Bart Simpson wrote:
> What are some practical uses of APR::Base64?
Sending binary data in ASCII.
> Encoding
> credit card nums before storing in DB? Passwords?
No. It's not encryption.
> I'm
> particular in need of encrypting/encoding credit card
> nums before
>>I'm
>>particular in need of encrypting/encoding credit card
>>nums before storing them
>
>
> Two-way encryption? Blowfish, with Crypt::CBC. Storing credit cards is
> a bad idea though.
that really depends on your business - if you are, say, an ISP that invoices
clients monthly asking them t
On Tue, 2004-08-10 at 20:01, Geoffrey Young wrote:
> that really depends on your business - if you are, say, an ISP that invoices
> clients monthly asking them to give your a CC number each month is not
> exactly customer friendly :)
Verisign, and undoubtedly others, will store it for you and give
>>but hiding the decryption key from technical people is generally
>>impossible
>
>
> Only if they crack your application server. Cracking the database or
> sniffing packets would not be good enough, assuming traffic to your
> credit card company is over SSL.
oh, sure.
I guess I had a differe
--- Perrin Harkins <[EMAIL PROTECTED]> wrote:
> On Tue, 2004-08-10 at 19:00, Bart Simpson wrote:
> > What are some practical uses of APR::Base64?
>
> Sending binary data in ASCII.
>
> > Encoding
> > credit card nums before storing in DB? Passwords?
>
>
> No. It's not encryption.
>
OK.
thank you. i'll look into it. How much do you pay for
this service?
--- Trond Michelsen <[EMAIL PROTECTED]> wrote:
> On Tue, Aug 10, 2004 at 04:00:58PM -0700, Bart
> Simpson wrote:
> >> APR::Base64 and APR::URI look pretty
> >> useful too.
> > What are some practical uses of APR::Base64?
> E
Bart Simpson wrote:
OK. its good for Encoding as in changing forms but
not hiding from other readers. I think i get the
difference. Encode does not imply any secrecy or
privacy where as encrypt does.
Right.
Aside [
I looked encode and cryptography (encrypt wasn't in my
webster collegiate paperback
--- Perrin Harkins <[EMAIL PROTECTED]> wrote:
> Bart Simpson wrote:
> > OK. its good for Encoding as in changing forms
> but
> > not hiding from other readers. I think i get the
> > difference. Encode does not imply any secrecy or
> > privacy where as encrypt does.
>
> Right.
>
> > Aside [
> >
On Tue, Aug 10, 2004 at 08:57:14PM -0400, Geoffrey Young wrote:
>
> >>but hiding the decryption key from technical people is generally
> >>impossible
> >
> >
> > Only if they crack your application server. Cracking the database or
> > sniffing packets would not be good enough, assuming traffic
27 matches
Mail list logo
