Artur Bergman

In an editorial for Forbes, Tim called for the the opening of the Kindle, else it will slowly turn obsolete. Since I love my Kindle, I am happy that my friend, Jesse Vincent, a long time open source contributor and OSCON speaker is trying to open the Kindle, you might remember him as the guy who discovered Amazon's USB-network easter-egg in the Kindle 2 last month.

He is developing Savory, the first native Kindle application. Savory is an open source epub and PDF converter that actually runs natively on the Kindle. While it doesn't add anything that you couldn't do from a desktop, it streamlines the process allowing you copy epubs and PDFs to your Kindle over USB or download them from the web, and immediately read them offline. (O'Reilly provides bookworm which converts DRM free epubs to HTML and lets you read them through the Kindle's web browser, as well as DRM-free .mobi formatted versions of much of O'Reilly's catalog at O'Reilly Ebook Bundles.) Jesse on why he created Savory:

I'm in love with my Kindle. I've been reading ebooks on screens of various sorts for many years, but the Kindle2 is the first device that I actually enjoy reading as much as I enjoy reading paper books. I've tried other ebook readers, but for a variety of reasons, they just don't work for me. My goal is to make it easier for readers to read more free content on the Kindle.

Based on the open source project Calibre -- a python application that lets you convert between multiple ebook formats. The implementation is a background daemon that uses inotify to immediately convert the file to to the mobi format. To get a performance boost, it uses unladen-swallow -- Google's optimized version of Python. I find it exciting that this paves the way for 3rd party applications on the Kindle.

While I wish that Amazon would follow Apples path and make the Kindle DRM free, it is worthwhile to note Savory itself does not deal with DRM at all.
Jesse says:

No. Savory does not include support for ebooks protected by DRM. DRM is an incredibly "hot" topic in the ebook world right now. There are varying opinions on its efficacy. My opinions on the matter aren't relevant, except to say that I am not touching the topic with a 10 foot pole. It will not convert DRM-protected ebooks into a format the Kindle will read. It will not add or remove DRM from any ebook.

Personally, I've been using Calibre to create and convert a daily operations report for all of Wikia -- and I look forward to be able to download the report from the web and just read it.

More information can be found on Jesse's blog, with the code available at savory.googlecode.com.

I am pleased to finally have found a paper that manages to bring together the different aspects of cloud computing in a coherent fashion, and suggests the requirements for it to develop further.

Written by the Berkeley RAD Lab (UC Berkeley Reliable Adaptive Distributed Systems Laboratory) the paper succinctly brings together Software as a Service with Utility Computing to come up with a workable definition of Cloud Computing and is a recommended read.

The services themselves have long been referred to as Software as a Service (SaaS). The datacenter hardware and software is what we will call a Cloud. When a Cloud is made available in a pay-as-you-go manner to the general public, we call it a Public Cloud; the service being sold is Utility Computing. We use the term Private Cloud to refer to internal datacenters of a business or other organization, not made available to the general public. Thus, Cloud Computing is the sum of SaaS and Utility Computing, but does not include Private Clouds.

Exploring the difference between the raw service of Amazon EC2 to the high level web centered Google App Engine, the highlights are:

• Insight into the pay-as-you go aspect with no commits
• Analysis of cost with regards to peak and elasticity in face of unknown demand
• Cost of data transfers versus processing time
• Seamless migration of user to cloud processing
• Limits and problems with I/O on shared hardware

• Availability of Service
• Data Lock-In
• Data Confidentiality and Auditability
• Data Transfer Bottlenecks
• Performance Unpredictability
• Scalable Storage
• Bugs in Large-Scale Distributed Systems
• Scaling Quickly
• Reputation Fate Sharing
• Software Licensing

I particularly find interesting the analysis of transportation cost versus computing cost; when is it more efficient to to use EC2 than your own individual processing? I predict speed of light and available of raw transfer capacity is going to become a even larger obstacle. (Both inside computers, between them on local LANs and on WANs.)

The paper reinforces my belief in the cloud, but that we need open source cloud environments and a larger ecosystem of providers.

Read more on the Above the Clouds blog.

Adhearsion is written in Ruby and lets those even without any VoIP experience write applications intuitively and productively or simply download and use a pre-written solution. With the framework extension architecture, VoIP functionality can now be actually traded around - an issue the VoIP industry has always suffered from.

A fresh, standard Adhearsion system out of the box does what many companies spend thousands on. It includes a wide - and growing - set of features that should not have to be rewritten for every business that wants to implement them. And yes, this is open-source.

Considering Microsoft spent around $800M on Tellme, I look forward to see what kind of applications this leads to, and what value they generate. We often forget the enormous market for telephone based services.

I am a Perl hacker. I have written parts of the core, created CPAN modules and written tons of perl code. In fact I am addicted to it ; or rather, CPAN. I have been wanting to play around with Google App Engine, but I haven't had time to get up to speed in Python. Today at OSCON I met up with Brad Fitzpatrick, who told me he had permission from Google to talk about and work on a Perl on App Engine project.

He makes it clear that,

I'm happy to announce that the Google App Engine team has given me permission to talk about a 20% project inside Google to to add Perl support to App Engine.  To be clear:  I'm not a member of the App Engine team and the App Engine team is not promising to add Perl support.  They're just saying that I (along with other Perl hackers here at Google) are now allowed to work on this 20% project of ours out in the open where other Perl hackers can help us out, should you be so inclined.

The plan is to harden Perl (one layer of defense in App Engine's hardened environment); implement Protocol Buffers and stubs of the backend services, so people can write App Engine applications on their local servers.

There is more information at Brad's LiveJournal, as well as the the Perl-AppEngine project. Capturing the creative spirit here at OSCON, Brad and I hacked together a new module that emulates a protected environment, Sys::Protect (generally good idea for any web application).