10
Jul 07

RIP PHP4?

I suppose my earlier comment wasn’t exactly expansive, so I may as well elaborate. I’m not reporting any news by saying that the uptake of PHP5 hasn’t been explosive – over the past year, most of the big names in PHP-land have been commenting on it on mailing lists and elsewhere. The figures weren’t leaving much wiggle room either – 80/20 splits in favour of PHP4 were approximately what we were seeing.

Thing is, while backwards compatibility is a good thing in general, in specific cases like this one – well, it’s not that it’s not a good thing, it’s that it’s not really applicable. PHP4 and PHP5 are enormously different beasties and treating one as a slightly enhanced version of the other isn’t really valid.

Hence, goPHP5.org, the new movement amongst the dev community to push for PHP4 to be dropped from applications and for 5.2 to be made a requirement. Lots of big names have signed onto this effort, including PHPUnit, Drupal, Solar, Symphony, Propel, phpMyAdmin, Typo3 and others. No shocker that Solar and Symphony would sign up I suppose – both being php5 frameworks from the get-go. However, the list continues to grow and with apps like Moodle leaning heavily towards signing up, this does look like it could run.

On the other side, however, the php internals developers are also pushing for a dropping of PHP4 – but this time from the language end, with no further support (other than serious security fixes) being provided and efforts being redirected to PHP5.2 and the upcoming PHP6.

Frankly, the sooner this happens, the better. 4 was always a half-finished idea, an OO language with half-implemented OO constructs. It served well when there was nothing else in place, but right now no developer in his right mind (and with a free choice in the matter) would use PHP4.


10
Jul 07

X.org 7.2 memory leak

Sigh…

One of the things I really like about the Ubuntu family of distributions is that you get a good solid chunk of the stability you see in stock Debian Stable installations, but with the release cycle being so much faster, you get more up to date apps. Which is fine for a desktop to be honest. Let’s face it, for a server you want Debian (hell, for a *really* critical server you probably want OpenBSD); but for a desktop you just need it to run for ten to twelve hours between restarting X, and if you get a month’s uptime before a reboot, that’s perfectly acceptable (more time for either, is of course better, but those times are what you need, not what you want). And Ubuntu can do that and give you the cool bells and whistles to silence the iBook-and-Vista-wielding critics (Leopard, you say? Multiple desktops, eh? Vista, you say? Cool spinning desktop changing you say? Hmmm. Have you seen Beryl yet? Old project I know, been doing this for a few years now, but … 😀 )

Unfortunately, sometimes the great idea doesn’t work. Right now I’m looking at X.org 7.2 (without Beryl, which doesn’t like my three screen xinerama setup yet 🙁 ), and it’s using up 342Mb of RAM.

I mean, that’s just daft.

Granted, three 24-bit colour, 1280×1024 screens. Fine. But that’s only about 90Mb in total – and when X.org starts up, sure enough, that’s what it takes up (well, slightly over that). And granted, X.org does swipe memory that’s not in use for caching to speed things up (which is a good thing). But it’s not giving this memory back, and after a few days (or a really heavy Firefox session with forty-odd tabs open), I can be looking at over 700Mb of my 1Gb being used, and the machine is swapping just to open an rxvt shell.

It also seems like I’m not alone in this. And since there have been memory leaks in earlier versions of X.org, I’m looking forward to finally updating to Gusty to get away from this.

(ps. it’d be really nice if Gusty’s version of Beryl supported the whole three-screen xinerama setup too…)