Tiles in the Topkapı Sarayı in İstanbul, Turkey. This time the symmetry is perfect. Thanks to Gimp.
One of the cupolas in the Topkapı Sarayı in İstanbul, Turkey. In one of the inner rings is a certain asymmetry. I wonder why?
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.