Lessons learned
- Do not attach an RJ45 plug to a cable right above a laptop's keyboard.
- When ignoring the above, make sure you do the cutting somewhere else, so that the little pieces of throwaway cable do not fall on top of your keyboard.
- When ignoring the above, turn the laptop upside-down, rather than trying to push down one of the buttons in an attempt to more easily reach the little cable thing.
- Cable bits in a keyboard can really mess it up.
- Laptop keyboards are even worse to reassemble after removing the keys than are desktop keyboards.
- Attaching a space bar to a laptop keyboard is a horrible puzzle, which is likely to take you about an hour to figure out if you've never done so before. Once you have, though, and understand the procedure, it takes only a few minutes to do properly.
- Mail sucks. No, that's not related to any of the above, but it still does.
At least I didn't break any parts this time. Progress.
You know you've been doing too much m68k stuff...
... when you read about one product called "Q40" and think they mean another.
New toy.
On thursday, I bought me a digital camera; a Nikon D50. That's the cheapest DSLR camera they had at the shop where I bought it—they had models for prices going up to just under €7000. The latter obviously is "slightly" out of budget for me, but this one isn't bad, at all. I took some pictures with it on friday, and yesterday I went to "De Oude Landen", a local (and rather unique) piece of nature, to try out my new camera. Most of the pictures I took then were crap due to bad lighting; I guess I need to read the manual a bit more. We'll see. In any case, it's a fun piece of machinery, and it seems my long-lost photography sk1llz are coming back now (I did a photography course when I was a 13-14yo). Love it.
Roland Mas pointed out that f-spot is a great application to manage pictures, and I have to agree with him. Apart from the fact that it is a bit pedantically gnome-esque in its settings dialog ("settings, what's that? Oh, right, that's where you enable the screensaver"), it has a whole bunch of nice and interesting features, such as the ability to tag pictures, export them to CD or web-based applications, and more interesting stuff. A bit too much clickety-clickety, but then I guess it's impossible to design a good command-line based interface to manage graphical subject matters.
Setting up gallery on sarge is not even half as hard as I'd feared, either. Long live the Debian apache team.
So, yes, the above means I have a gallery online. Take a look if you care; I personally very much like this one.
A trainride at dusk
Dusk is getting pretty early this time of the year; a picture taken at 15:39 already has a low sun, with the sky getting kinda red around 16:28. Oh well.
Two days ago, I had forgotten my laptop's battery charger at home. So when it was empty, I didn't stay at the office; instead, I took the train home. At that specific time. I did have my camera with me, though, and taking pictures on the train is fun. It's not easy to do well; most of the pictures taken on the train are bad, but there are some exceptions.
Before I left, there was a nice light from the sun playing on the station platform. It took me a few attempts to get the exposure right (the first few were simply too dark), but this one has nice colors.
While the train was waiting in Antwerp Central station, I was playing with the camera's settings a bit; amongst others, I had totally miscalibrated the white balance setting. When it left again, I forgot to set the white balance back to what it was supposed to be, so the next few pictures were blue and ugly. Except this one—that is, it's blue, but not ugly.
When arriving home, I was greeted by this magnificent sky. I love this picture.
I did take some more pictures on the train; but like I said, it's pretty hard to do that well; and while I didn't throw all of them away, I don't think most of them were well suited to be put online.
click on any of the picture thumbnails to get larger versions.
Perfectism
For me to accept someone's claim that they are perfect, they have to back it up first. I discovered that I, too, am perfect—for the time being. I also discovered that currently, there are only 44 known perfect numbers. The 44th is, uh, slightly large.
wouter@country:~$ LC_ALL=C wget http://amicable.adsl.dk/aliquot/c1/perfx44.txt --10:54:31-- http://amicable.adsl.dk/aliquot/c1/perfx44.txt => `perfx44.txt' Resolving localhost... 127.0.0.1, ::1 Connecting to localhost|127.0.0.1|:3128... connected. Proxy request sent, awaiting response... 200 OK Length: 20,107,132 (19M) [text/plain]
Holy sweet smoking mother of Jezus.
(note, though, that the 20M characters include newlines every 80 (or so) characters. The 44th perfect number, which occasionally was discovered this year, has 19616714 digits. That's 19 million 616 thousand 714 digits)
Choir
Last week's sunday (that is, 2006-12-10), we had a concert with the choir. Rather than just singing four songs as we did during our "toonmoment", this time we had about an hour of music, spanning about everything (really) from the Renaissance up to modern music. Pretty fun, that. It went pretty well, too—except for one little note which we totally missed in the low end. But that's because it was really in the low end, and we had gone down a bit.
For those who care about that stuff, there's a (low quality) fragment of the video they made of the concert up on youtube, with us singing "Tourdion", a French Renaissance drinking song, which we opened the concert with—although this version is the one we did at the end, because people asked for another song. I stand at the far right, the last bass singer; at my left (your right), there are only altos. Occasionally, the first alto to my left happens to be Leen Verhelst, my sister, who's been in choirs mostly all her life.
Nope
0.0.0.0 is not the same thing as 127.0.0.1. You may get the same behaviour in some cases due to some implementation details, but that does not mean that both are the same!
127.0.0.1 means "The host this software is running on". In contrast, 0.0.0.0 means "Any host"; it can be used in software as the C constant "INADDR_ANY".
While it is true that connecting to 0.0.0.0 from software such as ping will yield the same result as connecting to 127.0.0.1, it is absolutely not true that listening to 0.0.0.0 (in a bind(2) kind of way) yields the same result as listening to 127.0.0.1. After all, in the latter case you will only accept connections that originate from localhost; in the former case, you will accept any connection, whether from localhost, the local network, or the big and evil Internet.
I presume you will have at least some firewall in between, but still.
That being said, however, 127.0.0.2 is an alias for 127.0.0.1. So is 127.0.1.0. And 127.255.0.1. And, really, anything in the 127/8 network range. Now that has no utility—there can be use in having a /24 reserved for loopback, but a /8? Who would ever need 16M ip addresses for the local host? Is there even an operating system that can keep track of that many IP addresses?
Oh well. not as if I care. And, after all, IPv6 has fixed that little issue. Although it might be fair to say that they overcompensated there a little bit.
Dunc-Tank, Debian, and crises in general
For those who've been hiding under a rock for the last few months: dunc-tank is the (controversion) project that was founded by the current DPL, Anthony 'aj' Towns. Controversial, because a lot of people feel that this goes against the spirit of Debian; and that by paying some Debian people and not paying others, we're creating a two-class system that we'd best avoid. And probably a bunch of other arguments, too, but that's not what this blog post is about.
Me, I've been staying rather quiet in the whole debate. It's not that I don't have an opinion; rather, I haven't been voicing it, mostly because my thoughts on the matter are rather convoluted, and I'm not sure I can put them in words pretty well. But since the debate seems to be going in circles, and since I think that I might be able to help it out, I'll try anyway. If that doesn't bring the debate any further, well—can't blame me for trying.
Do I think that paying people to do work on Debian is necessarily a bad idea? No, not at all. Quite to the contrary; by paying people to work full-time on Debian for a while, we will increase the amount of work that's being put into Debian, which can only be a good thing; and I can only applaud aj for trying to get this done, since it should be obvious to anyone involved that by proposing this, he only had Debian's best interests (i.e., improve our distribution) in mind. The obvious question, however, is who we'll be paying. After all, while I don't think it's necessarily bad to pay people, I do think that with money, you introduce the possibility for corruption; so at the very least, it should be strictly checked what exactly happens with the money that's being spent. Accordingly, the way in which you pay people—your whole set-up and procedures—should have a number of safeguards. Which brings me to my next point.
Do I think that dunc-tank, as a project, is a good idea? No, not at all. Quite to the contrary; and I have a number of reasons for that. First, I don't think that deciding by committee who can get paid and who can't is the way to go forward. A committee will always be biased, no matter how diverse its membership. Even if you could find a committee that would not be biased—an impossibility by definition—then there will still be people who will not agree with the committee's decision. Are they right not to agree? Not necessarily. Is it bad to create such controversy if it could be avoided? Sure as hell.
Moreover, by creating a project which populated by Debian people and which has the sole purpose of paying Debian people, it's fairly possible to create the impression as if all other ways to get paid to do Debian work would be unsound; that if a developer accepts money for Debian work without going through the committee, he's somehow doing something morally wrong. This would be very bad indeed; I know for a fact that there are cases of people paying Debian Developers to work a few days on a certain package so that a certain bug which impedes their business is fixed, or so that a certain version of a random package which this company is using, is uploaded into the archive. I've done this myself in the past (although I can't disclose more, since the person who paid me requested to remain anonymous); I know of at least two other Debian Developers who've done so as well.
So what's the alternative? Not paying people is one, but it would not necessarily be the best. One alternative, which the FreeBSD people have been doing, is just "no organization at all". People who want to get paid just put up a web page with the amount of money they would like to have, and it's up to the community to decide whether their request is valuable enough for it to actually be paid. To some extent, this is also what the Dunc-Tank committee is doing, except that as FreeBSD does it, there is no committee in between. The problem with this approach, however, is that if we all go ahead and ask for money at the same time, it'll not only make us look like a bunch of beggars; it's also very likely that nobody will actually be getting any money, because there's so many "good causes" to choose from that there might not be enough donations to fund them all.
Another proposal was one made by Manoj Srivastava, before word got out that dunc-tank would be started (or about at that time). As it was made on the debian-private mailinglist, I can't say much about that; suffice to say that I feel his proposal was overly bureaucratic, and had problems that were similar in nature to the problems I feel exist with dunc-tank.
So do I have any answers which might get us a way out of the current status quo? Nope, afraid not. But allow me to make this final observation:
In early 2005, a bunch of people decided that Vancouver was a nice place, and travelled there. As it happened, they were all Debian people. What a coincidence. Since they were all there anyway, they decided to talk a bit about Debian, and as a result, came up with some plan for its future. This plan, too, was rather controversial. When I initially read the first few paragraphs, I suddenly fell upon this paragraph which seemed to say that "we suspect we won't be releasing with anything but i386, amd64, and powerpc for etch". Things suddenly turned kinda red from then on. And it wasn't the wine that I hadn't been drinking.
I could imagine that what I felt back then is somewhat similar to what some other people felt when they first heard about the suggestion to pay people for Debian work; and this realization is the reason why I haven't been dismissing their arguments or thoughts, much like I've seen other people do. However, I cannot say that I feel the current crisis to have many parallels with the Vancouver one; this is mostly because in the current case, people on both side of the argument seem to be building up walls around themselves, to help them ignore whatever the other side was saying. In contrast, when someone suggested something which had the potential effect of throwing most of the hard work I'd been putting in for Debian during the last five years now down the drain, I went to talk with them—after the heat had cooled down, anyway. Unfortunately for me, the result is exactly the same; for all my effort, I haven't been able to prevent m68k to be kicked out of the release; and to say I'm not happy about this would be an understatement. But at least this way the port has been given a fair chance; if I hadn't been talking to the people on the other side of the argument, I would still be talking about Steve Langasek as if he were the devil himself, and m68k would probably have been kicked out of Debian—along with a bunch of other architectures. At least I got that bit fixed.
I guess what I'm saying is that people, rather than farting in eachother's general direction, should be working together in finding a compromise. Sure, that means making concessions, and agreeing to something you'd rather not agree to. But at least this way, the thing you have to agree to isn't as bad as what it could be. And trust me, people will do the stuff you don't want them to do, with or without your agreement. Hell, they've already started.
Whoa, long post. I'll stop preaching now.
NBD 2.9.1
I released the userland NBD tools of version 2.9.1 today, incorporating a fix for a minor memory leak (it would allocate memory for a hash table for each and every port on which nbd-server was going to listen, rather than just once for the entire server), and a fix for some piece of code which followed a null pointer (I had actually found that bug earlier, but forgot to commit the fix up to now). These were minor, but important, changes.
Of course only now do I see the mails from Mike Frysing (the Gentoo maintainer for the userland NBD tools) containing a number of build fixes. Had I seen them earlier, I could obviously have included them in the 2.9.1 release. Ghaah!
Lesson learned: check your mailbox before doing an NBD release.
Oh well.
On a side note, there's a pretty annoying and disgusting heisenbug in nbd-server, involving reliability. If you know stuff about mutexes (I don't) and are willing to help, here's a chance to be my personal hero.
Han shoots first
I had received some gift certificates for the Fnac for christmas, and also some plain money. So today I went there, and spent it on a few DVDs containing the Star Wars original trilogy.
Since this is the 2006 DVD release, it contains two versions of every movie: the original theatrical version, as it appeared in cinema at the time of their release, and the more "modern" version, which had some computer alterations to make the special effects be more stunning. And which led to the now infamous "Han shot first T-shirts.
The DVD also contains a commentary audio track for the modern version of the movie, as can be expected from most modern DVD sets these days. Intrigued about the fact that they actually went ahead and did another alteration on the movie just because fans were not happy with the new version, I switched on the commentary track and went ahead to the problematic scene 22. The commentary starts off with "There was a bit of controversy when I told everyone I was going to...", so one would think he's going to mention the whole 'Han Shot First' controversy. But he's not; he goes on with "... shoot this scene with subtitles"; the commentary during that scene simply explains how huttese (the language spoken by poor Greedo) came to be.
Why they had to do that there (instead of waiting until Jabba actually joins in), I don't know. They probably wanted to talk about something else there...
f-spot vs digiKam
Since I have been having a digital camera since a few weeks now, I've had a need for an application to manage my pictures. The two applications that people have pointed me to are f-spot and digiKam, which also seem to be the most popular applications in this category for Linux. Since I use neither KDE nor GNOME as my user interface, it doesn't matter much to me which I install; so I've tried them both. Their feature set is quite different; unfortunately, though, they both have some features which the other doesn't, which makes choosing for one or the other rather hard.
Since their on-disk format is rather different, it's impossible to use them both at the same time—at least not if I don't want to enter commentary and tags each and every time; so I'll have to choose one or the other based on their features. Since that requires me to actually compare them, I thought I might as well make a blog post out of that. Note, though, that this comparison is in no way intended to be complete; it only compares those features which I really care about.
Features
digiKam
- Stores pictures in
albums
; these albums can be created hierarchically, and are created on disk as the directory lay-out in which to store pictures. One picture can be chosen as anexample
picture per album. - Pictures can have tags, comments, and a score (on a scale of one to five stars) applied to them. Tags can be created hierarchically; the default tagset is empty. Tags can be made to have icons that are otherwise available to KDE attached to them, to make them more immediately visually recognizable, but selecting pictures to fulfill that function seems impossible.
- Has an interface to manage pictures in gallery and gallery 2; it can view, add, and remove pictures in that gallery.
- The selector dialog which is used to upload pictures is rather spartanic; it allows one to select pictures by filename and by album; pictures aren't even shown before upload (bug filed).
- Pictures can be filtered by tag, album, or date; I haven't been able to find an interface to filter pictures by score (it is possible to sort them by score in any view, though).
- A KDE application, so written in C++, which is a compiled language; i.e., rather fast.
F-spot
- Does not know the concept of
albums
- Pictures can have tags and comments applied to them. Tags can be
created hierarchically; the default tag set contains (amongst others)
People
,Places
, andEvents
, suggesting that f-spot encourages the use of tags where Albums would be used in the case of digiKam. Tags can have icons which are otherwise available to gnome selected as their icon, or one can select a picture to fulfill that function (in fact, it selects the first picture which receives a tag to do that by default) - Does not know the concept of scoring; instead, the default tagset
contains a tag
Favourites
, suggesting a scoring system with a binary scale. - Uploading pictures can be done by selecting them, and choosing the right option in the menu system. As a result, all filtering options otherwise available can be used to select which pictures to export (just filter the view, then select all pictures in the view).
- Uploading pictures will optionally also export comments that were applied to it.
- Since it does not know the concept of
albums
, pictures cannot be stored in a one-directory-per-album lay-out. Instead, pictures are stored in a one-directory-per-day layout, using a yyyy/mm/dd format. Unfortunately, this also means that no picture metadata (tags, comments) is easily available to command-line applications. - Apart from the ability to upload pictures to gallery or gallery 2,
does not interface with it in any way; gallery is a
write-only
storage medium to f-spot. - Written for mono, a system that requires a runtime environment to translate instructions at runtime from some sort of virtual machine code, and which uses garbage collection all over; i.e., rather slow, especially after you've been using it for a while.
My opinion
After having used f-spot for a few weeks before I tried digiKam, I
have to be honest and say that I don't like the concept of
albums
. They do not add value; everything they allow you to
express can equally well be expressed with tags. Additionally, one can
categorize a picture in only one album
, whereas it's possible to
categorize pictures in as many tags as you would want. Just creating one
album which contains all my pictures, with tagging used for
categorizing, doesn't help either; that way, digiKam would store all my
pictures in a single flat directory, which would become problematic when
the number in the picture filenames wraps around.
I do love the scoring thing in digiKam. A favourites
tag just
doesn't cut it; and creating five tags for scoring would make things
like find all pictures that have a score of three or above
rather
cumbersome, and sort by score
outright impossible. However, the
fact that it's not possible to filter by score makes it all rather
useless.
The export to gallery
function in digiKam is horrible. I have
to select my pictures blindly; none of the metadata which I tack on them
can be used to help select which pictures I want. Workaround: use
whatever filtering is available to select the right pictures and add
them to a temporary album from which I then upload all pictures, but
that's silly (and requires disk space for no good reason). Additionally,
there seems to be a bug in
the interface, which means that I have to babysit an upload (with no
workaround). And I can't even
view my pictures to spend the time waiting. Bah.
F-spot isn't without problems of its own. Due to a bug in mono, it crashes rather often on my PowerPC laptop. When that happens, it can't be restarted until the X server is restarted. Workaround: use Xnest, but that makes it impossible to view pictures in full-screen mode.
Also, since f-spot is a GNOME application, its options
dialog
is as helpful as a pair of soccer shoes when you're out swimming. No
surprises there.
Conclusion
Which one do I prefer? I'm not sure. The digiKam upload interface is
positively annoying, especially the bug which requires me to click
continue
after every picture. For that alone, I might ditch it.
On the other hand, it has a slew of interesting features (the scoring,
to name one) that f-spot lacks, and that pull me more towards
digiKam.
I guess I'll have to give it a few days of thought. But hey, at least I know where I stand now.