Microsoft's score

Vista's DRM stuff sucks. I don't really use DRM-encumbered media myself, and as long as I can still buy me non-DRM'ed stuff, I don't really care much. But if "the others" bring out operating systems that make insane requirements on the hardware, which may in turn drive prices for said hardware up, even if I don't want or need those "features", then they've crossed a line.

I've therefore decided to keep score. Microsoft gets one point if they make it harder for people to copy DRM-encumbered media. The World gets one point if they make it easier for people to copy DRM-encumbered media.

The score currently is 2-1 for The World (Microsoft implemented Vista in the first place, so that got them one).

Firefox

To the people who developed Firefox...

You utter cocks, Linux is not Windows.

Love,

Wouter

Etch m68k

So now that etch is out, m68k is no longer an officially supported port in the latest version of Debian . However, if you have a look at a DMNY[1], you'll see the following:

ncftp /debian/dists > ls
Debian3.1r6@                           proposed-updates@
Debian4.0r0@                           README
etch/                                  sarge/
etch-m68k/                             sid/
etch-proposed-updates/                 stable@
experimental/                          stable-proposed-updates@
lenny/                                 testing@
lenny-proposed-updates/                testing-proposed-updates@
oldstable@                             unstable@

Note the 4th line of output:

etch-m68k/

Yes, that means there is a way out for users of Debian/m68k. The etch-m68k suite will allow us to update patckages for etch on m68k only, much like the AMD64 folks did on sarge. This is necessary, since etch/m68k is a bit too different from 'regular' etch.

Want to help? Head over to debian-68k@lists.debian.org and/or #debian-68k on OFTC. Help is always welcome.

[1]Debian Mirror Near You

My DPL ballot

So, now that the results of the DPL vote are in, I feel I can reasonably show my DPL ballot without doing something which I would consider "campaigning". And since I've done this a few times in the past now, I feel I ought to do it again. So, here goes:

[ 1 ] Choice 1: Wouter Verhelst
[ 6 ] Choice 6: Aigars Mahinovs
[ 4 ] Choice 3: Gustavo Franco
[ 2 ] Choice 4: Sam Hocevar
[ 1 ] Choice 5: Steve McIntyre
[ 5 ] Choice 6: Raphaël Hertzog
[ 5 ] Choice 7: Anthony Towns
[ 3 ] Choice 8: Simon Richter
[   ] Choice 9: None Of The Above

I guess it's no surprise I put myself up first. Running for DPL is a serious business, so it makes no sense running if you don't believe in it yourself. However, as I expressed during campaigning, I believe Steve was a very strong candidate, too; so I wouldn't have mind if it was him who won instead of me.

Next, I put Sam Hocevar, since he also had a rather strong platform; he has some experience in leading a project (albeit on a much smaller scale); and yes, humour is good, too. I didn't put him first too, because there are some things in his platform that I have second thoughts on (mainly some of the technical matters that I believe have nothing to do with the DPL), but that didn't cause me to rank him down.

Simon Richter had a rather weak platform, and failed to convince me during campaigning, too. That I still put him rather high has everything to do with having met him in person a few times.

What follows are people I would have preferred not to see elected. I didn't feel that strong about it that I would vote them below NOTA, but still.

Gustavo is very enthousiastic and had many projects he would have liked to accomplish, but I sensed some naivete coming from him. Therefore, I wasn't sure he'd make a good DPL.

If I look at this past year, I look at a lot of unneeded bitterness. Some of that bitterness is a direct result of actions the DPL took; others are a result of things the DPL failed to act upon properly. Therefore, I feel the current DPL hasn't done much of what I want a DPL to do. Ranked along with him is Raphaël; after thinking about it, I think a DPL election is not the right place to promote a replacement structure in place of the DPL. Hence.

Last, I've put Aigars. I'm sorry to say that I feel his platform has lost all touch with reality.

Finally, I'd like to congratulate Sam Hocevar for winning, and Steve for making a very close second—again. I don't know about him, but I'd be rather frustrated with such a result.

Gunnar,

It was on your blog. At least if I didn't miscopy the URL back then. And, no, I again don't remember where I was when Sarge released. I do know where I was when etch released, though—at home, on IRC.

Belgian eID proxy code

I was recently (at FOSDEM) made aware of the fact that apart from the client-side software, Zetes also provides some server-side software to allow one to verify electronic ID card certificates on an HTTP server. I didn't know about that, since nobody ever told me about it; and none of the eID sites that I know of mention it, either. So today I had a first look at the code to see what I'd need to do to properly package it.

The code does contain a few WTFs, though.

-    if (!r->proxyreq || !r->filename || strncmp(r->filename, "proxy:", 6) != 0)
+    if (!r->proxyreq)
+        return DECLINED;
+
+    if (!r->filename)
+        return DECLINED;
+
+    if (strncmp(r->filename, "proxy:", 6) != 0)
         return DECLINED;

This one is especially silly if you know that the above is the only change to mod_proxy.c.

They do extensive changes to apache's mod_ssl, since that is where most of the needed work is done. The changes include the following stuff:

 #ifndef BOOL
-#define BOOL unsigned int
+#define BOOL int
 #endif

It's a boolean. By definition, that needs to keep only 2 values. The ability to set it to negative values doesn't matter.

But, well; the above two could be explained by compilers having strange ideas about what should be warned about. So let's ignore those. The code should be sane then, right?

Well, almost.

--- httpd-2.0.54/modules/ssl/mod_ssl.h  2005-02-04 21:21:18.000000000 +0100
+++ httpd-2.0.54-beid-proxy/modules/ssl/mod_ssl.h       2007-04-15 13:45:27.0000
00000 +0200
@@ -74,7 +74,7 @@
 #include "apr_global_mutex.h"
 #include "apr_optional.h"
 
-#define MOD_SSL_VERSION AP_SERVER_BASEREVISION
+#define MOD_SSL_VERSION AP_SERVER_BASEREVISION "+OCSP (1.0.8)"
 
 #ifdef HAVE_SSLC
   
@@ -152,7 +152,7 @@

That's okay, sure? If you change mod_ssl to include OCSP support, you may want to change its version number to reflect that? Yes, indeed. But if you set the version number like above, and spread the rest of the mod_ssl code with patches like...

+#ifndef NOOCSP

(...)

+#endif

...and...

+ifndef NO_OCSP

(...)

+#endif

... then my guess is something's wrong with your processes.

Anyway. The modified SSL code for apache will be coming to a Debian mirror near you some time. But not soon.

Etch release party in Leuven

I was informed that there's an Etch release party in Leuven, tonight. I've added it to the wiki; if you can still make it, you're welcome to join us. I'll be there, as will (hopefully) a number of other Belgian debian people.

Interesting slogan

Debian. Now also bleeding etch.

At least that isn't as old and boring as "The Universal Operating System". Yet.