Debian describes itself as the Universal Operating System, and basically tries to run in the same way everywhere, from an NSLU2 to an s390.

I find it funny to see the number of Ubuntu variants. I can understand that for marketing reasons (Debian doesn’t really know about marketing), it is good to advertise Kubuntu, Xubuntu, etc. Even if it’s the same distro and the same packages. But seriously. An Xubuntu EEE now.

I’m the happy owner of an Asus EEE PC, running Debian. Installing Debian on it is quite straightforward, and only requires you to install the module for the ethernet NIC (available as Debian package), to compile the madwifi driver (non-free, patched version needed) for Wifi, and hack a few scripts in /etc/acpi if you want to get the hotkeys (volume, etc) working. Nothing impossible, really. And for those not familiar with the command line, some detailed documentation could be written, or a Debian package or a script that does all the tuning could be provided. (I think all of this has been done already anyway)

But an new Ubuntu derivative! Just for that! Are we going to see a new Ubuntu derivative for each new laptop that is not perfectly supported yet? Hey, my desktop PC’s keyboard has some hotkeys that don’t work properly without hacking .xmodmaprc. Can I get my Ubuntu derivative? :) Also, GNOME works perfectly on the EEE, and I assume KDE does as well. What about Ubuntu EEE, and Kubuntu EEE?

Now, let’s watch the flow of blog posts from Ubuntu fans acclaiming the release of the Xubuntu EEE.

Comments closed, trackbacks open.

Andreas Schuldei writes about my blog post about making it easier to contribute to Debian:

It is much more gratifying for a contributor if his effords have
immediate effects.
[…]
So what can people who want to help Debian do to achive more imminent gratification? Pick projects that let you help directly with direct svn/git/whatnot access (Security team, Debian Edu, Debian-Installer…)

While I agree that Instant Gratification is very important, I don’t think that the proposed solutions solve anything. It’s easy to have things sleep in an SVN repository instead of the BTS (lots of teams do that, sometimes for good reasons, like the lack of sponsors – hint: Games team). It doesn’t make things any better. What we need is tasks whose results will be available without too much wait in Debian unstable, for everybody.

Also, I must admit that I know very little about the inner workings of the Security Team. But I have the idea that it involves quite a lot of procedures (helping with bugs tagged security probably doesn’t, but going further than that probably does). Contributing to Debian already involves A LOT of procedures. A new contributor, even very good technically, can easily get lost in all the different ways to package stuff and solve common problems. So we should identify tasks that don’t have huge requirements. Ubuntu has the concept of bite-size bugs.

I started working on a page explaining the different ways someone can contribute to Debian. The goal is to provide a good entry point (not something that replaces existing documentation) and keep it at a manageable size. Its focus is mainly to replace the emails we write to people asking “I’d like to contribute, but I don’t know what I can do or where I should start!”. The page is available on wiki.d.o/HelpDebian/Start. Don’t hesitate to improve it (see also wiki.d.o/HelpDebian for a TODO list). When it will be good enough, I plan to move it out of the wiki (the content shouldn’t change much anyway) to eg http://help.debian.net/, so we can improve the design (I really like the idea of adding pictures of past Debconfs like Christian Perrier did in his FOSS.in talk).

Andrew writes about Python, Perl and Ruby:

Ruby has some nice things (like Perlish regular expression handling), but it brings back all that punctuation noise again.

He gives an example of punctuation noise in Perl:

I go back to Perl and my eyes bleed after trying to dereference a reference to a scalar, or something like that. It’s just ugly in Perl.

I don’t think that’s fair to compare Perl’s ponctuation noise with Ruby. Ruby has a feature that could qualify as punctuation noise, but it’s really a feature: variables are prefixed with their scope. For example, class variables start with @@ (@@var), instance variables start with @ (@var), global variables start with $ ($var), and constants are in CAPS.

I don’t know if Ruby “invented” that, or if it comes from another language (it’s probably the case: Ruby takes a lot of good ideas everywhere).

Also, Andrew, joining elements of an array in ruby is written myarray.join(” “), and Ruby has =~. So you should definitely give Ruby a try ;) No, seriously, Ruby is a really interesting language. It’s really a shame that it’s still so japanese-centric (most development decisions are taken on a japanese mailing list !!), since it’s not really help a wide adoption.

The current status of the NM process, with 1 NM awaiting FD approval, 7 awaiting DAM approval, and 30 waiting for their accounts to be created, leads people to thinking that the big bottleneck is the account creation stage. However, when you look at what happened since december 2005, it’s not that simple.

See the graph linked above, which shows where people are waiting. While it seems that the FD stage hasn’t been blocking people for nearly a year, it’s the DAM stage which has been the biggest blocker. Indeed, on average, 8.3 NMs have been blocked by FD, 16.2 by DAM, and 9.0 by account creation.

I understand that processing NM reports in batch mode makes it more efficient. However, I’m wondering if processing them 20 per 20, is really that more efficient than processing them 5 per 5, which would justify such long queues. The NEW queue, which used to be a problem, is now being processed on a very regular basis, and hasn’t grown widely recently, except after Debconf when the ftpmaster processing NEW was on VAC. Couldn’t we have the same thing for DAM, account creations, and while we are at it, removals from unstable? Having clearly defined human-crontab-jobs would certainly make working on Debian less frustrating.