On Mon, May 16, 2005 at 11:30:36AM +1200, Steve Holdoway wrote: > > that does not help me when my users ask me to run applications that > > require it to be on. > So warn them and just switch it on for their own application. What's the > problem? They can only hurt themselves.
but i am the one made responsible if they, or better, if we get hurt. this is not a regular isp situation. i am just one of the admins for that group of users and it is my responsibility to protect them. a warning will not do here if i want to do my job in a responsible manner. > > yup, and now it is on the php side to convince me otherwise. no luck so > > far. > Wrong. As a customer, it is fine to think that. As a *service* provider, > you need to keep current. uhm, you are missreading that. i did not say anything about not keeping current. i am watching php and am waiting for the evidence that all the problematic php code has gone out of use, and every relevant php application has been updated to the latest safety standards. > >> >but the signal/noise ratio for php is just worse than other languages > >> Is, or was? > > is. > been in comp.lang.c lately? sorry, i meant worse than perl, python, pike and related languages. > >> I'd look more at using release candidate webserver software ( > >> Caudium/1.4.4 RC1 ) or old versions ( Apache/1.3.26 ) as a far greater > >> potential for damage than whether or not to support php. > > how so? > Well the potential buffer overflow in 1.3.32 that could compromise the > whole server would be a start. i don't see the difference to problems in php applications. it might be relevant for people doing shared hosting, nothing i need to worry about fortunately. > If only buffer overflows were a major problem! Libraries (like for example > stlport) catch all that. It's logic that causes most of the problems - > which is screwed up by a failing in the analysis phase of any major > project... a point that got snipped from my post. there is no project analysis phase when i take applications others have written. i have no control over how they write their code. there is only analysis of the results, which brings us back to signal/noise. short from reading all the code myself the only way to judge applications is to listen to what other people have to say about them. > > my personal preferance IS maintainability, portability, and related > > things. working with pike is a result of that preference because these > > all things where dynamic languages like python or pike (and php too) are > > a lot better in than c or the like. and if there is a reason to write > > parts of your application in c you can still do that. both languages > > easely include c libraries. > Err... what's php, pike, great big chunks of python written in again? And > the kernel, sendmail, apache.... even that appalling mail client that you > use (: you are mixing unrelated things. i prefer maintainability and portability for my code. as a result i prefer to write my code in pike. i do not need to maintain the pike binary, nor the kernel, or any of the other applications i use, hence i do not care what language they are written in, as long as i can establish (at least by reputation) that they are written reasonably well. greetings, martin. -- cooperative communication with sTeam - caudium, pike, roxen and unix offering: programming, training and administration - anywhere in the world -- pike programmer travelling and working in europe open-steam.org unix system- bahai.or.at iaeste.(tuwien.ac|or).at administrator (caudium|gotpike).org is.schon.org Martin B�hr http://www.iaeste.or.at/~mbaehr/
