As a followup to the talk given at Galway Astrofest 2007 by Dr. Aaron Golden on work done by the Cool Stars research Group here at NUIG, the detail of this work were announced this week at the RAS National Astronomy Meeting 2007. Other press releases can be found at Spaceflight Now, and NRAO, though the best summary is probably at the NUIG Webpage (Thanks to Ronan Newman for the links). Kudos to all involved: Gregg and Stephen are currently writing up their PhDs and should have an interesting dissertions from this. Basically, they discovered that some Brown Dwarfs can act as Pulsars, blasting out huge amounts of radio-wave energy. Brown Dwarfs are objects between 'Planet' and 'Star' in mass terms, often thought of as boring failed stars, not large enough to ignite into fusion. They were thought by most to be highly boring : this discovery was completely unexpected. As the group in Galway has a lot of pulsar experience, they were well set to explain this. It looks as though this phenomena is due to a 'coherent maser' : an effect seen in large planets such as Jupiter, where the magnetic field spins up electrons from a solar wind. Certainly, it makes Brown Dwarfs, undiscovered until 1994 but thought to be widespread across the universe, more interesting things to look at.

Two semi-related things. Firstly, I just got notice that North Somerset Council are going to let North Somerset Housing pointlessly tarmac over a square of grass near us. Planning application 07/P/0464/F claims to provide 3 additional car parking spaces, but it tarmacs 7m width of grass while marking 6m width of current tarmac as no-parking: a net addition of 1m! Not enough for even one additional car! Now they've made this officially-acceptable reasoning, I reckon it will feature in a planning application for building more houses on the village's green spaces. How about: you can build a new house as long as you mark an existing house as uninhabitable? Secondly, Clevedon residents are petitioning the Prime Minister to stop Tesco expansion as reported in the Mercury. Expanding the Tescopoly in Clevedon will harm what already looks to me like an endangered town centre. OK, it's not the PM's responsibility to stop one store expanding in one town, but it is his government's planning policies which are aiding and abetting the continued growth of unsustainable 'big box' stores. I can see Clevedon from my office window. I'd need binoculars to spot Morrisons, but I think Tesco is visible with the naked eye already from the top of Worlebury hill. Every Little Hurts but they just keep on rolling like Renard, not noticing the pain.

I just released new version of Gammu, you can download it from download server. There is quite a lot of changes:

• Work with AT phones which can not write SMS to ME (bug #282).
• Increse limits for SMS backups (this requires dynamic allocation).
• Development switched to Subversion, see README for details.
• Detect Motorola Bluetooth port (Daniel Gimpelevich).
• Fixup AT driver to work with Samsung SGH X160.
• Support for last modified field in vCalendar.
• Adjust vCalendar entries from SE phones on DST (bug #81).
• Fix updating of delivery report date in SMSD (thanks to Peter Stuge).
• Fix format strings for Win32 build.
• Fix crash when no config exists.
• Support for MinGW crosscompation with MySQL.
• Support for MinGW crosscompation with PostgreSQL.
• MakeTerminatedCall can be now called more times in batch mode.
• Support for MinGW crosscompation with Gettext.

As I can now build full featured Gammu binary for Windows, the download size increased a lot. If you thing it is too big, I can start to produce two sets of binaries.

There are a lot of pages out there explaining how to convert your mail from mbox to maildir. I’m going to add one more, resurrecting the “tips” section of my blog. (All the tips from my blosxom days are grouped together on one page — someday I’ll get around to breaking those up properly.) If nothing else, I’ll never have to write these instructions in an email to someone again, instead I’ll just send them the link to this entry. I hope these steps are specific enough so anyone savvy enough to even have this problem in the first place will be able to follow them. One thing I find consistently concerns people when converting to maildir is how to make sure no mail is lost in the transition. The steps below address that concern. It’s really not hard at all once you understand how maildir works. First, I’m assuming you have mb2md installed and procmail support. Also, if you plan to access your mail through IMAP, your IMAP server needs to know to use ~/Maildir if ~/Mail does not exist. This is often default behavior (at least it is for Dovecot). Finally, I assume that your inbox is in /var/mail/username, and your other mail folders are in ~/mail. So, here goes:

1. Edit your .procmailrc. The first two lines should read:
   MAILDIR=$HOME/Maildir
DEFAULT=$MAILDIR/
   This will cause all new mail to be delivered (after you save your .procmailrc) to be stored in maildir format under ~/Maildir. The key for procmail to know to use the maildir format is the trailing slash in the “DEFAULT” line. Note that under the new system, your inbox and all your folders are kept in ~/Maildir, rather than having an inbox in /var/mail and your folders under your home directory. (This is nice because it makes it easier to back up all your mail together, among other things).
2. If you have any specific procmail rules in your .procmailrc, you’ll also need to change the target folders for that. For example, if you have a spam filtering rule like this:
   :0 H
* ^X-Spam-Level: *****
spam
It needs to be changed to this:
   
:0 H
* ^X-Spam-Level: *****
.spam/
   The trailing slash, again, tells procmail to use maildir rather mbox format for delivery. The leading dot will make the folder appear properly for your IMAP client (there’s a trick I suggest below for making “dot” folders easy to access with a command line client like mutt).

If you have mail being delivered to a nested mail folder, an additional change is needed because maildir has a flat hierarchy. So if your mail was being delivered to “misc/other/spam” the new target should be “.misc.other.spam/”.

Save your .procmailrc. From this point forward, all mail will be delivered to your maildir folders. You can now import all your old mail to the new folders without concern. Since maildir stores each individual message as a separate unique file, you don’t need to worry about any overwriting issues while you are making the transition. New mail will be delivered to newly named files; old mail will be imported to other, unique, newly named files.

Import your mail folders:
mb2md -s ~/mail -R
The -R just means to import recursively through all your folders; if your mail folder is Mail rather than mail, use that instead. No destination is needed because mb2md uses ~/Maildir by default.

Import your inbox:
mb2md -m

Move your old inbox out of the way. Most people won’t actually be able to move or delete files in /var/mail (since they don’t have directory write privileges), so the easiest thing is probably to just open the inbox in your IMAP client or with mutt and save or delete all the messages.

Move your old mail folder out of the way:mv ~/mail ,.bak Once you’ve confirmed that everything is okay, you should be able to delete ~/mail.bak (or compress it and move it elsewhere.) If you saved your inbox to mail folder in step 6, that will get moved out of the way here as well.

That’s it, you’re done.

Okay, so you’re not quite done if you access your mail with mutt rather than an IMAP client. (You could just point your mutt at your local IMAP server, of course). I’ve found the most convenient way to access the “dot” folders with mutt is to create a parallel symlinked folder structure without the dots. Here’s a hacked-together shell script that will do that. This could obviously be rewritten to be much more elegant (probably in perl). But we all have our messy scripts, right?

#!/bin/bash

cd ~/Maildir for x in .*
do
y=$ x##.
if ( echo $y grep -q ‘.’ )
then
mkdir -p ~/mymail/$ y%.*
fi
ln -s ~/Maildir/$x ~/mymail/ echo $y sed “s/.///g”
done for x in *
do
ln -s ~/Maildir/$x ~/mymail
done
Then, just add these lines to your .muttrc file:
set folder="~/mymail"
set spoolfile=”~/mymail” Any questions?

Desde su concepci n, Planeta Linux ha exhortado a sus participantes a sindicar contenido exclusivamente relacionado con tecnolog a, computaci n, software libre y Linux, en orden incremental de preferencia. Pronto se determin que la exhortaci n no era suficiente y se pas al requerimiento. H ctor Colina y Milton Mazzarri, por nombrar dos venezolanos, estuvieron involucrados en los Lineamientos y las Preguntas Frecuentes de Planeta Linux Venezuela. Como para ese momento ya hab amos hecho un grupo inicial de “venezolanos con blog que hablan de Linux” (b sicamente gente de VELUG, SOLVE, Debian Venezuela y de unplug.org.ve), no tuvimos la oportunidad de requerirles que tuvieran una categor a dedicada a Planeta Linux. A las nuevas personas que se inscrib an por la lista, en ocasiones se les requer a la categor a si su blog conten a, a primera vista, contenido no relacionado con Linux. En todos los casos, se requer a estar de acuerdo con los Lineamientos. En el caso de las personas que me solicitaban a mi directamente (que desde hace no mucho tengo acceso al SVN de Planeta Linux) yo les requer a una categor a particular, a menos de que su software no lo permitiera. En este ltimo caso, muy a pesar de los quejones de oficio, elimin bamos a la persona de PL. Es el caso de Luigino Bracci, quien en alguna ocasi n lleg a llenar todo Planeta Linux con contenido pol tico parcializado, y quien manifest que su sistema de blogs no le permit a agregar categor as. Hay casos en los que una persona que escribe poco o que suele escribir de Linux llega y hace algun desastre al estilo Alberto Capella con su foto a tama o gigante. En esos casos alguien se da cuenta y me avisa (aunque es un error, al final de la p gina hay direcciones de contacto y en Venezuela somos varios que administramos!) pero estoy involucrado en muchas cosas como para dar respuesta inmediata a ese tipo de casos. Y ah viene otro problema. En Planeta Linux NO PODEMOS moderar un post o a una persona. Solo podemos suspenderlo o eliminarlo. No podemos borrar una imagen ni un post ni nada, porque en 15 minutos perdemos los cambios. Espero que eso de algunas luces cuando haya algo de que quejarse en Planeta Linux. El ltimo caso es particular. Jes s Lara hizo varios posts no relacionados con Linux en su blog. Particularmente hubo gente que reclam que hab an recien escrito algo relacionado con Linux y los posts de Jes s “empujaron” los posts relacionados con Linux hacia el final del Planeta. Por lo tanto suspendi la suscripci n de Jes s y lo contact el 9 de Abril. Cre una categor a y me lo comunic . Eso es suficiente para volver a reactivar su suscripci n (en este caso me tard unos d as porque el commit fall y nunca me enter de ello, ni Jes s me lo inform , realmente) Ya hay mucha gente que sindica categor as en PL, y pronto ser n muchos m s. Cont ctenme si quieren hacer el proceso pronto. Por favor, la pr xima vez que encuentren un problema en Planeta Linux:

• Av sennos a Milton Mazzarri, David Moreno Garza o a mi, o a trav s de los medios de contacto de Planeta Linux. Podemos ayudarles, y el trabajo voluntario no nos excluye de responsabilidades.
• Den ideas y soluciones, que son muy bien recibidas. No den cr ticas ni flameen, porque recibir n lo mismo de vuelta (aqu son bienvenidos todos los que usen Linux en Venezuela, no traigan los vicios de los grupos de usuarios y las listas de amor y dolor)
• Descarten la teor a de la conspiraci n. No todos los que est n involucrados en proyectos comunitarios de Software Libre tienen problemas de cari o ni necesitan pensar que otros los atacan o necesitan meterse en la vida de los dem s. Lo m s probable es que lo hayamos olvidado o no tengamos tiempo. Usen el sentido com n.

Aside from Paul Graham's list of reasons not to do a startup on your own (http://www.paulgraham.com/startupmistakes.html), there's another very simple one: pronouns. It's much, much nicer to be able to write "we" on a corporate web site. "We" could be anything from 2 to IBM's zillions, but it implies a real organization, whereas "I" implies some guy off working on his own. Of course, you could lie and write "we", but that will probably catch up with you at an inopportune moment.

Currently there is a discussion about a new theme for debian.org going on on -www. Some people presented their ideas and build some mockups while others commented them. I strongly suggest to let some professional designers and other (not necessarily Debian related) talented people create some mockups, to avoid moving from one outdated and rusty design to the next. I wonder if we couldn’t open up the process a bit by starting some kind of contest. Skilled webdesigners could create some mockups and we could collect all those and let a vote decide which one to keep.

5 star hotel tips There are things you don't think about until you spend 2 weeks in a 5 star hotel. In 5 star hotels you have a minibar that you're not supposed to open unless you want to be charged something stupid like 10 euros for 25cl of still water claiming to have been bottled in the opposite side of the world from where the hotel is located. But on top of the minibar there are glasses you can use for drinking, and an ice bucket you can refill in the corridor. This allows you to put ice in tap water. If the tap water is undrinkable, buy a 3l water bottle in the nearby supermarket and use the ice to make it colder without upsetting the minibar. Note: this specific minibar has sensors, and charges you the very moment you take things away from the fridge, so it's out of the question to temporarily empty it to put my things in for a while. Now, the ice bucket, the ice clips in the ice bucket and the glasses used for drinking, how do they clean them? Are they sent 6 floors downstairs to the dishwasher? Certainly not. They use the DETERGENT FOR THE WINDOWS. I went to get some ice and realised that the inside of the bucket (and the ice clip to put the ice in your cocktails) smelled like window detergent. Then I sniffed around: same did the glasses, and one had leftover foam in the bottom. So I had to wash the toxic stuff away from them before using them. Now I can assume that I have to wash the glasses every time I need them, as I know that they are not necessarily cleaned with food-safe detergents. So, here's the tip: before leaving the room in the morning, I put glasses and ice bucket back on the tray on top of the fridge, and I put the cheap-pretending-to-be-fancy cocktail mixing plastic sticks back in the glasses. This succeeded in tricking the cleaning people into believing that I didn't use them. As a consequence they didn't clean them, and now I can use them without needing to wash the window detergent away first. Another tip: don't leave your shoes next to the sofa, or the cleaning staff will put them on the sofa when cleaning (sometimes they forget them on the sofa, so you realise). Even better: don't put them next to the bed. Another tip: if the breakfast buffet has only scary things it takes half a day to digest, make friend with the omelette cook.

As some people may know, there's a group of us getting some official Debian Tartan (thanks to Phil at hands.com) kits made up for DebConf 7.
Moray got back from the weavers today, with a nice photo of the tartan being weaved :)

Recently a Debian user left a really nice note letting me know “It makes
me happy and proud to learn that boricuas are Debian developers! (Hopefully you are not the only one). This is for me the best Debian News since Etch released. Proud and happy for you.” Here I have to confess, however that I am neither a DD nor really a true Boriqua. I have studied Debian for many years, but have never officially joined. In terms of PR, none of my family is originally from there as my father is Jewish American and my mom was born in Russian, wandered as war refugee for many years in Europe and eventually landed in Venezuela, where I was born. But I have made my home in PR for many years and do consider it one of my many homes. Speaking of many homes, I also feel, even though I am not a DD, that Debian is an important touchstone in my life. It reminded me of a conversation I had with Manoj recently related to this topic, who almost mistook me for a DD: [biella] who is that DD that wrote an anthro thesis on debian? [08:55]
[biella] he is brazilian [manoj] I was gonna say that the dd who did an anthro thesis on debian
was you, then it struck me that you are not a dd, but I still
think of you as one now, and then it struck me further that
making you a dd might compromise your postiion as an observer After many years following the project, I have grown quite attached to it, and every year, a few months before Debconf I am reminded of this attachment. I have managed to make Debconf only every other year, and usually when I face this fact, a sense of melancholia and slight sadness sets in, especially when I hear of everyone making plans to go. I always start to question my decision to stay back, then hit all sorts of websites for cheap tickets, and start to wonder if I can perhaps manage to complete some work there, which is the main reason this year I am staying away. I then make myself confront REALITY and remind myself that the whole reason I love attending Debconf is because of its extreme vitality, which after a week, leaves you wrung out and tired, because you put so much of your attention and mind, soul and heart in the events. So even if I go for a week, or longer, you usually need a week ore more to recover. I am not sure I can spare such time this year, especially since less than a month after Debconf, I am packing my bags and moving back to the east coast of the United States. And as I learned last year and the year before and two years before, these sorts of long-distance moves take a lot of your time. My longing reminds me of how important it is to celebrate those things in life you love. And while there is more to Debconf than a celebration, much of it is just that, a chance, a space, a place by which and where you celebrate. And since I sit only in the shadows of Debian, I imagine the pleasure and joy runs deeper and wider for those who sit at its heart. So if you are on the fence on whether to go, this is your friendly public service announcement that it is, indeed, so worth your while.

I've rewritten Notetak, my search centric note taking application for GNOME. The goal of the rewrite was to make the code clearer, and to get test coverage to 100% on the statement level. Both goals achieved. Functionally, the new version should be identical to the old one, but I'm sure I missed something. Now that the code is clean again, I expect to start adding new things every now and then.

The short answer is no, but as our status page easily reflects, there has been lots of work going on during the last two weeks, once etch's release unblocked the way to upload new versions to unstable. This post intends to resume the trend of updating on the status of GNOME in Debian, after we ended up deciding we'd ship etch with 2.14 for a number of reasons, most notably some complications with the GTK 2.10 transition at that time. You'll be able to find other related news items in Debian GNOME team's website. What has the Debian GNOME team up to during the last 6 months? Our first priority was to focus on unstable's GNOME 2.14 packages again, in an attempt to fix any outstanding remaining bugs from our packaging, and get them in the best shape possible to deliver a polished GNOME desktop for etch. I think the result is really good, and Debian's default GNOME desktop is both very usable and attractive. In parallel, the preparations for a complete set of GNOME 2.16 packages continued in our Subversion repository and kept appearing, little by little, in experimental. The most visible consequence of our 2.16 efforts translated into nobse's backport of 2.16 for etch, which can be found in the corresponding repository. And then, with etch deep frozen and nearly ready to be released, GNOME 2.18 was released, and of course the GNOME team didn't wait too much to start working on it. Our current status is looking good: the Developer Platform is already available in unstable, although buildd's are fighting the builds on various architectures. When the dust settles (GTK 2.10's landing has generated quite a big cloud; we have a list of packages that still haven't completed the GTK+ 2.10 transition), we'll be able to prepare and upload the more complex Desktop components like the panel, nautilus, evolution or control-center. Unstable users should probably be seeing daily progress on this front, so keep an eye on your package managers! Although Debian 4.0 released with an old version of GNOME, vast amounts of time and work have been invested to release it with the necessary backported fixes and enhancements. The newer GNOME versions have been available in Debian official ftp archives in very reasonable timeframes; this has only been possible thanks to the restless efforts of the (fortunately) growing Debian GNOME team members: giskard, feedback, HE, lool, np237, slomo, shaka, sjoerd, xaiki and not forgetting our incredible bug triager, svena. Thanks! On the behind the scenes department, it's a pleasure to report that Lo c Minier and Jordi Mallach very recently joined the GNOME Foundation's board of advisors in representation of the Debian Project, replacing Matthew Garrett, who has been representing us for the last few years until he left the project. Thanks, Matthew!

Who are the next generation of Debianists? Are they all still coming to us out of different OS backgrounds, or do we now have the significant beginnings of a home grown generation, born and raised in Debian-using families and now making their voices heard? I hope that Debian Jr. will encourage this kind of generational growth of the project. When recently I rewrote the guiding principles of Debian Jr., my vision was a Debian that children would identify as their own. I expect they will be eager to add their own ideas as they grow up with it. It was pointed out to me today that there is some evidence that this is already happening (thanks for the link, Matthew Wilcox). As for my own kids, ages 16, 15, 12, 9 and 5, only the oldest have ever used some system at home other than Debian¹. They all comfortably use our Debian systems daily, discussing regularly with me what they need. This leads to filing bugs and patches on their behalf², and inspires further development of the Debian Jr. project. So, in at least this sense, the children of Debian are already contributing members of Debian, if not voting members. The ideas of families are improving Debian for everyone. As the project grows, I expect the ways in which families will change Debian will be more significant, not only technically but also in Debian’s character.

¹ Before we started using Debian in 1995, the family system was a VT-420 terminal connected to the Solaris system running our community freenet. At that time our kids would sit in my lap and play at typing into pico for their amusement.

² For instance, I was pleased to discover the other day that my egoboo patch was accepted. That was a direct result of my kids asking me to make it work for them.

Gunnar is following up on the init script blog posts by Erich and me. First a note to Gunnar: The idea of the init scrip snippets isn’t exactly my own idea, but rather taken from a comment to one of Erich’s posts (IIRC), I don’t know the original author anymore. Anyway, I really think that some init script generator should work. It should even be possible to fetch variables from /etc/default/<daemon-name> if needed. I’m just doing a braindump of what I have in mind for the start and stop of a daemon. I would expect a configuration file (currently I think one for each operation might be best, but INI-lookalike files might also be OK). So for the start operation, I would expect these options:

1. simple daemon, uses a default config with a hardcoded path and needs no options or only static options passed:

   [SIMPLE]
   /path/to/daemon
   option 1
   option 2
   option 3
   

   Where I chose to name one option per line so whitespace and controll characters can be part of the options without the need to quote anything.
2. a bit more complicated, needs a few variables from /etc/default/daemon:

   [TEMPLATED]
   /path/to/daemon
   option 1
   %PARAMETER_FROM_ETC_DEFAULT%
   --parameter=%ANOTHER_ONE_FROM_ETC_DEFAULT%
   

   Where the script generator would have to make sure that the parameters from /etc/default are filled in at runtime. I would expect POSIX-Shell-Scripts in /etc/default for this.
3. Really complex: A custom script snippet is needed which has to do some specificc tasks, like cleaning possible stable locks which had been left behind.

   [SCRIPT]
   rm /var/lock/daemon.lck
   /path/to/daemon --background --and --other --options
   

   Where the script generator would simply take this script and use it where it would otherwise generate its own code.

As for stopping, I generally see only three options for the sysv-like background processes: Either a script is needed (see above for how that would look like) or a process needs to be killed according to a PID-file or the process name (with the later being rather bad). So this would result in:

1. [SCRIPT] like for starting the daemon
2. killing by PID-file:

   [PIDFILE]
   /path/to/pid-file
   

3. killing by process name/executable:

   [PROCESS]
   binary
   

   or

   [PROCESS]
   /path/to/binary
   

   where the generator would either only look at the name of the process (first version, no full pathname) or for a process with the given executable (from /proc/ /exec, I would expect).

Alright, this would leave the cases of running (instead of backgrounding) the server and stopping such a running server (the later should be fairly simple unless the stopping of the server requires additional actions other than simply killing it) as well as the reload/restart/status stuff. But these should also be relatively simple actually. What would be interesting for me:
Does any init system require information that is not part of the following list? I would plan with supplying information how to:

• start server in background
• start server in foreground (without the need for a terminal)
• determine wether a server runs (status)
• determine wether a server is ready to serve requests (also part of status)
• determine wether the server is installed (and able to be started)
• stop a background server
• stop a foreground server (unless specified, a simple SIGKILL to the process is assumed)
• restart foreground server (unless specified, a simple stop-start cycle is assumed)
• restart background server (unless specified, a simple stop-start cycle is assumed)
• reload config (unless specified, it is assumed that reloading doesn’t work and a restart is needed)
• reopen logs (unless specified, the “reload config” operation is assumed to do this)
• some meta information: short description, needs writeable filesystem(s) mounted, needs a certain daemon to be running already (or even: able to serve requests), enhances other daemon X and should be started before it (don’t care if X isn’t installed/configured), is enhanced by daemon Y and should be started after it (don’t care if Y isn’t installed/configured), replaces daemon Z, should only run once at startup, …

Finally, even with all that information available inside a Debian package, this would still leave one question unanswered: Who triggers init script generation? If a daemon package does so in postinst: How do I switch to a different init system? If the init system does it in postinst: What happens to additional daemons installed later on? If they get regenerated during system start: How much penalty does that cause? Currently I think the route to go is to provide a command to daemon packages’ postinst that (re)generates only the needed scripts for that package and have a command used in an init system’s postinst which regenerates all of them. That should do. Regenerating during boot would most likely take too much time and has other problems, too, like the availability of a writeable filesystem to store the generated scripts.
Alright, if someone would like to see this post (or rather parts of it) on the Wiki page about an Init HackFest, please transfer it there yourself. I’m currently not able to log in, for whatever reason.

First of all, sorry for the delay. Leaving just as the discussion gets started is bad, yes... But I'm only now reading Erich's and Sven's follow-ups. Both (as well as some comments in my blog) ask why not integrating the startup links in each of the packages - Well, basically because I don't think that most maintainers will take care to do this, and we will end up having a situation very close to what we have today: If I'm not interested in supporting your favorite init system in my packages, I just won't bother to make the scripts.
Note: I'm going into braindump mode. Verbose blabber and some stupidity might follow ;-)
Think on the webapp scene - Most webapps ship with an Apache-like snippet so that http://yourserver/thisapp just works(tm). I love that, and it's one of the little details that make Debian shine - Things usually work with the least administrator burden possible. But it happens that there are other web servers around there - They just become somehow second class citizens (I happen to sponsor/comaintain Cherokee, for instance), as nobody cares to include the equivalent snippets for them. Apache is the standard, and is good enough.
The same goes for sysv-rc: It just rules the world. Who will work all the needed patches to support all the different init systems? As the maintainer for a simple package which requires to be started up, I probably won't care to even understand all the intimacies of every init system, at least until they all have a decent user base. But by having one package per (server,init-scheme) pair, any maintainer can come up with the needed initialization.
Of course, this degrades quickly. First of all, as a user: if mydaemon is not correctly starting up, I will probably file bugs at mydaemon, not at mydaemon-initscheme. If mydaemon changes its parameters, we will witness transition of mydaemon-*.
Further, remember this is Debian, and volunteer-work has its downsides. If the mydaemon maintainer is a primadonna (or just does not give a flying crap about the runit init scheme), he will just trash reports regarding a nonimportant init scheme. Bad. And, as Erich points out, we have ~1000 packages including /etc/init.d/something - It will mean 3000 or so packages for a decent (not complete!) coverage of the different schemes. And, of course, a very uncoordinated way of working. But back to my line of thought: If I'm promoting an init scheme, I cannot just push it down each maintainer's throat. I must include at least the most important init scripts somewhere. Maybe we could just group daemons by task, and then have -say- a webservers-runit package providing the init scripts for each webserver for runit? This could cut down from 3000 to some 100 packages, most probably team-maintained... But it still faces many scalability problems, and the bug-filled-somewhere-else problem seems unavoidable.
I think something interesting could come off Sven's idea of providing several independent scripts instead of today's complete init scripts - This would make it easier to adapt startup/shutdown and similar events to different world views, and if not specifically needed, most init scripts could even be autogenerated calling the right bits here and there. That would rock - except in the corner cases (I predict no less than 10% of the packages will become corner cases ;-) ) where it will crumble apart. But maybe if a package declares it should be autostarted and provides the separate bits, the sysv-rc, upstart or runit helper can come up with an autobuilt initscript (or equivalent) - And if it does not work, it can always be overriden by a maintainer- (or user-) supplied, explicitly built script. Humh...
The topic surely calls for a Debcamp session, as Joachim says in comments in two of our posts and Erich acknowledges. Erich, as the main instigator of this blog series, I hope you can at least join via Ekiga or such, as it can be quite interesting - But, yes, none of the people involved so far participates in any of the inits' maintenance... Anyway, please keep the ideas flowing. I want to sketch something up, as I feel this can be useful - and not only for initscripts, but for many of the areas where Debian provides several ways to do the same thing. And, once again, that's one of the best points of Debian for me.

I was delighted at finding Erich's series of posts regarding init schemes - In fact, when reading the bottom of your third message I got disappointing at you stating that this concludes this series of blog posts. Maybe someone can follow up with some details on upstart (which seems to be the most promising init replacement)? - I expected you to delve a bit into other schemes, such as file-rc (which is, AFAIK, quite similar to the standard sysv-rc, but instead of having directories with symlinks has files describing each runlevel in similar terms, and I understand works in quite a similar logic to sysv-rc), runit seems to work in a way quite similar to BSD's RC...
I was particularly interested on your point of view on something like Init NG - And, of course, Upstart sounds sexy, and besides, being Scott's brainchild automatically stamps a must be good legend on it, at least for me. Shame that you didn't follow on with the series - but hey, nobody's paying you to do it ;-)
Anyway... I was thinking on a way we could get at least Debian maintainers work more easily towards having more than one init scheme for our daemons and such - or at least, shipping less cruft for derived distributions to clean up. Specifically, yes, our most notorious descendant goes Upstart, so /etc/init.d/* becomes crufty for them. So, what if:

• All daemon-like packages (i.e. those containing a daemon, or running something at startup, i.e. setting up a service interface) will be affected. Lets call our sample daemon-bearing package example
• example will no longer ship an initscript. In fact, after some time, policy will mandate no initscripts (that is, what we today put in /etc/init.d) are included in our base packages. example will only recommend example-init. Why recommend it? Because it does not even now depend on a specific initscript - I've rolled some systems which are based on my very own init handler, for specific needs.
• The original example package maintainer will probably take his very same initscript, and package it as example-sysvinit. This script will provide the example-init virtual package. (Of course, this will mean a very real proliferation of virtual package names). example-sysvinit will depend on sysv-rc.
• The same maintainer, or a different one, will also package example-nginit, example-bsdinit, example-runitinit and/or example-upstartinit, depending on their respective infrastructures, and providing as well example-init. Ideally, they won't even have to conflict on each other.
• Maybe I'm daydreaming and this could just be a bit too much... But with all support in place, even the init system itself could be handled via /etc/alternatives ;-)

This means, yes, a serious explosion of very small packages. But it also means less dependency on a specific maintainer to be sympathetic to yet-another-init-scheme. If I'm pushing superb-init, which does preemptive reverse dependency tracking and invention and works based on the oh-so-3v1l aptsh, and I'm having a hard time convincing anybody to update their packages to support my init scheme before it matures, I can at least come up with all the needed scripts to get my system usable and considerable for the masses. Sounds decent? Did I smoke too much crack? No, I haven't had my morning coffee yet, so I'll go grab some while this hits the planet.

Wow, that sucked. It took this company in Austria nearly a month to connect me back up to the internet. And since I don't have a laptop with which to roam around in search of wireless, I was pretty much completely out of it since we moved up here. I'm still getting the network reconfigured, so I won't be at %100 capacity for a little bit. I took the time to explore the area some by bicycle, which was pretty nice. The area around Innsbruck is full of nice evergreen forests, snow capped mountains and mountain fields. Unfortunately, while everything was quite beautiful, it didn't smell so good, because the industrious farmers are busy spreading tons of cow dung over all those nice green fields, as well as dribbling it all over the roads leading to the fields... Oh well, we ended up in a nice place, and we're pretty happy about it. More later as I start getting things going again.

Erich Fromm, 1900 - 1980, internationally renowned Jewish-German-American social psychologist, psychoanalyst, and humanistic philosopher. Fromm describes three ways in which we escape from freedom: 1. Authoritarianism. We seek to avoid freedom by fusing ourselves with others, by becoming a part of an authoritarian system. There are two ways to approach this. One is to submit to the power of others, becoming passive and compliant. The other is to become an authority yourself, a person who applies structure to others. Either way, you escape your separate identity. Fromm referred to the extreme version of authoritarianism as masochism and sadism. Authoritarians respond to a painful existence by, in a sense, eliminating themselves: If there is no me, how can anything hurt me? 2. Destructiveness. Others respond to pain by striking out against the world: If I destroy the world, how can it hurt me? If a person’s desire to destroy is blocked by circumstances, he or she may redirect it inward. The most obvious kind of self-destructiveness is, of course, suicide. But we can also include many illnesses, drug addiction, alcoholism, even the joys of passive entertainment. 3. Automaton conformity. If I look like, talk like, think like, feel like… everyone else in my society, then I disappear into the crowd, and I don’t need to acknowledge my freedom or take responsibility. It is the horizontal counterpart to authoritarianism. The person who uses automaton conformity is like a social chameleon: He takes on the coloring of his surroundings. Since he looks like a million other people, he no longer feels alone. He isn’t alone, perhaps, but he’s not himself either. The automaton conformist experiences a split between his genuine feelings and the colors he shows the world.

The blog All About Linux wrote "Install multimedia codecs, libdvdcss in Debian Etch GNU/Linux". Small and interesting article, but there's a huge mistake there: "... so as to enable you to play multimedia files which are encoded using proprietary or closed formats such as Microsoft's WMV files or Apple's quick time files. uh, no?!

The fact is that Debian Etch Desktop (GNOME is the default, KDE and Xfce are alternatives) gives you totem, totem-xine and totem-mozilla. In other words you're able to watch .asf, .avi, .mov, .wma and more not only 'out of the box', not only using totem, but from any gecko based browser and you've two installed by default: iceweasel and epiphany. If in doubt run "aptitude update && aptitude install gnome-desktop" go to the web browser and type 'about:plugins' before installing non-free software. Say hello to Etch, not Woody.

Closing, I recommend the movie clips from Apple's website. I don't like their ads, but the fresh movie trailers are cool.

Dear Lazyweb, can you please explain how to properly credit a frenchman in a changelog without mangling his name? I do not consider it acceptable to use a different editor, make sure that my terminal was started with the proper environment variables set (run-time configuration does not seem to do it) before I can correctly enter non-english characters in a text mode editor. I guess I need to make the UTF-8 transition on the desktop. Are there any docs about how to do this? It is just incredibly frustrating to spend an hour on IRC just to create a changelog entry for a patch that took a minute to make and five minutes to test.