On iCloud Thursday, Jun 9 2011 

Now playing: ♫ Set Me on Fire — Pendulum

I was recently emailed an article from the Telegraph about the forthcoming cloud services from Apple, iCloud.  The subject read “Is it safe?” and the portion of the article I’m going to respond to is quoted here for convenience.

With iCloud, Apple has cut the cord. It’s not a company that sells computers, or even mobile phones. It’s a company that wants to be so helpful for every single aspect of your personal life, your work, your entertainment, and your memories, that whatever it sells, it’s simply indispensable.

They make iCloud, and the related enhancements in iOS 5, sound almost altruistic with this paragraph.  It isn’t.

What it is, however, is solving something that the Android/Google people have been whining about since day one: You basically need a Mac to own an iPhone.  Now, you don’t.

You can sync your media wirelessly with any computer, if you want.  You set a passcode in your iPhone/iPod/iPad (I’ll call them iDevice from here on out for simplicity).  When you’re within range to a computer with iTunes, you can tell iTunes to “Wirelessly sync to a device”.  It will then prompt you for the passcode, and if you enter it correctly, iTunes will upload all your music to iDevice.  This part is fairly safe.  You just have to trust the wireless hotspots you are connecting to.  You can temporarily disable wireless syncing, too, if you’re at a public place (say Starbucks).  The nice thing is, you can activate your iDevice and receive software updates without requiring a computer with iTunes installed.  This is good for people without PCs, good for people who don’t run Mac OS X, and good for people who have computers that break down frequently.  *Ahem*Mac mini*ahem*

Now.  iCloud is taking that to the next level.  Your music is stored on Apple’s servers.  Your data is stored on Apple’s servers.  Your notes, your preferences, your apps, your iBooks, your digital magazines…stored on Apple’s servers.  Of course they have 256-bit SSL (like HTTPS).  And they claim it to be very secure and robust.  But as the article you sent points out, Sony just lost the trust of about 80 million people when crackers broke in and quite easily retrieved personal information — including passwords — about every last person that was signed up to their cloud gaming service.

I’m not saying the cloud is a bad idea per se.  But when you think about the Sony incident, or the Amazon Web Services incident a few months ago — that took popular sites like Reddit and Foursquare completely down, and left thousands of business up a creek — well, you start to realise that the cloud isn’t all it’s touted.

Now, Apple has other cloud services, and they have millions of users and they’ve never been cracked or broken in to.  If that is your definition of “Safe”, then yes, by all means.  You can only secure a computer network so much, and Apple seems to be at least half decent at that.  (See the built-in firewall in Mac OS X.  And it’s getting a lot more powerful in Lion.)

But if you want to define “Safe” as “Will I be able to access this data all the time for the next 10 years”…I’m not so sure.


On running Mac OS X with VirtualBox Sunday, May 2 2010 

I’ve been testing VirtualBox 3.2.0-beta1 out on my Mac mini.  The capabilities of this new beta are quite helpful for system developers and coders in addition to users.  Some of my favourite features include:

  • Real, working APIC 1.4 support.
  • Better SMP support.
  • EFI works much better, but still has really odd bugs.
  • More guests support 2D accel.

Snowflake works well and Windows 7 works better.

But my most favourite new feature, by far, is the ability to install and run Mac OS X.  Apparently both 10.5 and 10.6 work, but my 10.5 DVD is for Mac minis only, so I got 10.6 working.  On a real Mac, it takes nothing but time.  It took over 2 hours to install.  However, it does work, and it works quite well.  Most effects are smooth, even without a native framebuffer kext.  It did take a tiny hack though: I had to boot to the EFI shell and run:

mount fs0:
fs0:\System\Library\CoreServices\boot.efi rd=disk0

Then it Just Worked™. On a real Mac, you don’t need any additional kexts, or anything. It boots natively. Only thing that is missing is the Apple boot logo; it always boots in verbose, again due to no native framebuffer kext.

If you’re unlucky enough to have a genuine not-Apple computer and still want to run Mac OS X in VirtualBox, I highly recommend this helpful guide (which I have even commented on).  It has worked for a few people I know, and I hope to try it on my Core 2 box tomorrow (er, today, it just turned midnight).  I’ll certainly report how that works.  But for now, it’s back to kernel hacking for me.

On getting lighttpd + PHP working on OS X Tuesday, Mar 2 2010 

Now playing: ♫ One More Time – Daft Punk

My first post of 2010!  I have been so busy that I just haven’t had any time to write anything in here.  But I have something special for you today; some build instructions for making an experimental dev server out of a Mac.

I use a Mac at work.  And being that I frequently have to test out our new Web stuff (some written in PHP but the majority written in Django), it’s helpful to have a working lighttpd install on it.  I’ve considered dual-booting with FreeBSD, but it seems a bit of a challenge to get all of the Apple hardware to work on FreeBSD (especially WiFi; we don’t even really use wired Ethernet at work anymore) so I’ve held that off for a while.  I could also use my desktop, but with the KVM on the fritz I just find it easier to sometimes run sites on OS X.

This isn’t a problem with Django, because it comes with a small development server that I can use.  But it is big problem with PHP; the Apache2 built in to Snow Leopard doesn’t seem to like me or PHP (or my configuration) and I prefer lighttpd anyway.  I could never find a really good guide to installing any of this online without resorting to MacPorts or Fink or even Aptitude.  I prefer to keep my system clean of the port systems (even though I’ve heard great things about MacPorts, it just seems ugh).   So, here’s how I got lighttpd and PHP to play nice on OS X with FastCGI:

Absolute prerequisites

  1. You must be absolutely comfortable with using Terminal and compiling things by hand.
  2. You must have already installed XCode, because we’re going to be using GCC and friends.

lighttpd installation

  1. Install PCRE.  This is the only lighttpd dependency that Mac OS X doesn’t ship developer libs with.
  2. I ran configure like this:
    ./configure --prefix=/usr/local --with-openssl --with-kerberos5 --with-ldap --with-zlib
    This allowed me to test SSL and Kerb5, which we use on one of our portals, and a few other miscellaneous things I feel will be useful.
  3. make and then sudo make install.
  4. Congratulations, you have an almost-working lighttpd!

PHP installation

For GD, you’ll need at least:

  1. libjpeg (Note: You’ll need to run sudo mkdir -p /usr/local/man/man1 for manpages.  If you don’t want them, you can ignore the error Make throws.)
  2. libpng (Don’t you love that they still distribute .TXZ’s?)

You can also snag FreeType and libxpm, but it isn’t necessary and building them is beyond the scope of this document.

Okay, so now we’re ready to build PHP. The configure line you supply to PHP is site-specific.  The one I used was:

./configure --prefix=/usr/local --with-openssl=/usr --with-kerberos --with-pcre-regex=/usr/local --without-sqlite --without-sqlite3 --disable-pdo --with-zlib --with-bz2 --enable-exif --with-gd --with-ldap --with-ldap-sasl --with-mcrypt --without-mysql --with-pgsql=/usr/local/pgsql

but I stress again: this is site-specific. You probably want MySQL and don’t want PostgreSQL (even though it takes a lot to squeeze even equal performance out of MySQL).  That said, the only oddity is that on OS X, PHP has a problem locating the OpenSSL lib for itself and I had to use –with-openssl=/usr to allow it to find where it was.

Also, a big disclaimer: GD is still broken with libpng>=1.3.  Since I use 1.4, I was forced to use the SVN version of 5.3.  Not even the new 5.2.13 release has the patch (even though this bug was reported in early January).

Now that we’ve gotten that out of the way, let’s get a server running!

Configuration files

The lighttpd configuration file is up to you.  Note that you have to use server.event-handler = "freebsd-kqueue" on OS X.  Mine is pretty standard, so I’m only going to paste the FastCGI configuration section here:

fastcgi.server = (
".php" => (
"php-osx" => (
"socket" => "/tmp/php5.sock",
"bin-path" => "/usr/local/bin/php-cgi",
"bin-environment" => (

Now, one of the most painful parts of this process was getting a LaunchDaemon configured for lighttpd properly.  Note that when under launchd, lighttpd is very sensitive to syntax; I spent about an hour trying to figure out why it wouldn’t start until I realised I had an extraneous space in the plist.  Here is my /Library/LaunchDaemons/net.lighttpd.plist file:

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN"
<plist version="1.0">

Now run launchctl as root and type load /Library/LaunchDaemons/net.lighttpd.plist.  If you’ve come this far and you don’t get any errors, congratulations!  Your Mac is now a lighttpd+PHP/FastCGI server!