JupiterHost.Net wrote:
Stut wrote:
What planet are you on? Seriously? Because PEAR does not need to be
compiled into PHP. Zend Optimizer is no different to the optimizers
I was referring to --with-pear, sorry "compiled" was not the right
word *
I'm not familiar with the switch you are referring to. If you look into
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.
PEAR a bit closer you will find that it is simply a package of
classes. It does not need any changes to your PHP binary for it to
work correctly.
available for other scripting languages. Version mismatches are a fact
I was referring to how Zend Opt is "required" for some stuff mainly
because its necessary to offset the bloat. *
I'm not sure what gives you the impression that Zend Optimizer is
"required" for anything. ZO is a system for pre-compiling PHP code to
If a PHP system has been "Optimized" then it requires ZO. Most admins
need to have ZO since at least one of theri users will want to use sucha
PHP system.
I think you're grossly over-estimating the number of PHP systems that
use Zend Optimizer, not so much as an actual number but more as a
percentage of all software written in PHP.
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.
bytecodes such that the PHP source files do not need to be interpreted
each time they are run. While it is true that some commercial software
written in PHP is encoded and requires ZO, but this is a choice of
that particular developer and is not attributable to PHP as a language
or as a technology.
But it does epitomize PHP's overall paradigm of "you want to add
funtionality for XYZ? ok lets drunkenly add support for it without
tryign to be consistent or plan for anything in the future.
How so? Take any other interpreted language, and you don't usually get
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.
I'll freely agree that there are a number of things that exist in PHP
that are not ideal, and could appear to have been implemented by a
drunken developer trying to meet a deadline. However, having been a
lurker on the PHP-Dev list for a long time now I can say with absolute
confidence that most of the decisions made regarding what gets into PHP
and what doesn't are well-justified.
PHP is not a small system, and it takes a huge effort to manage the
ongoing development. Mistakes have been made and undoubtedly will
continue to be made, but I'm sure the same can be said for any
similarly-sized open-source project.
of life with all tools, deal with it. And last but not least, you do
not
And PHP tends to have a greater majority of them, have you ever
managed PHP on multiple servers? If you have you kwo exactly what I'm
referring to.
I maintain 13 servers in total, each of them have PHP installed, and
try 13000 :) 13 is child's play and can be easily managed.
IMHO, 13,000 servers should be just as easy to manage as 13 - it all
depends on the infrastructure (in terms of tools) you have in place to
assist you in the task.
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?
have to be root to do anything with PHP, or indeed Apache except to
I was referring to building PHP/Apache in general *
You do not need to be root to build PHP or Apache, or in fact anything
else, so I'm not sure where you're getting that requirement from.
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
compiling it in their own directories, they'll be running their own
copies. They can't interfere with the systems installation of either
because file permissions don't let them, but that doesn't stop them
working on their own copies of it.
Any user with shell access with the required build tools available to
them will be able to do the same. If you think otherwise I encourage you
to try it.
listen on a port lower than 1024, which is true for all tools since
it's a platform limitation.
* I'm speaking in generalitites of working with PHP not specifics
components of the technology.
In that case I would point out that your personal experiences with PHP
are not necessarily a reflection on PHP. I hope you don't take offense
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
learn something from this exchange. You clearly feel quite passionate
about it, so please share.
Quoting your original post... "it uses perl's MIME tools and SMTP
tools". How is that not saying "PEAR or any specific package used Perl"?
Because I was refering to the URL I'd sent to Perl's Mail::Sender::Easy
module.
Reading back I see that now, but it was a bit ambiguous. My apologies.
Your solution was not "better" given the context of the question.
Specifically that the question was asking about doing something in PHP
and was asked on the PHP list meaning it's not a great leap to assume
the guy need a solution in PHP.
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
are still on a PHP list, and as I've stated before, the question was
clearly asking for a PHP solution.
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.
I'm on this list because I am a developer for a company that makes an
apache install system and I needed to find out some info on the specific
oddness of PHP4 and PHP5's --with-mysql and --with-mysqli options so
that its would work properly.
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
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
personally have never had a problem with them, but if there is a better
way I'm all ears.
-Stut
--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
