In September, the Debian GRUB maintainers took a step further in the long way of deprecating grub in favour of grub2. From my personal point of view, grub2 is not the way to go. Mostly because of these reasons:

• I don't have systems using a non-ext 3,4 filesystems.
• I don't have use for any of the grub2 advanced features.
• I don't want to wait another few seconds until grub2 has been loaded.
• I don't want to learn yet another theme-ing mechanism for bootloader splashes and menu structures.
• I don't want to use a different bootloader project, regardless from which media I boot (iso, usb-hdd, netboot).

Back in Juli, when I was listening to the talk of Giacomo Catenazzi at DebConf 9 about bootloaders in Debian (high (618MB), low (110MB)), I was reminded that I really should getting EXTLINUX splittet out of Debians syslinux packaging and made available as an alternative bootloader within Debian. Last week I hacked together an initial working version and uploaded it to experimental. Note that the two comands extlinux-install and update-extlinux do not have all the safety belts yet, the theme-ing mechanisms are not integrated yet (I'll upload a syslinux-themes-debian soon), and that the layout of the generation of the config files in /boot/extlinux may could change (debian-wise, not upstream-wise). For me, it works already well though, I'm using it on my main desktop and notebook. If you want to help finding bugs or submitting wishlist bugs for additional stuff to be added, and recovering from an unbootable system is not a problem for you, you're welcome to try it out:

	# apt-get install -t experimental extlinux syslinux-common
	# sed -i -e 's ^postinst_hook =.*$ postinst_hook = update-extlinux ' \
		-e 's ^postrm_hook =.*$ postrm_hook = update-extlinux ' \
		/etc/kernel-img.conf
	# mkdir -p /boot/extlinux
	# update-extlinux
	# extlinux-install DEVICE

Update: Rather than having /etc/kernel-img.conf modified by users, bootloader packages should add symlinks to their update scripts to /etc/kernel/postinst.d and /etc/kernel/postrm.d. Uploaded new version to experimental. Thanks maks for mentioning it.

A few of us are working on spam removal from Debian lists archives. The wiki page linked above explains how to report spam on Debian mailing lists. This is in short as easy as bouncing a mail to a specific address, from your favourite MUA. These "reported spams" then need to be reviewed. Once a given message has been identified as "spam" by enough DD's (there are many false positives in the candidates, particularly in non English-speaking mailing lists), it is removed from the archives. Many mails have already been removed and any help is welcomed. Since Frans Pop launched this for debian-boot, back in May, I use 1 or 2 hours every Sunday to this work. After working on debian-boot only, I gradually worked on reported spams in other lists. As of now, I only have 4 lists where I still have work to do:

• debian-user (115 of 2420 reviewed)
• debian-user-spanish (177 of 1157 reviewed)
• debian-devel (136 of 1075 reviewed)
• debian-chinese-gb (159 of 556 reviewed)

The Chinese and the Spanish ones are tricky because identifying spam there is much less easy (for Chinese, I'm quite conservative and only tag very obvious spam....for Spanish, I read enough of the language to be able to target spam). What about you? Will you be able to help the few of us who work on getting clean archives (noticeably, Sandro Tosi, Giacomo Catenazzi, Cord Beermann, Luk Claes, Frans Pop, Bastian Blank, Luca Falavigna, Michael Koch, Bernd Steinmetz, Thoomas Viehmann, Florian Ernst, Adam D. Barratt, to name thos ewho reviewed more than 1000 mails)? Working on lists in your own language might be a good idea (I'm particularly thinking about lists in German, Spanish, Chinese and French).

On debian planet. I read the C and multithreading post of Miriam Ruiz, but I don't agree with some conclusions:

First of all, I don't agree with Linus. C standard doesn't allow such optimizations. One of the driving point of C standard (and thus C) is that compiler should do what a programmer write, without much optimization, i.e. C should remain a low level language. It was iterated also for the principles of new C1X standard.

Second point. Volatile is not the right solution. volatile means that a variable should be read every time it is accessed, so the variable should not be but in registers (remember the nearly obsolete register keyword).

The problem of multi threading is not only that variables could changes (but this is a fact also of
single thread programs, when you write a signal handler [which are specified in C standard and which are handled correctly]), but for semaphores there are "barriers", i.e. you should not move read or write across such barriers.

What do volatile have with barriers? Nothing. If you read the standard (you can check also only the one page C appendix), you see that C specify what are the "standard" barrier, and they are nearly in all obvious points (i.e. a ";" is also a barrier), so moving instructions is "illegal" for C.
Ok. volatile had few other barriers, but across ";" there is already a barrier, so volatile is not the solution of barrier problem (AB locking).

References: see C wiki and C standard.

This weekend I finally finished the Linux Kernel Driver DataBase . Really I started this project in 2000, but in 2001 after some flames in the LKML (for CML2, the configuration engine used by my project) I put the project in a long hibernation. Now I had some time to finish it.

LKDDb is a database of hardware (and protocols), kernel configuration items and associated kernel driver files. Actually it has nearly 6000 entries (see the statistics). The database is generated automagically, quite fast: it take 2 minutes to scan the whole kernel source, and to interpret it. Unfortunately it is not complete and not accurate (I'm not sure if there is some black-list in kernel, but my scanner cannot distinguish the black-list with the supported hardware list).

Now I'm looking for some application of the database. In 2001 it seemed that there was some interest, but let see.

As a prototype, I dis-hibernate also the AutoKernConf, an automagical kernel configuration. The old version was a more powerful, so I need to forward-port some old features. BTW I changed an other time the project name: autoconfig was too similar to existing projects, kautoconfig, kernfig, kernautoconf were other names, but I like better the new name, and I can use the automagical word in the description ;-)

Do you see other uses of the database?

Yesterday ICANN published an interesting article about last attack of root servers (6 February 2007): see http://www.icann.org/announcements/announcement-08mar07.htm . The paper is not so detailed and technical as one should expect, anyway it is worth to read it.

It seems that also the remaining root servers should move to anycast. I think this is good, but it will works reliable with TCP? Do someone use TCP to query DNS servers? Why is it not disabled? It seems that all root servers accept TCP ( dig @l.root-servers.net. . NS +tcp).

A side note: as you can see, root servers don't give you yet the IPv6 addresses of root servers. Now they do some test, prior to broke the root server 512-bytes packet rule. We are still away to the full IPv4/IPv6 inter-operative nets.

The last recommendation is: "ISPs should only accept DNS queries from trusted sources (i.e., their own customers) rather than allow anyone to use their servers." . This rule (on recursive queries) is already a well know rule, and I I think it is less problematic of mail-rely (ev. with SPF), but on the other side, we are moving to the point that we should trust our ISP and our ISP will firewall "non-proxied" traffic.

As last point, the fact sheet cite two wikipedia articles. Wikipedia is so good, or there are not better (updated) documentation on the net?

From time in time I was looking how to run a command with a timeout (in a shell script). I never put big efford to find the solution, because I always found a easyer (and probably better) workaround. But few days ago, in a discussion in the austing group (POSIX standardization), I found the solution, in an elegant manner, and it permit also to run commands in parallel.

The solution (it works on bash, dash, and it seems posix compatible, but you should test, because the discussion was about the different behaviours of $! in bash and kornshell):

 # run command1 in background, and the sleeping killer
command1 &
pid=$!
( sleep 60; kill $pid ) &
# other stuffs
command2
# wait command1
wait $pid

Note: kill (the shell buildin) prints some error messages, which you should filter
Note: Security: the methods is not very clean and secure. If an user can force system to recycle the PID, the scripts could do unintended things.

I this trick can be used to parallel the init script (parallelize within the script, not "run scripts in parallel", as the current trend).
So another short tip: Debian sleep support "floating sleep", so use sleep .1 istead of sleep 1, to speed up the init scripts (module loading, waiting for devices, net,...). Unfortunately most of the debian scripts use integer sleeps.