Mashed Articles

Despite being an open-source stalwart, I’m ashamed to admit that I’ve always had something of a love-hate relationship with Apple. In the ’80s, I owned – and still do own – an original Apple IIe along with a real hard drive and two 5.25in floppy drives. It was inherited from the video shop that I worked in, and I put it and its immense customer database to all kinds of nefarious uses. But eventually I moved on to the upland pastures of colour displays, 880kB of storage on a 3.5in disk and four-channel sound. All thanks to Commodore.

In the ’90s, Apple’s expensive and closed hardware meant that an upgrade was never on the cards. This was now the world of Windows, of cheap hardware and modular upgrades. It was the time when Microsoft solidified its dominance, and the time that many of us were looking for a more open alternative. Developing applications on Windows was expensive, especially if you wanted to share the source code. That left us with only one option: Linux. And I’ve never looked back.

But I’ve continued to follow, and occasionally invest in, the progress of Apple, especially in recent years. The move to Intel and a BSD-based operating system has made OS X eminently more hackable, and Linux-
based open-source applications are far easier to build and port to OS X than they are to Windows. This has helped make the venerable MacBook Pro one of the most common laptops in use at open-source and Linux conventions, despite Apple’s obsessive control of the hardware. Apple, for many, has become an acceptable compromise for those who believe in free software but still want a machine that can resume from hibernation without the need to build a custom kernel.

But it’s the iPhone, and now the iPad, that has built a brick wall of division between what most of us are willing to ignore, and what Apple hopes will become their ultimate cash cow. Both are the result of a singular, draconian vision, the antithesis of what the open-source community represents. This isn’t a bad thing in itself, especially when the results leave a lot of free software products wanting. The interfaces of iPhone apps tend to be refined, simple and intuitive. The apps are consistent, responsive and cheap. Our parents could use an iPad without fear of viruses, malware and updates. For almost all the same reasons I’ve been telling them to switch to Linux, they can now switch to Apple for about the same cost.

But doing so is a pact with the devil, because you’re forgoing technical complexity in exchange for loss of freedom. This is the reason for Richard Stallman’s GNU manifesto. And while there’s little doubt that Apple’s enforced gateway to new applications has helped to make it a success, it’s this subtle trade of simplicity for complicity that is perhaps the biggest threat to free software in 10 years.

My fears were proven when Apple recently changed clauses 3.3.1 and 3.3.2 in its developer’s agreement, stopping programmers linking to third-party APIs. Its motivation may have been to halt apps using Adobe’s new Flash-based building tools, but it could also stop applications using open source-based frameworks such as MonoTouch and SDL. Apple refuses to clarify what will and will not be allowed through its vetting procedure. Presumably Electronic Arts games will still be allowed to use the LUA scripting engine, for example, while many independent developers aren’t going to know whether their approach is acceptable until they submit their app for review.

This type of business plan shows the very worst of what closed-source development has to offer, and exactly what open-source software blossomed to combat. But we can’t fight it with rhetoric and positive spin while our hardware and applications aren’t as good as those from closed systems. Public development and public scrutiny should lead to a better, more usable and more stable product. It worked for Linux servers and desktops, but it hasn’t worked for mobile devices yet. This is the challenge for free software developers.

It’s going to be tough, but this point in time probably marks the biggest opportunity for free software to prove its worth. It’s going to be a simple battle between closed, proprietary development on a single platform, and open innovation on open hardware. Open-source developers need to rise to the challenge or face a future that will be closed to collaboration, community and conscience.

While enjoying holidays, I read the book “Programming Amazon Web Services” by James Murty. As explained in my earlier post, I was most interested to learn how cloud computing could be leveraged for developing integration solutions.

The book discusses 5 Amazon Web Services (AWS):

• Simple Storage Service (S3)
• Elastic Cloud Computing (EC2), virtual Linux servers on demand
• Simple Queue Service (SQS), to deliver short messages
• Flexible Payment Service
• SimpleDB – simple database with no SQL support

The book goes into quite some technical detail and has code snippets showing in detail how to interact with the Amazon services. All the samples are written in Ruby. I don’t know Ruby, but the code is quite readable (should read Enterprise Integration with Ruby some day). The author prefers the REST and the Query API. Unfortunately, he does not show anywhere the use of the SOAP API to access Amazon WS.

The 1st chapter is introductory and e.g. explains how to use self-signed certificates to connect with AWS, explains how AWS were developed for internal use by Amazon and later turned into a products, come without an SLA (except for S3) and without real support.

In the 2nd chapter, the author builds up a library of Ruby code to access the Amazon Web Services. This is very well written and gives an immediate feeling for some aspects to take into account, e.g. clock differences.

S3 is covered in chapters 3 and 4. No standard file access but the use of buckets and objects through a non-standard API (REST or SOAP); no FTP, WebDAV or SFTP. And objects cannot be modified: only deleted and re-created (after the deletion has propagated). Ruby code is shown for all the options the API offers: bucket creation/lookup/deletion, object creation/listing/deletion, ACL update/retrieval and access logging file retrieval. Tricks with HTTP header fields (object metadata), posting data through forms, alternative hostnames and BitTorrent are discussed. The last part discusses signed URI’s: this is a neat trick to make S3 resources temporarily accessible to users without Amazon account.

Chapter 4 shows some applications of the S3 service: large file transfer, backup, turning S3 into a file system (with FTP or WebDAV). Interesting to note that the author has his doubts wrt. exposing S3 as a file system. The author also discusses his own Java open source application: JetS3t. This application is a “gatekeeper” for S3 resources and authorizes local agent applications after acquiring signed URL to upload files to S3 and download files from S3.

Chapter 5, 6 and 7 dive into EC2 and how virtual Linux systems (based on Xen) can be configured using Amazon Machine Images. Ruby code is shown for every available API: keypairs (for SSH access), network security (dynamically configure the firewall), images and instances. Chapter 6 explains instances in more detail and discusses how to create new images. This involves quite some commands and scripts at the Linux command prompt. Chapter 7 discusses some sample applications: VPN server, web photo album thereby backing up data on S3. Chapter 7 also discusses issues around dynamically assigned IP addresses and the use of dynamic DNS.

The Simple Queue Service (SQS) is discussed in chapters 8 and 9. Because of the small message size, SQS is clearly meant for events with actual data stored on S3 (or elsewhere). Again Ruby code to manipulate queues and messages. Chapter 9 describes a Messaging Simulator application, not that relevant in my opinion. The 2nd application – leveraging a video conversion tool – shows how to build generic service for implementing “batch” services (Command Message pattern). The 3rd application – LifeGuard – leverages SQS to manage EC2 instance pools and dynamically scale the number of EC2 instances.

The chapter on payment service I skipped and I only skimmed through the SimpleDB chapter. Enough to learn that SimpleDB is not an RDBMS but a basic storage mechanism (no data types) with proprietary query facilities (no SQL).

The author writes fluently and gives a non-biased view on the Amazon Web Services. Sometimes the code goes into too much detail, showing how to invoke every available method of the API. Although the book is very recent (March 2008), important new features such as elastic IP addresses, persistent storage for EC2 and availability zones weren’t yet available at the time of writing. The book definitely taught me that AWS is quite proprietary and not that trivial. And to use Amazon’s cloud computing and AWS, you’d better “think like Amazon”.