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.


PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to