On Mon, May 16, 2005 9:40 am, Martin Baehr said: > On Mon, May 16, 2005 at 06:24:18AM +1200, Steve Holdoway wrote: >> by default, register_globals = off. > > 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. > >> Anyway, that last sentence is like my own personal sentiment that 'KDE >> is crap', which was true when I first tried to use it. What relevance it >> has to the current version of KDE is irrelevant, because the damage has >> been done to my thinking. > > 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. > >> >but the signal/noise ratio for php is just worse than other languages >> Is, or was? > > is. been in comp.lang.c lately? > >> As an ISP, I think you're failing to re-evaluate the tools out there on >> a regular basis. Yes, php did have the odd security hole, but, *none* >> have been found for over 3 years. > > i thought we alredy established that i was not talking about php itself > but the code written in it. Nope. > >> 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? > please elaborate. Well the potential buffer overflow in 1.3.32 that could compromise the whole server would be a start. > >> For large applications you should be looking at compiled languages - C, >> C++, Pascal,... all of which are far more mature than python, pike and >> the like. > > no. > but that is a completely different topic. > pike (and i think python too) is designed to write large applications. > writing code in it is much faster done than in c. > because of automated memory management you will not get buffer overflow > problems in your code. you do not need to do any memory managment, and > it is a lot easier to debug and test due to the runtime nature. > (in pike i can add and recompile classes at runtime, without restarting > the application, saving me a huge junk of time when developing.) > > c and c++ require much more experience to write good clean and safe > code. developing is much slower, and much more expensive without much > benefit. applications like zope or roxen/caudium show that these > languages are quite capable at handling complex applications. > 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 are one or two products that support C development - it has been around for a while after all. >> Anyway, the choice of language is far less important than a >> proper design framework, and things like portability, maintainability, >> and just about every other kind of -ability should be considered in your >> choice, not just personal perference. > > 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 (: > 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/ >
Steve. -- Windows: Where do you want to go today? MacOS: Where do you want to be tomorrow? Linux: Are you coming or what?
