Conference organizers! Be attentive to the signs of times! There's a trend towards smaller laptops. Don't hand out laptop bags where those newer laptops (such as the X60) fits in two or more times! Lighter is better!
A while ago I posted a story on my blog which then appeared on Fedora Planet. In it I expressed my doubts on the usefulness of the planet, due to its low signal-to-noise ratio, due to the babel-like mix of languages. As a response to this posting I got a lot of really dumb comments, both directly on the blog story and by email. I was called "intolerant", a "Nazi", "stupid", that I should "revise my geography", that I should go "fuck myself", that I apparently thought that the "world was USA property" [1]. Back then I thought that there were just a few morons in the peripherals of the community. But now, since this incident happened I started to wonder if we might actually have a bigger problem in the community.
I guess this is a good opportunity to pimp David Arlie's alternative Fedora aggregator which I find a very useful replacement for Fedora Planet.
Footnotes
[1] I am wondering though why people think that I am a monoglot american? I am not. Neither monoglot, nor american. And if suggesting that I was was intended as an insult, then I can only say that it insulted me far less than the insulter might have thought...
Last weekend I set myself the task to write an ATA S.M.A.R.T. (i.e. hard disk health monitoring) reader and parser. After spending some time reading all kinds of T13 and T10 docs and a bit of hacking I now present you the following new software:
- libatasmart: a lean, small and clean implementation of an ATA S.M.A.R.T. reading and parsing library. It's fairly comprehensive, however I only support a subset of the full S.M.A.R.T. set of functions: those parts which made sense to me, not the esoteric stuff. Here's the API and here's the README.
- skdump: a little tool that produces a similar output to smartctl -a, but uses libatasmart.
- sktest: a little tool for starting/aborting S.M.A.R.T. self-tests, based on libatasmart
- gnome-disk-health-service: a little wrapper around libatasmart that exports its entire functionality via D-Bus, so that unpriviliged processes can introspect a drive's health records, including temperature, number of bad sectors and suchlike. This is written in Vala, which BTW is awesome for doing D-Bus services. Actually after having done this once now I really hope I will never have to write a D-Bus server without Vala again. I also wrote a Vala .vapi file for libatasmart which is shipped in its tarball.
- gnome-disk-health: a little tool that reads the S.M.A.R.T. data from g-d-h-s and presents it in a pretty dialog. Includes support for viewing attributes and starting self-tests and stuff. Also written with Vala.
Why? You might ask what the point of all this stuff is where smartmontools already exists. What I'd like to see on future GNOME desktops is that as soon as a disk starts to fail a notification bubble pops up warning the user about this fact, and suggesting that he makes backups and replaces the disk. For a tight integration into the desktop, a S.M.A.R.T. implementation that is small, and not C++, and a library (i.e. embeddable into other software with a sane interface) is highly preferable. Also, stuff like distribution installers should link against libatasmart to warn the user about old, and defective disks before he even starts the installation on them. (Hey, anaconda developers! That means you! It's a tiny library, and all you need to do is a single call: int sk_disk_smart_status(SkDisk *d, SkBool *good);)
Please note that I certainly don't plan to replace smartmontools. libatasmart will always implement only a subset of S.M.A.R.T. If you want the full set of functionality then please refer to smartmontools.
Where's this going? I plan to fully maintain libatasmart (including skdump and sktest) for the future. However g-d-h and g-d-h-s will probably just bitrot in my repository -- unless someone else wants to pick this up and maintain it. The reason my further interest in those tools is rather limited is that for the long run we will hopefully will see davidz's DeviceKit-disks (screenhot) changed to use this library for health monitoring. Then DK-d will export the S.M.A.R.T. info on the bus, and a separate daemon would not be necessary anymore. DK-d provides a single interface for all kinds of health parameters for storage, including RAID health and suchlike. I thus think this is the way forward and not g-d-h-s. (That should, of course, not hinder anyone to step up and take up maintainership of g-d-h/g-d-h-s if he wants to. There might be good reasons for doing so. Maybe because you need something to do, or because you want a S.M.A.R.T. solution for the desktop now, and not wait until DeviceKit gets pushed into all the distros).
So, here's where you can get this stuff:
git://git.0pointer.de/libatasmart.git
git://git.0pointer.de/gnome-disk-health.git
I will roll a 0.1 tarball of libatasmart soon. I'd be thankful if people could run skdump on their disks and check if its output is basically the same as smartctl -a's. Especially people with BE machines.
Of course the most important part of a software announcement is always the screenshot:
return -ETOOMANYDOTS;
Here's what I have to say about today's state of version control systems in Free Software:
We shouldn't forget that a VC system is just a development tool. Preferring one over the other is nothing that has any direct influence on code quality, it doesn't make your algorithms perform any better, or your applications look prettier. It's just a tool. As such it should just do its job and get out of the way. A programmer should have religious arguments about code quality, about algorithms or about UIs, but what he certainly should not have is religious arguments over the feature set of specific VCSes[1].
Does this mean it doesn't matter at all which VCS to choose? No, of course it does matter a lot. The step from traditional VCSes to DVCS is a major one, an important one. Starting a fresh new Free Software project today and choosing CVS or SVN is anachronistic at best.
Which leaves of course the question, which DVCS to pick. If you take the "get out of the way" requirement seriously than there can only be one answer to the question: GIT. Why? It certainly (still) has a steep learning curve, and a steeper one than most other VC systems. But what is even harder to learn than GIT is learning all of GIT, Mercurial, Monotone, Bizarre^H^H^H^H^H^H^HBazaar, Darcs, Arch, SVK at the same time. If every project picked a different VCS system, and you'd want to contribute to more than just a single project, then you'd have to learn them all. And learning them all means learning them all not very well. And needing to learn them all means scaring people away who don't want to learn yet another VCS just to check out your code. Fragmentation in use of VCSes for Free Software projects hinders development.
Which brings me to the main point I want to raise with this blog story:
It is much more important to make contributing to Free Software projects easy by choosing a VCS everyone knows well -- than it is to make it easy by choosing a VCS that everyone could learn easily.
So, and which VCS is it that has a chance of qualifying as "everyone knows well" and is a DVCS? I would say there is only one answer to the question: GIT. Sure, there are some high-profile projects using HG (Mozilla, Java, Solaris), but my impression is that the vast majority of projects that are central to free desktops do use GIT.
Certainly, some DVCSes might be nicer than others, there might be areas where GIT is lacking in comparison to others, but those differences are tiny. What matters more is not scaring contributors away by making it hard for them to contribute by requiring them to learn yet another VCS.
Yes, with CVS, SVN and GIT I think I have learned enough VC systems for now. My hunger for learning further ones is exactly zero. Let me just code, and don't make it hard for me by asking me to learn your favourite one, please.
Or in other, frank words, if you start a new Open Source project today, and you don't choose GIT as VCS then you basically ask potential contributors to go away.
ALSA recently switched from Mercurial to GIT. That was a good move.
So, please stop discussing which DVCS is the best one. It doesn't matter. Picking one that everyone knows is far more important.
That's all I have to say.
Footnotes
[1] Of course, unless he himself develops a VC system.
And here's a another conference CFP, this time for Foundations of Open Media Software 2009 (FOMS). It's simply the best conference about multimedia on free systems. Period.
It's the third iteration now, and the first two were plain awesome, so don't miss this one. It happens in Hobart, Tasmania, next to linux.conf.au 2009.
Send in your paper! Attend! Spread the word!
The Call for Papers for the Linux Plumbers Conference in September in Portland is out now. It's a conference about the core infrastructure of Linux systems: the part of the system where userspace and the kernel interface. It's the first conference where the focus is specifically on getting together the kernel people who work on the userspace interfaces and the userspace people who have to deal with kernel interfaces. It's supposed to be a place where all the people doing infrastructure work sit down and talk, so that each other understands better what the requirements and needs of the other are, and where we can work towards fixing the major problems we currently have with our lower-level APIs.
I am running the Audio microconf of the Plumbers Conference. Audio infrastructure on Linux is still heavily fragmented. Pro, desktop and embedded worlds are almost completely seperate worlds. While we have quite good driver support the user experience is far from perfect, mostly due because our infrastructure is so balkanized. Join us at the Plumbers Conference and help to fix this! If you are doing audio infrastructure work on Linux, make sure to attend or -- even better -- submit a paper!
Sign up soon! Send in your paper early! The conference is expected to sell out pretty quickly!
See you in Portland!
Yesterday I did the final steps to convert all my SVN repositories to GIT (including Avahi and PulseAudio). I had been running hot GIT mirrors of the SVN repositories for quite a while now. The last step was the switch to make them canonical upstream, and to disable the SVN repos.
For future Google reference, here are the steps that are necessary to make an SVN GIT mirror into a proper GIT repo:
# On the client: $ git clone ssh://..../git/foobar foobar $ cd foobar $ git checkout trunk $ git branch -m master $ git push origin master # This is a good time to edit the HEAD file on the server and replace its contents "ref: refs/heads/trunk" by "ref: refs/heads/master" $ git push origin :trunk
This will basically replace 'trunk' by 'master', and make it the default when clients clone the repository. This will however not rename tags from the git-svn style to the GIT style. (Which I personally think would be a bad idea anyway, BTW)
Removing the origin from the server's config file is a good idea, too, since the repo is now canonical upstream.
Of course, afterwards you still need to create proper .gitignore files for the repositories. Just taking the value of the old svn:ignore property is a bad idea BTW, because .gitignore lists patterns that are used for the directory it is placed in and everything beneath, while svn:ignore is not applied recursively.
And finally you need to remove all those $Id$ lines and suchlike from all source files since they are kind of pointless on GIT. It is left as an excercise to the user to craft a good sed or perl script to do this automatically and recursively for an entire tree.
Lazyweb, do you have a good idea how to integrate mutt and git-am best? I want a key in mutt I can press which will ask me for a GIT directory and then call git-am --interactive for the currently selected email. Anyone got a good idea? Right now I am piping the mail from mutt to git-am. But that sucks, because --interactive refuses to work called like that and because I cannot specify the git repo to apply this to.
OK, before more people complain that I didn't keep the KDE in the loop about all that fancy event sound infrastructure work. The complaint is only partially valid: stuff like the sound specs have been seen before by the KDE guys. And for the rest it's just better to have something concrete to discuss about first instead of just starting an unfocussed discussion about all the grand plans we might have without ever having looked into actually implementing them.
Shortly after I posted that last blog story of mine I informed the KDE guys about this, and asked for their comments and suggestions. And this is my summary of those dicussions.
Let's have a small poll here: what is the most annoying feature of a modern GNOME desktop? You got three options to choose from:
- Event sounds, if they are enabled
- Event sounds, if they are enabled
- Event sounds, if they are enabled
Difficult choice, right?
In my pursuit to make this choice a little bit less difficult, I'd like to draw your attention to the following six announcements:
Announcement Number One: The XDG Sound Theming Specification
Following closely the mechanisms of the XDG Icon Theme Specification I may now announce you the XDG Sound Theme Specification which will hopefully be established as the future standard for better event sound theming for free desktops. This project was started by Patryk Zawadzki and is now maintained by Marc-André Lureau.
Announcement Number Two: The XDG Sound Naming Specification
If we have a Sound Theming Specification, then we also need an XDG Sound Naming Specification, again drawing heavily from the original XDG Icon Naming Specification. It's based on some older Bango work (which seems to be a defunct project these days), and is also maintained by Monsieur Lureau. The list of defined sounds is hopefully much more complete than any previous work in this area for free desktops.
Announcement Number Three: The freedesktop Sound Theme
Of course, what would the mentioned two standards be worth if there wasn't a single implementation of them? So here I may now announce you the first (rubbish) version of the XDG freedesktop Sound Theme.. It's basically just a tarball with a number of symlinks linking to the old gnome-audio event sounds. It's only a very small subset of the entire list of XDG sound names. My hope is that this initial release will spark community contributions for a better, higher quality default sound theme for free desktops. If you are some kind of musician or audio technician I am happy to take your submissions!
Announcement Number Four: The libcanberra Event Sound API
Ok, we now have those two specs, and an example theme, what else is missing to make this stuff a success? Absolutely right, an actual implementation of the sound theming logic! And this is what libcanberra is. It is a very small and lean implementation of the specification. However, it is also very powerful, and can be used in a much more elaborate way than previous APIs. It's all about the central function called ca_context_play() which takes a NULL terminated list of string properties for the sound you want to generate. How this looks like?
{
ca_context *c = NULL;
/* Create a context for the event sounds for your application */
ca_context_create(&c);
/* Set a few application-global properties */
ca_context_change_props(c,
CA_PROP_APPLICATION_NAME, "An example",
CA_PROP_APPLICATION_ID, "org.freedesktop.libcanberra.Test",
CA_PROP_APPLICATION_ICON_NAME, "libcanberra-test",
NULL);
/* ... */
/* Trigger an event sound */
ca_context_play(c, 0,
CA_PROP_EVENT_ID, "button-pressed", /* The XDG sound name */
CA_PROP_MEDIA_NAME, "The user pressed the button foobar",
CA_PROP_EVENT_MOUSE_X, "555",
CA_PROP_EVENT_MOUSE_Y, "666",
CA_PROP_WINDOW_NAME, "Foobar Dialog",
CA_PROP_WINDOW_ICON_NAME, "libcanberra-test-foobar-dialog",
CA_PROP_WINDOW_X11_DISPLAY, ":0",
CA_PROP_WINDOW_X11_XID, "4711",
NULL);
/* ... */
ca_context_destroy(&c);
}
So, the idea is pretty simple, it's all built around those sound event properties. A few you initialize globally for your application, and some you pass each time you actually want to trigger a sound. The properties listed above are only a subset of the default ones that are defined. They can be extended at any time. Why is it good to attach all this information to those event sounds? First, for a11y reasons, where visual feedback in addition of audible feedback might be advisable. And then, if the underlying sound system knows which window triggered the event it can take per-window volumes or other settings into account. If we know that the sound event was triggered by a mouse event, then the sound system could position the sound in space: i.e. if you click a button on the left side of the screen, the event sound will come more out of your left speaker, and if you click on the right, it will be positioned nearer to the right speaker. The more information the underlying audio system has about the event sound the fancier 'earcandy' it can do to enhance your user experience with all kinds of audio effects.
The library is thread-safe, brings no dependencies besides OGG Vorbis (and of course a Libc), and whatever the used backend requires. The library can support multiple different backends. Either you can compile a single one directly into the libcanberra.so library, or you can bind them at runtime via shared objects. Right now, libcanberra supports ALSA, PulseAudio and a null backend. The library is designed to be portable, however only supports Linux right now. The idea is to translate the XDG sound names into the sounds that are native the local platform (i.e. to whatever API Windows or MacOS use natively for sound events).
Besides all that fancy property stuff it also can do implicit on-demand cacheing of samples in the sound server, cancel currently playing sounds, notify an application when a sound finished to play and other features.
My hope is that this piece of core desktop technology can be shared by both GNOME and the KDE world.
Check out the (complete!) documentation!
Announcement Number Five: The libcanberra-gtk Sound Event Binding for Gtk+
If you compile libcanberra with Gtk+ support (optional), than you'll get an additional library libcanberra-gtk which provides a couple of functions to simplify event sound generation from Gtk+ programs. It will maintain a global libcanberra context, and provides a few functions that will automatically fill in quite a few properties for you, so that you don't have to fill them in manually. How does that look like? Deadly simple:
{
/* Trigger an event sound from a GtkWidget, will automaticall fill in CA_PROP_WINDOW_xxx */
ca_gtk_play_for_widget(GTK_WIDGET(w), 0,
CA_PROP_EVENT_ID, "foobar-event",
CA_PROP_EVENT_DESCRIPTION, "foobar event happened",
NULL);
/* Alternatively, triggger an event sound from a GdkEvent, will also fill in CA_PROP_EVENT_MOUSE_xxx */
ca_gtk_play_for_event(gtk_get_current_event(), 0
CA_PROP_EVENT_ID, "waldo-event",
CA_PROP_EVENT_DESCRIPTION, "waldo event happened",
NULL);
}
Simple? Yes, deadly simple.
Check out the (complete!) documentation!
Announcement Number Five: the libcanberra-gtk-module Gtk+ Module
Okey, the example code for libcanberra-gtk is already very simple. Can we do it even shorter? Yes!
If you compile libcanberra with Gtk+ support, then you will also get a ne GtkModule which will automatically hook into all kinds of events inside a Gtk+ program and generate sound events from them. You can have sounds when you press a button, when you popup a menu or window, or when you select an item from a list box. It's all done automatically, no further change in the program is necessary. It works very similar to the old sound event code in libgnomeui, but is far less ugly, much more complete, and most importantly, works for all Gtk+ programs, not just those which link against libgnomeui. To activate this feature $GTK_MODULES=libcanberra-gtk-module must be set. So, just for completeness sake, here's how the example code for using this feature in your program looks like:
{
}
Yes, indeed. No code changes necessary. You get all those fancy UI sounds for free. Awesome? Awesome!
Of course, if you use custom widgets, or need more than just the simplest audio feedback for input you should link against libcanberra-gtk yourself, and add ca_gtk_play_for_widget() and ca_gtk_play_for_event() calls to your code, at the right places.
Announcement Number Six: My GUADEC talk
You want to know more about all this fancy new sound event world order? Then make sure to attend my talk at GUADEC 2008 in Istanbul!
Ok, that't enough announcements for now. If you want to discuss or contribute to the two specs, then please join the XDG mailing list. If you want to contribute to libcanberra, you are invited to join the libcanberra mailing list.
Of course these six announcements won't add a happy end to the GNOME sound event story just like that. We still need better sounds, and better integration into applications. But just think of how high quality the sound events on e.g. MacOS X are, and you can see (or hear) what I hope to get for the free desktops as well. Also my hope is that since we now have a decent localization infrastructure for our sounds in place, we can make speech sound events more popular, and thus sound events much more useful. i.e. have a nice girl's voice telling you "You disc finished burning!" instead of some annoying nobody-knows-what-it-means bing sound. I am one of those who usually have there event sounds disabled all the time. My hope is that in a few months time I won't have any reason more to do so.
Until yesterday Ohloh was the only social network site I was a member of. That changed now. I joined DOPPLR. It's pretty nice. Very Web 2.0, but in the good way. Free Software people, join now!
No, nobody paid me for writing this, I just think it is indeed useful.