I think we may have to agree to disagree. I love PHP. I've never had a
problem with it that couldn't be solved that's made me want to switch.
Just to make it clear I do try the so-called "up-and-coming" development
trends, and over the years have tried most of the existing systems. I
recently started using Rails, which has some very nice features but I
find it far too restrictive for development of anything more than 'toy'
apps. Just wanted to make the point that I'm not pro-PHP for no reason.
I've tried the rest, I've settled on what I believe to be the best.
JupiterHost.Net wrote:
in PHP source:
./configure --help
I've had a look and it would appear that all that switch does is
install PEAR for you during the build process. That doesn't change the
fact that it's still just a collection of PHP classes and does not
require rebuilding of PHP to benefit from it.
sure no problem, again mostly I was speaking in gernalities about how
its works and referencing the switch since you'd never heard of ti.
You're also making it sound like adding ZO to a PHP installation is a
mammoth task... it's not. It's just as simple as building PHP itself.
Which is a mammoth task ;)
No more so than building Perl or Python or Ruby IMHO.
How so? Take any other interpreted language, and you don't usually get
Even though PECL and PEAR alleviate some of the headache by trying to be
CPAN, much funtionality is based on build options (mysql, curl, etc)
Again, this is not true. As far as I know, PHP is architected as a core
engine with modules for all userland functions, including what could be
considered basic features such as array operations. What this means is
that each module that provides additional functionality can be built as
a dynamically loaded object. That is to say separate from any other
functionality.
So if I find that my server does not have, say, mysql support built in
or I need a special kind (see ./configure --help for a list) then PHP
will most likely need recompiled.
Not so. Or rather, I should say, build the .so.
If it breaks, you may break PHP for everyone, it may even take down
apache if the .so got goofy.
With Perl
perl -MCPAN -e 'install DBD::mysql;'
if it breaks then
- all scripts still work
- apache still works
Build the .so. Run php on the command line with a script that uses the
dl function to dynamically load the new module. If it doesn't work it
hasn't broken anything since it's dynamically loaded. If it does work
then you update the configuration file that lists the extensions to be
loaded at startup and restart Apache.
pre-compilation for free. Correct me if I'm wrong but this goes for
Perl as much as it does for PHP. You have to 'jump through hoops' to
get it.
one command, no possiblity of breaking anything, one hoop, very low to
the ground and about ten feet tall :)
Likewise with adding MySQL to PHP, as long as you do it right. Do it the
lazy way (which is just to recompile) and you could encounter problems.
Out of curiosity, why do you find it easier to manage Perl on 13,000
servers? What specific advantages does it have over PHP when it comes
to this?
Perl just works and make sense so its easier to code with. Any issue
sthat do come up now and then are usually resolved by a moduel upgrade,
one CPAN cpmmand :)
Same with PHP.
So any user on your systems can recompile apache or PHP at will?
Yeah, I don't stop them - more hassle than it's worth. But they'll be
Ok, i guess I'm refering to running a webserver that all the user's
share. If "bob" needs --with-curl then PHP needs to be recompiled. in
practice most hosting customers are hosting customers because they
woudln't knwo anythgin about compiling their own anything.
Its all really besides the point though, perhaps I shoudl have just
phrased it "you have to recompile some major stuff just to add minor
functionality"
We're talking about different things. The only point I was making is
that building PHP and Apache do not *require* root. In fact only
installing it requires root. You certainly don't need root to run
either. You seem to be extending this to include whether users are
capable. That's irrelevant - they can if they want to, but in most cases
it's not worth their while.
In your example of "bob" and his CURL module, it's as simple as building
to .so (bob can do this if he's able), sticking it in the right
directory and running a test script (as I described above) to ensure it
doesn't break anything. No recompilation of PHP, or any other "major
stuff" needed, and nothing gets broken.
My personal experiences with PHP and many other internet technologies
is quite extensive.
I don't doubt that, but I'm not understanding what Perl gives you that
makes it easier to manage than PHP. Please explain it to me so I can
As I stated I'm not doing a Perl vs PHP rant I'm doing an "anything but
PHP" rant :)
And that justifies it how? All I'm getting is an "I hate PHP and nothing
you say will sway me from that opinion". Is that accurate? Because if it
is I have better things to do with my time.
learn something from this exchange. You clearly feel quite passionate
about it, so please share.
Actually since most everyone has expressed an interest in stopping this
thread, I think I will. Teh facts are there do as you wish :)
Agreed, we should probably both give up. The "facts" are still in
dispute, but each to his or her own.
A solution is a solution, PHP is just one tiny option, I was offering
an easier to work with alternative.
Without adequately explaining why it's easier. And more to the point you
Sure I did, no one wants to hear it though :)
are still on a PHP list, and as I've stated before, the question was
clearly asking for a PHP solution.
True enough, but if you want to be strict then why not send them to a
none DB list?
Fair point, but it was still a *PHP* list not a generic DB list.
Feel free to ignore the rest of this post, which I hope you'll take
in the spirit it is meant, but please answer me this. What has PHP
done to you? Why are you so anti-PHP? And specifically why are you
on a PHP list suggesting people use a different technology?
PHP has all the problems I've been specifying, that costs time and
money, and I'm sick of it :)
Yeah, I got that already :). What I haven't grok'd is what
specifically makes Perl easier and therefore cheaper to manage.
As I stated I'm not doing a Perl vs PHP rant I'm doing an "anything but
PHP" rant :)
Which in fact PHP4/5 + --with-mysql[i] *is* a huge example of what
makes PHP the last choice for any project.
Again, this is a statement that makes no sense to me. You've made a
statement saying you hate something without explaining why. Do you see
Because its got *soooo* many problems, security, development, admin wise
- details throughout this thread :)
Yeah, about those security problems. You mentioned phpBB as an example.
You must be aware that nearly every problem related to security that has
ever been found in relation to PHP has been down to poor implementation
on the part of the script developer and not PHP itself. All other
languages and tools are open to the same type of problems, but
popularity and user-base of PHP cause bad press.
why it's very hard to learn from you when you don't justify your
hatred? What's the problem with the MySQL modules available for PHP? I
Those configure flags have so many combinations to get unpredicatabel
behavior this is the pseudo thought process while doing it:
--with-mysql (make sense so far)
but lest add the super duper mysqli stuff:
Oi crap what arg do you give it depending on what --with-mysql 's value
is?
--with-mysql=/usr --with-mysqli=path_to_mysql_config
--with-mysql --with-mysqli=/usr
Please enlighten me as to how other tools find the MySQL libs. As far as
I'm aware they do it in exactly the same way, namely an automatic search
which will occasionally fail which requires the ability to specify it in
the configure command.
Is all of that mess the same on PHP 4 and 5 ?
Pretty much.
What if you have mysql 4.0, 4.1, or 5 ?
Doesn't matter.
and once you get your head wrapped around it are all the badly named
funitons gogin to behave the same?
Badly named functions? There are some dodgy ones still in there for BC
reasons, but this has improved a lot since PHP 4 & 5 arrived.
personally have never had a problem with them, but if there is a better
way I'm all ears.
yep, use Perl's DBI modules or some other API (C, Python, Ruby,
*anything*) to MySQL that is consistently easier to setup and use
Again, we'll have to agree to disagree. For me PHP makes setting up and
using MySQL a breeze.
Anyway, I think we should end this here since we're clearly not making a
dent in each others opinion of PHP. Feel free to reply to me offlist if
you really want to continue, but I don't think there would be much point.
-Stut
--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
