Discussions about KDE are source of endless fun.

Answering a question about openSUSE support for KDE3 to guy claiming that it will end soon, if it is not already stopped, I caught myself thinking that support will last for a quite long period.
KDE4 will be probably at version 4.4 when support for openSUSE 11.1 stops, and right now at version 4.2 it is already in a good shape for Joe the Plumber.

The whole pile of rants on opensuse@opensuse.org mail list is actually written by people that would like to run bleeding edge system that is stable. Wash me, but don't make me wet.

They complain because openSUSE 11.2 will not have KDE3, and claim time and again that is catastrophe, like support will end when 11.2 is released. Well, the KDE3 support in openSUSE will last till December 2010, just the same as for openSUSE 11.1. It is standard openSUSE practice to support each release for 2 years.

You know, we are serious distro.

Tomboy 0.14.1 Stable Release for Linux, Windows, and Mac OS X

I'm very proud to announce Tomboy 0.14.1, which represents the beginning of our stable support for Tomboy on all major desktop platforms. Here are some of the major changes since the 0.12.x stable versions:

• Tomboy is now fully supported on Windows and Mac OS X
  
• Printing has been rewritten using the Gtk.Print API, fixing many bugs
  
• 25% reduction in memory usage and slightly faster startup
  
• Significant memory savings with very large note collections
  
• Improvements to HTML Export add-in
  
• Improvements in note and URL linking
  
• Many fixes to note synchronization and D-Bus API
  
• Process now named "tomboy", not "Tomboy"
  
• No longer writes to disk every 40 seconds

All in all this has been a pretty great cycle for Tomboy. Windows support has been the most-requested Tomboy feature for awhile, and in fact some of my first work on Tomboy three years ago was to make it work at my old Windows-only job. The Windows version has generated interest from a whole new set of users, but most importantly to me, it has gained us several new contributors! Benjamin Podszun, for example, rewrote printing to remove our dependence on the obsolete libgnomeprint, then went on to fix several other bugs and to triage the rest. Since I am not generally a Windows user, it is important to be able to depend on contributors from that world to keep an eye on things.

The Mac port is a little less mature, and we will probably need to get more involved in in the GTK+ implementation on that platform to ensure solid support. Nevertheless, though there are quirks, we are happy to support Tomboy on Mac OS X, too.



If you are a GNOME Do user, you may currently be enjoying the wonderful Tomboy plugin, which provides instant access to your notes, and convenient creation of new notes.



With Tomboy 0.14.1 we have striven to create a solid base on which to build the future of Tomboy. Cross-platform support has given us new contributors and a cleaner code base. We have gotten rid of most of our use of obsolete GNOME APIs. We are off to a great start on profiling and making performance enhancements. Note synchronization is stable on all platforms. Now is the time to make Tomboy really shine.

Looking Forward

For Tomboy 0.16.0, we have a few more fun things planned. The community is having the planning meeting tomorrow, so we'll have our official roadmap soon, but some features I'm currently excited to work on are:

• Automatic note synchronization between Tomboy(s), G1, iPhone, and the web.
  
• Continued improvements to memory usage and overall performance, especially on startup (lots of low-hanging fruit here).
  
• Figuring out how best to integrate with gnome-shell, which currently has no specific plans for applet support (which means it's a great time for us to figure out how to make applets awesome in GNOME 3.0!).

The great thing is that most of this work is easy to do in parallel, so now is a wonderful time to join in the hacking.



A Note about Gnote

Some people have started asking about Gnote, Hubert Figuiere's line-for-line port of Tomboy to C++. Our stance on Gnote is that it is counterproductive to maintain identical software in two languages. It will be harmful to the community, especially as these two apps inevitably diverge. It will result in duplication of effort, duplication of bugs, and a lot of wasted time for those who are trying to add value to the user experience.

Tomboy is not going away, and it will continue to be developed on the extremely productive Mono/GTK# language platform. Anyone thinking about distributing Gnote should consider the impact on users and their data. When we develop, we should always be asking ourselves, "is this adding value for our users?"

Tomboy has a vibrant community, a happy relationship with GNOME, and an exciting future. If you'd like to help us out come to tomorrow's planning meeting, join us on our mailing list, or just start hacking!

This post brought to you by the Tomboy Blogposter add-in.

There hasn't been much encouraging happening the last weeks to write about, sorry. But let me summarize some points:

I have meanwhile released libgphoto2 2.4.5. Bugfixes, mostly for Nikon and Canon Capture code, first try at Nikon LiveView support, some under the hood fixes. Spotted some more problems in the meantime of course, so perhaps a new release soon.

Worked on libgphoto2 2.5 API stuff a bit, added a new trigger capture method (not really working well yet), and a CameraFile type for download_to_function(). Quite some work in PTP event handling.

Not much Wine work, but built releases 1.1.18 and 1.1.19 as usual.

Lots of security incident work currently, due to large input of issues. But nothing really noticable different than usual.

Last week after work I waited for the tram, listening to music on my earphones and was so tired and lost in thought that I did not notice the tram pulling up, but only as it left the station... Time for vacation I guess.

LinuxExpo is one of the biggest Czech Linux and open-source software events. It takes place every year in Prague and openSUSE project is for several years already one of the event regulars. In our openSUSE booth visitors can see and try the newest openSUSE release, get openSUSE DVD for free or buy a T-shirt. At the same time, talks and presentations of folks from Prague SUSE office are part of the event program.

This year, I also participated. With Miso Zugec, we had a joint talk on network-based installation and AutoYaST. Miso opened the talk by saying that for installing openSUSE on your machine neither you necessarily need any of the usual pre-requisities such as DVD, hard-disk or monitor, nor you have to spend 1 hour in cold server room clicking and answering installer's questions. He has shown some practical examples of how to use installation repository on network, install on iSCSI disk, or remotely via SSH or VNC.

I went on to introduce AutoYaST - a tool that comes in really handy when you install often, install lot of machines and you want to automate great part of the process. I introduced the basic concept of AutoYaST, showed folks the smallest AutoYaST profile in the world, how to clone your system and mentioned even some advanced AutoYaST usage, such as "<ask>" feature (a simple way of interactively asking for user input - such as root password or hostname - in the beginning of installation), or AutoYaST scripts.

In general, the talk was a success and I'm not saying that just because the presentation room (with ~100 seats) was so full that people had to stand on the corridor as they did not fit in. For me, much more significant measure was the number and meaningfullness of the questions people were asking in question time. At the end, I was really sorry that I did not have more time, so I could have introduced even more AY features, such as rules.

We spent the rest of the day in our openSUSE booth. To attract more visitors, a quiz question on openSUSE (Did you know when the openSUSE project was founded?  Or how many binary packages is there in our BuildService?) was published every hour or so and folks could submit their answers. At announced time, three correct answers were drawn and winners got openSUSE T-shirts, plush geekos and other presents.

Other open-source project also participated on the event. For example, our booth was just next to Ubuntu's one (it was funny to see how people used Ubuntu machines in there to google for correct answers to openSUSE questions :) ). All in all, Pavol has some interesting pictures from the event (these are from Day 1) and there is also an article on LinuxExpo on root.cz (in Czech only, I'm sorry).

P.S. root.cz could definitely benefit from hiring a better photographer ... and I'm not saying that just because I, unlike the photo, don't look like zombie in real life :D In general, much of the photos from the talks are of rather bad quality, considering the fact that you can do much better with my beloved Canon EOS 350D (which is what their photographer also had).

YaST, the openSUSE installation and configuration tool, is about to get a web based user interface.

The interesting part of this is the proposed service-oriented architecture. REST, Representational State Transfer, is currently the holy grail for managing resources (objects) using http.
REST is not a protocol but an architectural style making best use of the properties of http. And the Internet is the best proof that this style performs and scales well with a distributed client/server architecture.

Roy Fielding, one of the authors of the http protocol, has written a complete doctoral dissertation on this topic. For the purpose of this blog entry, seeing it as a lightweight alternative to e.g. XML-RPC or SOAP is sufficient.

How does it relate to YaST ?

As Stefan has explained on his blog before, a web based YaST will be splitted into client and server parts. This forms a three tiered architecture, where the server runs on the managed system and exposes a REST-style API to access YaST functionality.

Getting this API right in terms of extensibility, flexibility or conformance to REST best practices is an important design goal.

Now whats good REST style ?

There is no fixed list of requirements for REST or a conformance testing tool. Designing a well behaved REST implementation is mostly about learning from others experience and follow common practice.

Browsing through popular REST related bookmarks at delicious.com gives me a much better signal-to-noise ratio than Google. And it pointed me to a couple of useful references for the do's and dont's when planning a REST-style architecture.

1. REST APIs must be hypertext-driven
2. Versioning REST Web Services
3. Common REST Mistakes

Hypertext style

The first is the most interesting (IMHO). Its about exposing only a very limited set of explicit URIs. This also prevents hard-coding them into the client but let the client query the server instead. So you start from a single URI and hop from there (thats what hypertext is all about!) to the right resource. Thats like moving from node to node in a state diagram.

Versioning in media types

When doing API versioning on the web, one might be tempted to do an all-or-nothing approach and embed a version specifier (like .../v1/...) into the URL. The second link above explains why this is a bad idea and comes up with a better one: media types. The client can tell the server how to format the response to an http request by setting the Accept field in the http header. Its like calling a function and telling it the expected return type.

And REST explicitly supports this style as it does not make any assumption on the representation of a resource. Client and server are free to agree on the actual format. Using XML for object serialization is a smart move as it allows for extensibility. Clients just pick the xml tags they need and ignore all others.

Stateless

REST, being based on http, stipulates a stateless protocol. Doing stateful REST is listed as one of the typical mistakes in implementing REST-style.
Considering the proposed YaST web architecture, this means keeping state (session) information in the client and not in the server.

More recommended reading

• How to Create a REST Protocol
• Explaining REST to Damien Katz
• Roger L. Costello: REST

Having a few days holiday, we decided to visit something here in UK, so we went to Liverpool and Knowsley Safari Park.

"Knowsley Safari Park has become one of Merseyside's premier leisure attractions, winning several awards for tourism and it's animal husbandry."

"These days Knowsley's 500 mammals include rhinos, camels, buffalo, bison, wildebeest, lions, tigers, zebra, baboons, monkeys, deer, antelopes and wallabies."

It was a great weekend a lot of photos are available on my Flickr gallery: Liverpool and Knowsley Safari Park set.

Last week i became a gnome-do fan. That make me also use it for a Twitter client.
Now you can follow me on Twitter.

Today i've just released Brasero 2.26.1.

I'm trying to write an Android game, but I've been rather addicted to playing KNetWalk, which is slowing me down somewhat. I'm getting fast at KNetWalk though - I just did the Very Hard level in 59 seconds without any penalties. I think I might give up now, although I reckon I could probably do it in 50 seconds if I was very lucky.