[PHP-DB] Re: Sending filing attachments using PHP
Am 2006-05-12 10:09:46, schrieb JupiterHost.Net: Right after rebuilding php and apache and breaking PHP funtionality for everyone, just so you can send a semi complex MIME message? That is the epitome of PHP's lameness and why I can't sit quietly by and not recommend an easy to install and use and maintain solution. Hmmm, I send per day around 80.000 different E-Mails created with php5 most of them are mime-encoded and multipart... I do not know, which problems you have, but it works perfectly Even complex multiparts with message/rfc822 and binaries inside. OK, the message should not be bigger then 20 MByte except you have a machine like mine... 32 CPU's and 64 GByte of memory. - no fiddling with apache No problem for apache 1.3 with php5 - no fiddling with the interpretet binary apt-get install ... - no possibility of breaking anyone's scripts It just works... So why bother wit a language no ene knows how this crappy syntax works? ;-) Greetings Michelle Konzack -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/6/6192519367100 Strasbourg/France IRC #Debian (irc.icq.com) -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DB] Re: Sending filing attachments using PHP
Am 2006-05-12 15:39:44, schrieb JupiterHost.Net: Why not use Perl, it has all the pros but does not have the cons :) Oh yes it has... Perl is a memory monster... I have no problems to soupport over 17.000 Users on 32 CPU machine with 64 GByte of memory using apache 1.3 and php5. Perl would just kill the machine... In fact, I use it for several high volumn websites: - with persistent database connections and persistently running instances of the script (which is the *only* positive PHP has, except it means running PHP as nobody and with really really bad permissions) Why this? - without doing *anything* with apache apache servs only websites and the output of the php... - works with SuExec so it runs as the user so the permissions can be 700 and config files 600 - try that with PHP without days of fiddling and breaking stuff and finally giving up ;) Sorry? - I do exactly the same with my 17.000 users using suphp. Greetings Michelle Konzack Systemadministrator Tamay Dogan Network Debian GNU/Linux Consultant -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/6/6192519367100 Strasbourg/France IRC #Debian (irc.icq.com) -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] Re: Sending filing attachments using PHP
So why bother wit a language no ene knows how this crappy syntax works? Because you are mistaken based on your preference and experience and calling it crappy is not a very professional way to make your argument. Again I was simply pointing out some *major* drawbacks of PHP, not doing a one lang vs another comparison. -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] Re: Sending filing attachments using PHP
Michelle Konzack wrote: Am 2006-05-12 15:39:44, schrieb JupiterHost.Net: Why not use Perl, it has all the pros but does not have the cons :) Oh yes it has... Perl is a memory monster... Anything is a memory monster if the task is memory intensive. many benchmarks of multi languages (not just Perl/PHP) doing similar task show PHP as one of the highest actually. I have no problems to soupport over 17.000 Users on 32 CPU machine with 64 GByte of memory using apache 1.3 and php5. Perl would just kill the machine... Thats good that you have had good experince on one machine or cluster. Have you tried 17000 servers yet? -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] Re: Sending filing attachments using PHP
Ron Piggott (PHP) wrote: I came up with some code today. I started e-mailing myself file attachments to see what my e-mail program did in preparing them and when I opened the e-mails I changed the view to show e-mail source. The biggest challenge is the boundary that separates the e-mail message text from the file attachment. I found this command on php.net here to generate the boundary: You're piping a hand crafted mime message to sendmial via mail()? You are a glutton for pain :) (and oh yeah theres about a zillion MIME issues you've overlooked that will come back and bite you later, gauranteed) use a tool thats made for it: http://search.cpan.org/perldoc?Mail::Sender::Easy -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] Re: Sending filing attachments using PHP
Alister Bulman wrote: On 12/05/06, JupiterHost.Net [EMAIL PROTECTED] wrote: You're piping a hand crafted mime message to sendmial via mail()? You are a glutton for pain :) (and oh yeah theres about a zillion MIME issues you've overlooked that will come back and bite you later, gauranteed) use a tool thats made for it: http://search.cpan.org/perldoc?Mail::Sender::Easy I agree - don't get bitten on the ass, but OTOH, there's already a PHP Mime encoder - no need to point him to a Perl library http://pear.php.net/package/Mail_Mime Yes there's a huge need, PHP is way to problematic and many folks don't even realize thats its one of a hundred possible tools. Most of which are better suited for most things. Plus, what if you don't have Pear compiled into PHP? Now theres more hoops, oops need zend optimizer, more hoops, oops that version doesn;t work on that verison, more hoops. Oh yeah and you have to be root to do all this, nice. And that module is not a MIME tool in itself, it uses perl's MIME tools and SMTP tools but it abstracts all of that for you so all you have to do is make a hash that represents your mail. No knowlege of SMTP or MIME necessary. And you can install it as a regular user and use it yourself if need be, what could be easier :) -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] Re: Sending filing attachments using PHP
JupiterHost.Net wrote: Alister Bulman wrote: On 12/05/06, JupiterHost.Net [EMAIL PROTECTED] wrote: You're piping a hand crafted mime message to sendmial via mail()? You are a glutton for pain :) (and oh yeah theres about a zillion MIME issues you've overlooked that will come back and bite you later, gauranteed) use a tool thats made for it: http://search.cpan.org/perldoc?Mail::Sender::Easy I agree - don't get bitten on the ass, but OTOH, there's already a PHP Mime encoder - no need to point him to a Perl library http://pear.php.net/package/Mail_Mime Yes there's a huge need, PHP is way to problematic and many folks don't even realize thats its one of a hundred possible tools. Most of which are better suited for most things. Plus, what if you don't have Pear compiled into PHP? Now theres more hoops, oops need zend optimizer, more hoops, oops that version doesn;t work on that verison, more hoops. Oh yeah and you have to be root to do all this, nice. What planet are you on? Seriously? Because PEAR does not need to be compiled into PHP. Zend Optimizer is no different to the optimizers available for other scripting languages. Version mismatches are a fact of life with all tools, deal with it. And last but not least, you do not have to be root to do anything with PHP, or indeed Apache except to listen on a port lower than 1024, which is true for all tools since it's a platform limitation. And that module is not a MIME tool in itself, it uses perl's MIME tools and SMTP tools but it abstracts all of that for you so all you have to do is make a hash that represents your mail. No knowlege of SMTP or MIME necessary. And you can install it as a regular user and use it yourself if need be, what could be easier :) Yeah, you're definitely smoking somethin'. The PEAR package Mail_Mime is another example of a pure-php class. It certainly does not use anything perl related at all. I'd really like to know what makes you think it does. Oh, and there's nothing stopping you installing any of the PEAR classes as a regular user and using it yourself. What could be easier? Not having to read your ignorant emails. -Stut -- If ignorance is bliss, you must be in heaven! -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] Re: Sending filing attachments using PHP
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 * 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. * 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. have to be root to do anything with PHP, or indeed Apache except to I was referring to building PHP/Apache in general * 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. And that module is not a MIME tool in itself, it uses perl's MIME tools and SMTP tools but it abstracts all of that for you so all you have to do is make a hash that represents your mail. No knowlege of SMTP or MIME necessary. And you can install it as a regular user and use it yourself if need be, what could be easier :) Yeah, you're definitely smoking somethin'. The PEAR package Mail_Mime is another example of a pure-php class. It certainly does not use anything perl related at all. I'd really like to know what makes you think it does. I never said PEAR or any specific package used Perl, I'd simply offered a better solution that happend to be done in Perl. Oh, and there's nothing stopping you installing any of the PEAR classes as a regular user and using it yourself. What could be easier? Not having to read your ignorant emails. I was outlining some of PHP faults, not getting personal which truly *is* ignorant. Good day to all, sorry if I was to ambiguouse or I've offended. -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] Re: Sending filing attachments using PHP
Let me start by apologising if my posts came across as personal. Check the archives for my posts, primarily on php-general and you will see that I have a very sarcastic personality. No offence was meant or is meant by what follows. JupiterHost.Net 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 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 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. 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 I've never had a problem with version issues. And I have to say that in my experience other tools have more problems with this. Perl used to be a nightmare for us until we rewrote the scripts we had in PHP. I'm not blaming PHP for this, I'm just trying to point out that problems related to version mismatches are usually related to the administrators understanding of that particular package. For me that means Perl caused me more issues than PHP because I know PHP better. 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. 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 at that but I know a huge number of developers and sysadmins who are more than happy with working with PHP, and nearly all of them have been through the process of trying the alternatives before landing on PHP as the right solution for them. And that module is not a MIME tool in itself, it uses perl's MIME tools and SMTP tools but it abstracts all of that for you so all you have to do is make a hash that represents your mail. No knowlege of SMTP or MIME necessary. And you can install it as a regular user and use it yourself if need be, what could be easier :) Yeah, you're definitely smoking somethin'. The PEAR package Mail_Mime is another example of a pure-php class. It certainly does not use anything perl related at all. I'd really like to know what makes you think it does. I never said PEAR or any specific package used Perl, I'd simply offered a better solution that happend to be done in Perl. 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? 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. Oh, and there's nothing stopping you installing any of the PEAR classes as a regular user and using it yourself. What could be easier? Not having to read your ignorant emails. I was outlining some of PHP faults, not getting personal which truly *is* ignorant. I hope you understand that I wasn't getting personal, but you must accept that your answers so far have suggested that you don't actually know much about what you are talking about. Good day to all, sorry if I was to ambiguouse or I've offended. 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? -Stut -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] Re: Sending filing attachments using PHP
Stut wrote: Let me start by apologising if my posts came across as personal. Check If? How else can What could be easier? Not having to read your ignorant emails. be taken? No worries though I understand, thanks :) 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 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. 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. 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. 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? 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. 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. 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. 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 :) 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. -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] Re: Sending filing attachments using PHP
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
Re: [PHP-DB] Re: Sending filing attachments using PHP
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 ;) 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) 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. 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 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 :) 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 :) 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 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 :) 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 :) 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? 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 *s* many problems, security, development, admin wise - details throughout this thread :) 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 Is all of that mess the same on PHP 4 and 5 ? What if you have mysql 4.0, 4.1, or 5 ? and once you get your head wrapped around it are all the badly named funitons gogin to behave the
Re: [PHP-DB] Re: Sending filing attachments using PHP
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
Re: [PHP-DB] Re: Sending filing attachments using PHP
Stut wrote: I think we may have to agree to disagree. I love PHP. I've never had a Ah I completely forgot about this sort of fun thing that I find in my email almost once a week, just got this one: http://forums.gentoo.org/viewtopic-t-460727.html now how many phpinfo() pages do you think there are and how many are vulnerable to the cross-site scripting attack. So this report means you have to upgrade your binary and it addresses: - system level problems (buffer overflow, memory leak, potential crash) - web based secuity attacks (corss-site scripting) - code based security attacks (restriction bybasses) *exactly* the sort of stuff thats jaded me :) Time to upgrade each install of PHP on all 13 server's :) The phpingo(0 reminds me of the one they had where a php file with only this line: ? phpinfo(); ? would allow an attacker to upload a rootkit and damage the system, saaaweeet ;p or a cross site scripting/SQL injection thing that'd allow people to post HTML to your site and make it show whatever they wanted... good times, good times Peace everyone, its been really fun :) -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] Re: Sending filing attachments using PHP
php is not the only language susceptible to x-browser attacks... seems unfair to single it out. And as previously pointed out, many times it the developer's fault for writing that insecure code Bastien From: JupiterHost.Net [EMAIL PROTECTED] To: php-db@lists.php.net Subject: Re: [PHP-DB] Re: Sending filing attachments using PHP Date: Fri, 12 May 2006 18:53:13 -0500 Stut wrote: I think we may have to agree to disagree. I love PHP. I've never had a Ah I completely forgot about this sort of fun thing that I find in my email almost once a week, just got this one: http://forums.gentoo.org/viewtopic-t-460727.html now how many phpinfo() pages do you think there are and how many are vulnerable to the cross-site scripting attack. So this report means you have to upgrade your binary and it addresses: - system level problems (buffer overflow, memory leak, potential crash) - web based secuity attacks (corss-site scripting) - code based security attacks (restriction bybasses) *exactly* the sort of stuff thats jaded me :) Time to upgrade each install of PHP on all 13 server's :) The phpingo(0 reminds me of the one they had where a php file with only this line: ? phpinfo(); ? would allow an attacker to upload a rootkit and damage the system, saaaweeet ;p or a cross site scripting/SQL injection thing that'd allow people to post HTML to your site and make it show whatever they wanted... good times, good times Peace everyone, its been really fun :) -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] Re: Sending filing attachments using PHP
Bastien Koert wrote: php is not the only language susceptible to x-browser attacks... seems unfair to single it out. Why not? Its the only I've seen that actually has hackability built in! (see below) So it singles itself out, thats the whole point :) And as previously pointed out, many times it the developer's fault for writing that insecure code Yes developer does cross-site scripting suseptable code = developer's fault * but if a script has *only* this as its content: ? phpinfo(); ? And *that* script has cross-site vulnerabilities is the programmer at fault for writing bad code? No, he's at fault for using PHP I rest my case ;) The only solution is to upgrade the binary. That SUCKS big time! -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
