Today I discovered Dropbox, an online storage and synchronization tool. It offers 2 GB of free storage to its users and is available for Mac OS X, Windows and Linux. I’ve tested it on Linux and Windows so far and it’s working great. If you’re tired of carrying around USB sticks to share files between different workstations, be sure to check it out. Hint: by clicking on the link above you (and me) will get 250 MB of free online storage as a bonus.

Installation and Setup on openSUSE 11.1 is a breeze

• 1-click install is available in Gnome:Community
• Logout from your GNOME Session and login again
• Run “Dropbox” from the GNOME menu to link your workstation to your Dropbox account

Currently there’s a plugin for nautilus available. Hopefully some KDE coders more experienced than me will come up with a Dolphin plugin soon. Where the Dropbox daemon is proprietary software, the nautilus plugin is released under GPL and its sourcecode should provide the required information about the Dropbox daemon’s API to port it to KDE/Dolphin as well.

Have fun!

During the fall, Olivier showed up on tomboy-list announcing a school project he would be working on: Tomdroid, a Tomboy note reader (and eventually editor) for the Android mobile platform that drives the wonderful G1 phone. After a few months of development, the first "baby-eating" release is available for testing. Olivier mentions a number of nasty little bugs in this first release, but he is already working on fixing them, and people are already starting to poke around with the code and find ways to help.


Obviously, having access to your Tomboy notes on your mobile phone is a huge win. Even when they are read-only, you can:

• Access your grocery list without having to call your wife (which only proves that you weren't listening in the first place)
  
• Quickly access your notes about obscure system configurations when visiting a client site, instead of googling (ever worked for a client who stood over you shoulder, and wasn't too impressed by your frequent googling?)
  
• For me, I often forget to add contacts and calendar events until I am repeatedly burned, but it's pretty common to have that info floating around in my Tomboy notes.
  
• And the number one win: you can have the schizophrenic dude next to you on the bus review the draft of your latest blog post (this keeps him busy, making it less likely he will stab you in the face)

See? Tomdroid just saved your life.

As a G1 owner, I'm extremely excited about this project. I downloaded the Android SDK just so I could start playing around with the code. Olivier has communicated extensively with us on tomboy-list and in #tomboy, and one of the really nice things he's done is initial work on an XML schema for the Tomboy note format. This will be extremely useful to maintain, as it is inevitable that Tomboy notes will being to be read and edited via interesting new clients.

If you're looking for a fun (because it's Tomboy-related) and hip (because it's mobile) project to work on, I recommend spending some time with Tomdroid. New projects are always fun, for example you could work on tighter integration with phone features (like phone numbers, contacts, calendar, and web), or you can start playing with note editing (maybe a nerdy markdown editor would be a good fit?).

Ideas for getting your notes onto your G1:

• Manually copy ~/.tomboy/*.note to your G1 periodically. Verdict: Lame
  
• Write Tomboy add-in that hooks into HAL, notices when a G1 is connected, offers to push notes to phone (could be a button that appears in the note toolbar, a libnotify bubble, or even a totally automatic process). Verdict: Instant win, minus the requirement to plug in your phone.
  
• Implement Tomboy online service, and corresponding sync functionality in Tomdroid. Verdict: Epic win, may not be ready for a few months.

Those are great ideas. While drafting this post last night I really liked the second one, so here you can download my quick hack job that Gets It Done. Drop Tomdroid.dll into ~/.tomboy/addins, or `make && make install`. Many thanks to James Wilcox for his incredible vision and Aaron Bockover for all the Banshee code I stole to make interacting with HAL devices brain-dead simple. Right now you just get an item in the Tools menu in the note window, but clearly there are better things that could be done. Patches welcome, I'll dump this into git as soon as I get rid of the excess Banshee code I brought in.

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

As you may know, SUSE was originally based on Slackware. And some some relics from those early days if SUSE survives to present. The biggest example visible for end-users was packaging of desktop environment to /opt. Gnome was switched few years ago and KDE3 packages still remains in it, because packagers decided to focus on KDE4, so only those packages are comfortable with FHS and are installed into /usr.

With opening of SUSE development towards community via BuildService’s collaboration, or Contrib, the another relict of Slackware days was raised – which I mentioned in my previous post – a .changes file.

This file is used in SUSE for tracing of package changes and rpm %changelog is created from this file during build. As it has a consistent format, we used an internal command called vc for add a new entry to it and this tool generates a proper header of changes file. So after my last patch, implementation of osc vc was a logical (but not straightforward) job.

After some discussions with Ludwig Nussel and on opensuse-buildservice mailing lists, I implemented and committed an osc vc command. This is based on buildvc script written by Ludwig and is available in build.rpm (from version 2009.04.17). It has the same behavior as an old vc command.

Basic usage of this command is simple:

user@host:some:project/package/ $ osc vc

Command will find a changes file, open it in EDITOR (default is vim) and fill a header. You can also use it in non-interactive mode using -m MESSAGE. You can also specify a file to edit, or edit a file in other directory than current, … – see osc vc –help

The main difference between buildvc and osc variant is in e-mail address handling. The osc implementation has more sources of it, so it try to

1. use content of mailaddr variable (same as buildvc)
2. read a configuration from ~/.oscrc
3. read an email from user’s metadata (see osc meta user your_login)

This is because many users want to use a different e-mail for changelogs than iChain one, so osc allows configure an email for each instance of BuildService. Appropriate part of ~/.oscrc looks like

[https://api.opensuse.org/]
user = login
pass = password
email = user@defined.email

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