After four decades, the future of the operating system is clouded, but its legacy will endure.

Regardless of the ultimate fate of Unix, the operating system born at Bell Labs 40 years ago has established a legacy likely to endure for decades more. It can claim parentage of a long list of popular software, including the Unix offerings of IBM, HP and Sun, Apple’s Mac OS X and Linux. It has also influenced systems with few direct roots in Unix, such as Microsoft’s Windows NT and the IBM and Microsoft versions of DOS.

The [Association for Computing Machinery] may have said it best in its 1983 Turing award citation in honor of Thompson and Ritchie’s Unix work: “The genius of the Unix system is its framework, which enables programmers to stand on the work of others.”

I’ve just started experimenting with LESS for a new web development project. With my programmer head on, LESS looks like it has the potential to speed up my CSS coding (which I do by hand) as well as enabling me to abstract my CSS with variables (very handy), nested rules, mixins and even mathematical operations (yeah baby)!

However, installing LESS on my OS X “Leopard” machine wasn’t quite as simple as advertised. I should just be able to go:

sudo gem install less


But that resulted in an error:

ERROR: While executing gem ... (Gem::RemoteSourceException)
HTTP Response 403 fetching http://gems.rubyforge.org/yaml


I ended up scratching my head for a moment — before turning to my good friend and problem-solving guru, Google, for help. I was advised as follows:

wget http://rubyforge.org/frs/download.php/45905/rubygems-1.3.1.tgz
tar xzf rubygems-1.3.1.tgz
cd rubygems-1.3.1
sudo ruby setup.rb
sudo gem update --system
sudo gem install less


That worked a treat.

Then, in Terminal, I navigated to my source directory, renamed my style.css file to style.less and issued the following command:

lessc style.less --watch


LESS then generated a new style.css from my .less file and went into watching mode — automatically compiling my .less file into its .css counterpart whenever it detected changes in my source (ie: when I hit save in my text editor) which is a rather cool.

It’s early days yet, but so far LESS is looking like a tool that I can really make use of. I don’t need to change my workflow (aside from starting the watch/compiler process) and I get a degree of CSS flexibility and freedom that I didn’t have before. That’s neat.

A long time ago, in a galaxy far, far away… oh sorry, wrong script. I’ll start over. In the dim and distant past, I wrote about my efforts to eke a little bit more performance out of the WordPress installation that this glorious website runs upon. What I’d done was fairly basic: content compression, reduced page weights, database tuning… the usual stuff.

I also described how I’d failed to get WP Super Cache working and wrote that I was investigating PHP accelerators. Yet, despite my endeavours, the website’s performance continued to be, well, pitiful. Some time later I managed to get WP Super Cache working and things improved, but were still disappointing to me.

I come from a mod_perl background and one of mod_perl’s strengths is the speed at which it can run its applications. The PHP app’s that I now find myself working with just can’t compete. I believed that I’d just have to accept that the performance goals I was aiming for weren’t achievable.

However, I was recently forced to reconsider my position when I was contracted to build a website on top of the Zend Framework — because, despite being written entirely in PHP, nursesstore.co.uk turned out to be very fast.

Suddenly, I knew that it was possible to build fast PHP applications. So I turned my attention, once again, to the speed-deficient Urban Mainframe with the fire of the true zealot burning in my eyes.

Continue Reading…

For some time now I’ve been wanting to install the Alternative PHP Cache (APC) on the Media Temple GS server upon which this website is hosted. Tantalised by the performance improvements that I’ve read about, APC became my Holy Grail. But I couldn’t get it to install on the GS server, until now.

I’ve documented the steps I used to get APC running here, in case they’re useful to anyone else.

1. Telnet or SSH onto your GS server
2. mkdir /home/#####/data/lib (where “#####” is your Media Temple account number)
3. mkdir /home/#####/data/lib/php
4. wget http://pecl.php.net/get/APC-3.0.19.tgz (at the time of writing, this is the latest stable version - adjust as necessary)
5. tar zxvf APC-3.0.19.tgz (again, adjust as necessary)
6. cd APC-3.0.19
7. phpize5
8. ./configure --enable-apc --enable-apc-mmap --with-apxs2=/usr/sbin/apxs --with-php-config=/usr/local/php-5.2.6-1/bin/php-config
9. make clean
10. make && cp modules/*.so /home/#####/data/lib/php
11. Finally, add the following code to your php.ini file:
    extension_dir = /home/#####/data/lib/php/
extension = apc.so

That’s it. APC should now be installed and you should be able to measure a significant improvement in your PHP script performance.

Via Simon Willison:

An impressive combination. CouchDB can be easily set up in a multi-master configuration, where writes to one master are replicated to the other and vice versa. This makes setting up a reliable CouchDB cluster is as simple as putting two such servers behind a single nginx proxy.

Using Graphics Card Memory as Swap. Interesting idea: “Graphic cards contain a lot of very fast RAM, typically between 64 and 512 MB. With Linux, it’s possible to use it as swap space, or even as RAM disk.” [via]

Mark Nottingham tells us about Traffic Server: [via]

A long time ago, the word in high-performance proxy-caching was Inktomi’s Traffic Server. It was so fast it was referred to as being “carrier grade” and this could be said without people smirking, and it was deployed by the likes of AOL, when AOL was still how most people accessed the Internet.

A few years ago, some Yahoo! engineers found that code sitting on a shelf and decided to have a play. What they found was that it was still faster than pretty much every thing else out there. So they started using it, and built a team around it.

Fast forward to today, when the source code for Traffic Server is suddenly available as an Apache Incubator Project.

Now this is a handy little hack. Over on the Mac OS X Hints site, robg has posted a script that will record the CPU usage of a specified process, with a configurable frequency over a configurable period of time. The script dumps the resulting data into a text file for further analysis/graphing.

I really like this. Very handy for debugging and keeping an eye on rogue processes. This script has a much smaller footprint than the Instruments program from the Xcode Developer Tools.

Now this looks interesting. Recess is a PHP development framework based on the Model-View-Controller principle.

Apple made the source code of Grand Central Dispatch available under an Apache open source license. One of the new technologies for concurrency added to Mac OS X 10.6 Snow Leopard, Grand Central is Apple’s attempt to help developers deal with the rise of multi-core. The open sourcing of Grand Central comes as something of a surprise, because it is a core technology in Snow Leopard, and could be seen to give Apple a competitive edge in the new world of multi-core… this is an exciting move, particularly for scientific developers. If Grand Central Dispatch does catch on, it could provide a genuine option for code parallelization on and off the Mac.