The nomination period for the Debian Project Leader is on again. This means that the Finnish winter is at its worst, and indeed, as I write this, it is -22 degrees Celsius outside. The sun went down about six hours ago; I woke up quite late, so I only saw half the sunset. Back in November, while vacationing, I spent some time thinking about what the role of the DPL is, and now seems a good time to say it. The actual work of developing and maintaining Debian is done by package maintainers, translators, a handful of infrastructure teams or other special purpose teams, bug reporters, and others. It is not the job of the DPL (in their role as DPL) to take charge of the actual development: the DPL is not expected to administer debian.org machines, to fix RC bugs themselves, or to make decisions about release management. Instead, the DPL's job is to help everyone else do those things. If some part of project isn't working well due to resource shortage, or personality conflicts, or other issues, it is ultimately the DPL who needs to facilitate, mediate, or otherwise deal with it. This is not uniquely the DPL's job: any Debian member could step into a situation and help, but the project does need someone whose job it is to do that if no-one else will or succeeds. Another important job of the leader (again not uniquely) is to provide inspiration. Our leaders in the past few years have provided fairly little of that. I would like us to have a DPL that inspires the project into setting and achieving goals that make us happy and make Debian the best operating system ever. The important thing is to inspire, not to force, cajole, or otherwise unilaterally decide. Not quite sure now how that should happen. Perhaps the Finnish military saying that "leading is best done at the front" is applicable: an inspiring DPL is one who by his own work, and his own behavior, shows by example what a good, productive member of the Debian development community is like. A third important job of the leader is to be the project's public face to the rest of humanity. Again, not uniquely, we have other members who are often prominently in the public eye, such as release managers or security people, but the DPL is the main such public face. And finally, the fourth important job of the leader is to do the tasks assigned to him in the Debian Constitution. These are not daily tasks, but they're important, and these, at least, are uniquely the DPL's domain.

Martin, you should enable comments in your blog instead of forcing me to resort to email or spamming Planet Debian :) Seriously though, while I know that the FHS recommends /media as a mount point for removable media (and it sure makes sense for Debian as a whole to use that), one of the first things I do on my own boxes upon a fresh install is "rmdir /media /cdrom /floppy /initrd". I don't want to have yet another directory cluttering my root, and I find /mnt is perfectly fine for any mount points, especially since I don't really care whether I mount removable media or not. For example, I have /mnt/cdrom, /mnt/usbstick, /mnt/win, /mnt/hda1, /mnt/hda2, ..., /mnt/ipod etc. etc.

John Williams, of GNOME fame, recently blogged on window placement as part of his "things about gnome that suck" series. Well, I basically agree with him - but he doesn't propose a solution. Devil's Pie isn't a solution, because it's not configurable by the average user. Or even by me, I failed to have it tell apart my terminal windows and use a sane placement for them. Just remembering the last window position doesn't work either - I'm annoyed by this "feature" by nautilus, for example. I tend to have a default position for my windows, by I occasionally have to move them away, and I do not want to have them reappear at this different position ever. My personal approach basically is to run all windows (except my terminals and popups such as IM windows) fullscreened, on dedicated desktops. Even the IM windows are usually on my "IM & Chat" desktop. This works really well, especially since I keep my terminal windows open all the time, and the default placement to minimize overlap works fairly well. Still I couldn't specify a general rule how any window manager could learn where to place my windows... so just complaining that Gnome doesn't do this good isn't all - we need to find a way to make this work just fine without the user noticing... I don't know about OSX - how does this work there? In windows it definitely is horrible. When you watch windows users, you'll often see them stating their Internet Explorer, then clicking on the maximize button. All the time.

I was baking waffles today, using my not-so-secret recepy. I needed about fifteen of them, and murphy helped me let it take far longer than initially expected. I had already made some errors in creating the dough (though nothing that I couldn't fix), and when I had eventually finished it and was halfway through baking those waffles, my waffle iron broke down. Which wasn't totally unexpected, given how this is a waffle iron that was part of the inheritance of an aunt of my dad's who had died even before I was born, which must have been approximately fourty years ago. Still, it had me sitting there with a broken waffle iron, a promise that I'd be baking waffles for a fundraising activity, and only half the number of waffles that I needed. I had found myself a slight little problem. So, I went to a local shop, had a look at the waffle irons that they had for sale, and chose one that looked OK to me. I hadn't taken a close look at the box, but the saleswoman had shown me the device and it looked well suited for my needs. Once home, I showed it to my brother. Who promptly exclaimed that 'it is the same as the old one'. At first, I wanted to protest; but on close examination of the picture on the box, I had to agree that he was right! They had restyled the one inside the box—given it a different colour, and used a temperature dial with a more modern look—but it was, indeed, the same model. And this redesign must have happened fairly recently; the illustratory pictures in the user manual still show the 'old' style design, which is identical to the old waffle iron, modulo approximately fourty years of technical evolution. In fact, the single most drastic change between the old device and the pictures in the manual of the new one would seem to be the fact that the company producing these devices changed names in the mean time. They also appear to be having a website, which contains pictures of yet another design of the same appliance. I was baffled. I mean, sure, home appliances are not computers, and I could imagine how a waffle iron, designed five years ago, would still be in sale today. But after that long? What I haven't checked yet, for lack of time, is whether the irons of the old device would fit in the new device. I'll do that tomorrow, because the old device had a 4x6 "Brussels waffles" iron, whereas the new only came with a double 4x7 "Home-made waffles" iron, and an iron for six heart-shaped biscuit waffles. If that would fit, then that would save me an expense of 32 euros—I love baking Brussels waffles, so any waffle iron I use needs to be able to do those. Even if it can only do so one waffle at a time. The ability to use the iron of that 40-year-old thing in the new device would be... great.

Have you noticed the incredibly annoying dialogs appearing in new Gnome/GTK apps in sid? They no longer allow you to use the keyboard to enter a filename. Not only that, but they are *incredibly* slow when working with large directories. You better go get some caffeine when if you need to open something under /usr/share/doc. Here's an example from Firefox: Other apps, such as Gimp, also have this problem. I have one thing to say to these people: WHAT WERE YOU THINKING? The keyboard is still a useful part of a computer, and I have absolutely no inclination to wait 45 seconds for some annoyingly slow dialog to populate because you prefered to remove the ability for me to enter a filename in a dialog box myself.

The Seven Secrets of Successful Programmers article was on reddit today. I found it to be simplistic enough to be inane. Also not particularly good advice in all parts. For example, the article says that "[m]ost compilers will strip the comments from the executable program". Strictly speakig this is true: there is probably one or two compilers out there that retain comments in the binary code they put out. They're so rare, though, that it is quite utterly pointless to say anything about it. Anyone who needs to be told that comments don't impact performance or executable code size needs a course in basic programming, not secrets about being successful. "A good indication that you have got the level of comment right: could someone understand what your program does if all but the comments were removed?" I disagree with this: better advice would be "could someone understand the code if you remove all the comments?" It's the code that gets executed and so it is the code that should be used to communicate and not comments, except when code can't be made clear enough. For example: if you write a wrapper around malloc to check that it succeeds, a comment explaining why it is acceptable to just kill the application on failure would be good, and very hard to express with code. "In particular any code branch (an IF..THEN...ELSE construction) and any code repetition (a WHILE...END WHILE construction) should be indented so that it is easy to see where they start and end." Gee, that surely is a big secret that only successful programmers know about. "Expect the unexpected and deal with it. Before you open a file, make sure that the file is present." That's not a good way to deal with it. It's a race condition just waiting to blow in your face. The correct way is to attempt opening a file and then deal with an error if it failed. "Name your variables to aid readability. - - - The key is to be consistent and to be as informative as possible." Packing as much information as possible into a variable name can be a hindrance to readability. Too many people read advice like this given in well-meaning but misguided articles and then go on to name loop variables nElementIndex. The loop gets more readable if you name your loop variable just plain i. The loop variable is not significant enough to warrant all the attention from a reader that a long name requires. A short name in this context makes it much faster and easier to glance at the loop and see what it is doing. Obviously names with scopes longer than a (fairly short) loop need to be more descriptive. Here's my seven secrets of being a successful programmer.

1. Learn to worship the goddess of simplicity. KISS a lot. This is much harder than it seems: it's more difficult to be simple and good than to be complicated and adequate. Simplicity starts with the specification of the program or system, and needs to permeate the design, and the implementation, at every step.
2. Pick good tools, and learn them well. You need to know many tools, and know them well, or you'll waste time on doing unecessary things. Tools include software programs, books, algorithms, data structures, and mental models. Learn editors, programming languages, Unix command line tools, and so on. Learn at least three different paradigms for programming.
3. Learn how to learn and keep on learning. New stuff is invented daily, and you need to keep up with it, or you'll end up as useless as a COBOL programmer doing a web shop.
4. Develop debugging muscles. This is perhaps the hardest thing to learn, since no-body seems to be teaching it. You'll be spending most of your time doing it.
5. Learn how to do testing well. Unit tests, test driven development, black-box testing, integration testing, regression testing, test automation, ... There's lots of ways of reducing the likelyhood that code escapes your hands with bugs still in it. It will inevitably happen, but if you know what you do, you can be better than most everyone else. The industry standard for commercial, proprietary code seems to be around 20 to 30 bugs per thousand lines of code; the Linux kernel has less than 1, and is known as a cesspool of bug-infested muck, so surely you can do better?
6. Learn to write prose well. Then write a lot. If you can't write a README, a manual page, or the specification for your next work project, who's going to know about your great programming?
7. Oh, you need to learn how to program well as well, and that isn't so easy either. Knowing how to program well merely isn't enough to be a successful programmer.

Licenses are just too nice... Especially if you put special clauses in the context of the application they apply to. SUN states the following in a code example for the Java Micro Edition.

You acknowledge that this software is not designed, licensed or intended
for use in the design, construction, operation or maintenance of any
nuclear facility.

Now consider that the Java Micro Edition usually runs on mobile phones. Well, yes it’s for embedded devices too, but I found it in a GUI example. If I imagine to control a nuclear power plant by just using my phone in the bus, using a nice little Java application... What a threat I would be.

Finding arm machines is not hard. In fact, everyone of you probably owns some of them. However, finding something suitable for Debian infrastructure usage is harder. For example Buildd load pattern requires not only a decent CPU, but above all good IO performance. Most ARM systems do not have a hard drive, and if they do like on personal media players like Archos pma400, the drives are slow and optimized to minimize power consumption.

Therefor, the logical place to look for machines would the NAS devices, like the already-being-Debianized Linksys nslu-2. NAS machines tend to (relatively) cheap, well available and need good IO performance. The main problem with NAS devices is the lack of RAM (to minimize costs they tend to have 32MB or something soldered to mainboard), so I was more than happy to spot a NAS with 256MB of ram:

Linksys NSLU2	Allnet ALL6500
266Mhz* ixp420	400/600Mhz IOP80219
32MB ram	256MB ram
USB 2.0	2xSATA & USB 2.0
100Mbit ethernet	2x 1000Mbit ethernet
95	350

*overclocked

The real shocker came when reading "Manual englisch": (arrows by me)

This bloody thing seems to have a DIMM socket!

GPL sources seem to be well available. Can someone from .de confirm if the memory is really there? (Why does so many cool hardware never end OEM'ed this north?) IOP80219 supports up to 1GB so it really seems quite promising :)

I've always seen the relationship between users and developers in the Free Software world as fluid and more of a partnership. That means trying your best to fix problems yourself, and if you can't, make it as easy as possible for other people to fix it. Here's an example of a bug that isn't helpful:

The user tried to install
http://ftp.mozilla.org/pub/mozilla.org/extensions/sage/sage-1.3.6-fx mz.xpi
He is told he needs to edit his preferences to permit this, and given a button.
It turns out instead he needs to edit about:config, and set
xpinstall.enabled = true.
And indeed when he finally does, installation fails as it is an
invalid file or something.
One would be much more confident if there were a debian sage package.

It is not at all clear what the submitter is complaining about. Do they object to the preference setting for software installation? Is there a bug installing extensions? Or do they want sage packaged in Debian? Bug reports should make it clear what the submitter thinks the single problem is. When asked if the were really wanted an RFP bug, the response was:

Please reassign it that way if that is correct. All this is over my head.
Thanks.

If you've submitted over 1000 bugs maybe learning how the bug system works and is organized is a good idea? I'm not trying to attack Dan, but he is a good example of not being helpful.

Thanks to everybody who wrote in with suggestions following on from my initial Ruby GNOME investigations yesterday. After talking at cross purposes for some time in a bug report with a Ruby GNOME developer, I was pointed to a good example of how to do what I wanted: subclassing a GObject in Ruby. This is something that the Mono Gtk# bindings do so well, I'd forgotten the required mechanics. Here's a simple subclass of button. I've highlighted the required magic in bold.

class MyButton < Gtk::Button
   attr_accessor :hitcount
   # tell the GLib object system this is a new type
   type_register
 
   def initialize(text)
     super("label" => text)
     self.hitcount = 0
   end
 
   # rather than overriding 'clicked', we must
   # override the signal_do_clicked method
   def signal_do_clicked(*args)
     self.hitcount+=1
     super
   end
 end

The type_register call registers the new class with the GLib type system (something the Mono bindings do for you automatically).  The second key was knowing the name of the default signal handler, which turns out to be of the form signal_do_signalname. So, to follow up yesterday, I hadn't found a bug, merely a gap in the documentation. Thanks to Masao Mutoh for taking the time to answer my questions. For comparison, here's the same implementation in Gtk#. There are pros and cons of both languages. Ruby's succinct attr_accessor is balanced by the neat GObject-aware subclassing and the constructor inheritance of C#.

class MyButton : Button  
        private int hitcount;

        public MyButton (string text) : base (text)
         
                hitcount = 0;
         

        protected override void OnClicked ()
         
                hitcount++;
                base.OnClicked ();
         

        public int HitCount  
                get
                 
                        return hitcount;
                 
                set
                 
                        hitcount = value;
                 
         
  

A while back I started porting the GTK examples from Mono: A Developer's Notebook to IronPython and Boo, the results of which are available in my Subversion repository. Although I've not finished that task yet, I thought I'd investigate the state of the Ruby GNOME bindings by porting those same examples. They have the advantage of increasing gently in complexity. Before I go on, you can find the work in progress posted in the ruby-gnome/monodn branch of my Subversion repository. Now for a few observations. At the basic level, Ruby GNOME has a lot in common with all the other GNOME bindings out there. One distinguishing feature however is signal handlers, which take a Ruby closure as an argument. Look at this handler for closing the window, for example:

w = Gtk::Window.new("My Window")
w.signal_connect("delete_event")   Gtk.main_quit   

This is fine for simple handlers. Developers wanting to reuse handlers might wish to specify a method here to use. The best way of doing this I've found is:

def my_handler(but)
     ...
end
 
button.signal_connect("changed", &method(:my_handler))

This involves a little bit more magic, as you can see. I've also run into an unexpected barrier with subclassing and the class default signal handler. The subclassing example from the Mono Notebook shows an example of overriding the clicked method of a Button. In C# this looks like this:

class MyButton : Button  
 ...
 protected override void OnClicked ()
  
    hitcount++;
    base.OnClicked ();
  

In Ruby I would write this:

class MyButton < Gtk::Button
 ...
 def clicked
   self.hitcount += 1
   super
 end

However, when you click the button it's clear the overridden method isn't being called. I've filed a bug with what I think is the underlying problem. In this instance, I worked round it by adding a signal handler in the constructor:

self.signal_connect("clicked")    b  b.hitcount += 1  

At the moment it feels like I'm writing rather C-like Ruby, rather than it being idiomatic. But then again, I am porting examples from C# in as literal manner as possible, in order to facilitate comparison.

This is a blog entry I wanted to write for about six weeks now, but I was busy with other stuff. In December 2005 I got curious why 2.4.32 wasn't packaged for Debian and investigated the situation a bit.

There are several reasons why 2.4 is still interesting:

- Kernel 2.6 is still a moving target...

- Some hardware is only supported with 2.4, for example older laptops which need APM and don't work with ACPI. Also some non-i386 machines.

- According to popcon, 6-7% of the i386 users have a kernel-2.4 image installed.

Unfortunatly, nobody from the kernel team is really interested in working on 2.4 anymore. They do security fixes for the 2.4 kernels in woody and sarge, for which I'm very thankful, but that's about it.

Even though 2.4 is moving very slowly nowadays (mostly security updates, very seldom new drivers are including), this is more work than needed, because every fix needs to be backported to 2.4.27 (and 2.4.18 for woody).

Of course there are some issues which need to be taken into consideration when thinking about whether it's worthwhile to have 2.4.3x in Etch:

- it needs gcc-3.3 to compile, gcc-4.0 won't work. Period. So gcc-3.4 also needs to supported during etch's lifetime - which will be something like 2009 when etch+1 will become oldstable (by current release cycles)...

- it's not sensible to have powerpc and amd64 flavors, and probably others. So this kernel package will not be arch any. (Which is not really a problem, but unusual.)

- Both kernel 2.4 and 2.6 contain non-free firmware and drivers. I seriously doubt people want to deal with this issue and solve it for 2.4. For 2.6 it will be done, but for 2.4 ? As I see it, this is the biggest showstopper for 2.4 in etch, I would be happy to be proven wrong. As a starting point, you can look at this investigation by Bill Allombert about the the situation in 2.4.25.

Removing those files would be an option, but maybe we can also "borrow a better solution" from 2.6...?!

- if 2.4.32 or .33 shall be used in d-i/g-i, work on this integration needs to be started real soon now.

I have done some work on creating a linux-2.4.32 package which is based on the new kernel packaging. I got busy with videos for debconf-es2, so I didn't finish and commit this.

Horms made a presentation about the kernel packaging in debian for LCA and gave two options: a.) support and backport fixes for 2.4.27 or b.) go with 2.4.32. Somehow he did not consider the option of dropping 2.4 even if he calls it legacy ;-)

Besides technical reasons (security fixes handled by upstream, some driver updates and very few new ones) I think we should not forget that most people have no idea that 2.4.27 in debian is far closer to 2.4.32 than to .27, and therefore will think debian ships an outdated 2.4 kernel. So I think we should simply go for 2.4.3x, if it is sensible to support 2.4 in etch at all.

It "just" needs to be done, and I volunteer to do it (with the help of the kernel team, the porters and anybody else who wants to join), if this work will not be in vain.

Please send comments to the debian-kernel-mailinglist, where I posted this blog entry before. Thanks.

Al Gore, former vice president of the US, has given a very, very interesting and impressing speech on Martin Luther King Day a few days ago. He states very clearly a huge number of (unlawful, illegal, or immoral) things the current US president Bush and/or his administration have done. For example:

• illegal wiretapping of American citizens
• illegal imprisonment of American (and other) citizens
• illegal torture by the CIA
• illegal kidnapping of people
• suppression of free speech by threatening NASA scientists
• and lots more

A quote of Al Gore, from a small Reuters summary of the speech:

We still have much to learn about the NSA's domestic surveillance. What we do know about this pervasive wiretapping virtually compels the conclusion that the president of the United States has been breaking the law repeatedly and insistently.

Transscripts are available from The Raw Story and the Washington Post, and there's also a full audio recording of the speech (MP3, 48 MB). Although I'm not very political usually (or at least I don't write too much about it), this is really something I highly recommend listening to. I cannot imagine why a president of a democratic country can still be in charge, after all these things have become publically known... (via Tim Pritlove)

This week is Regents week in New York, so juniors and seniors had Thursday and Friday “off” — meaning you only go to school when and if you have an exam, at least in my district. Today I had a great time leaving the house at 2:20-ish on bike to hand in my Engineering final report, which was due at 2:30 today (the end of the school day, in essence). Needless to say, I barged my way through hordes of exiting freshmen and handed it in at approximately 2:27. Nothing like punctuality. This week’s been busy, heh. In other news, combined with biking back and forth to the school for my Calculus midterm this morning, I’ve put in about 5.8 miles today. Bwah.