Blog - tech

As I wrote quite a while back, there seems to be a convergence on open-source technologies that will enable all the old-school thick-client desktop applications and their nice interfaces, and much more for new applications. Now Apple has demonstrated a use and commitment to a JavaScript framework known as SproutCore which further pushes the state of the art in that direction.

Do you have a Mac still running Tiger (Mac OS 10.4)? And did you recently decide to install a PEAR component for use with some PHP? And lastly, did it fail with some cryptic HTTP error "410 Gone" that you had very little luck finding with Google? I did.

The solution is a bunch of steps backward and then forward again. Unfortunately, it's not very clear to the perhaps large number of Mac users who did not keep their PEAR libraries up to date all along on Tiger. But the answer is here, at the moment (it will scroll off when more news is added): http://pear.php.net/

I run a couple of Drupal sites on 1and1 for historical reasons (3 years free). A while ago, I dutifully upgraded them to Drupal 5.7. And was surprised to find that PHP's register_globals was enabled.

All this time, I've been running with a .htaccess file which explicitly disabled that setting -- if 1and1's Apache was running mod_php only, it turns out. Apparently, such PHP settings in .htaccess files don't do anything if running PHP in CGI mode.

Here we are, 2 years after the first Intel Macs went on sale, and 3 years after Steve Jobs announced that Apple would transition to Intel CPU chips. Wouldn't one think that all major makers of Mac software would have long since ported their software to work on Intel Macs?

I too have now run into the infamous Time Machine bug. Little did I know. I upgraded my 3 Macs to Leopard back around December 1. On my primary Mac Mini desktiop, I pointed Time Machine at my external 250Gb drive, which also had some large video files on it, but which was mostly otherwise empty.

I was profiling one of my favorite large PHP applications today using APD. I kept getting what seemed to be strange results -- it was telling me that bunch of defines statements (30+ of them) were responsible for an inordinately large percentage of the page generation time. On minimal pages it was as much as 37%. Even on the well-known largest of pages, they were still clocking in at a not insignificant 5%.

That just didn't seem possible.

So I just did several Mac OS X 10.5 Leopard installs, upgrading from Tiger (10.4) and even one machine from Panther (10.3). Although for the most part they went well (though very slowly),I have a few complaints. Some things are stupidly difficult, because Apple's obtuseness, combined with the plain complexity of the system (required, I suppose, to get the functionality), but mostly just because of the lack of documentation. So here are some:

After posting Why I don't like WebDAV, part 1 I got involved in a bit of email discussion with some people who are much more expert than I regarding the protocol (Kevin, Mike, Julian, Tim). I appreciate they included me, and I now know a lot more about WebDAV than I did before.

The protocol itself doesn't really suck. Rather, it's the implementations and the purposes for which it has been used, it seems. It's a bit odd in that it's a lower-level protocol for a high-level purpose. Use it for the wrong purpose, and it's like using the wrong tool.

Yesterday and today I spent a lot of time using WebDAV updating one web site, and creating another, both at hosts which use that protocol for accessing file directories on hosted sites. It has taken longer than it should have, possibly caused my Mac OS X 10.4.10 desktop to crash, and ultimately forced me to use both the shell and FTP to get permissions set right and the right files in the right places. It shouldn't be this hard. Part of the blame may lay with Mac OS's native implementation of WebDAV, but I've not seen any implementation that is better on the whole.

James Bennett nailed it on the head late last year with his post about I can’t believe it’s not XML! Not that XML is terrible in my view, but it is mostly overly wordy for most of the simple cases where it is used. And the big XML-as-a-protocol-stack, like the SOAP and WS* web services people -- and probably even the SOA hawkers -- are to web services as XML is to JSON.

As James put it: