After a lot of thought how many and what kind of monitors to put on my desk, I finally ended up buying two of those:

They're 20 inch at 1400x1050 pixels and the one I've put up today looks pretty nice. I was originally planning to get a 20" widescreen (1680x1050) and an ordinary 20" (1400x1050) but it turns out (it's not exactly a surprise, come to think of it) the pixel mask is very different, so it would look plain weird in a dual screen scenario. And two widescreens next to each other might give the word "rubberneck" a whole new meaning.

I'm considering getting a widescreen monitor at home, though. With the cheap TFT prices here it's hard to stay below 22" and not to buy them by the dozen. Can you say Swordfish? :-)

Today was the first day of Taiwanese WinHEC, so the Logitech driver team took a little field trip to Taipei--except for the lucky people who got to go to WinHEC in Los Angeles. :-)

So far, it's pretty interesting and I'm learning plenty of new stuff, although not necessarily in great detail. Some of the demos are really impressive but after seeing Vista fail miserably in my personal test I'm very suspicious of some of the things I see "work great".

Anyway, here are two photos I took in the conference center:

Who would have guessed Microsoft would display the products of their hardware division's biggest competitor ...

Things are finally calming down a little bit here in Lausanne. I've moved into my apartment last Saturday. (Aren't those supposed to get bigger once you get out of school and start a job?) Because it's about 11 km away from Romanel-sur-Morges where I work and I refuse to give in to public transportation one of my favorite pastimes is eating.

When I'm not eating I'm enjoying work at Logitech. Mainly reading up on driver development (Windows this time) and trying to get organized.

Two things positively surprised me about Logitech Switzerland, one of them has to do with Logitech and the other with Switzerland.

1. The cafeteria actually serves good food. You know, real menus with healthy vegetables instead of rare-cooked hamburgers that make you sick for the rest of the day. (Hello, Fremont cafeteria ...)

2. I know nobody's last name. Cause I don't have to. Just like in Fremont, people call each other by their first names. No "Monsieur" or "Madame". I was really expecting the typical uptight Swiss attitude there. I hope this spreads out to other European companies!

Not really surprising but nontheless positive is the fact that I have fancy keyboards and mice, e.g. one of these. (Yes, the diNovo Edge works fine even on Linux, it's recognized as two HID devices.) Working on consumer devices is just so much more fun to than sitting in the basement of a bank. ;-)

There were a few other things I wanted to mention but I seem to have forgotten. A clear sign to make three steps to the right and go to bed.

It's amazing how carefully some people do research for their papers. Here's an interesting excerpt I found in a paper from the Rhodes University in South Africa that compares the Windows and Linux driver models:

"Linux is a clone of the UNIX operating system first created by Linux Travolds [Linus FAQ, 02] ..."

(Note the spelling of the name of the Linux author.) The bibliography entry reads like this:

[Linus FAQ, 02] The Rampantly Unofficial Linus Torvalds FAQ, http://www.tuxedo.org/~esr/faqs/linus/index.html, 2002.

If the authors can't even get a simple name right, do I really want to trust the rest of the paper treating the highly complex topic of driver architecture? I don't think so.

PS: Okay, he did fix it for his thesis ... ;-)

Remember the time I said good-bye to Lausanne? Well, apparently all roads don't lead to Rome but back to Lausanne.

I will start out my new position as Video Software Engineer at Logitech in Romanel-sur-Morges until the end of December. Therefore, I will once again be living in Lausanne, albeit only for four weeks. At least that should give me time to get over the weather shock I suffered in sunny California. ;-)

People are moving here in Fremont.

I moved to a new cube at Logitech two days ago, away from people who make fun of interns and closer towards people who make fun of Linux.

Today Thomas also moved. From a cozy (ok, there's still not much more than a desk and two chairs but you get the idea) home into the cold, dangerous wilderness of California and Nevada. He and his girlfriend Bea are spending the next couple of weeks traveling and backpacking.

The fact that I'll be living alone for the next two weeks means that I'll have more time to work on my thesis. Have I mentioned that it's rapidly approaching the 100 pages mark meaning that I've written way too much? Maybe I should spend the extra time blogging or reading instead. I'll think about it.

Anyway, the plan is to finish the report by the end of this week, which will give me next week to proofread it, hate LaTeX, finish the layout, hate LaTeX a little more, print it, and send it off to Switzerland. After 10/02 I'll also become more talkative again on IM and via e-mail.

Sunday there's paintball on the cards. I'll get to let off some of my concealed anger by shooting the c... out of people. That should work! :-) We're still looking for people, by the way ...

More moving coming up. It's time I moved into my bed.

It turns out I'm not the only one who loathes the GNU Autotools suite. One of the BasKet developers doesn't seem too delighted with their performance either like an excerpt from today's mailing list traffic shows:

"And now other good news. I got too confused trying to build the test with autotools (I HATE THEM!!!!!!!! I HATE THEM!!!!!!! I HATE THEM!!!!!!), so I just went out and wrote a cmake build for them. And guess what? It was easy, and it works great! It's so much faster than auto* that it hurts."

He's right. It really hurts. Not only does the build system slow down compilation by orders of magnitude, it has very subtle bugs (only recoverable by radical measures such as deleting all autogenerated files including those not deleted by distclean), and it is a huge pain to adapt to your needs.

I have sworn to myself more than once that the project I'm currently working on for my thesis (more details soon!) shall be the last one I'm trying to do with automake & accomplices. In less then a month it's a big fat tomb stone with "Autotools" carved in and me dancing on top of it. R.I.P.

What better way to start a day than with a beautiful, intuitive error message like the following:

GLib-GObject-WARNING **: value "TRUE" of type `gboolean'
is invalid or out of range for property `force-aspect-ratio'
of type `gboolean'

It happens when a gboolean variable has a value other than 0 or 1 and you try to assign it to the property of a GObject. Here's an example:

gboolean enabled = 18;
g_object_set(myobject, "my-boolean-property", enabled, NULL);

Obviously, the above example is a little unrealistic. But what about this?

void set_my_property(bool enabled) {
    g_object_set(myobject, "my-boolean-property", enabled, NULL);
}

You guessed it. That's a nightmare because you have no control over the fact whether your callers pass you 0, 1, or 317. The latter can easily happen if you use uninitialized bool variables. Not exactly what you'd expect from your callers but if you don't want your function to output weird warnings you have to prevent it.

Even the following idea (obviously, because gboolean is a simple typedef to an int) doesn't help:

void set_my_property(bool enabled) {
    gboolean genabled = enabled;
    g_object_set(myobject, "my-boolean-property", genabled, NULL);
}

The nightmare really starts when your gboolean values are passed along a few function calls and you have no idea which of the g_* functions accept only 0 and 1.

So what's the solution then?

void set_my_property(bool enabled) {
    g_object_set(myobject, "my-boolean-property", enabled ? TRUE : FALSE, NULL);
}

Easily readable. Fast. Intuitive. GLib.

Have you ever wondered what the sleep mode on your laptop is actually useful for? Saving battery? Protecting the hard drive while you're carrying your computer around? Silencing the noisy beast? Maybe there's something to the battery argument but the others? Baloney!

Ok, the noise argument first: If the difference between a laptop running and in standby mode were actually audible, I wouldn't have forgotten to switch it off at the office, right? And protecting the hard drive? If that were in fact necessary then how come I'm blogging from the very same computer that I carried home--running--while riding my bike for about half an hour over California's bumpy roads?

You can see this as an interesting experiment whose outcome humanity has been waiting for or as a sign that I should not be working till 11pm.

What was the reason I stayed so long, then? Automake. If you don't know what automake is, you can safely skip this paragraph. Let's just say that some combinations of convenience libraries, static libraries, and shared libraries are pretty hard to link together to a plugin (itself a shared library). Not getting it? Well, there you go ...

Lunch was fun today, we had a new hire lunch with Guerrino De Luca, the CEO of Logitech. It's not like we had filet mignon--it was pizza--but I guess they had spent all the money on a few hundred mysterious plastic cubes about which I shall blog later this week. ;-) Anyway, I love pizza, so I'm not complaining, and some of the discussions that were going on were pretty interesting.

As you can imagine I'm way to tired to end this post on a witty punch line, so here we go instead:

---p-u-n-c-h-l-i-n-e---

Here's one to test your computer skills. If you don't have any, feel free to skip this post. :-)

Keywords: C, POSIX, waste-of-time, nothing, Linux, annoying, keeps-you-at-work-till-10pm, pthreads, mutex, geek

The question: What does the following program print?

int main() {
	int i;
	pthread_mutex_t mootex;
	
	pthread_mutex_init(&mootex, 0);
	for(i = 0; i < 10; i++) {
		printf("%d\n", i);
		pthread_mutex_lock(&mootex);
	}
}

The answer: It depends.

On what, you ask? On how you compile it! Say you compile and run it like this:

$ gcc -o mootex1 -pthread mootex.c
$ ./mootex1
0
1 (Program hangs here)

Makes sense, right? The second call to mutex_lock hangs--because that's what mutexes (mutices?) do!

Let's look at a slightly different way to compile it:

$ gcc -o mootex2 mootex.c
$ ./mootex2
0
1
2
3
4

Shocking, the program just runs through ... What happened? A short look at the libraries these two programs were linked against gives us a hint:

$ ldd mootex1
        linux-gate.so.1 =>  (0xffffe000)
        libpthread.so.0 => /lib/tls/libpthread.so.0 (0xb7f61000)
        libc.so.6 => /lib/tls/libc.so.6 (0xb7e29000)
        /lib/ld-linux.so.2 (0xb7f8d000)
$ ldd mootex2
        linux-gate.so.1 =>  (0xffffe000)
        libc.so.6 => /lib/tls/libc.so.6 (0xb7db0000)
        /lib/ld-linux.so.2 (0xb7f02000)

The version without the -pthread option lacks the link to libpthread.so. But why weren't there any linker errors?

The short version is that glibc provides stubs of the pthread functions that do nothing. Nothing as in nada. No warning, no documentation, nothing.

The long version is part of an interesting newsgroup thread.

So the next time you use the pthread library for synchronization, you may want to keep the small differences in mind. Otherwise, mutexes may become moot.