Sven Luther and Debian mailinglists

A few days ago, I forwarded a mail from Sven Luther to the debian-vote and debian-project mailinglists. The reason I did so was that, apart from the last two paragraphs, the mail's tone was reasonable, polite, and did not try to rehash the old arguments. Also, and more importantly, I thought it was a useful contribution to the discussion at hand. I then received a private email in response to that forward from someone—who shall remain nameless—that expressed disapproval of this forwarding. Not because of the content (which i could understand), but because of the person whose mail I forwarded.

I am shocked beyond words that such a thing is possible. Mind you, I'm not supporting at this point that we just allow Sven back in the project; the decision to throw him out was based on solid arguments, and though I am sad that it was necessary, I do support the decision that has been made. However, I would think we would have expelled him because of the problems that resolved around his person, rather than because we didn't like his name, background, or, say, the color of his skin.

Problems can be solved. Personalities can change. Throwing a person out of the project because of interpersonal problems is one thing. Forbidding him to ever join it again is quite another.

I'm not saying we should just forget the whole thing, pretend it never happened, and move on. However, I do not think that just because the man has a history, we should ignore his useful contributions.

Although I disagree with some of the suggestions he made, I do happen to think that this particular contribution was useful, and so I forwarded it. I do disapprove of some of the things he's done, but that doesn't mean I disapprove of the person; I do believe any person deserves a minimum of respect.

Apparently some people in this project disagree with me on that, however. I'm not sure what I'll do about that, but suffice to say that I will not be part of a project that considers a person's history to be of more importance than a person's current behaviour.

Let's hope this is just the opinion of one person...

Dependency graphs

Andrew blogs about this nice Debian Dependency graph generator over at gnowledge.org.

It nicely shows why I'm not entirely fond of the belgian electronic ID software: just have a look at the dependency graph for libbeidlibopensc2. Seriously.

Quake I

Years ago—I think some two years after it was released—I bought me a copy of Quake. I found the original box in a shop that had just one left, and was selling it at a serious discount; I still have the box, with the original artwork.

I didn't have Internet at the time, though, so I never played it online. I did finish the game at one point, though I don't remember whether it was with or without cheatcodes. I'm certain I got very far, though I had a tendency to start using cheatcodes when the monsters I had to pass got too hard for me to actually be able to pass them.

When I did get an Internet connection, Quake III Arena had just been released, so not many people still played Quake I. However, my very own ISP then did have a QuakeWorld server still running, and I fondly remember playing a lot on that server. Since I hadn't heard of +mlook, which enables modern-style mouse-based movement in quake, I was still playing with doom-style controls, that is, keyboard only. At first I got fragged all the time, but it didn't take me long to master this method. I got so good at it that I've won some deathmatch games, with keyboard only. Seriously.

Eventually, however, I migrated to a state where I did not have any Microsoft operating systems installed on my system anymore; and while Debian had a 'quakeforge' package in potato, it was rather buggy; I remember it would reproducibly crash when you would load a particular level from the third episode. I did think about fixing the code, but then I didn't really have the time or expertise to do so, so that never got anywhere. Eventually, it was pulled from the archives; and after a while—around the time when my ISP shut down their quakeworld server—I stopped playing Quake; and though I was sad about it not being installed anymore, I just forgot about it.

Recently, however, I somehow stumbled upon this 'Linux Quake HOWTO' over at tldp, and noticed that apart from Quakeforge, there really are other engines, and there really still is a Quake I community around. With quakeworld servers and everything.

Oh boy.

So I installed this 'tyrquake' a few days ago, and I've now already reached episode 3. Some things are coming back, but others aren't really...

Of course, when I connect to one of those quakeworld servers, I get fragged all over. I'm lucky when I end up with a positive frag count. For reference: in Quake I, you only lose frag points when you kill yourself...

Hah.

To be continued, I guess...

On DebGem

I feel I should comment on the whole DebGem thing.

About a week ago, the guys from that project mailed me, stating that they were about to go public, and if I would please have a look at it before they would do so and perhaps give some constructive criticism.

So I did. I must say I wasn't very impressed, initially. What you get there is what the name suggests: a Ruby Gem, but then just repackaged as a Debian package. As in, files laid out exactly the same way. As in, still not FHS compliant. As in, many other problems.

I came up with a list of problems that was quite long, and they've fixed most of them; but the fundamental problem—that RubyGems are peculiar beasts, making it hard, if not impossible, for Debian people to package them so that they adhere to Debian's strict quality requirements—remains, and this service does not (or cannot) solve that.

To be sure, it's a step in the right direction, which will ease the maintenance of Ruby software on many a Debian system, and for that they deserve praise. However, it is not a solution; much more work needs to be done—and it needs to be done within the Ruby community.

FOSDEM 2009: Debian talk schedule almost ready

Lessons learned: using the phrase third, final, and slightly desperate is an excellent way to motivate people into reacting to your Call for Talks. I've even had to reject some people now, unfortunately.

Maybe next year, I'll use that phrase in my first call for talks.

Then again, maybe not.

Anyway, of course that does mean that there are no slots available anymore. If you wanted to hold a talk in the Debian devroom, you've had plenty of opportunity and will now have to wait until next year.

There are still some minor loose ends that need to be filled in (of course there are always people who will wait until the very last moment to send mails they need to send... including me), but once that's done, I'll announce the schedule on the -events-eu mailinglist, and probably here too. And if you're worried that the word 'desperate' perhaps got us some boring talks in the end, don't be; the talks that are on the schedule are, I hope, all very interesting. Watch this space!

So, things left to do, in no particular order:

• Do a schedule for talk announcers. There's enough volunteers now, I only need to assign slots.
• Come up with something cool for the booth. There's going to be T-shirts, as always, but more things are always welcome.
• Booth volunteers. Since I haven't been at the booth much during these past few FOSDEMs, and since two years ago it turned out that my 'great idea' about organising that wasn't such a great idea after all, I did the right thing and decided to delegate organising the volunteers to someone else. That someone else is Nattie; so if you want to help out at the booth, be sure to contact her.

That's it for now, I guess. Back to your regularly-scheduled flamewar.

Hackergochi 'meme'

Christian, you forgot my (not so) recent hackergochi redo

Anyway, the picture I took of you back in Argentina isn't great hackergochi material; it cuts off part of your chin and the top of your head, which will get you a very very ugly hackergochi if you try to use it. Trust me—been there, done that. In addition, it's very likely that you like the picture because of the somewhat dark background, even if only subconsciously; by turning it into a hackergochi, you cut out that background, so the appeal of the picture gets lost somewhat.

Since you won't be at FOSDEM, I can't offer to take another picture of you. And since the picture you refer to is mostly great because of the lighting (which will no doubt be completely different, it freezing right now over here and everything) and the lens I used (which wasn't mine, but belonged to someone else; I just borrowed it for a few hours), I seriously doubt that I'll be able to get a picture that's in any way similar to the one you seem to like so much.

Having said that, taking a good hackergochi picture isn't too hard; just think of a few basic things while taking it. If you're not happy with any of the pictures you already have, then take a new one! The following might help you with that:

• You'll need a halfway decent camera. Webcams probably won't do, but your el cheapo digital camera will likely cut it.
• Good lighting. Try to use sunlight if at all possible; at any rate, try to avoid the use of a flash (except if you have one of those extremely expensive flashes that will simulate sunlight, but you probably don't).
• Turn yourself so that the sun casts some interesting shadows. Do not move at a 90-degree angle, because such long shadows are not interesting anymore; Something like 45-degree would probably be nice. At any rate, make sure the sun is not in the background of the picture, unless you want to see a black hackergochi.
• Frame the picture well. The more pixels you have for your head, the better. Make sure your head and neck fill as much as possible of the picture's frame, but do not zoom in too much—you do not want to have any part of your head and/or neck even touch the edge of the frame.
• Find a bland background. Something monochromatic is the best; think 'bluescreen'. Make sure you get a wall that is not near the colortones of human flesh.

After that, just cut out the head and add a dropshadow. Even if you're not very familiar with The Gimp, that shouldn't take you a very long time; andn The Gimp is fun enough to play with anyway. Hints: Look for 'scissors select'; the dropshadow is in 'filters' -> 'light and shadow' -> 'dropshadow'

Good luck

FOSDEM Devroom schedule

I just mailed the schedule for the FOSDEM '09 Debian Devroom to the -events-eu mailinglist.

Also note that Bdale Garbee will be doing a Debian keynote talk on saturday morning.

How not to enable ACLs

Yesterday, I wanted to test something involving ACLs on my laptop, so I had to enable them on my laptop's filesystem.

Since I don't believe in multiple filesystems for a laptop, that meant changing mount options on the root filesystem. Changing fstab is easy enough, but for changing the options on the live filesystem, you need to remount it.

No problem, I thought, there's '-o remount', right?

mount -o remount,acl /

Turns out that's not such a good idea. This morning, I boot up my laptop, and I'm greeted with the following message:

/dev/hda4 superblock features are different from backup, check forced

... which took quite a while, as usual. Sigh.

Re: On filesystem layouts

Someone posted a comment to my previous post on ACLs; and now Andrew blogs about the same question:

Why don't I believe in multiple filesystems for a laptop?

Andrew's arguments don't really convince me. A filesystem eating itself? That's never happened to me yet. A hard disk dying on me, however, I've had that. Since I first owned a computer with a hard disk, I think there've been 5 of them. There's only one thing you can do against that -- have a proper backup strategy. That not only protects you against losing your data due to the somewhat likely event of a hard disk dying, it also protects you against losing your data due to the somewhat unlikely event of a filesystem eating itself.

On the other hand, however, a laptop hard disk is usually slow, small, and painfully so. Partitioning already-small hard disks into even-smaller partitions therefore doesn't sound like a particularly bright idea to me. Losing half a gig on unused space for /, then 400M for /usr, and 600M for /home, and another 2G for /var, or some such, is pretty stupid if you want to store a 3G file that you want to burn to disk; you have the available space, but you don't have it in one partition, so you get to do the cleanup dance. And nobody likes to do that, right? Oh, and don't try to fool me—I have yet to see a laptop that's been in use for more than a few months and whose disk is not filled to all but a few gigabytes. Nobody removes files until they're out of space, and then you only remove just as much as you need to be able to do the job at hand...

Occasionally, I do install server systems with multiple filesystems, and with LVM. On a server, the inability of a run-away system process (or user) to 'accidentally' fill up the root filesystem with junk is definately a life-saver. But once you have lost data, you need to recover anyway, and having partitions doesn't particularly help you in doing that. Also, servers tend to have multiple huge disks in a RAID array, so loss is less likely, and disk space is plenty; as such, the loss of 10% on the LVM overhead isn't something I care about, which it is on my laptop.

But, hey, to each their own preference. I won't look at you funny for preferring multiple partitions on your laptop. Promise!

Of course I am

In case there was any doubt:

Not that I think there was, but, well.

In related news, there've been some minor updates to the devroom schedule, especially on saturday. If you were interested in some of the saturday talks, you'd better go have a look.

Filesystems: the saga continues

Bernhard comes up with a few arguments in support of multiple filesystems which, in my arrogant opinion, make no sense.

The first argument (about hardlinking a file to your homedirectory until something bad is discovered in one of the binaries) has been sufficiently debunked by Joey Hess.

The second and third arguments are the same, really. Repeating your argument won't buy you any beer, sorry.

Finally, all your arguments talk about server. I was talking about laptop. I don't know about you, but me, I'm not in the habit of loaning out my laptop to someone I don't trust. I'm not even in the habit of loaning out my laptop to someone I do trust, come to think of it. I do run some servers on my laptop, but I also have a firewall on my laptop that refuses incoming connections.

This is a laptop. Not a machine in a data center.

As such, the only person with access to my machine is me. Now I don't say I trust each and every bit of software that I run on my laptop, but I do trust myself. I won't start scanning my laptop's hard disk for rogue SetUID hardlinks in another user's home directory, because there isn't another user, stupid!

Paranoid security is nice and dandy and totally useless. Security is all about trade-offs. Even Bruce says so: if the cost of a security measure (having to deal with with 73 filesystems) does not outweigh its benefit (protection against cosmic rays changing not only my firewall configuration, but also writing a suid CGI binary and installing that in /usr/lib/cgi-bin), then it's just not worth it. Now of course you might argue that 'having to deal with 73 filesystems' is no cost at all, in which case it would be worth it. But to me, it certainly is a cost, and one I'm not willing to take—even if it did protect me against a real-life problem.

And if someone were to break into my system, I'll just reformat it and recover from back-ups. I won't even have to revoke my GPG key, this time, since it's no longer on the disk.

FOSDEM Debian Devroom: annotated schedule

FOSDEM is a 2-day weekend of insanity. 218 talks this year; if you want to understand exactly how insane that is, have a look at the schedule grid. There are 19 rooms where events are held; possibly more, since I understand not every devroom has sent in its schedule yet.

Might be hard for people to make a choice that way, I guess.

Now there're supposed to be abstracts of each talk on the FOSDEM website, but reading them all can be quite tedius. In an effort to help, at least for the Debian devroom, here's the schedule for our devroom with a bit of explanation of what it's about. Note that this is mainly aimed at people not familiar with Debian; those who are should probably understand it enough by looking at the titles.

Saturday:

13:00 - 14:00: 'Outside broadcast on a budget - the DebConf video team and DVswitch'. DVswitch is the software used to create those excellent Debian videos. The best ones yet, IMO, are the ones of Debconf8. Check them out. There's nothing Debian-specific about DVswitch, except that it was written by Debian people. It's a great way to do live Internet .ogg streaming by using nothing more than DV cams, Firewire, and plain old Ethernet.

14:00 - 15:00: 'Ultimate Debian Database: datamining Debian made easy!'. UDD is a SQL database containing a shitload of data related to Debian, and which should allow easy datamining. Hence the title. This probably won't be of any interest to people who are not either a Debian Developer or a statistician, but I might be mistaken.

15:00 - 16:00: 'Introducing DDE, Debian Data Export'. This is a new project Enrico came up with, and which is related to the same subject as the previous talk. I don't know much more beyond what's in the abstract. However, given the fact that Enrico is going to be doing this talk, it can't be bad. Seriously.

16:00 - 17:00: 'The Debian status quo on the Openmoko Neo Freerunner'. Yup, Debian runs on the OpenMoko, and has done so since Debconf8, last august. This talk should give some more insight; if you have an OpenMoko, this definately is for you.

17:00 - 17:30: 'Running Debian on Inexpensive Network Storage Devices'. I've been running Debian on a Thecus N2100 for a few years now, and it's great. There are more options, however, and Martin does most of the hard work related to these devices. He's done a similar talk on the two previous FOSDEMs (go check out the videos), and this one will mainly be an update on what's going to be new in Lenny.

17:30 - 18:15: 'Grid Computing with Debian, Globus and ARC'. These guys are a group of academics from three different universities who've been doing grid computing (i.e., something like 'SETI@Home', but then somewhat different) with Debian and some other technologies. They'll be explaining how, exactly. I don't know much about this talk; it could be great, or it could fail miserably. I guess we'll see.

18:15 - 19:00: 'What does the DPL do?'. This is really firmly targetted at Debian people. If you're not in the least interested in how Debian does things, you'll be bored.

Sunday

09:15 - 10:00: 'The state of Virtualization in Debian'. If you're a Debian user interested in virtualization, this talk is for you. Henning will explain what virtualization options exist in the upcoming 'Lenny' release, and how to use them.

10:00 - 11:00: 'TDebs'. This might not be too interesting to you unless you happen to be involved in Debian infrastructure. TDebs don't exist yet, but will sometime soon; Neil will be explaining how, why, and what.

11:00 - 12:00: 'Internationalization in Debian: How to improve further?' If you're interested in i18n, this is probably for you.

12:00 - 13:00: 'The Common Debian Build System (CDBS)'. CDBS is one way to build a Debian package. This is probably only of interest to Debian people.

13:00 - 14:00: 'Release management in Debian - can we do better?'. Frans isn't a member of the release team, but has some criticism on how they function. He intends to present his arguments in order to start a discussion. This is Debian internal kitchery, really.

14:00 - 15:00: 'Lenny - the road to release'. Neil is a member of the release team, and is going to explain how we got to the current state. I hope he'll also explain why we still haven't released. I guess we'll see

15:00 - 16:00: 'The long road to KDE4 in Debian'. Um, yeah. I'm not a KDE guy, but I understand some other people are. In any case, might be an interesting talk even if you don't use Debian, since I understand it will look at some of the new features in KDE (and how they relate to packaging).

16:00 - 17:00: 'Debian and Google Summer of Code 2008: wrap-up and insights'. I guess Leslie will be there. The speaker was a student working on Debian during this year's SoC, and he will present what's been accomplished.

There, that's it. Now my only hope is that there'll be many people attending. If previous editions are any indication, however, that won't be a problem.

Re: emulated buildds

Aurelien, your claim is wrong. About a year ago (IIRC; might've been longer), the Debian/m68k team decided that it wanted to do emulated buildd hosts, since that would allow us to more easily keep up with unstable. We discussed it in the team, we discussed it with ftp-masters, and we all decided to go for it. We've had emulated m68k builds go to the archive for quite a long time, with full knowledge and agreement of ftp-masters. We realized that emulated builds could be problematic, but we evaluated the issues and decided to take that risk, as a team.

The reason your key was rejected for uploads of arm binaries was because you started doing those emulated builds without discussing it with the arm buildd maintainers, and without discussing it with the arm porters. You just decided it might help, so it must be good, right?

Finding the difference is left as an exercise to the reader.

FOSDEM and Novell

Sigh.

I'm not part of the FOSDEM organisation team, and this is by choice. I know that I wouldn't find the time to help organize a conference of the scale of FOSDEM, since I'm rather liable to forget to do important things at times.

Having said that, I happen to run a company together with Philip Paeps, who is now one of the main FOSDEM organizers; apart from that, I've also managed the Debian presence there for the past few years (lost count how many exactly), and arranged the key signing party for a few years—with Joost Van Baal taking over for me starting this year. As such, I'd like to believe that although I'm not exactly in to all their secrets, I do have a front-row seat when it comes to how things are going there.

FOSDEM is the "Free and Open Source Developers' European Meeting". It has been that since 2001, and will always remain so. Yes, originally it was called "OSDEM", because frankly, the organisation of the original OSDEM was done by a group of people who like Open Source, without necessarily subscribing to the Free Software ideals. The core group of the organisation is a rather diverse group; for instance, Philip has been known to be rather... negative... about Ubuntu, while Mark (one of the press contacts) has done some activism and translation work for Ubuntu.

The change of name from OSDEM to FOSDEM was done not because the organisation's ideas about software were changed overnight by a mail from Richard Stallman or anyone else from the FSF; but rather, because they were open-minded enough to understand that having a name which only says 'Open Source' would be excluding a considerable part of the community that encompasses both Free and Open Source people. This is why the name wasn't changed in FSDEM; it is FOSDEM.

I'm quite sure that the fact that FOSDEM is so open-minded about many of the controversial issues that have separated our community over the years—not just Open Source vs Free Software, but so many other things as well—is one of the main reasons why FOSDEM is so popular today: because everyone, and I truly mean everyone, will find something that he or she likes.

That is why I'm so saddened that some people seem to find it necessary to not only whine, but also boycott a conference, because they believe that FOSDEM should not take money from a big Free Software/Open Source contributor, just because they also happen to be a company, and as such make business deals with Microsoft. Note that I'm not either defending or condemning Novell's attitude here; but it is a fact that not everyone in the larger Free and Open Source community feels the same way about the whole Novell/Microsoft deal (else there wouldn't be an openSUSE anymore), and as such they still deserve a place on FOSDEM.

Over the history of the organisation of FOSDEM, it's always been a place where everyone could get their opinion out; whether it be the opinion that "Free Software Must Rule The World", or that "It's All About The Way You Do Things"; as long as your opinion is shared by a large enough number of people in the larger FLOSS community, it is welcome.

I feel that blocking one organization from sponsoring the event, just because they have made some deals which a significant group of people, one which nevertheless does not encompass the whole of the FLOSS community, disapprove of, would set a dangerous precendent that might jeopardize the very core of what makes FOSDEM so great: its impartiality.

Thank god that didn't happen.

dlhack()

In my living room, there's a TV, with a computer connected to it.

In that computer, there's a DVD-ROM player, a hard disk, and a card with a TV output.

On that hard disk, there's Debian with xine to view DVDs

When I originally put it there, I would pick up the keyboard to do some user input. This works, but a keyboard is klunky. So, instead, I've been working on jsxine, a little application that does not much more than open a window, and tell xine to play a DVD there, but use the joystick for UI[1]. My 'joystick' is a Logitech Wingman Gamepad Extreme, which has a cable long enough for me to be able to use it comfortably from the couch, so I can use it as a sort of remote control.

The current version has quite some things hardcoded: button 0 is 'select', button 5 is 'eject', button 6 'previous chapter', button 7 'next chapter', and button 8 is 'start or stop playing'. The primary two axes move around in the DVD menu; and other stuff is not yet implemented. This layout, of course, makes a lot of sense on this particular gamepad, but I doubt it does on other joystick devices. And since I want this to eventually be useful for other people, too, I recognized that I would need some way to configure things.

My initial stab at configuration would create a hash table of available actions, read out a configuration file, and then find the appropriate function pointer in the hash table. While this works, it has one rather important downside: adding a configurable action would requrie another item in the hash table; this would eventually make the hash table horribly long. So I thought, why not use the configuration value to ask the dynamic linker to get me a function pointer?

With a little help from my friends, that's exactly what I did. Proof-of-concept code:

#include <dlfcn.h>
#include <stdio.h>

int function() {
	printf("In function!\n");
}

int main(int argc, char**argv) {
	int (*funcptr)(void);
	void* handle;

	printf("foo\n");
	handle = dlopen(NULL, RTLD_NOW);
	funcptr = dlsym(handle, "function");
	funcptr();
	return 0;
}

Compile with cc -ldl -rdynamic. Et voila, that gets you an application which can do a lookup of function names at run time.

Long live C.

Of course, there's a bit of a danger in the above example. A user could just write a config file that has things like 'open' and/or 'write' as arguments, or the like. One should make sure that it can be obvious from the function name that it does indeed define an action; for example, by giving them a common prefix, and prepending that prefix to the function name before handing the name off to dlsym().

But other than that, this seems to work. It apparently also is documented in the FreeBSD documentation on dlopen(), so maybe it's not as much a hack as I thought...

Oh well.

Note that on GNU systems, you can also put a #define _GNU_SOURCE before the #include <dlfcn.h>, you can drop the dlopen() call and go straight to dlsym(), with RTLD_DEFAULT as the handle.

[1] Yes, I could have done a Xine plugin. I didn't want to. This is as much a project to produce something useful as it is a project to hack and have fun.

dlhack("followup");

I received quite some feedback on my dlhack() post. Most of it negative.

For clarity: no, I do not consider such practices to be the best of ideas. I called it a 'hack' for a reason—I fully expect this mechanism to be replaced by the time I eventually release the code.

It was just fun to do it this way, that's all.

Having said that,

There's one comment from a xine developer that deserves a followup:

I'm sure I have seen a few different software that can simulate keypresses from the keyboard through the user event interface of the kernel with a joystick, and thus you should just need to wire it down with the original xine-ui. Or use gxine and the gxine_client program to control it.

While this will work, there are several problems with this approach:

• The kernel can't know which application currently has the focus. With this approach, you may be sending joystick-generated keypress events to your IM client because it popped up while you were watching a DVD, and you hit the table (causing the joystick to move) while trying to click it away.
• A keyboard and a joystick are fundamentally different devices. While a keyboard can only tell the difference between 'the button is depressed' or 'the button is not depressed', a joystick has a much wider range; the Linux API will give you a signed 16-bit integer for the position of the stick. This can be useful to skip forward or backward in a much more detailed manner than the traditional 'chapter, 5 seconds, 30 seconds' approach; or one could use it to set the volume to a particular level (activate 'set volume', push the stick somewhere between fully-forward and the idle position for a volume level over 50%, or somewhere between fully-backward and idle for a volume level under 50%, then push a button to confirm). This kind of UI comes naturally with joysticks, but is impossible to implement through a keyboard-emulated UI.
• Some of the functionality I have in mind will require some visual feedback (e.g., the volume setter described above). I could do a separate window, of course, but that has its own set of problems; e.g., you need to ensure that it is on top of the video window; it will also be opaque, which is not as nice as transparent overlays on the xine window itself.

While all of the above is not a problem if I write a xine plugin, and indeed I might eventually convert the code to a one, the problem with that is that I don't know the xine plugin API yet; and writing a standalone application makes for easier prototyping. For the time being, at least.

Oh, and in case you wonder why I don't just buy a LIRC-capable device and use a regular remote control: I have my gamepad. I do not have such a LIRC-capable device. My budget is not unlimited. 'Nuf said.