iBooks, database layout and series, oh my

With iOS 8 and OS X 10.10 Yosemite, iBooks gained the ability to display series of books in nested folders. As a lover of books with a bit of OCD and severe data hoarding streak I was very excited about this. Finally my 20+ GB collection of books would be able to be organized a little nicer, after all, I had already painstakingly corrected all the metadata for my entire collection using Calibre and I knew that this included series metadata.

However upon first installing these wonderous new toys there appeared to be no way for the user to group existing books into series. Yet magically certain books were grouped in this manner, specifically books bought in the iBooks store.

This left me wondering, clearly the functionality was present but not exposed, meaning there was room to abuse... ergh coerce iBooks into letting me organize my collection with a bit of clever hacking. So I started searching around to see what work had already been done examining this and luckily AskDifferent (StackExchange for Apple questions) came to the rescue.

Essentially iBooks can be broken down to two SQLite database, one for your library and a secondary one for series information (why oh why?), a plist of containing all your book import data and of course the storage location[1].

As can be imagined each book has an id by which can be referenced. In the Series db this is known as ZADAMID in the ZBKSERIESCHECK table, and in the Library db this id is known as ZSTOREID in the ZBKLIBRARYASSET table. They are identical, and as can be guessed by the ZSTOREID name, these ids are derived from the iBooks store.

This means that books imported into iBooks do not have a ZSTOREID and therefore no ZADAMID. As ZADAMID is used for defining what books go into a series, if we want to abuse iBooks to have series for non-store books we have to create such an id manually and blindly insert it into the database. In the process hoping that any future purchases do not have ids which clash with any chosen id because then, surely, all hell breaks loose.

This is terrible, so very terrible. There is no way to safely hack iBooks so far as I can tell, within the current database design at least, which will allow users to organize their own books into series.

My hope for iOS 9 and OS X 10.11 is that this changes. iBooks is a nice application overall, for a collection of my size though the added organization provided by series is a great boon.

I'd also like to see iBooks back up my collection to iCloud to provide similar on demand local storage as is seen with items bought in the iBooks store where the books show up in the collection even if they are not available on the device. I imagine rightsholders would have a thing or two to say about such a scheme, but frankly I already paid for this content and much of it they have not made available in the iBooks store so if I was Apple I'd start the argument there. I personally already spent a great deal of time contacting publishers to ask why their ebooks were available on Amazon but not in iBooks, surprisingly they can't even bother answer customer email when I offer them my money (I assume my money is smelly or something). Failing this, it would be nice if one could define the storage location, with a collection as large as mine, my local harddrive is not exactly the place I want this data, after all Apple only sold me 500GB with this Mac Mini making my book collection a good 5% of the total storage. Being able to stuff that on my NAS would be nice, it's where iTunes library lives after all, it's time for books to rejoin the family.

Some performance improvements would be nice. Importing large collections into iBooks leaves the application beachballing for quite a number of hours with no indicator that work is being done. I imagine it blocks on io due to copying the files into the storage location, really I would expect Apple to provide a better experience, a progress bar e.g. would be a good start. Scroll performance also isn't exactly buttery smooth on such a large collection, perhaps because of the sheer amount of high resolution thumbnails but performance of the new Photos application which I see as facing a lot of the same basic issues leaves me hopeful that this is a problem Apple will be able to solve (it might require a rewrite of at least some aspects of iBooks, but that hasn't stopped Apple before and it's a fairly new app as things stand).

[1] The locations of these:

  • Main library db: ~/Library/Containers/com.apple.iBooksX/Data/Documents/BKLibrary/BKLibrary-(some number).sqlite
  • Series db: ~/Library/Containers/com.apple.iBooksX/Data/Documents/BKSeriesDatabase/BKSeries-(some number).sqlite
  • Book plist: ~/Library/Containers/com.apple.BKAgentService/Data/Documents/iBooks/Books/Books.plist
  • Storage location: ~/Library/Containers/com.apple.BKAgentService/Data/Documents/iBooks/Books

Mega review

Mega is a phenomenal service to store your files online which gives you pretty much what Dropbox offers but better in almost every way.

Everything you store on Mega is encrypted so your data is kept completely secure and private. Nobody except you and people with whom you share will ever have access.

The service by default gives you 50GB for free which is the largest free tier in the business to my knowledge and it is by far sufficient space for most people. If more is needed then larger plans are available at prices comparable to the industry standard.

The application is beautiful and simple to use. Functionality wise it offers backing up your photos and access to the files you've stored on the service, messaging (read only currently) and a contact list of other Mega users with whom you have communicated.


Due to the use of encryption, upload speed can be a bit slower and more battery intensive than competing services but performance of the service is still world class and the trade off is in my opinion worth it.

There is also no iPad version currently available.

The messaging and contact list is very rudimentary but Mega has announced that they are heavily expanding into secure communications during 2014 with secure messaging, email and Skype-like VoIP video/audio services.

For sharing photos there currently isn't a service on the Mega website to present a gallery but you can send links to folders or individual pictures.

Finally the service currently doesn't have as wide integration into other services and applications as Dropbox so but this should also improve over time as demand increases. The service and application remains useful without it though.

For purposes of contact by the developer regarding this review I can be found on Twitter as @gnomeuser.

Version reviewed: 1.1 via the App Store on an iPhone 5 running iOS 7.1 beta 5.

Rating given: 5 stars

Mail Pilot Review

I am forever on the lookout for better ways to manage my email so far everything has failed in one way or another.

For me presently Mail Pilot is the closest to a truly great application to handle this. That being said it is still quite young, somewhat unstable at times and has some odd choices.

The good

Mail Pilot takes a todo list approach to email which is optimal for my way of dealing with mail. It allows deferring messages to a later date, or you can deal with messages right away. This is an easy way to reach the elusive empty, guilt free inbox we all crave. Once messages have been read and if required replied to you can delete them or archive them.

This difference is important as most mail applications will merely allow one or the other. Doing so creates either no history of messages or an archive filled will irrelevant entries. In my case e.g. I delete all Kickstarter project update emails after reading them as they are available on that service and I will rarely if every need to go back to them in the context of mail.

You can also set messages aside and create lists for specific scenarios but I have not yet found a need to use this functionality. Perhaps more advanced users will but frankly I find that it is just cluttering up the interface.

Mail Pilot is available both on iOS (with version tailored for the iPhone and the iPad) and on OS X allowing me to use the same tool for email on all my devices. This is a relief compared to similar solutions such as Mailbox as once you get attached to a workflow you want it to be everywhere your mail is. Sadly the OS X counterpart is not very polished presently but it remains a good mail application that is recommendable.

Additionally everything Mail Pilot offers is handled in the application and stored securely, no mail is sent off to a server for processing (other than your existing email server) which is more secure, private and for me it creates a level of trust in the business model as there are no running costs for servers.

The developers are very active on Twitter and seem very approachable which is really helpful for reporting problems or suggestion changes.

I love that Mail Pilot is like Mailbox but handled securely on the devices and that it expands on Mailbox's very limited yet elegant idea. I do wish though that the developers would embrace gestures in a similar fashion to quickly rough sort my inbox as this works really well especially on the iPhone.

The bad

Mail Pilot handles mail well but when it comes to displaying such things as email conversations it insists on showing the oldest message on top, forcing you to scroll down to see the latest mail. In the OS X version this is configurable but it is not on iOS. This is a major source of frustration and wasted time, I hope a future version reverses this odd design choice or at least allows me to specify what I want as on OS X.

Also for all its fine ways of easily handling mail you cannot mark mail as spam to train the spam filter or application on what is irrelevant right off the bat, such as those annoying messages from Nigerian royalty. I'd really like to see Mail Pilot expand the application in this direction.

Mail Pilot is rather slow, e.g. it will notify you that new mail has arrived but it will not actually have loaded it once you tap the notification. Leading to wasted time and manual refreshing of the inbox. This is the case on all platforms so it cannot just be down to not using iOS 7 background downloading feature and it is very close to a deal breaker for me.

The interface is also sadly prone to not registering when it's buttons are tapped. Leading to many frustrating tabs on mails trying to get the application to actually delete or archive a message. Clearly this is a bug and hopefully something the developers will address in future updates.

Mail Pilot is beautiful but personally I find the application a bit visually crowded and overly complex especially on the iPhone. Likely the best way to reach elegance will be to cut out the list and set aside features. I do not see this happening though but once you learn to ignore this it is a mere annoyance, it is just one that in my opinion should not be there.

For an application that is available on multiple platforms and devices which relies on folder configuration on the mail server for its features it seems weird that Mail Pilot does not use iCloud to store at least some of this information to make correctly setting up the application on all your devices easy. Currently this means e.g. paths the default setup uses different folders on OS X and iOS for me when configured to use GMail.

Finally handling a typical case such as a mail filled with pictures is relatively poor as you cannot download every single picture and added to your collection in on action. Instead you have to manually click every image and select save which gets tedious really fast.


I like Mail Pilot a lot, it already works well for my workflow and it exists on the platforms I care about. It is secure, private and sustainable while also reinventing email in a way that is utterly useful to me. It does have a number of flaws but most of them seem to be bugs that will surely be fixed rather than fundamental flaws in design or the business model.

For purposes of contact by the developer regarding this review I can be found on twitter as @gnomeuser.

Rating given in the App Store: 4 Stars Version reviewed: 1.3

Workflow idea: Read Later integration with content creation

One of my most important tools, or rather one that has grown to become so in the past two years is Read Later services. It is one of the many changes in my life that has come about after acquiring an iPad that has truly improved my life in ways I did not expect. For one it has freed me from the hell of having hundreds of open tabs in my web browser, and occasionally losing all that "saved" content when the browser crashed and could not recover the open tabs. It has also, finally, made the vast amount of data I consume and remember bits of searchable at much later dates which is extremely handy. Finally it is the one approach to bookmarking that has managed to stick with me without turning my web browser toolbar into a complete mess (that I swear I will clean up one day but never do).

I love Pocket to death, their parser is excellent and often gives the most complete results. Their iOS applications are really solid and unlike most such services they have a good OS X application as well so I can work with the service on whichever of my devices I am on without skipping a beat and without relying on a web application which inherently will always have tradeoffs and subpar integration with any environment I am in. The service has also been extremely successful in lobbying for integration into multiple applications such as Tweetbot and multiple RSS readers, making it dead easy to send information to the storage with a single click.

This wealth of applications and integration points however has increasingly caused me to wish Read Later services had more features for content creation and later reference.

Mainly because I use these services not just to archieve articles for my own reading pleasure but as a bookmarking service and a research tool for blog articles or other work.

Hence it would often be useful to be able to reference a saved item in my MarkDown editor. I'd like this to work pretty much the way Intellisense does in an IDE. Such that I could type some magic like later.foo and get a reverse chronologically sorted list matching search results as foo is typed.

I'd love to be able to pull in bits of the parsed text and have the quote, link and other magic be done automatically in this fashion, or downright pull the whole article text into the editor for purposes of inserting commentary (I suspect the former is best implemented as a subcase of the latter where I merely delete content I am not going to use).

I am also highly interested in having good references in the articles I write and having them be obvious to readers in the format and the version I used for the article at the time of writing.

It would thus also be useful for implementing an endnote reference style set of entries with links to articles, e.g. using the MultiMarkdown footnote syntax. All managed by the editor so the footnotes are ensured to always be in order.

This would require somehow exposing the parsed article online, as content has a tendency to disappear or have URLs changed.

I suspect a service such as Pinboard with archival support would be best to integrate for the archival portion of this idea but I really like the easy readable format Read Later services gives me and it is the format I would prefer to send my readers to rather than a dump of a website. I also prefer working with the parsed text for my own content creation and reference since copy pasting between websites is time consuming and not a good workflow in a single application environment such as my iPad (which is all I travel with).

I imagine the entire workflow could be implemented in e.g. Editorial on iOS provided the Read Later service API grants the access needed to query articles or some reasonable means to extract data out of the service.

I have yet to see any of the services currently available offer this, or at least no applications exist that take advantage of it to pull content in for editing (3rd party reader applications such as ReadKit do exist but they are all solely consumption oriented).

Hence when the relatively new Read Later service Poche started asking how they could stand out from the competition I was happy to suggest that they gear themselves towards enabling content creation as much as consumption.

Their upcoming 1.3 release will support fetching stored articles using RSS and ATOM which I figure is a reasonable way to at least get a list of the stored articles and to pull down select items.

I think that could be a very nice first step towards prototyping this kind of workflow. I don't expect that Poche should be the one to create these tools. That is better left to 3rd parties such as the excellent Byword and other MarkDown editors. I would just like to see them work with such developers to make it possible and easy to implement in applications.

Another way Poche could stand out would be to handle duplicate items better than the competition does. I often run through my Twitter feed and news articles roughly storing things into 3 piles:

  • Read Now - Typically personal stuff, followup on bug reports or things that I know will not be useful for longer term storage at first glance (animated gifs, bacon jokes, funny things Scott Hanselman's children say thqt I just have to share with my wife, etc.)
  • Read Later - Which all gets shipped off to my Read Later service without any additional sorting or treatment what so ever.
  • Read Never - Which is skippable all together (typically marketing tweets, special offers, sponsor messages, etc.)

I treat most of the massive amounts of information I collect in this way, it fits well into the pattern I am the most productive in and it allows me to focus on the initial flood of data, getting it sorted before it becomes overwhelming and I just mark all as read. It allows me to put off the analysis till a later moment where I can gather all the strings. I do not add tags or any additional information to items at this initial rough sorting stage, I have tried using them but they always seem like an unhelpful roadbump as they are additional information needs to be added typically at the time of saving to Read Later services to be of any use.

As one can imagine this often leads me to add the same article multiple times (e.g. if multiple people I follow on Twitter links it, then I when I go to my RSS reader I might similarly end up added the same source multiple times) and in most cases these are just added to my stash leading to utter chaos. Having some means of sorting articles and marking likely duplicates would greatly improve my use of Read Later. It would also be helpful to run a secondary sweep against articles already in my archive, indicating that I have read them in the past but for some reason considered relevant again.

Perhaps this is best left to a 3rd party application, much like the many, fairly poor, utilities that offer to fix up metadata on stuff in my iTunes music library. Hopefully better better results though. Still it is something for which I would pay good money as I end up wasting a lot of time and effort on this hell. It is a downside to my rough sorting workflow, so far the only major one (except the fact that the overwhelming stack of information now is the +10.000 unread items in my Pocket Queue but that worries me less than one would imagine).


With only 2 days left of the .NET and GNOME hackfest we are all really proud of the progress that has been made so far.


Robert Nordan finished the port of Mono-addins to GTK# and issued a pull request to upstream

Mono-addins on GTK#


With Mono-addins being fully ported and Timo Dörr having moved a lot of the Rainy note storage backend work to the Tomboy library we can now begin the port of Tomboy to GNOME 3.

We aim to deliver a true GNOME 3 application with Header Bars and other GNOME 3 integration as our current bindings will allow but the first release is going to be a pretty straight port of the Tomboy UI to GTK#3.

Robert undertook the port of Tomboy to GTK#3 and rapidly made significant progress.

Tomboy on GTK#3

And after just 25 mins of productive hacking, Robert managed to also make the new Tomboy not crash when you open a note, search is working and Tomboy is now remarkably usable. Robert indicates that now all that needs porting is settings and hotkeys.

Tomboy on GTK#3 now with notes

Robert's current progress can be found on GitHub.

Jared Jennings decided to stay up hacking till 6 am this morning and managed to make Tomboy for OS X improvements to properly handle note saving and note titles. Jared has moved on to implementing support for syncing with assistance from Timo.

Tomboy for OS X

Additionally Stephen Shaw's wife has contributed some new icons for Tomboy for OS X, that are in line with the OS X Human Interface Guidelines and style. These will have to pass the approval of Jared and Hylke but Tomboy for OS X is on track to becoming a first class OS X citizen.

I also wrote a little item on Tomboy usage patterns and what is in store going forward.


Stephen Shaw also stayed up till 6am hacking with Jared and managed to port a massive portion of F-Spot to GTK#3 with one mega commit.

A lot of work is still left to be done e.g. converting the deprecated gdk drawing calls which were removed from GTK3 but progress has been stunning so far and F-Spot will be better for it.


Stephen Sundermann and Andres G. Aragoneses's work porting Banshee to GStreamer# 1.0 continues to yield improvements to GTK#3 which are being merged and GTK#3 itself is now in really great shape. As of this afternoon have eliminated all the compile errors, now they are now handling runtime crashes and other issues preventing Banshee from using the new bindings.

Sebastian Dröge's invaluable assistance on irc in #GStreamer ensured that progress has been nothing short of fantastic.

Just before dinner time, Andres and Stephan reached a major milestone, the new GTK#3 based Banshee playing music using GStreamer# 1.0.

I captured a video of the historic moment.


While the current GTK#3 will not allow implementing certain elements of the preferences dialog using GtkStack as the APIs are not yet available, Mirco Bauer will find a way to approximate the design using existing GTK#3 widgets till these APIs are available in a GTK#3 release.

Shortly before dinner Mirco announced that he had finished the implementation of the new preferences dialog. The current work in progress can be found on GitHub.

Smuxi GTK#3 with new Preferences dialog

And here is a side by side shot of the new and the old dialog.

Smuxi new Preferences dialog side by side with the old one


Stephen Sundermann and Andres G. Aragoneses's work porting Banshee to GStreamer# 1.0 continues to yield improvements to GTK#3 which are being merged and GTK#3 itself is now in really great shape.

Currently GTK#3 binds the GTK 3.0 API which means that we do not have access to any of the new APIs which have been added since the initial release of GTK 3.0. It will run against the system GTK3 library so users will benefit from any bug fixes in newer GTK3 release but developers will not be able to use recent additions such as Gtk Header Bars and Gtk Stacks. The latter being needed to properly implement e.g. the Smuxi preference dialog.

The plan is to get a GTK#3 1.0 release out that is stable and then move the bindings to target 3.10 or git master to bring those changes in to a future release which will, hopefully, follow GTK#3 1.0 quite rapidly.


We are really grateful for the chance to spend this week working on Open Source software and it would not be possible if not for our sponsors.

Norkart logo

Norkart AS, Norway's premier supplier of Geographic Information Systems and related consulting.

Collabora logo

Collabora Ltd, Open Source Consulting

Schottenpoint logo

Hotel Schottenpoint, Our hotel partner

Novacoast logo

Novacoast IT, Professional Services and Product Development

GNOME logo

The GNOME Foundation, providers of the GNOME desktop

The University of Vienna logo

The University of Vienna - Institute for Theoretical Chemistry


The preliminary data from our Tomboy usage survey despite covering only 7 people, two distinct patterns of Tomboy use seems to emerge.

User : Notebooks : Notes

User 1 : ? : 50
User 2 : 1 : 115
USer 3 : 1 : 178
User 4 : 6 : 50
User 5 : 10 : 226
User 6 : 17 : 1030
User 7 : 29 : 350
* given lack of information it is assumed that User 1 uses only 1 notebook

Type 1 Tomboy users

Uses just the default notebook and keep a small to moderate number of notes.

I assume this class of user would tend to use Tomboy as a scratchpad to start notes and evolve them into other things such as blog posts, article, etc.

They might also use simple notes that are short lived such as shopping lists, to do lists and quick notes which have little use long term. Once a note has outlived its usefulness it is likely to be discarded in favor of keeping the note list manageable.

Type 2 Tomboy users

Uses multiple notebooks and tend to keep a moderate to larger number of notes.

I think this class of user tends to do greater amounts of work in Tomboy directly. This type of workflow would seem to be highly organized, and over time as can be seen from user 4, 5 and 7 notes are perhaps merged into fewer, but larger and more complete notes. Notes for these users have high value and Tomboy is a tool for both creation and management.

This would match well with e.g. taking class notes during class/studying and consolidating them into topic notes for revision and later reference.

Observations and comments

This only covers 7 users but it seems clear that there are a few things that would perhaps benefit both groups of users.

  • Making notebooks more discoverable and easier to use

It is worth considering that maybe a number of users are not using notebooks because they do not know how to, or find working with multiple notebooks difficult. E.g. starting a note and realizing it is in the wrong notebook, then not knowing how to move it.

It could also be that the current workflow for applying notebooks has room for improvement. This remains an area that is worth doing some experimentation in.

  • Improving the use of a single notebook

User also seem to occasionally prefer working without notebooks, especially for disposable notes or other short lived content.

It might be worth considering some form of disposable from a notebook (in this case, the only notebook) to a special archive notebook. This would allow the user to keep the list of active notes manageable without losing notes that might have value at a later date even if inactive.

Vesper for the iPhone is a great example of how this workflow could be implemented.

  • Bringing Tomboy to the user on all his platforms and devices

Tomboy currently runs only on Windows and Linux, the Android client only has support for reading notes, not writing them. Bringing the full Tomboy experience to as many platforms as possible would increase the usefulness of the application.

It would be useful to be able to take a note on your phone or tablet while on the go. To be able to interact with notes on OS X and in a web interface for machines without a client installed or a untrusted machine (e.g. using a friend's laptop, or a machine at an Internet cafe)

For that to work, both editing and reading must be fully supported, as must secure and reliable synchronization of the users notes.

Synchronization for Tomboy is currently completely unworkable as all the public synchronization servers have been taken down. Most notably Canonical's Ubuntu One Note synchronization server was taken down in February 2013 and user notes were deleted from the server.

  • First, do no harm

A great number of users will not need notebooks nor synchronization and will not expand their use of Tomboy beyond taking quick disposable notes. We should not expect every one to jump on Tomboy regardless of what features we bring to the table. For some people a scratchpad with disaposable notes is all they want and need. Tomboy should still be able to fill that role

What is being done

With the Rainy note synchronization server now being ready to deploy, the synchronization problem should not persist for much longer.

Though such services can be expensive to run in terms of servers (including system administrators occasional babysitting) and bandwidth. While there are likely to be free offerings, perhaps by GNOME itself, it also seems likely that 3rd parties will offer for pay services using Rainy to fill this gap and of course users will be able to set up their own instances of the server should they prefer that approach.

We are also deploying Tomboy on GNOME 3 and OS X, along with updating the Android port to support editing notes. Along with Rainy comes a full Tomboy on the web granting users access from everywhere

There is talk about getting Tomboy on iOS but so far we have not found time and developers to take this on. Perhaps this will change in the near future.

Finally it would be fantastic to get Tomboy on Windows 8 and Windows Phone 8 with native user experiences, though the Tomboy development team lacks Windows Phone 8 hardware and sufficient experience/knowledge to provide a truly native UX on these platforms. Following talks with Josh Blanchard from Inferno Red at MonkeySpace 2013 we are hoping work with them in the future to make this happen as they have a lot of expertise with the platform.

Luckily the Tomboy Library and leveraging C# (via Xamarin's offerings makes the task of supporting additional platforms significantly easier than having to rewrite everything from scratch in the preferred language of each platform (e.g. Objective C for iOS and Mac).

I personally believe that Tomboy therefore is positioned very nicely as a simpler alternative to Evernote that offers its own powerful features and fully native experiences. It is a chance to bring Open Source to a great number of users and get them great applications and services in the process.


We are really grateful for the chance to spend this week working on Open Source software and it would not be possible if not for our sponsors.

Norkart logo

Norkart AS, Norway's premier supplier of Geographic Information Systems and related consulting.

Collabora logo

Collabora Ltd, Open Source Consulting

Schottenpoint logo

Hotel Schottenpoint, Our hotel partner

Novacoast logo

Novacoast IT, Professional Services and Product Development

GNOME logo

The GNOME Foundation, providers of the GNOME desktop

The University of Vienna logo

The University of Vienna - Institute for Theoretical Chemistry


Last night everyone ended up working till midnight and beyond, so this morning was dutifully affected.

This is also the day we say goodbye to Jo Shields, who is going home to spend well earned time with his family after closing 21 bugs against Debian, updating packages and providing invaluable assistance guiding the path ahead for distributing and developing .NET for the GNOME platform.

From all of us here, thank you for your time and company Jo.


Stephen Shaw managed to fix a major crash in F-Spot and closed a number of bugs with invaluable assistance from Ailin Nemui on #F-Spot on IRC.

Applying filters to images now works as expected, images can be be rotated again and the F-Spot codebase has seen a great number of cleanups and refactoring.

Once Stephen is happy with the state of git master, the plan is to branch off and start the port to GTK#3. The hope is that this will be the case by the end of the day or early tomorrow.

As it has been 2 years and 9 months since the last stable F-Spot release a number of improvements has been introduced, getting that work into users hands is considered a high priority. Causing further delays by also having a release wait for a GTK#3 port and UI refresh would be undesirable. That being said we are happy to welcome the branch for the GTK#3 port of F-Spot.

This doesn't mean that a release is going to be issued tomorrow but it does mean that Stephen has the option to do so at his discretion.

Implementing filters in F# to increase performance is also a venue of possible investigation for the future as F# should be very well suited for this task without dropping the advantages of using .NET and fully managed code. When demonstrating the current UI to Hylke Bons he noted that the live filters was slower than desired and

Stephen has also been investigating a UI refresh with assistance from Hylke Bons, since the GTK#3 port is going to take a while and be a fairly big task it is a good time to also start thinking about ways to refresh the look and feel of F-Spot.


Stephan Sundermann and Andres G. Aragoneses's work on the GStreamer# 1.0 port has made great progress going from yesterday's 177 errors and 2 warnings to 19 errors.

This is taking longer than expected due to API changes and the fact that the handcrafted GStreamer# 0.10 bindings had glue code which has had to be implemented for the autogenerated GStreamer# 1.0 bindings.

As a side effect the GStreamer# port has spawned a number of fixes to GTK#3 which will benefit the entire GNOME .NET ecosystem. Stephan Sundermann also managed to fix a bug in upstream GStreamer.

Bertrand Lorentz has been porting Banshee to GSettings and merging all of the work submitted to GTK#3.


Mirco Bauer has everything in Smuxi ported to GTK#3 except the preferences dialog which he has decided is better suited for a reimplementation than direct porting to adopt the design proposed by Georgi Karavasilev.


Hylke Bons, Jared Jennings, Timo Dörr and I discussed designs for Tomboy for OS X and GNOME 3. Several good ideas for the direction forward were found and mockups of these will now be needed to guide implementation. We have also started gathering statistics on how many notebooks, notes and the average size of a note to guide certain choices.

We want to capture the essence of Tomboy, and it is felt that the existing GNOME Notes design is a poor fit for Tomboy. This is primarily because the standout feature of Tomboy is the ability to link notes via the note title, and the GNOME Notes design deemphasizes the note title in favor of a thumbnail of the note content.

Tomboy also at its core doesn't feel right being a full screen application, and instead is better suited to be essentially note windows to be summoned and created at will without taking over the entire desktop.

Stefan Hammer worked on rewriting the synchronization in Tomdroid to fix bugs and make the code more robust, with this done a release should be possible. Likewise Jared Jennings has started implementing synchronization for Tomboy for OS X.

Timo Dörr aside assisting Stefan to ensure that Tomdroid works with Rainy, fixed a few bugs in the web interface for Rainy.


Outside of lending his design expertise Hylke Bons managed to fix a few bugs in SparkleShare, add an AppData file to support the GNOME Software Center and he decided to relicense the SparkleLib library as LGPL which will allow other applications to integrating it more easily.

Finally with the help of Andres, Mirco and Lluis Sanchez's wonderful gui-thread-checker, Hylke managed to commit a fix for a long standing bug in SparkleShare which could cause a half gig DBus error message.

We decided that the gui-thread-check was such a useful tool, that Mirco added it to the Debian GTK#3 dev package to have it be available easily for developers.


Robert Nordan implemented a GTK#3 version of mono-addins, the current work in progress version can be found on his GitHub page. This removes an important blocker to porting Tomboy, Pinta and F-Spot to GTK#3.


MonoDevelop GTK#3 Application Template

The GTK#3 application template is now available for both MonoDevelop 3 and 4, and has been made available via GitHub and via the MonoDevelop Add-in repository.

Attendee dinner

Tonight was also our attendee dinner along with some invited guests from Institute for Theoretical Chemistry, as a thank you for lending us their facilities for the hackfest.

Of course after having ingested delicious local Austrian nourishment, the hackers dutifully went back to work to bring awesome to our users.


We are really grateful for the chance to spend this week working on Open Source software and it would not be possible if not for our sponsors.

Norkart logo

Norkart AS, Norway's premier supplier of Geographic Information Systems and related consulting.

Collabora logo

Collabora Ltd, Open Source Consulting

Schottenpoint logo

Hotel Schottenpoint, Our hotel partner

Novacoast logo

Novacoast IT, Professional Services and Product Development

GNOME logo

The GNOME Foundation, providers of the GNOME desktop

The University of Vienna logo

The University of Vienna - Institute for Theoretical Chemistry


Day 3 started early, while our hack room was in use for a class, people started work directly after breakfast at the hotel.

Breakfast hacking


Stephen Shaw has been hunting a bug which was introduced by yesterdays merges which caused metadata to not be written back to photos. Stephen also updated Taglib# to have better compatibility with MonoDevelop.

Bertrand Lorentz and Stephen Shaw also discussed which parts of Banshee could be shared with F-Spot outside the Hyena code.

MonoDevelop GTK#3 application template

Porting our existing applications to GTK#3 is just one aspect of embracing the GNOME 3 platform, we'd also like to enable developers to make new GTK#3 applications from scratch in MonoDevelop.

To enable this Robert Nordan has added a GTK#3 application template to MonoDevelop, however since Stetic (and MonoDevelop) remain GTK#2 applications for now, developers will have to launch Glade3 separately to build the actual UI.

MonoDevelop GTK#3 solution MonoDevelop GTK#3 solution


Jared Jennings made great progress on Tomboy for OS X, it now correctly handles the headline feature of Tomboy, the wiki style links between notes. Saving notes now mostly works correctly and a troublesome crash was eliminated (while also removing code, the best kind of fix).

Rich text styling still is a work in progress but Tomboy for OS X now works more or less as expected and a release seems on the horizon.

Tomboy for OS X

Stefan Hammer got his rich text metadata detection code working for Tomdroid with help from Timo Dörr. The only thing holding up a Tomdroid release now is updating the note synchronization handling which is slated to be done tomorrow.


Stephan Sundermann and Andres G. Aragoneses started porting Banshee to GStreamer# 1.0. Thus Banshee 2.9.1 will default to using the same GStreamer# backend for all platforms which is a big step forward in both stability and uniformity of the Banshee experience which users are sure to appreciate.

Banshee is keeping the libbanshee C shim that is currently being used for the Banshee stable Linux release but a patch will be added to support GStreamer 1.x should distributions elect not to use GStreamer# (e.g. if that package is not, yet, available).

Eventually libbanshee will go away entirely, hopefully without anyone even noticing.


Mirco Bauer has been reimplementing the menu bar design using Glade, this task was not suitable for the same kind of conversion as was used yesterday to get the connection dialog running so it had to be done from scratch.


Stephen Sundermann provided Hylke Bons with WebKitGTK# bindings and with very little effort Hylke was able to complete the GTK#3 port of SparkleShare.



Pinta, F-Spot and Tomboy all use mono-addins to provide a UI for handling extensions. Without a port of mono-addins to GTK#3 we will not be able to fully port these applications thus this task has taken on a degree of urgency. Andreia Gaita as it turned out did not have sufficient time to dedicate to the project.

The plan currently is for Robert Nordan and Stephen Shaw to take on this project tomorrow as it holds up both their application.


Bertrand Lorentz has been merging a lot of work coming from Stephan Sundermann's Bindinator work into the GTK#3 git repository.


Jo Shields has been building and uploading many of the Mono stack packages to Debian Experimental as well as his Monoxide PPA (for Ubuntu 13.04). Jo has also been working on making the Debian package for MonoDevelop use the system mono-addins rather than the copy that comes bundled with MonoDevelop.

Packages should also be available for openSUSE Factory courtesy of Stephen Shaw.

None of our ported applications are currently available for installation as they depend on the packages above and because they are currently considered experimental and should not be used by ordinary users.


We are really grateful for the chance to spend this week working on Open Source software and it would not be possible if not for our sponsors.

Norkart logo

Norkart AS, Norway's premier supplier of Geographic Information Systems and related consulting.

Collabora logo

Collabora Ltd, Open Source Consulting

Schottenpoint logo

Hotel Schottenpoint, Our hotel partner

Novacoast logo

Novacoast IT, Professional Services and Product Development

GNOME logo

The GNOME Foundation, providers of the GNOME desktop

The University of Vienna logo

The University of Vienna - Institute for Theoretical Chemistry


All the missing luggage from yesterday arrived at the hotel unharmed.

After that piece of good news Gerhard indicated via email that he would be unable to make it to the event.

Antonius's employeer has been unable to let him have time off for the event so he will be joining us on Saturday for the last two days of hacking.


The 2.9.0 release was picked up by a few news outlets and reception so far has been positive. It is still the same old Banshee everyone loves but on a modern foundation that brings hope for a bright future.

Andres G. Aragoneses has dedicated the day to reviewing and merging all of Stephen Sundermann's patches to the Bindinator into upstream and addressing any review issues. Hopefully this will be done today, meaning we are well on our way to providing a .NET GNOME experience that is great for both developers and packagers.

With that in place we will be able to start work on integrating GStreamer# 1.x with Banshee.

Bertrand Lorentz has been fixing bugs in the Hyena library which is shared between Banshee and F-Spot. Due to changes in GTK between 2.x and 3.x scrolling list using a scroll wheel no longer worked and this functionality has been restored.


Jared Jennings explored moving Tomboy for OS X from using WebKit to Xamarin.Mac. However problems fitting Tomboy's rich text editor needs to that framework proved that the original idea of using WebKit was likely still the best route.

The design of the application has been smoothened a little. Jared is trying to capture the magic that made Tomboy quick, elegant and lovable for note taking originally and enhancing those aspects in the OS X environment.

Stephen Shaw and I have been helping out with design ideas and once Hylke Bons becomes available we will be able to lend his wealth of design knowledge to that effort.

We have also been discussing how to implement new features such as image support and MarkDown syntax support. I am personally a big MarkDown fan and would love to be able to use that syntax to write notes. While it is very likely not something most users would want to be exposed to compared to the rich text editor we provide today, it would make a nice enhancement to Tomboy for more advanced users.

Tomdroid faced a stubborn bug that Stefan Hammer and Timo Dorr ended up dedicating a bit of their evening to solving after dinner and the official end of day 1. Though the problem persists so Stefan and Timo have dedicated their morning to solving it.

The bug being having been solved Timo went on to moving backend and authentication code from Rainy to the Tomboy Library so all implementations of Tomboy using the library will be able to leverage these easily. Meanwhile Stefan has been implementing a tag identification system using graph theory for Tomdroid. This code makes Tomdroid's codebase more robust and less prone to erroneously identifying rich text metadata such as: "the currently selected text is bold") in notes.


Robert Nordan has been continuing work porting Pinta to GTK#3 but is currently held up by mono-addins still being GTK#2 only. Additionally a lot of functionality Pinta uses in GTK has been removed in 3.x, most notably the Ruler widget and all drawing is now done with Cairo directly instead of using GTK.

This is makes the Pinta port one of the larger projects undertaken at the Hackfest so far. I would not expect this to be finished during the hackfest as a lot of code will have to be reimplemented to provide the Pinta experience people know and love. As is expected a lot of functionality is still not available, e.g. you can open images, manipulated them (such as resizing, inverting colors, etc.) and save images, however they will not be displayed in Pinta as the canvas currently isn't working.

The second big problem with porting Pinta is that mono-addins requires GTK#2. We cannot directly port this to GTK#3 as it would break applications which use the UI parts of mono-addins but which will remain on GTK#2 for the foreseeable future, such as MonoDevelop. This is a problem that is shared with F-Spot but not with Banshee as it has its own UI for handling extensions.

Andreia Gaita has undertaken the task of investigating this remotely from Copenhagen. An interesting idea would be to port mono-addins to XWT and creating a XWT backend for GTK#3.

Robert did make sufficient progress to get Pinta's GTK#3 port to launch, but it currently has no canvas to display or edit images.

Never the less we are proud to show off Pinta joining the ranks of GTK#3 enabled applications.

Pinta GTK#3

And here is a side by side shot of the new GTK#3 based Pinta and the current GTK#2 based version.

Pinta side by side

There is still a ways to go but the interface, save for the lack of the canvas are fairly identical. A lot of excellent progress for 2 days work by Robert.


Hylke Bons is continuing to make progress and Stephan Sundermann has been helping out by generating bindings for Application Indicators. With that integrated SparkleShare on GTK#3 is getting very close to being able to replace the existing GTK#2 release.

He has also been unleashing his inner designer to tweak SparkleShare to look great on GNOME 3. SparkleShare should thus now be the most beautiful and elegant looking of our .NET GNOME applications.

SparkleShare GTK#3


Stephen Shaw managed to merge a lot of work into F-Spot last night and he tracked down an xbuild bug causing F-Spot to fail building in MonoDevelop. F-Spot should also use Hyena as a git submodule now rather than embedding its own copy in the source tree, this is the same approach as Banshee uses presently.

Stephen been merging the work his GSoC students did on im/exporting RAW image files, facial detection and support for newer version of color profiles. As these are the default in GNOME 3.8+ thanks to Richard Hughes's colord, this also fixes a crash on start up when running on GNOME 3.8+ with colord which is sure to bring joy to F-Spot users of the world.

Moving F-Spot to GTK#3 is likely going to involve redesigning the UI in a significant way and Stephen has been examining XWT as a potential path towards such a redesign.

How much of that work can be done during the hackfest is uncertain but delivering a new F-Spot UI is likely a project that will take a lot longer than the week we have.

Luckily Hylke Bons offered his help working on mockups for a modern F-Spot design and some existing work from previous F-Spot maintainers exists build on.

Packaging and bindings

Yesterday Stephen Shaw managed to get openSUSE's Mono stack updated to include the new GTK#3 release and other vital version bumps to enable development on that platform.

Stephan Sundermann and Andres G. Aragoneses started work yesterday reviewing and merging Stephan's changes to the Bindinator tool so we can have one master repo with all the tooling and bindings for developers and packagers to rely on.

The resulting work can now generate WebKitGtk bindings which can be demoed using the FunnyBrowser example browser from WebKit.


Likewise, GStreamer# is functional and demo-able.


Jo Shields has been hunting a bug in monodoc which is currently holding up the progres he made towards updating the Mono stack in Debian/Ubuntu. Frustrations with which having reached the point of inserting Console.WriteLine calls, mainlining Red Bull and reading the ECMA-335 standard.

In the end though Jo emerged victorious and all is right in the world once more.

Was it not for the two additional bugs he uncovered in monodoc on Linux. First it crashes during runtime and secondly it seemingly fails to write the documentation index to disk so it cannot be utilized by MonoDevelop for searchable documentation.

Jo worked on this all day and in the end it resulted in 6 closed bugs against the Debian Mono stack and a small patch sent upstream. Essentially he moved documentation generations from package install to be at the users discretion.


We are really grateful for the chance to spend this week working on Open Source software and it would not be possible if not for our sponsors.

Norkart logo

Norkart AS, Norway's premier supplier of Geographic Information Systems and related consulting.

Collabora logo

Collabora Ltd, Open Source Consulting

Schottenpoint logo

Hotel Schottenpoint, Our hotel partner

Novacoast logo

Novacoast IT, Professional Services and Product Development

GNOME logo

The GNOME Foundation, providers of the GNOME desktop

The University of Vienna logo

The University of Vienna - Institute for Theoretical Chemistry


At dinner last night Micro Bauer pointed out that I had forgotten to add his progress to the daily report. Hence a short update on the progress for Smuxi in a separate post.

Smuxi GTK#3 with connection dialog That is Smuxi as of last night, the new feature is that the connection dialog is now on GTK#3.

As Smuxi uses the Stetic GUI designer to define these dialogs, and since Stetic is using GTK#2 for the time being Mirco worked with Stephan Sundermann to create an tool similar to the Bindinator to transform Stetic's XML output into the .ui format used by Glade3. This shows that the tool works and that interfaces constructed using Stetic can be moved to GTK#3 and Glade3 without having to throw out existing work which should aid in moving applications to the GNOME 3 platform.

So there you have it, the .NET + GNOME hackfest has now delivered Banshee, Pinta and Smuxi on GTK#3 with Banshee being close to usable and having seen a release. We have demonstrated GStreamer# 1.x and WebKitGTK3#, shipped the base packages (GTK#3 and Mono 3.x) along with fixes to long standing bugs on Linux and this is only day 2 of the week long event.

We are very pleased with the progress so far and we hope that everyone else is too.

.NET + GNOME Hackfest 2013: Everybody Jump on the Application Porting Omnibus (Day 1)

We have mostly all arrived safely in lovely Vienna though some of us with slightly less baggage than we expected. We also have yet to see our Tasque developers Antonius Riha and Gerhard Liebmann.


We have already had a very productive morning, managing releasing the first ever Banshee development preview using GTK#3, 2.9.0 on the road towards a 3.0 stable release for users later this year.

The next big step will be moving Banshee to using GStreamer 1.x via our freshly minted bindings generated using GObject Introspection. Andrés G. Aragoneses, Bertrand Lorentz and Stephan Sundermann are currently working on this and given the size of the task we should see some results in the near future.

That move will bring all our supported platforms to leveraging GStreamer using the same method and allow us to remove the C shim currently used on Linux for this task.

That piece of code is currently tying Banshee to an old and unmaintained version of GStreamer (0.10.x) and it is a source of a number of playback bugs. The end result should be that Banshee users will experience a much improved Banshee in terms of stability.

Hylke Bons volunteered his talents to help Banshee move its UI to be more in line with the design of GNOME 3 and technologies. Such work though is unlikely to see the light of day any time soon as the focus right now is moving Banshee to the modern GNOME 3 platform.


Tomdroid bugs are being squashed at a downright alarming rate. The aim is to get a Tomdroid release out with editing capabilities and support for our new Rainy note synchronization server.

Rainy is already in a fantastic state after a successful GSoC project and the web interface is seeing some small tweaks. Additionally progress is being made towards moving the SQLite backend from Rainy to the Tomboy Library. This will allow implementers of Tomboy to store notes in SQLite easily. With other public Tomboy note servers having been taken offline Rainy presents a valuable chance to restore this vital functionality to the Tomboy ecosystem, while also bringing encryption of notes, a web interface and many other things to the party.

After the long awaited Tomdroid release, a group of us are going to investigate moving Tomdroid from Java to Xamarin.iOS and C#, allowing sharing code thanks to the Tomboy Library.

With the Tomdroid release out of the way Stefan Hammer will move to working on Tomboy for GNOME 3. This however is likely to be work for Wednesday and beyond.

For Tomboy we also are actively working on the OS X port which is being moved from using WebKit to using Xamarin.Mac. However questions regarding rich text editing are being investigated as are UX choices.


Smuxi is seeing continued work towards its new GTK3 UI.

Smuxi GTK#3 day one progress


Robert Nordan is currently working on Pinta and has made some significant progress towards compiling against GTK#3.


Initial porting of SparkleShare to GTK#3 has been undertaken by Hylke Bons (http://twitter.com/hbons/status/387593459541897216). SparkleShare on GTK#3.

So far SparkleShare runs but lacks support for certain features such as Application Indicators for which we have yet to generate bindings but it is otherwise very functional.

Mono packaging of .NET bindings

We have packages out for Debian/Ubuntu providing gtk# 2.99.1 but the big task for today in this area is deciding how we are going to organize, develop and release the new generated bindings and the tools going forward.

We want this to be super easy for Linux distributions to package and provide this bindings to developers, Mirco Bauer and Jo Shields are proving invaluable to understanding how to best meet those needs.


While Jeremie Laval was unable to come to the hackfest he still is with us in spirit and has helped the event by releasing the long awaited DBus# 0.8.0 which will allow us to move to a more stable version of the managed DBus implementation that has superior test coverage. It will also allow us to remove some workarounds in applications like Banshee which are in place to support older known broken releases.


We are really grateful for the chance to spend this week working on Open Source software and it would not be possible if not for our sponsors.

Norkart logo

Norkart AS, Norway's premier supplier of Geographic Information Systems and related consulting.

Collabora logo

Collabora Ltd, Open Source Consulting

Schottenpoint logo

Hotel Schottenpoint, Our hotel partner

Novacoast logo

Novacoast IT, Professional Services and Product Development

GNOME logo

The GNOME Foundation, providers of the GNOME desktop

The University of Vienna logo

The University of Vienna - Institute for Theoretical Chemistry

MonkeySpace 2013

It’s that magical time of the year once more, and .NET users and developers are flocking to MonkeySpace, the heart and soul Open Source .NET.

This year we are in Chicago which marks a first for the conference and everyone is having a great time. Wonderful sessions and networking is taking place.

This year I am in charge of the hackroom which is 2013’s attempt at doing Open Source rather than just talking about it. While people do tend to get distracted by the great talks and not get a lot of hacking done the room is proving to be a great resource for everyone.

I am very excited about being here and talking to developers who come from completely different backgrounds to mine. There is no assuming that people know about Linux, GNOME or any frame of reference I am used to.

I am finding this very enlightening and refreshing, it is also a great way to get people interested as a lot of the applications I tend to associate with Open Source .NET such as Tomboy or Banshee do poorly in the Windows world from which this people hail.

This also means I have made a lot of contacts who are interested in doing fairly big chunks of work on such projects to fill in the gaps that are typically present such as integration with the Windows platform for Banshee to bring the experience up to the level of what we offer on Linux. Or simply providing a presence on these platforms for applications there for applications that have none such as Tomboy in respect to Windows 8 and Windows Phone 8.

In the coming months I will be working to set up these things and working with the truly wonderful people I have engaged with at MonkeySpace.

But we won’t stop there, Friday after the conference we are having a big all day hackfest. Aside representatives from a number of Open Source .NET projects, we will be having representatives from the Humanitarian toolbox so hackers can use their skills to help with disaster relief.

What iBooks for OS X tells us about the future of iTunes

iTunes, likely the most popular media application in the cosmos, is also one of the most uniformly loathed.

Primarily because it reeks of the 90’s, in that it tries to handle all kinds of tasks and all kinds of data in one huge application.

It is a monster that does everything under the sun with any kind of data you throw at it:
Music, podcasts, books, audiobooks, lectures, movies and TV shows.
It handles shopping for all of the above and apps.
Finally it manages, backs up and synchronizes your portable devices be that your iPhone, iPad and iPod.

iTunes presently harkens back to a time before the Internet, especially the Internet as provided by prevasive high speed wireless connections to powerful computers in your pockets and bags.

It served its purpose of centralizing your media and making iTunes (and in many cases your Mac) the organizer of your media. However the world has moved beyond this in a big way.

This makes iTunes overly complex, overly buggy and unintutitive. You know it, I know it and Apple knows it.

Which is why they have had to formulate a plan for iTunes going forth that tackles all of these issues.

We saw the first steps on iOS last year when they broke out Podcasts from iTunes into its own application along with separate applications for music and video.

Then followed the visual make over of iTunes for OS X with version 11, which fixed the ancient look and feel, or at least provided the first big step towards a modern user interface that is worthy of the 21th century.

Now with OS X Mavericks 10.9 we see Apple taking the next logical step, breaking out books from iTunes by shipping iBooks for OS X.

As a lover of ebooks I am very excited about this, mostly since iTunes is a terrible book manager but also because it will radically reduce the complexity of iTunes. It also covers ebook reading better on the Mac than it ever has been done previously (at least by Apple).

While getting iBooks on OS X is great it does raise the question of where Audio books belong in the future.

Do audio books go in iBooks using the same logic as we have seen in iTunes so far that they are books? Do they stay in iTunes following the logic that they are fundamentally sound not books? Or will audio books eventually be broken into its own application like we have seen happen with Podcasts?

I believe that for now audiobooks will stay in iTunes, but should eventually go in their own application. Regardless of the way you look at audio books, they are fundamentally a way to enjoy books not music but they are also not a natural fit with books in terms of how we use that content.

Like Podcasts, audio books seem well suited for a standalone application in that they need their own set of playback feature and the share mostly management needs with traditional books. I doubt that they would fit nicely into iBooks as things stand and by forcing them in there we would likely end up just moving the complexity problem from iTunes to iBooks. Though with the new interactive ebooks, perhaps it is not a great leap to put audio books in iBooks.

I think this is the direction we will see iTunes take for all major components. Podcasts on OS X is sure to follow, likely this year.

Another easy target could be iTunes U which is already a separate application on iOS.

The iTunes store will eventually go into the App Store, much akin to what Google presents with the Play Store. Centralizing buying content in one place would make sense.

Eventually iTunes will be back basics to it’s original music only application, with iTunes Radio and other cloud features. Much like the Music application on iOS as seen in iOS 7. At which point the question will be if the iTunes name will die. It has tremendous brand value but Apple has never been over attached to the past and maybe they will simply carry over the names used on iOS and bury iTunes with a fond farewell.

We will see Apple do this gradually rather than dumping a big reorganization and a bunch of new applications on users. Slowly easing us into this new world and allowing them to split the job up in managable bits. This will also allow Apple to keep the bug count and stability manageable, e.g. Podcasts on iOS was initially buggy and unstable but now it is great. I think that serves a good meassuring stick for the bumps in the road that can be expected with any single standalone former iTunes functionality application.

Podcasts for iOS, for all the hatred it got in the press initially is now very functional, elegant and it works well for most users. Apple were responsive in fixing issues and polish, to the point where today it is a much better experience than what iTunes provides for Podcasts for pretty much all users.

This whole process will likely take at least a couple of years to come about, depending of course on how important this is to Apple. It will likely take the course we have seen so far in being implemented on iOS first and making its way to the Mac with the big yearly updates.

On Marco's fertile ground

Instapaper creator Marco Arment on iOS 7 being fertile ground.

A wonderful little article and I think Marco is mostly right in his assessment that existing players will have some hard choices to make in supporting iOS 7.

It is a completely new world, and major redesigns will be needed to fit in, also there is no way to properly support older versions of iOS with the same application and looking native on both platforms. It is largely one or the other, and the only way to have both is maintaining an application for each which would present a huge burden for most developers.

Properly architected applications with separated core and user interface, such as encouraged by Xamarin with their .NET based development tools though will have a leg up in supporting both platforms to their maximum and the burden involved with supporting both will thus be lower.

Such development is done by e.g. Rdio and the result is that they are enabled to deploy on multiplatforms with nicely integrated native apps at low development cost. Applications employing such tools and development technics will be able to treat iOS 7 as merely another platform to support and will likely get to market very rapidly and feature a native application with broad functionality.

Sadly most applications do not fall into this category, but I doubt it will matter much for most applications.

Unless there is an existing need to support older platforms, such as a contractual obligation or an existing vast userbase on e.g. iOS 6 and below who cannot upgrade which cannot be sacrificed on the alter of progress.

If you are Facebook, Angry Birds or Candy Crush you will have to support everything, but the average developer is unlikely to have to care about non-iOS 7 users simply because they will be representing a fairly small share of all users, and that share will be shrinking over time so there is little hope for generating lots of income compared to the development investment it will take and the compromises that will be needed in the application to accommodate these users.

Now a year after iOS 6 has been introduced more than 92% of all iPhones are using it and 83% of all iPads[1]. iOS 7 adoption will likely be lower after its first year due to deprecating older devices like the 3GS which are still in use, especially in markets where Apple devices are expensive or technologically out of step with the US market (such as Brazil where the iPhone 4 is still sold today as a highend phone by some companies without any subsidies available).

Also being a major change is likely to make people hold off a bit longer than usual, as has been seen with other platforms that radically changed their interface.

That being said it can still be expected to be very high. No other platform has the update rate iOS has and there is little to stop that from continuing. Apple have made a lot of right choices regarding iOS upgrades such as making them free and easy to apply. That has clearly paid off for them as the numbers reflect.

Where new players have the advantage in my mind is that they will have a chance to build their application directly for the new platform without having their mind tied to an existing userbase or an existing custom user interface. That clarity of mind is likely to be the biggest factor counting in favor of new developers and new applications entering the market. There is no taint or worries about the past, and there is a window open while the existing players execute their game plan for iOS 7 and beyond.

iOS 7 represents not just a new look and feel but a set of functionality that developers will want to rely on being present. Such as the opportunistic downloading so applications will no longer have to refresh data upon loading thus delaying the users access to the content she is interested in.

Examples of this kind of limitation can be seen in Feedly which reloads upon loading to get the freshest news stories or in Pocket which has to poll its servers for the latest articles you saved to read later. These application can now refresh when the user does things unrelated to the application which lead to waking up the device, like quickly checking the time or responding to a message.

This will lead to smoother, quicker feeling applications as a result of using features only available in iOS 7, will make it desireable to depend on in the very design and execution of the application. Thus going for iOS 7 and above only support will present an advantage to developers, and users will get better applications as a result of it.

The only set of applications that will likely suffer greatly will be largely unmaintained free applications that generate income solely from displaying ads. I doubt these kinds of applications will be able to support the development investment required to support iOS 7 properly. These apps are typically dead wood and cutting them from the tree will do it good. I think users will be served better by new actively maintained iOS 7 applications and if these new apps are 99 cents rather than free then that is a small price to pay for progress.

Progress is good.

  1. Chitika Insights analysis as of June 6th 2013.  ↩

WWDC - iOS 7 impressions

The most anticipated announcement of the WWDC keynote was without doubt iOS 7.

I expected there to be few new features due to the Forstall to Ive transition and boy was I wrong. Not only did iOS get a modern visual makeover but it added 1500 new APIs for developers to leverage and great new functionality such as easy data sharing via AirDrop between devices supporting it (which apparently does not include my 3. generation iPad, something I can’t really see a technical reason is the case).

The iOS 7 user experience

The best way to get an idea of the new style is to go to Apple’s iOS 7 page which has a gallery showing off the new style and the redesigned core applications, as well as a video of Sir Jonathan Ive explaining the philosophy behind the design of iOS 7.

John Gruber also has nice write up of how to think about the new style on Daring Fireballs which is highly recommended.

What iOS has gained with the interface update in my mind is a modern slick style and a consistent visual design language. It clearly draws inspiration from the flatter, simpler look that Microsoft pioneered with Windows Phone 7 and Windows 8, but also from OS X, WebOS and even some concepts from Android. If you like the way games like Letterpress look then I think you will enjoy what iOS 7 brings to the table.

It already visually speaking feels very complete which is amazing given the amount of time that has been available to redesign and develop iOS 7. I would not have expected them to have implemented such broad changes, adapting the core applications. Not only did they do that but they added a lot of new features and polish in the process.

I like iOS 7 a lot, it is obviously still an early design and we will see spit and polish being applied between now and its public release this fall. Apple clearly have not had time to fully consider deeper application changes in how things will work rather than what they will look like, what Ive tends to call the essence. However they have the fully formulated language to express those changes in now and they have taken the first major step down that road.

iOS 7 appears new, yet still familiar, meaning users will not have to relearn how to use their devices from scratch once they install the update but it will feel like they got a new device in so many ways. I think Apple has struck a good balance that will not scare existing users and still feels very fresh which will help with adoption. It certainly is not as polarizing as some people feared.

The big question is how many developers will be able to redesign their applications to fit visually into the new interface before this fall brings it to users. I expect that the first year or so will be encumbered by applications that will not visually fit in, especially free applications which tend to lack the resources and incentives to perform such big tasks.

The new design will likely to force a lot of developers to either keep separate versions for compatibility with non-iOS 7 or dump anything older than iOS 7 from their support list. It is a big change to adapt to and it seems impossible to create a single application that visually fits into both iOS 7 and older iOS releases. I think we will see developers will use this as an excuse to drop support for non-iOS 7.

Being able to rely on a certain level of hardware and on certain technologies being present will make for more elegant, less buggy applications with better performance, at least that is my expectation and hope. It is a big amount of work and updates to these, which realistically speaking will be completely new applications will likely be paid to recoup the costs involved.

iOS 7 is going to be a clean break, it is going to be some what painful at first, especially for developers who will have to scramble to adapt. That being said I think it is about time it was done and the new design language will serve both developers and users well for many years to come by providing a consistent guideline for developers to make beautifully simply application. Applications that leverage what modern hardware can do and which will work to the limits of what your device can do, not the limits set by the physical items from whence they came once upon a time.

I, for one, cannot wait to get my hands on iOS 7, I think you will like it when it arrives and wish my developer friends a good time exploring what it can do over the couple of months so they can bring us truly awesome applications to compliment the new world of iOS 7.

WWDC iCloud improvements

The much awaited WWDC keynote is over and let’s start with the message on iCloud.

Much against my expectations Apple did not admit or hint that they understood the problems with iCloud for developers and platform lock in. They also did not announce any plans for addressing the problems it has with CoreData, perhaps such changes will be the focus of sessions in the coming week.

They also did not tone down iCloud mentions as I expected in light of the recent battering it has taken. Instead they doubled down on the message that this is the future and showed off some new iCloud uses.

iWorks for iCloud

iWorks is now essentially an iCloud using web application that allows you to work with Keynotes, Pages and Numbers documents in the web browser. There is no word on updates to the native iWorks applications for iOS and OS X but I am guessing this means the end of those.

I feel like the world is moving away from the traditional office suite in many ways but having the functionality be on the web makes sense for those legacy cases where it is still needed.

This is the right direction for iWorks and I am sure it will receive more love in this new form than Apple has given it the last couple of years. It is clear that Apple doesn’t see Microsoft Office as the competition but Google Docs, which shows that in terms of Office type work they have their eye on where the ball is going to be, not where it is right now.

iCloud Keychain

Apple also introduced iCloud Keychain, a useful cloud based locker for data such as credit card information, website logins, known wifi networks and account information. This is very similar to the wonderful 1Password and this type of application is something everybody should be employing these days to have good security and avoid problems like password reuse.

This is a very welcome addition for users, however it will currently be limited to OS X and iOS which I suspect makes it a lot less useful to most people than 3rd party solutions such as LastPass and 1Password, since these will support every platform you use (mostly). However compared to those, iCloud Keychain will be free to use which is sure to count it its favor with many users.

Additionally there is concern that Apple keeps a master key for users iCloud data and can decrypt it at any time of their choosing. Storing potentially important and private documents, all your website login, account information and credit card information in a service that can be decrypted at any time by a 3rd party seems.. insecure to me.

It is an especially worrying aspect of iCloud in light of the revelation of the NSA PRISM surveillance program which has apparent collaboration from Apple (and other tech giants). Though Apple are denying giving any government that level of access to their servers the mere fact that they can access your encrypted data is problematic to say the least. I would be worried about putting anything on iCloud, especially personal data.

All in all, I feel that Apple are committed to iCloud and their WWDC keynote shows that they will be working on its issues. It is a good sign that they are eating their own dogfood by integrating it in their core applications to a greater degree than in the past. This should expose them to the issues experienced by developers more readily than they have previously. I am far less worried about their ability to follow through than I was before but given Apple’s track record as a service provider there are still a lot of questions that need good answers. Hopefully those answers will come in the iCloud sessions over the coming week.

For the record, I now believe I was wrong with regards to Apple buying Yahoo!. It seems they have elected to double down on becoming good at running services on their own, it is a song and dance we have seen from Cupertino before and it has not worked out well so far. Maybe 4–5 times is the charm for Apple.

WWDC 2013 - My hopes and predictions for software

WWDC is a developer event and that means new software, new APIs to play with and new OS previews for our Macs and iOS devices.

Apple put OS X on a years cycle much like iOS recently and we already know to expect previews of both iOS 7 as well as OS X 10.9 at this years WWDC.

iOS 7

With Scott Forstall officially out and Sir Jonathan Ive in charge of both hardware and software design big changes are expected. The common wisdom is to look at the evolution of Apple’s Podcast application for iOS for clues to how Ive will be changing the visual language we are used to.

If that is any guide the skeomorphic metaphores are out and a flatter look is in. As Ive was only put in charge at what must have been the halfway point of the iOS 7 development cycle I doubt that there has been much time to implement wide changes but I do expect some visual changes to key applications such as Mail.app, Calendar and Contacts, these are core iOS applications and certainly ones in need of a once over. I am hoping that iBooks will also be losing it’s wooden bookcase and embracing what ebook reading can be, I believe Marvin ereader application is a good direction to go in generally in this respect (in terms of the reading experience, Marvin is getting rather functionally overloaded and certainly nothing Apple would ship themselves).

Of new features it is widely rumoured that the social integration will be expanded with Vimeo and Flickr. Of these I think Flickr is the most important to consider as Apple has had a long standing relationship with Yahoo! and currently is trying it’s hardest to lessen their dependency on Google. Both though are signs that Apple are opening up to working with more partners and it is a good thing.

I hope that they will open up the Online Account system to 3rd parties so that I could e.g. add my Mega.co.nz, Dropbox, Kickstarter, Diaspora and other services there. It would likely also encourage app developers to rely on the system account store rather than having the user type in user names and passwords in every application. This would be a general good and the standard application review process could likely to enforced to avoid abuses of such an opening of access. It would though mean that if application developers start relying on it, that users would have better more central control over what applications have access to what accounts, and with what privileges. In fact if this is opened, I would suggest that Apple reject all applications that rely on 3rd party accounts which does not adopt the API to improve user privacy control.

I also hope that users will finally be able to set their default applications for mail, browsing and so on in some way. If they also allow you to remove their applications if so replaced it would be perfect. Additionally it would help stimulate the app ecosystem for this types of applications, to allow the Sparrows of tomorrow a greater change of success than the Sparrow that died all to soon. Something that would I suspect be greatly welcomed by both users and developers alike.


I love OS X, but I realise that it is not the most important of the OS projects in Apple’s world. It is also the project we have heard the fewest rumors about. There are some who say that with iOS taking on a more userfriendly, easy interface, OS X will be taking a turn towards power users. I believe this is untrue and if it turns out to be true I would be a mistake. OS X is the only desktop platform that keeping steady in a climate where traditional PC and laptop sales are falling. Making Finder more awful by adding tabs as has been suggested rather than making it more intuitive and elegant (like GNOME3’s Nautilus).

One reason we likely have not heard much about OS X is that Apple have had to pool effort behind iOS 7 to get it ready for preview.

Another is that OS X as it stands is pretty good, in fact what it mostly needs is having some long standing issues addressed such as the fact that the file system is 20+ years old and currently held together by duct tape and gum.

You don’t however change a filesystem overnight, and for what it is worth HFS+ in its current state is fairly stable and performs okay on the hardware Apple provides. I think Apple will change the file system eventually but it is not a project for this year and it shouldn’t be. I think it would be more trouble than it is worth. It is also a hard thing to get right, failing to do so is certain to cause dataloss and that is something Apple will want to avoid at all costs, even keeping HFS+ alive for another couple of years.


I think the biggest changes to both iOS and OS X will be in services and integration.


iCloud is famously popular with users, it generally works well for the cases we see it. E.g. this very blog post is written in the excellent Byword, in a text file that is stored on iCloud. I have worked on it using both Byword for iOS and OS X seamlessly, and once I publish the post the original document will stay where it is.

For developers though iCloud is a completely different story.

The most obvious problem is that iCloud is only available for iOS and OS X. Developers who wish to support additional platforms will have to use something else, this is not in Apple’s best interest. Apple will have to make iCloud available to developers not using Apple’s platforms and deploying via their their App Stores exclusively. Tim Cook seems inclined to bringing iCloud to more platforms and opening up a bit more in his All Things Digital interview so hopefully this will happen.

Secondly, while the relatively simple key-value pair syncing and document store works well, whereas the complicated CoreData syncing does not (see e.g. this article on The Verge. Sadly the latter is by far the most valuable part of iCloud and one that desperately needs to work for iCloud to live up to its promise.

Thirdly, iCloud is quite tied to the core iOS and OS X code base and as such is on basically a yearly schedule. This means that the feedback loop for bug fixes and new features is far to slow. They need to decouple iCloud and make it a separate SDK which is on a more rapid cycle such as the 6 week cycle seen with web browsers.

Unless Apple does something about their iCloud problem it will fail to catch on the way Apple is betting on. Apple also has a terrible history with regards to providing and running services. They do wonderful products and beautiful end user software but they just cannot seem to grasp how to do services. They will have to get good at it really quickly and I don’t think they can do that on their own.

I also think there is a reason that the Moscone center decorations are not featuring the iCloud logo that otherwise is prominent on Apple’s packaging and other material. They know it is broken, and they have nothing to announce… Yet. I suspect a special developer event will be held later this year, I just don’t think they have managed to get this ready for the big WWDC event and they will hurt because of it.

I think the Flickr integration is the first sign that Apple are warming up to Yahoo! and I hope it means that they are looking at either buying them outright for the talent and expertise or expanding their existing work relationship by e.g. contracting them to run and maintain Apple’s services on Apple’s terms. Apple cannot afford to screw this up any longer and it will hurt them in a bad way if they continue to attempt and fail.

Luckily for Apple, Yahoo! while improving under Marissa Mayer’s leadership is still in a bad place and would likely be inclined increasing their reliance on Apple to remain relevant.

So my prediction is that Apple will acknowledge that they cannot fulfill their iCloud promises as things stand and that they need to change rather than dig in and continue to fail terribly like they did under Steve Jobs.

This is I believe going to be the first time Tim Cook can really shape Apple’s future in a deep and meaningful way that Steve Jobs would never have done, and it is because he is ready to publicly apologize for falling short of his promises. Having already done so with regards to Apple Maps for its initially disappointing state and taken steps to improve that product to where it is today.

They will likely do so by buying Yahoo!, it is already a company they have strong ties with, Yahoo! being the providers of e.g. Weather data to Apple.

Also Yahoo! under Marissa Mayer understands the importance of Apple’s platform as the number one mobile web consumer. I believe they will make a good match and with it Apple also gains some of the social aspects it has failed to build in the past with such miserable failures as Ping.


Apple began work on remodelling iTunes last year and I believe this work will continue. Eventually we will see them dramatically simplify the application by splitting it out into separate entities for Music, Video, Podcasts and Books. I don’t think this will happen this year, iTunes is simply to critical to Apple currently and the job it too big.

We have though already seen this start to happen on iOS, with the applications being split up but the iTunes app itself not being removed.

An improved iCloud should help towards this end goal and I think we will see Apple integrating iCloud more with iTunes this year.


One thing that will help any such iTunes refactoring come to pass is the rumored Pandora/Spotify/Rdio competitor iRadio. Every Indication is that this will be announced today, the required deals with big content appears to have been signed and all is ready.

I am still unsure about the rumor that this will be a free ad supported service. Going in that direction would be very unlike Apple and I certainly hope this is not true. At any rate I am happy with Rdio and will likely stick with them, though it would be handy to be able to access the big collection that such a streaming service provides from my AppleTV as it is connected to our sound system.


Safari after Google forked WebKit is in a position to clean up the WebKit codebase a lot, I hope this happens over the coming year. I also hope that Safari is radically simplified and becomes settings-wise more like Google Chrome. Mostly though I hope that Apple realizes that they need to decouple Safari from OS X and iOS and put it on a more rapid schedule to keep up with Firefox and Google Chrome. Doing this would show commitment to Safari and it would ensure that improvements get into users hands more rapidly.

WWDC 2013 - My hopes and predictions for hardware

Tomorrow is Apple’s big annual developer event, it is mostly going to be about iOS and OS X but the rumor mill is also predicting some hardware changes in the product line up.

The Macbook Air

It seems clear that we will see Macbook Air and Macbook Pro updates to Intel’s newly released Haswell chip. I would predict that these new models will be available either immediately at WWDC or right afterwards. Intel has a good push going for Haswell and I bet they have their fabrication ducks in a line to keep yield up to allow Apple to roll these out without any of the delays that last years iMac updates saw.

The Macbook Air is already pretty much as thin as we can make them with the technology and materials currently available.

I also doubt that Apple will be able to pull off putting a Retina display in the Air models this year as much as I would love to see it happen. I doubt they can keep the battery life without having to add more and/or better batteries into the form factor. They did do this to deliver the 3. generation iPad with a Retina display but I doubt it is possible for them to do just yet. There is also the problem that it would likely significantly raise costs and likely there would be a shortage of displays which would cause rollout delays Apple are likely keen to avoid after the iMac fiasco.

I predict the Macbook Air will stay non-Retina for another year and that it will stay in the same form factor. Due to the improvements Haswell brings to the table though it will be more powerful and likely last longer on battery.

The Macbook Pro

That leaves the which the Macbook Pro to make changes to. With last years introduction of the 15“ and 13” Retina models the line up now looks very visually distinct which is not really in Apple’s usual style. I predict they may want to unify these machines over time, likely to use the 15" Retina form factor.

If Apple decides to drop the discrete graphics from their Retina Macbook Pro machines they would likely to able to push in that direction. It seems likely that they could make those models slimmer and if that is the case I bet they will take the time to unify the look and feel. We are likely see going to see non-Retina models simply to keep affordable models in the line up but it is clear that Retina is the way Apple is going and the rest of the industry is following.

Any such change would depend on Apple being willing to trade off graphics performance by replacing the current generations discrete Nvidia chip with Intel’s new Iris integrated GPU. They would save power and while the new Intel chip is good, it still is not powerful enough to compete on the same level as the chip Nvidia currently supplies them with. It is however quite close in a number of places and even surpasses it in a few.

As a result gaming performance would go down but I expect that desktop performance would be close enough to the current generation to make no real difference.

I suspect Apple will be willing to make that tradeoff, they always had a thing for making thin, light and powerful machines. With an all Intel solution they would be able to deliver such an experience across their lineup (within reason on graphics performance) while completely removing the complicated and error prone graphics chip switching which happens in the current model to save power by changing from the Nvidia to the built in Intel.

The Mac Pro

I don’t think we will see the promised new Mac Pro, unless Apple replaces the Xeon style chips they traditionally have put in these machines for Haswell chips. That would mean a lower memory limit and the loss of dual CPU sockets. I am betting that they are holding out to deliver something later this year as soon as the needed hardware is available. Apple has also hinted that the Mac Pro upgrade will be completely different, and it is likely the machine that they will be assembling in the US.

The AppleTV

There has been much debate in the community on what Apple intends to do with their AppleTV hobby project. It currently has sold 13 million units and it is in my own experience a fantastic device. I personally love the remote to death and I have caught myself enjoying the feel of it in my hand more than is healthy.

The long term play with the AppleTV is likely going to be towards braod home entertainment but it would require more powerful hardware, developer access in the form of a SDK and a new controller (if they want to encompass gaming which I believe they do).

iOS is by the numbers one of the largest gaming platforms in existence already, and one can bring the iPad and iPhone screen to the TV via AirPlay over an AppleTV. This is though encumbered by a significant delay and isn’t really suitable for gaming.

To get gaming running I suspect Apple would need to beef up the AppleTV by adding more storage and more processing power for both graphics and processor. The Ouya shows us that ARM technology can support a console, though a fairly underpowered one compared to the Xbox One and Playstation 4.

The model Ouya espouses is yearly hardware upgrades at a 99$ price mark. This is currently what the AppleTV costs and being able to entice consumers to upgrade yearly with newer and faster models is very in line with Apple’s other businesses.

This would also allow Apple to iterate towards technology that is powerful enough to drive current AAA titles without having to spend years in development of a console that will have to last 5–8 years the way competitors do.

They already have an OS that is proven to be solid, performant and has a wide selection of games, many of which could likely be scaled to work with a separate wireless controller on the Apple TV. Add to this that the AppleTV also already has excellent media handling and a mature digital distribution channel in the form of the iOS App Store. Apple has on its hands a device that already has all the powerful media partnerships that its competitors are building and it has an existing gaming ecosystem as well as the service needed to drive it in Game Center.

So I think we might see an AppleTV model with increased storage, a quad core A6 derived chip and a bluetooth connected wireless controller (which will be sold separately at say 49–79$). I think these hardware increases are likely to mean that Apple will have to raise the price, but not by much, the device on its own could be a mere 149–179$ and still net Apple a handy profit.

Such a device would be significantly less powerful than the next generation consoles like the Playstation 4 that have been announced this year but it will be quite close to the current generation consoles so it is by no means crippled.

Apple will also be able to have quite a number of launch titles if they announce it now and have availability starting in a couple of months or if they have managed to sneak models out to selected developers in the past few months who have all kept their mouth shut. This is quite possible as we have just seen with the Xbox One and Playstation 4, both of which have significant titles announced without leaks. Apple are if anything even better at containing such leaks than Microsoft and Sony so it would not surprise me if they could pull that off.

Apple have also been hiring a lot of graphics chip designers which seems to indicate that they are aiming for some specialization in that area. On a console device one could deploy such technology with fewer concerns about power usage than on the iPhone or iPad, so I suspect over time we will see Apple deploying their most powerful hardware in the AppleTV in the future and working on scaling it to their portable devices from there.

I hope that we will indeed see an AppleTV upgrade at WWDC along with the release of an SDK for developers. Current AppleTV devices will likely be left out of the new world of apps and games, but such is life. A 149–179$ range upgrade will set things right and current AppleTV owners have never been promised anything except what we have been happy with uptil now. I know I would happily jump on the wagon immediately.

I think Apple can pull this off and it would certain broadside its competitors, as well as generating a new stream of income. All the pieces are there and the execution would be fairly classic Apple. It would also be a sign that Apple still can keep a secret and stun the world.

I do not believe the rumored iTV exists, it doesn’t make much sense compared to doing a home entertainment system like this. Convincing people to upgrade a home entertainment box yearly at <200$ is a lot easier than convincing them to do the same with a 2500$ TV. I also don’t believe Apple needs to make a TV to reinvent it or finally make it useful and less buggy. My own Phillips “smart” TV is certainly not without problems and nice as it is, it is far from smart - something the addition of my AppleTV makes up for.

The only question in my mind currently is if this will be a WWDC announcement or if they will hold a separate event for it. WWDC is a developer centric event and it will be packed with other announcements. This would also be so big that it would make sense to have a separate event dedicated to it.

The heart says WWDC, the brain says separate event but in the near future.

The iWatch

I think Apple have a wrist worn device in development. I also think that Tim Cook is right when he says that it has to have broader appeal than a current generation smart watch or any of the currently available wrist devices like the FitBit Flex or the Nike+ Fuelband which are essentially single purpose display less exercise aids to get people wearing them. Only a minority of the population wears a watch these days and convincing them to put something on their wrists will require it to be sensational.

I do not think we will see such a device at WWDC. The technology required for something as ambitious as the iWatch would have to be simply doesn’t appear to be quite there yet. I think this year belongs to the AppleTV, the iWatch I think is a surprise that will have to wait till next year at least.

Systemd in GNOME, PackageKit and what GNOME as an OS really means

Is the sky is falling? Is GNOME going Linux only?

recent proposal be PulseAudio and systemd lead developer Lennart Poettering to add systemd raised concerns that GNOME might drop support for non-Linux platforms.

Rest assure this is not the aim. Lennart in follow ups to his proposal explains that systemd could be separated into a core set of interfaces which could take replacement backends that support e.g. FreeBSD so long as it implements the interfaces systemd cares about or as it was their init system. What Lennart doesn't want is a lot of additional code in systemd as it is today to support these platforms as one of the main advantages is the simplicity and elegance obtained by relying on the functionality presented by Linux.

Why should we care about what systemd cares about?

Because systemd gives us a powerful set of tools to improve the user experience along the improvements promised and shown in performance and standardization (read Lennarts excellent series explaining systemd on his blog). With systemd we can replace some core functionality such as ConsoleKit which would allow for a smoother multi user experience.

Solving simple problems such as setting the pretty host name that gives your machine identity. Systemd strives to allow this now by standardizing on such things as where this data is stored and it what format. Fundamental assumptions about the system that will benefit the user experience.

Systemd goes beyond that, it's interfaces provides us a set of information and functionality which we can use to make GNOME more user friendly. E.g. systemd lets us provide a smooth experience via it's control group tracking of all processes. This allows balancing of CPU (and likely also IO) resources between applications making a system slow down more graceful and the overall experience smoother. This tracking also allows GNOME precise knowledge of these processes. data which might be used for improvements in how gnome-shell displays information to the user.

Shouldn't we wait depending on systemd till other platforms are supported somehow?

In honesty, resources are scarce and the truth is that the vast majority of developers and users of GNOME are on Linux. We have a reference implementation now on that most used platform and replying on it's interfaces would allow us to provide a superior user experience both short term and long term. Depending on ystemd only means depending on its interfaces and competing kernels can init systems could very well provide these interfaces as well. That effort is though on their shoulders but with apparent willingness to cooperate.

How this is analog to PackageKit longterm

Many people misunderstand PackageKit, mostly I suspect because they have had poor experiences with the default PackageKit user experience. PackageKit is not about these tools, PackageKit is about defining a common interface to talk to the package manager. This allows e.g. integration so that the system is requested to install support for missing formats if it is available. Common examples of these situations would be missing compression formats like .rar, missing codec support such as .mp3.

It is not about .deb vs. rpm, nor yum vs. apt-get!

PackageKit like systemd exist precisely to avoid those fights. The existing tools and package repos are excellent, what we care about is not replacing them but working with them in a consistent fashion. In PackageKit every package manager implements a backend which supports a common interface. In the same way that depending on systemd allows the assumption of a common set interfaces which can be used to enhance the user experience. There should be nothing technically baring an analog solution for systemd as what PackageKit has for separated backends.

But the PackageKit user interfaces are still ugly David!

That is true and it is widely agreed that the Ubuntu Software Center is a superb experience. It currently works not using apt-get directly but using an incompatible PackageKit fork aptdeamon. Porting this to PackageKit is being undertaken by Alex Eftimie under Google's Summer of Code 2011 so fear not you shall have the same experience as always, and it will be available on any GNOME platform. Naturally depending on completeness of PackageKit backend and existence, though most major distributions are covered to some degree.

Ubuntu's other tools such as the update experience are also aptdeamon tools and could be ported. My personal feeling would be that the better investment of resources would not be specifying GNOME3 stories for upgrades and updates in additions to the stories already told by PackageKit.

PackageKit and systemd are slow!

And I postulate to all that slow is a bug. In the case of systemd one of benefits should be performance an Lennart is already matching an Ubuntu Upstart powered 10 second boot. As I understand with patches to a standard Fedora 15 install and no LVM as I understand. PackageKit might have hard problems to solve to match what aptdeamon gives Ubuntu in terms of performance and certain features but Richard Hughes has shamed concerns before with actual hacking. I would trust him to solve this problem long term and reap the benefits of being allowed the assumptions PackageKit gives GNOME now.

GNOME as an OS is (partly) about interfaces, not defining a Linux only desktop that runs only on Thursdays if the window is open

Interfaces like PackageKit and systemd allow GNOME to solve problems and provide real improvements to the experience. The sad side effect of leveraging what the vast majority of GNOME users already have in Linux is short term that GNOME will be Linux only. Long term it is up to the competition to provide the same interfaces. This is no different than depending on Tracker or GTK+, these needed tools which provide the interfaces we need might not run on a given platform. Given resource constraints it must sadly fall upon these platforms to contribute in providing those required interfaces.

An adventure in Open Source contribution

I'm now officially a contributor to Banshee. While I have done a lot of advocacy work and packaging, this is my first ever proper code contribution to Open Source. Coding as such never really excited me and as a result it has been some 5 or 6 years since I last sat down to understand and work on significant code. Even then I never really got deep into programming as specification and design always was more fun to me than implementation.

It all started when a friend buzzed me a presentation by Anders Hejlsberg titled The Future of C#. While I haven't done much with .NET I have always been impressed by it as technology and I was eager to learn of what new tools would come in the future. Naturally the talk was also attractive to me because one of the features Anders demos (Compiler as a Service) as a coming post 4.0 release feature is in Mono today, something I always like to think about when people say that Mono forever will be "chasing the dragon". Regardless, the talk got me excited about coding and was extremely entertaining to boot. So I wanted to try something, anything, and since I like Banshee but also see it crashing and being slow a lot as a daily stress tester and bug filer I decided to subject it to experimentation.

In comes the magic of .NET, Mono, and Ubuntu. In Ubuntu I found all the tools I needed, namely MonoDevelop, mono-tools and finally Gendarme. Gendarme is a really cool project that can inspect assemblies and executables according to a set of rules for such things as security, performance and even bad practices. So I decided to run Gendarme on then content of /usr/lib/banshee-1 expecting to see a few hits and probably a lot of false positives. However Gendarme returned more than 8800 issues even on medium settings, so I limited my focus to just the performance rules set.

Gendarmes issue reports have excellent documentation with examples of bad and good code as well as careful explanations, making it easy to pick a simple problem such as the one addressed with my patch. In this case we now determine these variables at compile time rather than at link time which is faster. It is safe to do and doesn't break external assemblies as the fields are not shown outside. All of which was explained by Gendarme and confirmed on the Banshee IRC channel. Gendarme even explained how to fix the issue, it could not be easier. Bertrand Lorentz was kind enough to sign off the patch and commit it within minutes. As an example the Gendarme article on the issue type my fix addresses can be found here.

Regardless, that was yesterday. Today my Banshee is once again back to being a git build by hand which with the excellent Banshee daily repo hasn't been required since I stopped contributing to Fedora. The reason is simple, I needed to compile test some more changes as I was reading the Banshee source code and learning. With friendly hints from the existing developer base also growing some basic understanding of what is going on.

Contribution is easy, zero to sixty even, with Mono and Banshee.