[CS-FSLUG] Content Management Software

[Vincent Danen]

* Micah Yoder <yoderm at gmail.com> [2007-10-09 09:52:52 -0500]:

>> A lot of these vulnerabilities are relatively minor.  Yes, I know there
>> have been a *lot* (oh boy do I know!), but for the most part they're
>> very minor or very difficult to exploit in any significant way.
>
>Well, exploits definitely happen.  I work in Linux tech support at a
>managed hosting provider, and I see them ...

I didn't say they don't happen... however, are those exploits related to
problems in php itself, or bad coding in the part of the application?
Think about that one for a moment.  There's a whole host of
badly-written PHP code out there.  PHP-Nuke was notorious for causing
problems.  If people don't keep the applications up to date, well,
current versions of PHP won't help.

There is a difference between PHP the language and PHP the
script-of-the-week applications.  You can't classify them together.

And yeah, I know to... I build the updates for Mandriva and PHP is a
source of many headaches whenever patch-time comes around.

>> You can also use a caching system, like memcached or APC.  They work
>> quite well.
>
>Perhaps.  Normally people use ionCube or Zend Optimizer, which are
>closed source.  I'm not familiar with memcached/APC.

I am.  They both work quite well.

>> And ugly code is in the eye of the beholder (and the skill/care of the
>> developer).  =)  I've seen some pretty awful perl code, some disgusting
>> PHP code, and some really clean PHP code.  Python is a bit nicer in this
>> respect.. you're almost forced into being tidy.
>
>You can make reasonably structured PHP, sure.  I still assert that
>it's not as pretty or efficient as Python.

I can't say... python has been on my TODO list for a few years now, but
lack of time has prevented me from really getting into it.  Python
certainly looks cleaner/prettier -- I'll definitely grant that.  I can't
speak as to efficiency as I've not done more than very basic basic
things in python.

>> >PHP is fine for small sites with simple logic.  Using it for more than
>> >that is, IMHO, insane.
>>
>> I disagree.  I've implemented stuff in PHP that was big and complex and
>> have had no issues with it whatsoever.  In fact, things that I've
>> rewritten from perl (or mimicked from perl), has been faster...
>> sometimes *much* faster, in PHP.
>
>Is that with one of those bytecode caches?  If not, that would be hard
>to believe.

Nope.  No caching.  This is strictly a command-line app, no caching
involved.  Of course, no overhead from apache either.

And I'm not lying.  =)  Frankly, I didn't expect the results either, but
it's true.  I would maintain that a lot of slowdown you find in PHP
isn't so much the language itself, but the author of the script.  PHP
can be extremely fast, without any external bytecode optimizations... if
you write it properly.

>> PHP, if used properly, has great potential and can drive very complex
>> and large sites/scripts.  The problem is it's so easy to pick up, on
>> every web hosting service out there, so it's easy for people to write
>> quick-n-dirty crap code.
>
>True.  I just don't think it is the best language out there for large
>web applications.  I'd rather use about anything -- including Java, or
>even ASP.net via Mono.

I'm not a big java fan at all.  I avoid anything java if at all
possible.  I've never played with ASP.net either.

"Best language" is in the eye of the beholder as well.  PHP has been
proven to power large sites under extreme loads many many times.  It is
definitely a contender and is capable.  Is it the best?  That depends,
again, on the developer.  If you're more familiar with PHP than java,
then PHP probably is your best bet.  If you're more familiar with
ASP.net than PHP, then maybe ASP.net is the best language.

If you're not familiar or learning a language that is on par with one
you already know, chances are the best language is the one you already
know.  So it's largely a matter of perspective/experience/etc on the
part of the developer.

The caveat here being that it's a language that is both capable and
proven.  I certainly wouldn't want to write Facebook in BASIC, for
instance, no matter how well I knew it.

>> Now, to be fair, I can only really compare perl and php, and of the two,
>> I much prefer php.  I've very little experience with python.
>
>Granted, I don't have experience writing a web app with Python yet.
>But I've looked at mod_python and Django, a toolkit that looks like it
>makes it somewhat simple.
>
>One disadvantage of mod_perl is that it ate *huge* amounts of memory.
>(Several years ago I commercially hosted Slashcode-based sites.  I
>could only get a couple small sites in 512MB and quickly had to
>upgrade my server to 2GB.)  I'm not sure if mod_python is as bad or
>not.

Yeah, that was my experience with mod_perl a few years ago as well.
Apparently it's gotten better, but I don't really know.  The only
perl-based web app I use is Bugzilla...  I maintain two installations
(one for Annvix, one for Mandriva).  The Mandriva one has mod_perl
installed on the server and the appropriate needed modules by bugzilla
although I'm not sure if bugzilla is using it or not; on the Annvix
server there is no mod_perl.  From an end-user persective, they both
seem equally fast for the data they contain (the Mandriva bugzilla is
much larger than the Annvix one, of course, so it's slower, but has a
massive database to deal with).  But I've not done any real formal
benchmarks largely because there doesn't seem to be any real info on how
to make bugzilla use mod_perl.  It's not as straightforward as it should
be.

>> But I question the idea that php is inefficient becase it has to parse
>> code for every HTTP request.  Don't python and perl have to do the same
>> thing, unless the server itself is written in said language?  I mean,
>> under mod_python or mod_perl, wouldn't the results be the same as that
>> under mod_php?  I suspect there is support there to prevent the
>> interpretter from firing up every time a request comes in, which reduces
>> some overhead, but don't they still have to re-parse things for each
>> request unless an object cache is being used?
>
>No.  Mod_perl and mod_python automatically cache bytecode, *and* they
>run code at a lower level in the webserver.  When a request comes in,
>it knows right off which perl or python function to call, and all
>objects are available immediately.  You can also use them to write
>full fledged Apache modules, not so with PHP.

Ahhh...  ok, that makes sense then.  Definitely handy.  They should do
something like that with PHP instead of relying on 3-4 different
bytecode interpretters.

-- 
Vincent Danen @ http://linsec.ca/