Slashdot Mirror

← Back to Stories (view on slashdot.org)

PHP 5.2.2 and 4.4.7 Released

Posted by CowboyNeal on from the hot-off-the-presses dept.

daeg writes "PHP 5.2.2 and 4.4.7 have been released with a plethora of security updates. Many of the security notifications come from the Month of PHP Bugs effort, and range from double freed memory to bugs in functions that allow attackers to enable register_globals, to memory corruption with unserialize(), to input validation flaws that allow e-mail header injections, with an unhealthy sprinkling of other bugs and flaws fixed. All administrators that run any version of PHP are encouraged to update immediately."

122 comments

  1. I want to see someone claim again by suv4x4 · · Score: 5, Insightful

    I want to see someone claim that the "month of bugs" projects harms the products involved. From what we saw with Apple and PHP, they finally closed holes gaping for many previous versions.

    Now if only could PHP also fix their performance and inconsistencies..

    1. Re:I want to see someone claim again by KidSock · · Score: 2, Interesting

      I want to see someone claim that the "month of bugs" projects harms the products involved. From what we saw with Apple and PHP, they finally closed holes gaping for many previous versions.

      Now if only could PHP also fix their performance and inconsistencies..

      There's nothing "gaping". All the "month of bugs" were non-critical stuff pumped up by Esser for whatever reason I don't know. For example, there were a number of bugs that required the attacker to be able to supply their own code. If the attacker can supply their own code, they can just call popen() or system() and dispense with all the hoopla required to compermise the worker and inject shellcode.

      At first I thought you were trolling but from your "fix their performance" statement I realize you just don't know what the hell you're talking about.

      I'm happy to see bugs fixed but actually, I'm going to hold off on updating. These sorts of releases have a tendency to break things. Of course it might not but AFAIK these releases don't fix anything remotely exploitable so you won't see me running for the nearest terminal.

    2. Re:I want to see someone claim again by suv4x4 · · Score: 2, Funny

      At first I thought you were trolling but from your "fix their performance" statement I realize you just don't know what the hell you're talking about.

      Right. PHP's the fastest language out there, as proven in this test.

    3. Re:I want to see someone claim again by laffer1 · · Score: 1

      Its nice to find someone else who sees inconsistency problems with PHP. For those of you PHP users who don't see it, if I have to change code to make things work with PHP then a new release is not compatible with an old release. There are also some oddities in the API. PHP often gets a free pass because its open source and one of the earlier ASP like alternatives.

      I think the month of bugs helps consumers in the long term, but its certainly a bitch for the vendor to get flooded with tons of holes at once. If someone did that with one of my projects, it was be a nightmare right now. At least with apple and PHP (Zend) they have full time paid developers. PHP also has free developers obviously.

      --
      MidnightBSD: The BSD for Everyone
    4. Re:I want to see someone claim again by nxtw · · Score: 1

      That's pretty damning... If C# and Mono are faster, I can only imagine that MS's CLR would be even faster. Java's results vs. PHP are very similar.

      Perl is usually better as well, as is Python, Tcl, etc.

      In PHP's defense, how does performance compare once some sort of accelerator is involved? Are those fancy output caching engines or do they actually precompile/cache the code or something like that?

    5. Re:I want to see someone claim again by omeomi · · Score: 1

      Now if only could PHP also fix their performance and inconsistencies..

      Care to provide examples of either?

      --
      ZuluPad, the wiki notepad on crack
    6. Re:I want to see someone claim again by suv4x4 · · Score: 5, Interesting

      In PHP's defense, how does performance compare once some sort of accelerator is involved? Are those fancy output caching engines or do they actually precompile/cache the code or something like that?

      When you run a PHP file, there are two stages of execution:
      [build a parse tree from the source and output bytecodes] [interpret the bytecodes]

      The accelerators cache the bytecodes, so next time they are loaded (usually from RAM) and interpreted directly.

      However compare with what you get with the CLR by default:
      [a compiler builds the parse tree and outputs bytecodes] [opcodes are compiled to machine code] [natively run machine code linked to a runtime library]

      You basically never ever repeat the first step more than once there, and in some cases the second. And running as native code is hella faster. A big problem with PHP is it abuses string hashes and fails to do early binding where appropriate (indexed serial arrays, class objects and methods etc.).

      So everything you reference in PHP requires a bunch of hash lookups. It's terrible.

    7. Re:I want to see someone claim again by digidave · · Score: 4, Informative

      The raw speed of PHP isn't very relevant. It's a language for low to mid-range web apps that is flexible enough to do high-end web apps as well. If your PHP app is slow it's probably due to poor programming or poor database indexing or design. PHP usually takes request data, gathers a database result, shuffles around some data, then displays an HTML page. It's easily fast enough for its purpose.

      There are plenty of good criticisms for PHP (and every other language), but performance is only a factor in PHP web apps when the programmers do really stupid things.

      --
      The global economy is a great thing until you feel it locally.
    8. Re:I want to see someone claim again by Dragonslicer · · Score: 2, Funny

      I can't speak specifically about performance problems, since I know pretty much nothing about the engine itself, but anyone that doesn't think PHP has consistency issues doesn't use the language enough. There's some pretty serious inconsistency in function naming, though that's pretty much limited to functions that have been in the language for several major versions (array and string functions especially). PHP5 is a huge improvement over older versions, but it would still be nice to be able to completely get rid of all of the mistakes that were made in PHP3. And yes, I do write PHP code professionally, and I think it's a very good language, but you'd have to be delusional or inexperienced not to recognize its problems. Every language has its positives and negatives.

    9. Re:I want to see someone claim again by suv4x4 · · Score: 1, Insightful

      The raw speed of PHP isn't very relevant. It's a language for low to mid-range web apps that is flexible enough to do high-end web apps as well. If your PHP app is slow it's probably due to poor programming or poor database indexing or design. PHP usually takes request data, gathers a database result, shuffles around some data, then displays an HTML page. It's easily fast enough for its purpose.

      What you're saying: PHP is only good for gluing your DB to your HTML, straight procedural code. But that was true in the distant (in IT terms) past of the web, before PHP programmers got educated enough to demand applications with proper architecture and provisions, manageable and stable code, versus the spaghetti code we see so often in old open source PHP projects.

      Plus, go teach Zend about your view on their language. Their framework has terrible speed on their own language. Stupid Zend, doing stupid things.

      You can't put randomly a line where something becomes "too complex for PHP" and where it's not. If PHP struggles for tasks fast enough for other comparable, means the problem isn't in the programmers. In the end PHP loses, by having an "elite" of folks who would rather stubbornly defend PHP's faults than do something about them.

    10. Re:I want to see someone claim again by omeomi · · Score: 2

      Oh, you just mean naming conventions are inconsistent? I thought you were saying that, for instance, code written in one version of PHP doesn't work in a later version. That's a problem I haven't had. Upgrades have generally been pretty painless for me. And I've found PHP performance to be pretty good. My primary comparisons are with Perl and ColdFusion though, so maybe ASP is a lot quicker, and I just don't know it...

      --
      ZuluPad, the wiki notepad on crack
    11. Re:I want to see someone claim again by Dragonslicer · · Score: 1

      Yeah, the PHP devs have always put a lot of emphasis on maintaining backwards compatibility. Unfortunately, that has the down side of not being able to fix a lot of mistakes that were made in the past.

    12. Re:I want to see someone claim again by Bill,+Shooter+of+Bul · · Score: 1

      Their framework has terrible speed on their own language.

      care to site benchmarks? I saw one that had zend framework doing horribly as well. They were using version 0.4 beta. They're up to .92 beta now. From what I've heard on the news groups its doing better. Take a look at the language shoot out for comparison. Its still much faster than ruby.

      --
      Well.. maybe. Or Maybe not. But Definitely not sort of.
    13. Re:I want to see someone claim again by crayz · · Score: 1

      Yup. And as an ex-PHP coder, I spend about 1% of my time lamenting the performance hit from switching to Ruby. The other 99% of the time is spent glad I'm not using that nightmare of a language any more

    14. Re:I want to see someone claim again by cheater512 · · Score: 0, Flamebait

      Mono/C# are semi-compiled whilst PHP isnt (without a accelerator).

      If you tried using Mono/C# in a real world situation you'd find that it would be horrible because it would run as a CGI. The initialization for it would kill the server.

      I notice that none of the tests were remotely related to a web page as well.
      How the hell is Mandelbrot relevant?

    15. Re:I want to see someone claim again by arodland · · Score: 4, Interesting

      For example, there were a number of bugs that required the attacker to be able to supply their own code. If the attacker can supply their own code, they can just call popen() or system() and dispense with all the hoopla required to compermise the worker and inject shellcode. Well actually... no.

      PHP enjoys overwhelming popularity in shared-hosting environments, where you put a lot of users on one server, and the users supply the code, but you don't really trust the users. You don't want them to compromise other users' reliability, or break your server, or do anything very interesting... but you still have to let them run their code because that's what the service is. So PHP comes with all sorts of features to facilitate this... "safe mode" and the like. But if there are security issues all through PHP that poke holes in this security model, then you find yourself in a microsoft-esque situation where the security isn't real at all, and you're screwed. Not so pleasant.
    16. Re:I want to see someone claim again by cheater512 · · Score: 0

      The oddities are there to maintain backwards compatibility.

      I've never had a script break with version jumps (including 4 to 5) because I write good proper code.
      Some older crap wont work on PHP 5 but why would you want to run crap?

    17. Re:I want to see someone claim again by laffer1 · · Score: 1

      Sometimes you don't have a choice but to run crap. Either you get stuck on a product before you know its crap and its difficult to migrate or your boss mandates that you install crap.

      Besides, if Zend added the code to begin with how does one seperate what is going to go away from what is useful? Are they supposed to read minds? Seems very much like random windows apis that disappear or change.

      --
      MidnightBSD: The BSD for Everyone
    18. Re:I want to see someone claim again by CopaceticOpus · · Score: 3, Informative

      This is where we need to draw a line when talking about how good PHP's security is. For the case of a PHP developer running his own trusted code on a server, PHP can be very secure if the code is well written. That's the developer perspective. The other case is the PHP hosting company or system admin, running other people's untrusted code. In that case, the situation is much trickier. It may be possible to host that code securely, but it will take a lot of work and paying attention to security notices.

      So how worried you should be about PHP security comes down to whether you'll be running your own code you trust, or hosting someone else's code you don't trust.

    19. Re:I want to see someone claim again by cortana · · Score: 1

      Surely in a real-world situation you would run the C# app in a separate process and proxy requests from your frontend web server to the separate process via HTTP, FastCGI or SCGI.

      Or perhaps even build an interpreter into the web server itself (mod_mono).

      Spped problems eliminated.

    20. Re:I want to see someone claim again by RzUpAnmsCwrds · · Score: 4, Informative

      At first I thought you were trolling but from your "fix their performance" statement I realize you just don't know what the hell you're talking about.

      Right. PHP's the fastest language out there, as proven in this test.


      You're comparing two completely differnet language types. You might as well compare Java and C++.

      Compared to other interpreted (e.g. parse tree is built on the fly rather than by a compiler) languages like Python or Ruby, PHP is about average.

      Compare PHP to the CLR (or Mono) or to the JRE, and PHP is going to be way slower.

      But calling PHP slow because of some benchmark is just bull. Yes, Java or .NET is faster, and if you're writing an application that does a lot of crunching, by all means you should use a platform that is good at it. There are plenty of good reasons to choose J2EE or ASP.NET over PHP, but performance just isn't one of them in a lot of applications.

      The Wikimedia Foundation runs Wikipedia (the 10th most popular website in the world) with PHP and 123 commodity PC servers. What does that prove? It proves that application design and system architecture is FAR more important than what platform you choose. You can run benchmarks all day long, but that doesn't change the fact that Wikipedia does far more with far less than most websites out there - and they do it with PHP.

      I serve over 10 million pageviews a month on WS Network using PHP, MySQL, and a virtual server with 50MB of memory, a fraction of a 2.4GHz P4, and 100MB of swap. My informal load testing indicates that I could handle as many as 30 pageviews per second (80 million per month) with my current hardware and DB setup.

      Maybe I could do more with J2EE or ASP.NET (or, perhaps I could do far less - ASP.NET and J2EE aren't as easy on memory as PHP for small apps). But the fact is that I am doing a hell of a lot already considering the very limited hardware I'm running on.

      PHP code execution performance is not, and has never been, a major issue in my experience. It's the same way with Python, Perl, Ruby, and any other "scripting" language. The fact is, you're not going to write an H.264 codec or a PS3 game in Python. But many, many applications are not constrained by CPU performance. 8-core servers are now cheap. 16-core servers will be soon. Changing your language might give you 10x better performance. But architecture and algorithm improvements will probably get you much, much more.

      "Performance isn't a problem until it's a problem."
    21. Re:I want to see someone claim again by cortana · · Score: 1

      If you rely on safe mode to protect your system from your users, and your users from each other, then you have already failed.

      The only way to get this kind of security is to rely on the operating system to provide it for you; this is done by running PHP interpreters belonging to different security contexts as seperate users.

      With such a setup, the worst the user can do is screw up their own files (boo hoo!). :)

    22. Re:I want to see someone claim again by twomi · · Score: 1

      The fact is, you're not going to write an H.264 codec or a PS3 game in Python. No, but they made Civ4 with it ;)
    23. Re:I want to see someone claim again by nahdude812 · · Score: 1

      The PHP developers acknowledge that safe mode is a failure and PHP6 will not offer this feature. It was never meant to really be a complete sandbox environment, just a way to give a higher-than-usual level of isolation. People took this and expected more out of it than it was really designed to deliver, then criticized it for not being what they hoped it would be. It is already recommended that you use Xen or some other virtualization layer if you wish to sandbox your users.

      --
      Slay a dragon... over lunch!
    24. Re:I want to see someone claim again by TheSeer2 · · Score: 1

      That's a big stretch. A really, really big stretch. Infact, it's just plain bull. (I do realise Civ4 makes use of Python mind you).

    25. Re:I want to see someone claim again by Bert64 · · Score: 1

      Thats why you use something like mpm-peruser...
      That way, all the PHP code is executing as the individual web hosting user, and not as the global apache user. Thus:
      A bug in one user's site compromises their own account, but cannot mess with any of the other accounts.
      You cant stop users running buggy code, and its their own fault if they do. But you certainly should keep that code in a sandbox.

      --
      http://spamdecoy.net - free throwaway anonymous email - avoid spam!
    26. Re:I want to see someone claim again by jsebrech · · Score: 1

      The raw speed of PHP isn't very relevant. It's a language for low to mid-range web apps that is flexible enough to do high-end web apps as well. If your PHP app is slow it's probably due to poor programming or poor database indexing or design. PHP usually takes request data, gathers a database result, shuffles around some data, then displays an HTML page. It's easily fast enough for its purpose.

      What's also important is that PHP is meant to be parallelized, which lets it scale better to higher traffic. The larger web applications can't be run on a single box anymore, the performance requirements are too high. The difference between PHP and other solutions performance-wise is simply a matter of how many machines are in your server pool.

      Anyway, the simplest counter-argument to claims that PHP can't handle high loads is the fact that wikipedia runs on PHP.

    27. Re:I want to see someone claim again by Anonymous Coward · · Score: 0

      Someone around here has a very peculiar sense of humour.

    28. Re:I want to see someone claim again by amerinese · · Score: 1

      Are you going to try to monetize wikinote? What are your goals?

      I'm not against monetization, but if I don't understand what the provider is getting out of it, it makes me uneasy about using the service even if I like the service.

    29. Re:I want to see someone claim again by nxtw · · Score: 1

      Or perhaps even build an interpreter into the web server itself (mod_mono).


      mod_mono actually just sends the request to a mod_mono_server, which is a special version of the Mono ASP.NET web server that has a special interface.

      mod_mono's advantage is the ability to manage the mod_mono_server processes for you, while using standard HTTP proxying would require the user to start the process on their own.

      It is pretty similar to server-side Java.

      FastCGI support for Mono would be nice so that non-Apache servers could be used without having to manage your own processes.
    30. Re:I want to see someone claim again by shish · · Score: 3, Interesting

      The Wikimedia Foundation runs Wikipedia (the 10th most popular website in the world) with PHP and 123 commodity PC servers. What does that prove?

      Throwing more hardware at a problem will solve anything \o/

      I'm running a service which was originally PHP on a throwout box in the corner of my bedroom -- after a few months, the service was so popular the box was in a state of slashdottedness 24/7. I then moved to a shared host, where it ran happily for about a year, until it got so big it started breaking their uber-servers too. I have now rewritten it in python, and moved back to hosting it myself :P

      --
      I mod down anyone who says "I will be modded down for this", regardless of the rest of their comment
    31. Re:I want to see someone claim again by nxtw · · Score: 0, Troll

      If you tried using Mono/C# in a real world situation you'd find that it would be horrible because it would run as a CGI. The initialization for it would kill the server.


      I don't think there's many high-perormance websites out there that work using forking (standard CGI). In fact, IIRC Mono doesn't even support working as CGI, and I'm pretty sure Java doesn't as well. They only support running via an external process server (much like Java), e.g. via FastCGI, local proxying, or a special webserver/process server interface. (I personally like this design much better than mod_php/mod_perl/mod_* or CGI for all but the most trivial of pages.)

      It makes security easier and it means that you don't have to use the Apache prefork process model (if you use Apache).
    32. Re:I want to see someone claim again by Anonymous Coward · · Score: 0

      A typical PHP fanboy answer.

      PHP comes with a bunch of features that can either be activated or not by the admin by leaving out extensions.
      Additionally he can disable system(), popen(), ...

      These functions are always disabled in a secure PHP setup. No matter if shared hosting or not.
      So any kind of argumentation: the attacker can use popen() etc... are just lame excuses from the marketing department.

      And no this has nothing todo with safemode and no disable_function has never been considered broken by design like safe_mode.

    33. Re:I want to see someone claim again by cheater512 · · Score: 2, Insightful

      In fact, IIRC Mono doesn't even support working as CGI, Uhh...Anything can run as CGI as long as it can be executed.

      Heck you can make a bash script output your website for you. Or even QBASIC.

    34. Re:I want to see someone claim again by Anonymous Coward · · Score: 0

      "Thats why you use something like mpm-peruser...
      That way, all the PHP code is executing as the individual web hosting user"

      It's only so unfortunate you can't run PHP under mpm-peruser...

    35. Re:I want to see someone claim again by nxtw · · Score: 1

      Mono's ASP.NET implementation does not support working as CGI (for good reason). When someone refers to Mono or .NET in this context they are usually referring to ASP.NET.

    36. Re:I want to see someone claim again by cheater512 · · Score: 1

      What do you mean by 'supported'?
      It wont work or you wont get support if you bork your system doing it?

    37. Re:I want to see someone claim again by nxtw · · Score: 1

      Mono's ASP.NET implementation does not support working as CGI (for good reason). It sounds pretty unambigous to me. That is, it won't take the page arguments from environment variables and then output HTML over stdout. It operates using its own HTTP server or special MonoApache protocol, similar to Java servlets.

      CGI is unsuitable for any high-performance website, anyway.

    38. Re:I want to see someone claim again by Bert64 · · Score: 1

      No?
      I'm using it, it works just fine...
      Even supports eaccelerator too.

      --
      http://spamdecoy.net - free throwaway anonymous email - avoid spam!
    39. Re:I want to see someone claim again by Bill,+Shooter+of+Bul · · Score: 1

      O've never really understood the problem with the "nightmarish language" that is php. sure, I've programed in c, python, perl, pascal, delphi,Java, and yes php. They're all sort of messed up in their own ways. From having taught english, I can tell you its very messed up. part of being a programmer is thinking in new, creative, and yes nightmarish ways. Like putting Linux on a toaster, or making translating the Bible into Klingon. I would argue that PHP is the eqiuvalient of Linux on a toaster. The fact that it even works is amazing, and the fact that you cna use it for complex things is even more amazing.

      --
      Well.. maybe. Or Maybe not. But Definitely not sort of.
    40. Re:I want to see someone claim again by Anonymous Coward · · Score: 0

      The Wikimedia Foundation runs Wikipedia (the 10th most popular website in the world) with PHP and 123 commodity PC servers.
      Given Wikipedia's perennial performance problems, I'm not sure that's much of an advertisement. Yes, most of that is bandwidth-related, but the software is slow too - witness the way they beg people to avoid using template transclusion because it puts too much load on the servers.

      That's right - PHP was practically designed for including bits of templates in other pages, but when someone actually makes the foolish mistake of using PHP for a major application like Wikipedia, it turns out it can't even cope with that? Wow, what an awesome platform. Where do I sign up?
    41. Re:I want to see someone claim again by HvitRavn · · Score: 1

      If the attacker can supply their own code, they can just call popen() or system() and dispense with all the hoopla required to compermise the worker and inject shellcode.
      It's not that simple. In the case of web hosts with the open_basedir restriction in effect, you can't *open() or system() anything outside the basedir. It's a pretty effective jail. Here's an excerpt from the open_basedir documentation:

      Limit the files that can be opened by PHP to the specified directory-tree, including the file itself. This directive is NOT affected by whether Safe Mode is turned On or Off. When a script tries to open a file with, for example, fopen() or gzopen(), the location of the file is checked. When the file is outside the specified directory-tree, PHP will refuse to open it. All symbolic links are resolved, so it's not possible to avoid this restriction with a symlink.
  2. Any POC code? by Anonymous Coward · · Score: 0

    That enables hackers to register globals ? I have not heard of this.

  3. which one by yahurd · · Score: 0

    you heard them, upgrade to 4.4.7!
    then 5.2.2

    1. Re:which one by creativeHavoc · · Score: 1

      you obviously don't understand the PHP versioning.. this is like Microsoft updating XP and Vista... it doesn't mean upgrade to latest version of XP, then to latest version of vista... it means update your version.

      --
      insight through the mind
  4. Bad release practices by daeg · · Score: 5, Insightful
    I no longer use PHP, but these two releases highlight one of the things I hated the most about PHP. Every release, even minor "bugfix" releases (5.2.1 to 5.2.2) always do more than fix security and blocker bugs. That means that even if you're only updating to fix the mail() function, you have to run your entire site/system through testing to ensure the update didn't mysteriously break something else.

    See, for example, the 4.6.6 release notes:

    The PHP development team would like to announce the immediate availability of PHP 4.4.6. This release addresses a crash problem with the session extension when register_globals is turned on that was introduced in PHP 4.4.5. This release comes also with the new version 7.0 of PCRE and it addresses a number of minor bugs. That means that 4.4.5 introduced a major crash problem in a module every PHP website uses. How does that get missed? Also, why does that release also simultaneously bundle a new library version AND fix other "minor bugs"? Release the crash fix and that's it! Keep new features/minor bug fixes to point releases (4.5), not minor point versions.

    Thank god Python doesn't do that. At least they keep all the big changes to individual versions!
    1. Re:Bad release practices by gnud · · Score: 1, Insightful

      [snip]This release addresses a crash problem with the session extension when register_globals is turned on that was introduced in PHP 4.4.5.[snip](emphasis mine)

      If you use register_globals, you deserve all bugs that hit you. Period.
    2. Re:Bad release practices by atrus · · Score: 1

      I've personally always hated this too. They can't keep anything straight, and the core of PHP is a giant ball of inconsistency. I used to write PHP code. I mainly do Java with some Python or Perl on the side. All of them are far better in tools and workability than PHP. PHP just seems to outright encourage sloppy "just make it work" programming, which leads to all sorts of really really bad PHP "programs" (though some are good, when they're not weighed down by the language).

    3. Re:Bad release practices by maxume · · Score: 1

      s/register_globals/php/;

      Or maybe not?

      --
      Nerd rage is the funniest rage.
    4. Re:Bad release practices by Ambush+Commander · · Score: 5, Informative

      What you're missing is that fact that PHP uses the three digit version numbering system to mean something slightly different than what you're used to. Increments in the 0.x.0 number indicate, besides major changes in the language, that extension compatibility was broken and thus they need to be recompiled (to see a great example of this, check PHP 4.4). 0.0.x releases do contain feature releases, but you don't have to worry about extensions breaking.

      Firefox does the same thing too, except they end up stepping on extension authors feet when they increment the third version number! That's why they introduced a fourth number 0.0.0.x for memory leak / security fixes. But Firefox has the luxury of an auto-update system: something PHP doesn't have. It is in both sysadmin's and PHP's developer's best interests to not be releasing new versions every other week.

    5. Re:Bad release practices by Dragonslicer · · Score: 1

      I usually hate to comment on moderation, but I don't quite see how this is flamebait. Nobody in their right mind has used register_globals for several years now (well, anybody that knew what they were doing never used them at all, but some of us were still newbies back then). It really is a giant bug just waiting to happen.

    6. Re:Bad release practices by Dragonslicer · · Score: 3, Informative

      Yeah, I hate to admit it, but release management hasn't been the PHP developers' strength lately. I think 5.1.0 might have been the biggest screwup, where, after I think 7 release candidates, somebody committed new code a few days before the final release that created a builtin class named 'Date'. The thousands of people that used the PEAR class named 'Date' weren't too happy. In an amusing twist of irony, the developer that committed the code was a staunch opponent of adding namespaces to PHP.

    7. Re:Bad release practices by elronxenu · · Score: 1
      Hmm, wouldn't they be better off with X.Y.Z, where:
      • X means "functionality improvements" (relative to X-1)
      • Y means "bugs fixed" (relative to X.Y-1)
      • Z means "security fixes" (relative to X.Y.Z-1)
      ?
    8. Re:Bad release practices by TooMuchToDo · · Score: 1

      Any online resources or books you could suggest to help someone looking to write web apps in Python?

    9. Re:Bad release practices by Anonymous Coward · · Score: 0
      That means that 4.4.5 introduced a major crash problem in a module every PHP website uses. How does that get missed?


      How the heck did you miss it and upgraded production server to broken version of PHP?

    10. Re:Bad release practices by daeg · · Score: 3, Informative

      As a good start, i recommend Django. It's a nice framework that takes care of a lot for you, but still lets you write Python. They have a few tutorials as well as a good community and an ongoing project, The Django Book. I transitioned directly from PHP to Python without any books. Most coding forms transition directly over to Python. As you learn more Python, you'll find shortcuts, e.g., the list constructs and lambda functions.

      I also recommend reading over PEP 0008, the "standard" coding structure for the Python core libraries. It may seem restrictive limiting yourself to 79 character columns, but you get used to being able to read your code very quickly, especially if you come from PHP or Perl. (Tip: USE SPACES FROM THE START! You'll thank me later.) I can't underestimate the awesomeness of the interactive Python shell, either, especially for beginners.

      There are also other platforms out there, Turbogears and Pylons being two notable ones. I think the Django documentation is a bit better, though.

      You may also look up Web.py, which is as close to "drop and run" PHP as you'll get without going to pure CGI.

      Python takes a little more care to set up at the server level, and you won't find may $1 hosts that support it.

    11. Re:Bad release practices by cbraga · · Score: 0, Flamebait

      That's because you aren't supposed to use php for any serious stuff anyway, so it doesn't matter when it breaks, it's all in good fun.

    12. Re:Bad release practices by VGPowerlord · · Score: 1

      Ugh... the old spaces vs. tabs debate.

      I used to fall on the spaces side until I realized how iritating it is to respace things when you move down an indentation level and you're not using an IDE.

      I've been a staunch tab supporter ever since.

      It's not just that, either. If one uses tabs, then anyone else who has to edit it can set the tab size to whatever they wish. If Paul has a super widescreen monitor and wants his tab size set to 16 characters, more power to him! If George has a super small monitor and uses 2 character tabs, that's his choice.

      --
      GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
    13. Re:Bad release practices by cortana · · Score: 1

      No, you're right. ;)

    14. Re:Bad release practices by cortana · · Score: 1

      Basically the problem is that there are a lot of people out there that don't know how to use their editors; and a lot of broken editors that default to inserting 8 spaces when the user presses the tab key.

      The Tab key is not a shortcut for pressing space 8 times, damnit!

    15. Re:Bad release practices by cortana · · Score: 1

      Yeah and one effect of that is that lot of old crappy PHP 'applications' reimplement it themselves... *bashes head against wall*

    16. Re:Bad release practices by Anonymous Coward · · Score: 0

      Using spaces (and that includes "soft tabs") is morally wrong.

    17. Re:Bad release practices by daeg · · Score: 1

      The reason Python recommends spaces is because of line continuations, not because it makes things readable. If you follow the well-thought out coding guide, columns never go more tan 79 characters, so generally you'll find things like this:


      some_call(arg1, arg2,
                          arg3, arg4)


      but moved over, obviously. If you used tabs in there instead of spaces, and someone changes their tab size, your code instantly becomes completely unreadable.

    18. Re:Bad release practices by VGPowerlord · · Score: 1

      That kind of thing is the only time that I can think of right offhand that I mix tabs and spaces... of course Python doesn't like that.

      (I haven't learned Python yet, so I'm just guessing)

      --
      GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
    19. Re:Bad release practices by jZnat · · Score: 1

      Don't you mean:

      $msg = preg_replace('/register_globals/', 'php', $msg);

      --
      'Yes, firefox is indeed greater than women. Can women block pops up for you? No. Can Firefox show you naked women? Yes.'
    20. Re:Bad release practices by jZnat · · Score: 1

      Of course sysadmins have an autoupdate system! We have APT (Debian and co.), yum (Red Hat and co.), emerge (Gentoo), and various other autoupdate package managers. I believe there are even tools like XAMPP for Windows that include autoupdate features.

      --
      'Yes, firefox is indeed greater than women. Can women block pops up for you? No. Can Firefox show you naked women? Yes.'
    21. Re:Bad release practices by maxume · · Score: 1

      In the land of quibble, it would be:

      msg=msg.replace('register_globals, 'php')

      --
      Nerd rage is the funniest rage.
    22. Re:Bad release practices by jZnat · · Score: 1

      I don't remember if this was before or after the situation you describe, but there was a huge discussion on the PHP developer mailing lists on what to name the class. I believe it ended up being called DateTime.

      --
      'Yes, firefox is indeed greater than women. Can women block pops up for you? No. Can Firefox show you naked women? Yes.'
    23. Re:Bad release practices by Ambush+Commander · · Score: 1

      Yes, but any sysadmin worth their salt doesn't blindly install new versions of mission critical software until they make sure that it does indeed work properly.

    24. Re:Bad release practices by cortana · · Score: 1

      But why would you use tabs there in the first place?

      Tabs should be used for the initial indentation. Once you reach the indentation level that you want, use spaces to line things up (the clue is in the name... you can't "line things up" by using a spacing character that has a variable length... so don't!)

    25. Re:Bad release practices by daeg · · Score: 1

      Obviously my attempt to line it up in the element above didn't turn out as planned.

      To answer your question, though, Python doesn't "like" mixing tabs and spaces. It's also nice that almost all Python code follows "PEP 8". When interviewing for Python-heavy positions, for instance, I can ask if they know what PEP 8 syntax is. If they've never even heard of it, they aren't really interested in the language as far as I'm concerned. I wasn't a fan of spaces, either, until I switched into Python as my language of choice.

    26. Re:Bad release practices by Dragonslicer · · Score: 1

      Yup, it is called DateTime. It was after the 5.1.0 fiasco, because they picked the name specifically to not conflict with PEAR. It's a fortunate side effect that it's also a bit more descriptive (the class handles dates and times, not just dates).

    27. Re:Bad release practices by Anonymous Coward · · Score: 0

      If they've never even heard of it, they aren't really interested in the language as far as I'm concerned.

      Unfortunately, your opinion on whether they are interested or not does not determine fact.
    28. Re:Bad release practices by Anonymous Coward · · Score: 0

      I read lots of specs for fun that enable me to do new things, or just because I'm curious how everything really works. I don't read specs which consist of someone else's idea of what I shouldn't do, especially not style advice from a language designer who can't get comfortable with lambda and higher-order functions.

  5. Hate to whine, but... by Jasin+Natael · · Score: 1

    I failed to include support for curl when 5.2.1 came out and just spent close to an hour waiting for PHP 5.2.1 to compile, yesterday. Guess it's time to run ./configure again.

    --
    True science means that when you re-evaluate the evidence, you re-evaluate your faith.
    1. Re:Hate to whine, but... by Anonymous Coward · · Score: 0

      An hour? What are you running a 486?

  6. Someone has to say it... by Anonymous Coward · · Score: 0

    waiting for PHP 5.2.1 to compile, yesterday.

    [Nelson] HAH HAH! [/Nelson]

  7. Tag this story "phpsucks" if you agree by Andrew+Tanenbaum · · Score: 0, Troll

    As the subject says, tag this story "phpsucks" if you agree. PHP is a notoriously insecure language, and its design philosophy from its "Personal Home Page" days still shines through, despite its later renaming.

  8. You must be mistaken. by Generic+Player · · Score: 0, Flamebait

    Just listen to all the PHP apologists, PHP never has any security problems, its just people writing bad software in it that gives it a bad reputation.

    1. Re:You must be mistaken. by MrMunkey · · Score: 5, Insightful

      I'm not sure if you had some /sarcasm there or not. I'll assume not and say that you're partly right.

      I'm a PHP developer. I love PHP because I haven't come across anything that I can not do with it yet. Does that mean it's the best programming language ZOMG 3V3R! No. PHP is a pretty good general purpose web scripting language. Like all the other languages out there, it has bugs or features that haven't been implemented or thought of yet, and that's why there are version numbers.

      PHP does suffer some of the same issues that C++ has suffered in the past, and they are due to the fundamental ideas of the project. PHP doesn't have a framework for you to do everything. I guess that mostly comes up with ASP and probably Ruby, but I'm a little under read on Ruby. Much like the C++ vs. Java debate, C++ makes you do things yourself (or at least you need to know about the community projects that make life easier... like smart pointers and the like). That's pretty much the same with PHP. You have the base functions, and there are extensions you can get to help, but MVC and other parts of frameworks are left for you to decide what you want or need for your project.

      So, with that in mind, security is also left up to the developer. PHP 5.2.x has made a lot of great strides in helping out by introducing the Filter extension and others. If people do not filter/escape the input/output from their pages, they're just opening up a can of worms. I'm a firm believer in saying it's easier to filter yourself than undo a filter that the system did for you automatically.

      PHP has its issues, but I don't think it would be as popular as it is if PHP didn't serve a purpose and do it somewhat well.

    2. Re:You must be mistaken. by Dragonslicer · · Score: 1

      PHP never has any security problems, its just people writing bad software in it that gives it a bad reputation.
      Are you implying that those two items are mutually exclusive? I would be very impressed with any software project beyond "Hello World" that has never had a security problem. Having said that, a lot of the negative reputation is because people who haven't written more than 10 lines of PHP code think that phpBB and phpNuke demonstrate the only possible way to write PHP. Any language that lets you run shell commands (a very useful ability) will also let you run 'rm -rf /' if you don't know not to ever trust user input. There's only so much a language can do to protect the programmer before people start complaining that they can't do some necessary task.
    3. Re:You must be mistaken. by Generic+Player · · Score: 1

      What are you talking about? Read the summary, PHP has just fixed yet another batch of security holes. Trying to distract from the fact that PHP itself is poorly written and constantly full of exploitable holes is bull. Yes, lots of people write shitty PHP code. No, that does not mean PHP itself is secure, as their never-ending stream of security holes demonstrates.

    4. Re:You must be mistaken. by wwmedia · · Score: 1

      Yea really? what about multi-threading and proper unicode support?

    5. Re:You must be mistaken. by Jasin+Natael · · Score: 2, Informative

      For multi-threading, install a shared-memory cache, like apc, eAccelerator, or mmcache -- or use an in-memory table in your RDBMS. Now, you can spawn background tasks and monitor their progress or receive return values through the cache. You can even start a task as a server and keep it running indefinitely with set_time_limit(). I do plenty of unicode apps as UTF-8, and haven't had problems yet. If you're talking about UCS-2, then you have a good case. It's in development, but it's for PHP 6. Honestly, I'll probably switch languages before v6, based on all the other crap they're talking about throwing in. Version 5 is already getting pretty bloated, and it's only marginally faster than Java.

      Here's the utility function I use to spawn background threads (like, sending a thousand customized newsletters or updating hundreds of thousands of database rows). The background process can either lock a file or create some shared-memory structure to indicate its progress, and you can return immediately and end the script before it's done running. The nice prefix is optional.

      function fork($shellCmd) {
      exec("nice $shellCmd > /dev/null 2>&1 &");
      }
      --
      True science means that when you re-evaluate the evidence, you re-evaluate your faith.
    6. Re:You must be mistaken. by MrMunkey · · Score: 1

      You made good points about multi-threading, but it's possible the GP was also talking about multi-threaded support. It's a rumor that PHP itself isn't multi-threaded. Some of the older extensions are not multi-threaded, and that is why the suggestion to not go with multi-threaded apache exists.

    7. Re:You must be mistaken. by wwmedia · · Score: 1

      ah i know well how to start a new process from command line (and do so in a php based sockets server) but if you ever did Comp Architecture 101 you would realise that there a difference between a process and a thread, threads are lightweight processes with less switching overhead and smaller footprint, im talking about a Java / C# style threading model and an example were this would be usefull beside the sockets server i mentined would be an efficient proxy script, current php proxy scripts are over bloated pieces of spaghety code written by script kiddies (which is generaly true of many php apps) and yes i know of mbstring extension, but once again thats all it is and extension php6 wont be out for years yet

  9. Most of these bugs are completely preventable by chatgris · · Score: 2, Insightful

    There is really no excuse for those memory bugs. There are free, simple tools that check C code and memory management (and php itself is written in C).

    "double freed memory to bugs in functions that allow attackers to enable register_globals, to memory corruption with unserialize()"

    The authors of php should use valgrind, and with a few test cases, could virtually eliminate memory errors.

    Memory errors have been around for so long that there are numerous tools for dealing with them, many of them free. I know that many people on slashdot like to put down the importance of an education, but the knowledge, ability and discipline to use these tools is what separates professional software engineers from (generally smart) people who just hack at things.

    --
    Open Your Mind. Open Your Source.
    1. Re:Most of these bugs are completely preventable by Anonymous Coward · · Score: 0

      I know that many people on slashdot like to put down the importance of an education, but the knowledge, ability and discipline to use these tools is what separates professional software engineers from (generally smart) people who just hack at things.

      Yeah, but once somebody gets smart enough to realize what a steaming pile PHP is, they've moved on to another language. It's kinda like an "inverse Peter principle". So PHP tends to stay metastable. You know, like a cancer.

    2. Re:Most of these bugs are completely preventable by Anonymous Coward · · Score: 0

      "I know that many people on slashdot like to put down the importance of an education, but the knowledge, ability and discipline to use these tools is what separates professional software engineers from (generally smart) people who just hack at things."

      You had to sneak that in there, eh? "We" are against the idea that formal education is *necessary* for "knowledge, ability and discipline", not against education itself. But it's useless to argue about it; the proof is in the pudding.

  10. PHP is junk by Anonymous Coward · · Score: 0

    PHP has a long history of numerous remote-execution and other bugs like this. Great, so they went through 654,361 lines of C code and weeded out a dozen critical security bugs. Was that the last dozen in those 654,361 lines of code? There aren't any more critical security bugs lurking in there? And 654,361 lines doesn't even count all the external libraries that it links in and compiles with.

    Tomcat has never had a bug that would let a remote user execute code or change configuration settings or read files or doing a double-free or any of that kind of thing. And you would have to go out of your way to create a Tomcat application that has any of those bugs, because the framework has inherent protection against loading unknown code, double-freeing (not possible in any Java application), etc.

    1. Re:PHP is junk by Craig+Maloney · · Score: 1

      Here's a link to Secunia's Tomcat 5 advisories, one of which is a remote code buffer overflow exploit.
      http://secunia.com/product/3571/?task=advisories

      So yes, while PHP's advisories are about 10 orders of magnatude more numerous than Tomcat's, it still "bug that would let a remote user execute code or change configuration settings or read files or doing a double-free or any of that kind of thing".

      And trust me, it's just as easy to create fragile code in Java that can open your server like goatse as it is in any language, but it does seem to me that PHP puts most of the yoke of security squarely on the coder's shoulders. Unfortunately, I've also seen the code produced from those programmers, and the yoke was way too heavy for them to bear.

    2. Re:PHP is junk by Anonymous Coward · · Score: 1, Informative

      The buffer overflow you have referenced is in the mod_jk Apache module, written in C, which provides an AJP connector for communicating with Tomcat. It was not in the Tomcat application server.

  11. Examples of PHP inconsistency and performance by Snover · · Score: 4, Informative

    Sure, I'll give you some.

    Inconsistent function naming (underscores):

    substr_compare() vs.
    strcmp()

    More inconsistent function naming (verb location):

    file_get_contents() vs.
    get_html_translation_table()

    Even within the same extension:

    imagesetstyle() vs.
    imagecolorset()

    Flipped haystack and needle:

    strpos(haystack, needle) vs.
    in_array(needle, haystack)

    Speed:

    Scutigena Computer Language Performance Comparison (see graphs)
    There used to be another site that you could compare one language's speed relative to another that also showed PHP as one of the slowest. I can't seem to find it now, though. Also PHP5 might compare a bit more favourably, but this is all I could find after a quick Google search. Perhaps more importantly, PHP drags the speed of other things down (like Apache), since even though the core is supposedly thread-safe, nobody seems to know which extensions are and aren't, so eg. Apache needs to be run in prefork mpm instead of using a threaded mpm.

    I think PHP is overall a fairly decent language; I've used it for many years with great success. But it does have major problems, and it would be nice for them to get fixed instead of pushed aside. (I read some minutes from a PHP 6 meeting a while ago where they touched on the issue of consistency, and the PHP Group decided that it wasn't important enough to fix. It's really annoying to me to need a PHP-aware IDE or a manual always handy to program in a language because the arguments and function names are so non-uniform.)

    --

    [insert witty comment here]
    1. Re:Examples of PHP inconsistency and performance by Renegade88 · · Score: 2, Interesting

      There used to be another site that you could compare one language's speed relative to another that also showed PHP as one of the slowest.
      Yep, there still is. I think you are thinking about this one:
      Computer Language Benchmarks Game>

      That site features 19 programs implemented in 33 languages. Each program stresses something. You can see relative execution times and memory use, and it lets you pit one specific language and another and see how they compare.

      Yes, PHP loses in pretty much every performance category against compiled languages and even C#/mono.
    2. Re:Examples of PHP inconsistency and performance by jsebrech · · Score: 4, Insightful

      Perhaps more importantly, PHP drags the speed of other things down (like Apache), since even though the core is supposedly thread-safe, nobody seems to know which extensions are and aren't, so eg. Apache needs to be run in prefork mpm instead of using a threaded mpm.

      This is my main beef with PHP. They have their head in the sand with regards to server configuration.

      Case in point: the company I work for sells PHP-based service center and reservations systems to large companies. These companies generally have windows-based server infrastructures, so we have to deploy on windows/IIS. If you look at the suggested configuration for PHP on IIS in the PHP manual, you'll find this page, which explains regular CGI and ISAPI (multi-threaded) configurations. What the manual doesn't tell you is that neither of these configurations actually work in production environments. Regular CGI configurations are too slow (on windows), and ISAPI is too unreliable (customers that deployed with ISAPI configurations suffered daily server hangs).

      The only viable configuration for production IIS servers, as it turns out, is FastCGI, which is not documented in PHP's manual section on IIS configuration. Their documentation actively misinforms people on how to configure PHP. That's bad.

    3. Re:Examples of PHP inconsistency and performance by Just+Some+Guy · · Score: 1

      Oh, you forgot:

      5,343 built-in functions, assuming all the standard modules are installed. By comparison Python has 71. In other words, you have to keep track of about 75 times the number of name collisions when dealing with PHP versus Python.

      This could be almost instantly fixed if they'd add namespaces to PHP, but that keeps getting shot down.

      --
      Dewey, what part of this looks like authorities should be involved?
    4. Re:Examples of PHP inconsistency and performance by jZnat · · Score: 1

      Shot down? I was under the impression that namespaces were going to be in PHP 6, but the discussions over the syntax were pretty scary (should we use ":::" or "\"? they're the only two symbols left).

      --
      'Yes, firefox is indeed greater than women. Can women block pops up for you? No. Can Firefox show you naked women? Yes.'
    5. Re:Examples of PHP inconsistency and performance by Neutrino+Linguino · · Score: 1

      Have you considered or evaluated a Windows-based Apache/PHP solution? Recently, I've even been able to compile mod_fastcgi under win32 for Apache 2.2...

      As far as the thread-safe issue goes, [IMO] it has always been better to run Apache under a process-based MPM, as it's:
      1) more secure, isolating
      2) more stable

      The common misconception of the performance penalty arises more from the lack of any further MPM configuration to the specific task and system.

    6. Re:Examples of PHP inconsistency and performance by Just+Some+Guy · · Score: 1

      Shot down?

      Yep. They were removed from 5.0.0 beta 2 for various reasons.

      --
      Dewey, what part of this looks like authorities should be involved?
  12. lipstick on a pig... by Anonymous Coward · · Score: 0

    I'll probably be modded down as a troll but I would never ever consider PHP due to all the security holes found in this product. PHP is to average programmers what Windows is to average user: a security nightmare. There are so many PHP exploits out there and botnets of compromised PHP running systems it's not even funny anymore.

    When you've got a problem, PHP isn't the answer. PHP is the question... And the answer is "no".

    1. Re:lipstick on a pig... by Anonymous Coward · · Score: 1, Insightful

      you -are- a troll. I can write C programs just as insecurely as I can in PHP. If you are careful and have goood programming practices, you won't be affected by many of the 'holes'. The only problem is, the bar for entry is pretty low for PHP and there are lots of people who just learned 10 a=a+1 : 20 print a : 30 goto 10 and php is their next big adventure.

      If people like you were right, we'd all have ditched perl long ago because of the phf bug.

      PHP, like any software has its holes, but a properly secured system isn't much more likely to be compromised than an IIS server.

  13. yeah yeah yeah by Nappy+Headed+Ho · · Score: 1, Redundant

    yeah, PHP is sloppy, insecure by nature, and full of bugs - but there's a lot to be said for good programming practices as well, which when used can remedy many of these flaws. it's unfortunate that PHP is so easy to learn, as it has attracted hordes of people who couldn't or wouldn't learn another programming language, and of course, failed to learn (or have no desire to learn, hey it works just fine) anything about security, program efficiency, or how someone could take advantage of their sloppy coding. companies need web apps to be done yesterday, and they'll hire just about anyone based on a resume half the time, or find someone on one of those god awful freelancer sites. a lot of the time, "anyone" turns out to be some jackass who discovered PHP a few months ago, figured out how to connect to a database, and suddenly decided they were a programmer.

    that said, PHP is useful and a good performer when the right hands and brain are doing the work. i would be reluctant to hire anyone who learned PHP as a first language and hasn't moved on to something else by now, regardless of their experience level. nearly any language used for developing web apps can be dangerous in the wrong hands, it's usually PHP these days because those people can't manage to learn another language (unless it's coldfusion, and that's a completely different disaster).

    where i work, we use PHP. it's just everywhere; things are so easy to write that a lot of things have been written, and now someone has to either a) rewrite it all in another language, or b) just maintain and try to improve the existing codebase. guess what - "b" is the choice right now, and that's the way it is. i'll bet this is the case in a lot of places. i spend time trying to convince my superiors of PHP's shortcomings and the sensibilty of retiring some of this old junk in favor of something more robust and secure (like python), and they listen to me, but don't think that now is the time. i like where i work, and they do listen to me, so when it's time, i'll be there to do the work, the right way. if i wanted to leave, i'd definitely go somewhere where PHP wasn't used.

    and don't say PHP isn't getting any better. 5 is much better than 4, at least for OOP, and from what i can tell 6 will be even better, getting rid of register_globals altogether will be a dream come true for me (even if it breaks tons of code - not mine though, that's for sure), possibly namespaces finally, and E_STRICT errors will be the norm.

    1. Re:yeah yeah yeah by CopaceticOpus · · Score: 2, Insightful

      PHP is getting better. They are cleaning up security issues, and providing more and more of a solid core of capabilities. I just wish that the users were more excited about these developments. I can't understand why so many continue to develop in PHP4. Every change and step forward gets a mixed response.

      Personally, I'm all for breaking conventions if it will result in making PHP a better language. I wish that they would bite the bullet and rename all the functions to follow a consistent style in PHP6. Those who can't handle it can stick with 4 or 5, but let's look to the future and make PHP the best it can be.

    2. Re:yeah yeah yeah by Anonymous Coward · · Score: 0

      5 is much better than 4, at least for OOP

      Nobody cares about OOP anymore. It does not work well for business applications and e-commerce. The "business gap" in OOP has not been solved.

    3. Re:yeah yeah yeah by Octopus · · Score: 1

      I would LOVE to switch to PHP 5. But the truth is, I work for a variety of small companies that all want the cheapest hosting option I can find, and I can't always rely on PHP 5 being available, so most everything I build is in PHP 4. I'd much rather use some real OOP, but PHP 4's class framework works just fine for most of the projects I'm on.

      It has been discussed before that many of the larger hosts (GoDaddy, et al) run simple RedHat installations with specific packages of Apache, PHP and MySQL that they've tested for stability, and they're very hesitant to upgrade. Of course, with any kind of virtual/dedicated server package I could jump in with my own upgrades, but I'm not a Linux wiz and it makes for smoother launches if I don't have to upgrade everything. Maybe that could be viewed as laziness on my part, but the truth is there's no need to make a project more complex than it has to be, especially when dealing with smaller companies on a hard budget. It also keeps your dev environment config simpler if you're not dealing in both 4 and 5.

    4. Re:yeah yeah yeah by CopaceticOpus · · Score: 1

      I've used PHP 5 on both 1&1 and on Dreamhost. I don't know how you can get much cheaper than that.

      I can understand that it's not practical to upgrade existing code just for the sake of upgrading. But for new projects, I think maybe you're holding yourself back.

  14. Re:seriously ... by VGPowerlord · · Score: 2, Insightful

    PHP is just some hyped, misdesigned, inconsistent, unproductive kinda tool.

    Unfortunately, mod_php is still more programmer and administrator friendly than mod_perl, which probably explains why it has a higher usage rate.
    --
    GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
  15. Try Fastcgi by TheLink · · Score: 1

    If you don't need total control over how Apache behaves, use mod_fastcgi not mod_perl. For fastcgi typically the webserver forks off the webapp as a separate _persistent_ process and then they talk to each other via a socket (you could actually have the webapp on a separate machine, but I haven't had much need to do that yet). Fastcgi apps can be coded similar to CGI/mod_perl apps there's just a loop around the "Fastcgi accept" call.

    With fastcgi you can use perl, python, ruby, C++ or whatever - just like you can use these with CGI.

    It may be _slightly_ slower - two processes talking to each other rather than one big process, but it is faster than CGI. And it's more robust and clean than mod_perl.

    Also, if apache ever gets too slow, you can switch to Zeus, and you can still use fastcgi there. No change to your code.

    --
    1. Re:Try Fastcgi by VGPowerlord · · Score: 1

      I've tried using Perl with FastCGI before. It bugged me that you have to manually loop the accept call. It means that you have to wrap any code written for plain CGI... something that mod_perl's Apache::Request does for you.

      --
      GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
    2. Re:Try Fastcgi by TheLink · · Score: 1

      Didn't bug me that much, coz I usually wanted to do some useful stuff before the loop, like make persistent database connections, initialize caches, set up logging to syslog, set up other stuff.

      The mod_perl stuff tries to do the persistent DB stuff but in a kludgy untidy way that has a lot more gotchas. Same for PHP's mysql_pconnect. Go see people say "turn off persistent DB connections" in one answer and then "turn on persistent DB connections" in another answer ;).

      I've tried mod_perl, FastCGI is cleaner, less buggy and less bug prone.

      On Linux and *BSD you can even have the main fastcgi process fork multiple children and have the children make the persistent connections etc, then all accept on the same fastcgi socket - it still works. Used to be get more shared mem this way than if Apache forked each one separately, but maybe nowadays you don't gain anything from that?

      --
  16. from a ror perspective by winescout · · Score: 0

    You mean people still write websites in PHP? Gesh, my Ruby pals are going to get a kick out of that

  17. slownewsday by Anonymous Coward · · Score: 0

    It has been a while since I've seen a article on a PHP release.. I ask.. why?

    Personally I don't mind tech news of the such, but only if it is on kerneltrap or osnews. Heck, I perfer they keep them to those sites since I don't even use PHP anymore. Converted to Webware for Python a long time ago.

  18. Comparing mono with C# is unfair by anss123 · · Score: 2, Interesting

    Mono is a byte compiled language, not interpreted. Even so, PHP is still beaten quite badly by Perl. (In those benchmarks)

  19. Missing file from 5.2.2 for Win32: php_xmlrpc.dll by jgbustos · · Score: 1

    I tested it last night on a Win2003 Server box, and there is a missing file from the Win32 ZIP distribution: php_xmlrpc.dll.

    http://bugs.php.net/bug.php?id=41292

    The file can be obtained from the latest snapshot, though: http://snaps.php.net/

  20. Updating by MrMunkey · · Score: 1

    Here's another issue I have with updating to the latest version of PHP. I'd venture to say that quite a few companies out there use RedHat, SuSE, or some other OS/distribution because they get support. If we upgrade to the newest version of PHP, we lose vendor support for it. That's not to say that I can't compile it, it's just that the company isn't willing to risk losing support.

  21. better by CiderJack · · Score: 1

    Despite all the criticism I'm reading here, it still beats .aspx for database implementation, HANDS DOWN.