So this Monday was the 111th running, as they call it, of the venerable Boston Marathon, and my first time there. After the fairly serious storm warnings -- and the corresponding health warnings, delivered through two emails from the race organizers and a handout at registration, we got very, very lucky as the rain more or less stopped shortly after the start. And there was relatively little wind, and mostly laterally, rather than the 'in your face' gusts at the projected 30 to 50 mph.
There were actually six of us running from our little informal group in River Forest / Oak Park, and fellow rookie Russ and I decided to 'take it easy' and just 'go for a long run'. I ended up with a fairly even pace between 7:45 and 8:10, averaging 7:57 for a total of 3:28:24, or a few seconds faster than my very first marathon in Chicago. Which is quite pleasant, given the conditions, and the hillier course. The race went pretty well for all six us, which is nice too. Given how we trained together, it is neat how we all ended up within seven minutes of each other. The race itself is quite stunning. With the required qualifying time comes a 'seeding' system for the start, so one tends to run most of the course with runners of fairly similar speed. That made for nice cameraderie on the course -- and for beautiful sights of nothing but runners rolling through the hills of Massachusetts. I think I'll be back next year.

Today the RIPE DNS for LIRs Training Course did take place. (some not up to date course material can be found here)
Managing some thousands of zones inclusive nameserver infrastructure behind since several years, I thought it would be neat to provide a secure dns chain to our costumers.
After going deeper into the material within the course, I recognized the following impacts:

• only bind9 (>= 9.3) and NSD privides support (yet)
• bandwidth will be increased 2-3 times with max. key size
• increased memory usage depending on your server software
• operational costs will increasing dramaticaly due significant higher amount of regular work
• more computing power (hardware) needed to generate dnssec ready zones and signing
• unknown influence on resolving nameservers (load/memory/bandwidth)
• chain of trust ends at resolving nameserver and is not provided to enduser

Since the last issue isn’t solved (yet), it doesn’t make any sence for me to invest resources into setting up DNSSec infrastructur, cause the end user would not recognize if the communication with the resolving nameserver or the resolving nameserver itself is taken over. Any complaints and/or hint? Did I missed something? Networking, planet, ripe, security

I’ve just returned from renewing my passport (an important step in getting to DC7). They asked for originals and copies of my previous passport, my military service card, my voter’s registration card and my birth certificate. They forbid you from signing the application until you’re right at the counter, take three prints of each index finger and ask for three recent photos, then take one themselves anyways. Sadly, they did not ask for my GPG fingerprint. It would have been cool.

Many of us who believe in Web 2.0 (the concept, not the buzzword) have come to accept the wisdom of crowds like an article of faith. The Frontal Cortex describes a Columbia University sociology experiment that might undermine our dogma (apparently I missed it in Science):

In our study, published last year in Science, more than 14,000 participants registered at our Web site, Music Lab (www.musiclab.columbia.edu), and were asked to listen to, rate and, if they chose, download songs by bands they had never heard of. Some of the participants saw only the names of the songs and bands, while others also saw how many times the songs had been downloaded by previous participants. This second group — in what we called the “social influence” condition — was further split into eight parallel “worlds” such that participants could see the prior downloads of people only in their own world. We didn’t manipulate any of these rankings — all the artists in all the worlds started out identically, with zero downloads — but because the different worlds were kept separate, they subsequently evolved independently of one another. This setup let us test the possibility of prediction in two very direct ways. First, if people know what they like regardless of what they think other people like, the most successful songs should draw about the same amount of the total market share in both the independent and social-influence conditions — that is, hits shouldn’t be any bigger just because the people downloading them know what other people downloaded. And second, the very same songs — the “best” ones — should become hits in all social-influence worlds. What we found, however, was exactly the opposite. In all the social-influence worlds, the most popular songs were much more popular (and the least popular songs were less popular) than in the independent condition. At the same time, however, the particular songs that became hits were different in different worlds, just as cumulative-advantage theory would predict. Introducing social influence into human decision making, in other words, didn’t just make the hits bigger; it also made them more unpredictable.

I don’t accept this one study as proof that the entire user-centric content rating system is a failure (or random), but it does highlight some of the perils of a “winner takes most” mode of cultural evolution.

Alan Robertson (a major contributor to the Heartbeat project) commented on my post failure probability and clusters. His comment deserves wider readership than a comment generally gets so I'm making a post out of it. Here it is:

---

One of my favorite phrases is "complexity is the enemy of reliability" . This is absolutely true, but not a complete picture, because you don't actually care much about reliability, you care about availability.

Complexity (which reduces MTBF) is only worth it if you can use it to drastically cut MTTR - which in turn raises availability significantly. If your MTTR was 0, then you wouldn't care if you ever had a failure. Of course, it's never zero

But, with normal clustering software, you can significantly improve your availability, AND your maintainability.

Your post makes some assumptions which are more than a little simplistic. To be fair, the real mathematics of this are pretty darn complicated.

First I agree that there are FAR more 2-node clusters than larger clusters. But, I think for a different reason. People understand 2-node clusters. I'm not saying this isn't important, it is important. But, it's not related to reliability.

Second, you assume a particular model of quorum, and there are many. It is true that your model is the most common, but it's hardly the only one - not even for heartbeat (and there are others we want to implement).

Third, if you have redundant networking, and multiple power sources, as it should, then system failures become much less correlated. The normal model which is used is completely uncorrelated failures.

This is obviously an oversimplification as well, but if you have redundant power supplies supplied from redundant power feeds, and redundant networking etc. it's not a bad approximation.

So, if you have an MTTR of 4 hours to repair broken hardware, what you care about is the probability of having additional failures during those four hours.

If your HA software can recover from an error in 60 seconds, then that's your effective MTTR as seen by (a subset) of users. Some won't see it at all. And, of course, that should also go into your computation. This depends on knowing a lot about what kind of protocol is involved, and what the probability of various lengths of failures is to be visible to various kinds of users. And, of course, no one really knows that either in practice.

If you have a hardware failure every 5 years approximately, and a hardware repair MTTR of 4 hours, then the probability of a second failure during that time is about .009%. The probability of two failures occuring during that time is about 8^10-7% - which is a pretty small number.

Probabilities for higher order failures are proportionately smaller.

But, of course, like any calculation, the probabilities of this are calculated using a number of simplifying assumptions.

It assumes, for example, that the probabilities of correlated failures are small. For example, the probability of a flood taking out all the servers, or some other disaster is ignored.

You can add complexity to solve those problems too ;-), but at some point the managerial difficulties (complexity) overwhelms you and you say (regardless of the numbers) that you don't want to go there.

Mangerial complexity is minimized by uniformity in the configuration. So, if all your nodes can run any service, that's good. If they're asymmetric, and very wildly so, that's bad.

I have to go now, I had a family emergency come up while I was writing this. Later...

---

End quote.

It's interesting to note that there are other models of quorum, I'll have to investigate that. Most places I have worked have had a MTTR that is significantly greater than four hours. But if you have hot-swap hard drives (so drive failure isn't a serious problem) then having machines have an average of one failure per five years should be possible.

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.

Rolandas commented:

"Do you know, that you can get free listings from broadcasting data services by going to http://www.bds.tv/ and registering as person? You need to pay money if you making money out of it."

No, I didn't know that. Thanks for the tip. It's hard to register with BDS because it isn't accessible - anyone know whether the listings are in a useful format? Still doesn't really change that the TV listings tax is unjust: why shouldn't we be able to publish remixes of this data that we already pay for?

Update: Francies commented:

"I also emailed Barclays regarding their non-listing of Linux and had the "128-bit encryption" where again Linux was not mentioned (have they even heard of it? A friend mentioned today that he has read that Barclays will be issuing chip and pin or card devices to all online banking users so could it be that these will be Windows only? If so the Linux community should complain in case all banks get the same idea."

I've also seen Barclays announce the chip-and-pin readers and a BBC report about them. Anyone seen these before? Comment form at the end of the page.

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.

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.

Ok, so it just seems like a hot topic - I just submitted a BoF for Debcamp to talk about the init-related ideas we've been discussing. As Debconf's Pentabarf conference management system does not like disclosing talk details before the talks are accepted, I'll reproduce here my short blurb:

This BoF comes out from several ideas posted in Planet Debian by Erich Schubert, Sven M ller, Joachim Breitner, Mike Homey and myself (so far). It's not to be "chaired" by any of us particularly, but I expect an interesting brainstorming session.
There are several different init systems present in Debian - However, we are only supporting currently one of them, good ol' sysv-rc - We have close to a thousand packages providing init scripts suitable for it, and close to none for all of the other systems.
In current systems, full of hot-pluggable devices, changing network configurations and so on, however, I think this situation is quite prone to change - sysv-rc and its runlevels are better suited for stable server-like systems, and is hard to adapt for future needs.
We will talk about the potential difficulties Debian will face in order to better support more init schemes, and discuss some ideas to solve them.
This should be a brainstorming session, not much material will be prepared (maybe some sketches by each of us, but nothing formal). If you plan on attending, take a look at the messages linked to in the 'links' section.

Note that, following Nomeata's suggestion, I'm presenting this for Debcamp - If you are not attending Debcamp and are interested, we will try to set this up via some sort of videoconferencing (or at least the usual video feed + IRC feedback), and I do hope we can have something showable (at least a broken concept) after Debconf.
In not-so-closely-related topics, I just learnt there is a shadow of doubt regarding my presence in Edinburgh - I will do my best to dispell the threat. I just don't want to miss a Debconf!

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.

Smigs commented:

"perhaps the ultimate example of this is the ebay uk announcements feed - the items date back to 2004 and it totals 267.86 kB - so big that the livejournal syndicator refuses to use it at all. I went so far as to contact ebay about it, but they didn't do anything."

I'm having a little problem getting some money from ebay (which I might write about after I resolve it), so the above comes as no surprise to me. That sounds like the Carlsberg of feeds: probably the fattest feed in the world. Martijn wrote:

"I think a feed should contain all content the other versions of the page have, it's an alternative (link rel etc.) after all. Imho, parsers should just be made smarter, and drop things they consider to be 'too old'."

I agree that a feed should be the same content as other versions (or at least the main one of them should... see my site's filtered feeds) but my comment about being too big and too old applies to the non-feed versions too: Recent Changes pages should drop items which aren't recent. I disagree that parsers should drop things that are too old because it would do more harm than good: generally, you can't tell how old an item claims to be until after you've read it; and a lot of publishers have subtly broken clocks (which is why my aggregator uses ordered lists, instead of sorting by timestamps like planet). Related link: Problogger: 34 Reasons Why People Unsubscribe from RSS feeds.

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.

At work, we use Linux (and Debian, in specific) for a lot of different things: everything from our phone system (running on Asterisk) to file serving and running some proprietary applications. I'm one of the people that finds, sets up, and maintains these systems, and I write code for our in-house use as well. I like to learn from others, and get to know others that may have things in common with me and with our environment. So going to conferences is a useful thing to do.

I'm hoping that some reader out there will have a good suggestion for a conference I ought to attend. Here are some that I've looked into and my thoughts on them:

• Usenix Annual Tech Conference: I went last year. There were some very good talks, but the audience size was not all that large. I got to meet some peers there, but I didn't get to talk in-person to anybody I'd worked with online before. (LISA being in fall/winter means it's too early to consider it just yet)
• LinuxWorld Conference & Expo: My general impression of LWCE in the past has been that its technical talks aren't very technical; that is, they either cover things I already know or don't care about. They are starting to publish their program this year, and I see a few interesting things though. There have traditionally been a lot of Debian folks at the .org pavillion.
• Debconf: It seems to be focused almost exclusively on developing the Debian operating system, rather than on using it. While I am a Debian developer and have been for quite awhile, I would find new uses of Debian to be more interesting than new ways to hack on Debian. Plus, the insanely early registration requirements means that it's too late to go this year anyhow. (And my brother is getting married right in the middle of it.)
• OSCon: There look to be some interesting talks in the database area, and some about Xen and virtualization, and Simon PJ (one of the ghc hackers) will be there. So this would be interesting, though somewhat light on the admin side of things.
• OLS: Seems very focused on the kernel, and not much else. That is of interest, of course, but is one piece of many. Though there was a talk about Linux deployment at Nortel that sounded interesting.

My leading candidates are probably Usenix and OSCon. I'm interested to hear what people think, especially those that have attended some of these conferences.

Because of the problems with my aggregator's memory use, I'm unsubscribing from some feeds that are too big, too slow and not vital enough that I'll miss them. So, it's goodbye to: no2id.net newsletters - too big (144k), too slow (dates back to February) and not vital - I'll keep the events and news release feeds for now. www.thewildbeast.co.uk - too big (72k) and too slow (dates back to May 2006). scobleizer.com - I subscribed to this after a recommendation, but it's too big (128k) and actually rather irritating IMO, waffling about things that I'm not interested in. www.sbs.gov.uk - site seems to have vanished without warning. Typical failure of our government to make life easy for small businesses. aphoc.org - site has been offline too long and I don't remember what it was. There's a couple more which I'm keeping under review, but they've earned their keep for now. (Update: removing just the above has shortened the merge time from 3mins to 30secs.) My feed is about 29k at the time I write this: how big is yours? If your feed is larger than about 50k - particularly if you don't send a Last-Modified or Content-Length header - you should take steps to slim your fat feed. Consider reducing the number of items, particularly if you have stuff more than three month old in it. Am I lazier than most at unsubscribing from feeds - my main feedbox still contains more than 70 - or will people with fat feeds already have lost lots of readers?

Just quit my full time job, (hopefully) I'll just work for them keep leading the Sacix (www.sacix.org.br) development and not also in front of a team maintaining our ISP in parallel as I was. Sacix is yet another Debian/Ltsp based distribution but unlike many others from this camp we aren't focused on education. Yes, 0-200 age range! There's GNOME by default and regular apps (including gcompris, but as i wrote, education isn't the primary goal), we're also a custom Debian distribution and we've multiple profiles (artwork and set of packages). In other words almost any community telecenter project or lab can fit over our infrastructure. Sacix has more than 100,000 end users!

Sacix was all over the place during FISL in Porto Alegre, Brazil. Three setups running and the feedback of our upcoming Etch based release called Sagui was great! Arara (Sagui-1) supported only pt_BR, with Sagui we wanted to make sure that we weren't turning the life harder for English and Spanish speakers. Unfortunately, the website is over trac and I would like to hear about sane solutions on how to handle bugs in these three languages and a good plugin to start translating the wiki pages. Comments?

Thanks Paulo for contributing with usbfloppy drivers support (yes, this weird stuff really exists), tons of tests and ideas! We've been working very hard during the last two years releasing minor stuff here and there and nobody seemed to care, when we put the pieces together they finally get it and recognize it as something. ;-) Thanks for the others contributors, you know who you are and 'Sacis' wiki article too.

Btw, I'm just having a break from a 'code merging' session with Vagrant Cascardian. New ltsp package coming soon! It will be on the pile of my recent uploads: python-gdata, pyspf (thanks ScottK) and alacarte.

One step nearer removing OS X form my iBook. Now I got java running so I can log on to my net banking account. The following works on my Debian Etch (-ish):

1. Download IBM’s java-package from http://www-128.ibm.com/developerworks/java/jdk/linux/download.html (registration required) - you need the 32bit iSeries/pSeries version in tgz format
2. Make sure that the package includes …/jre/bin/libjavaplugin_oji.so (somehow I got a package which didn’t have the file)
3. install java-package
4. run make-jpkg <tgz file>. If it complain about “no matching plugin was found” look in /usr/share/doc/java-package/SUPPORTED and rename you tgz file to something supporte of almost the correct version.
5. Install the resulting package and restart firefox (whatever it is named today)

I downloaded a file called ibm-java2-jre-5.0-4.0-linux-ppc.tgz and renamed it to ibm-java2-jre-50-linux-ppc.tgz and it seems to work.

I think people are still a little euphoric over the etch release, but I'd like to let people know why Xorg 7.2 is still in experimental. Julien Cristau has done a ton of the grunt work, uploading all the usual library updates to unstable, and they're looking good so far, so at least that part is in place. The problem relates to the fact that the XSF wants to push forward with moving from Xlib to XCB. XCB represents a significant improvement over the traditional Xlib, and it's important that we work to nurture and standardize it. The good news about XCB is that most people transitioned over to it without any noticeable issues. Everything pretty much seems to work transparently, which is testament to the amount of care and time the XCB team has put in to creating it over the past several years.

But now for the bad news: there's some regressions, and they're almost all in non-free software. The biggest issue is this one: XCB will break java. You can work around it in older versions of java (as documented in that bug report) but in the newer ones you can't do much of anything. The XCB team and XSF (there's actually a fair bit of overlap there, because the XCB guys are Debian developers and I consider them XSF team members in that sense) were trying to hash out a solution to the problem. We're still working on it, but it represents the problems with depending heavily on non-free software in a free software context. Hopefully Sun will actually try to respond to the issue and release a java update that works with XCB. We can hack around the problem by disabling some checks in XCB, but the problem is really with buggy software, and we want to catch and fix those bugs. Essentially though, I'm not willing to break java in unstable so we're at something of a standstill.

In addition, there's a bug with a bit of proprietary Nvidia code. The XCB guys have a handle on that one, and think they can patch XCB itself to work around it, so hopefully that's a non-issue. Finally, some number of users have reported major performance degredation using XCB in some configurations. The XCB guys were actively going after that bug as well yesterday, so hopefully that'll be resolved soon too.

So that's where we're at. The server is looking good, and thanks to Julien and Drew Parsons we've got the latest X server release candidate and new drivers sitting in experimental, complete with the new (intel-only right now) randr 1.2 hotness, so if you want it, you know where to get it. I've finally begun my small contributions to the having a fully automagic configuring X server in experimental as well, but I'll blog about that when I reach my first milestone.