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.

A comment on my post about the failure probability of clusters suggested that a six node cluster that has one node fail should become a five node cluster.

The problem with this is what to do when nodes recover from a failure. For example if a six node cluster had a node fail and became a five node cluster, then became a three node cluster after another two nodes had failed, then you would have half the cluster that was disconnected. If the three nodes that appeared to have failed became active again but unable to see the other three nodes then you would have a split-brain situation.

As noted in the comment the special case of a two node cluster does have different failure situations. If the connection between nodes goes down and the router can still be pinged then you can have a split brain situation. To avoid this you will generally have a direct connection between the two nodes (either a null-modem cable or a crossover Ethernet cable), such cables are more reliable than networking which involves a switch or hub. Also the network interface which involves the router in question will ideally also be used as a method of maintaining cluster status - it seems unlikely that two nodes will both be able to ping the router but be unable to send data to each other.

For best reliability you need to use multiple network interfaces between cluster nodes. One way of doing this is to have a pair of Ethernet ports bonded for providing the service (connected to two switches and pinging a router to determine which switch is best to use). The Heartbeat software supports encrypted data so it should be safe to run it on the same interface as used for providing the service (of course if you provide a service to the public Internet then you want a firewall to prevent machines on the net from trying to attack it).

Heartbeat also supports using multiple interfaces for maintaining the cluster data, so you can have one network dedicated to cluster operations and the network that is used for providing the service can be a backup network for cluster data. The pingd service allows Heartbeat to place services on nodes that have good connectivity to the net. So you could have multiple nodes that each have one Ethernet port for providing the service and one port as a backup for Heartbeat operations, if pingd indicates that the service port was not functioning correctly then the services would be moved to other nodes.

If you want to avoid having private Heartbeat data going over the service interface then in the two-node case you need a minimum of two Ethernet ports for Heartbeat and one port for providing the service if you use pingd. If you don't use pingd then you need two bonded ports for providing the service and two ports (either bonded or independently configured in Hertbeat) for Heartbeat giving a total of four ports.

When there are more than two nodes in the cluster the criteria for cluster membership is that a majority of nodes are connected. This makes split-brain impossible and reduces the need to have reliable Ethernet interfaces. A cluster with three or more nodes could have a single service port and a single private port for Heartbeat, or if you trust the service interface you could do it all on one Ethernet port.

In summary, three nodes is better than two, but requires more hardware. Five nodes is better than three, but as I wrote in my previous post four nodes is not much good. I recommend against any even number of nodes other than two for the same reason.

I recently read through my blog's archive and guess what, today is its official second birthday! :) Its very first post was exactly two years ago and dealt with the upcoming LinuxTag. Thinking back, this blog has come a long way: from a simple list-like page without any navigational elements in my student webspace (constantly being in trouble with my 20Mb quota), to my first forays into php, to a rather horrible nested tables fest hosted on a friend's server, to today when I finally got my own server and domain and returned to simple handwritten html + css and blosxom. Its choice of content has mainly remained the same though: Debian, uni, personal life and the the occasional rant when there was nowhere else to complain ;)

Consider the following command:
echo (cat /etc/ motd,passwd ) (you can replace “echo” with any command that takes one file as argument and cannot take it as stdin) It’s obvious that the goal is to expand this to:
echo (cat /etc/motd /etc/passwd) Then to:
echo /dev/fd/63 However, it doesn’t work like this:
$ echo (cat /etc/ motd,passwd )
++ cat /etc/motd
++ cat /etc/passwd
+ echo /dev/fd/63 /dev/fd/62
/dev/fd/63 /dev/fd/62 But bash doesn’t work like this. Brace expansion is done first, but inside parameters of the command (that is, (cat /etc/ motd,passwd )) not words. So when (cat /etc/ motd,passwd ) is expanded, the prefix is (cat /etc/, the suffix is “)”, so it’s expanded to (cat /etc/motd) (cat /etc/passwd). After reporting a bug about that, Chet Ramey gave me the correct way to reach the initial goal:
cat (eval cat /etc/\ passwd,motd )

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.

Those who have recently tried to reach me, may have noticed that at least during the day I am mostly offline at the moment. The reason for this is, that I am currenty a bit more than half through the six months I got for the final thesis of my M.A. degree, and while the first "half time" was rather easy going with mostly empirical work, preperation and planning, the second half is now much more work intensive with the actual implementation and getting the whole thing on paper. So, since the beginning of this month I've sentenced myself to a kind of "voluntary solitary confinement". In practice this means that I usually get up in the morning, have breakfast, read up on email, irc etc, pack some fruit and our largest insulating teapot and leave for the university. There I move into one of the less popular student working rooms, spread all my stuff and work on my thesis until about 6 in the evening, return home, again read up on my backlog, have dinner, watch a movie and then go to bed. Although this sounds (and in fact is) rather monotonous, it is also a very productive modus operandi, since the student working rooms are literally bare of any distraction. There are a few tables, a few chairs and occasionally someone else comes in, quietly works for a while and leaves again. Leaving my wireless card at home gives me additional protection from the three gazillion distractions the dreaded internet has to offer. I don't know yet for how long I'll keep this up, but for the moment it works quite nicely and I produce a few pages (almost) every day. So please excuse that my e-mails are somewhat laggy at the moment, and if you want to talk to me on irc or the phone, try between 19:00 and 23:00 CEST.

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.

So, yes these three topics, the caveat, the book Better than Well and Hot Latino Bodies are related. You just have to stick with this long post to find out why… *** As I progress slowly but surely with my book manuscript, I am really coming to see how a dissertation and book are quite different creatures. I think one of the most important and noticeable differences is that a book has a lot more short caveats and warrants than necessary in a dissertation. I think there are two main reasons for this. One of which is has to do with your committee members, the primary and (usually only readers) of the dissertation. They are a lot more prepared and adept to ingest complex ideas than lets say undergraduate students, because that is what they are trained to do and because most of them are much more familiar with your topic because they have been with it nearly as long as you have. In a dissertation you are also allowed to (and often expected) to go on and on, ad naseum, with your theoretical explanations that help substantiate what are otherwise shakier, initial claims. For various reasons, for a book, especially if you are not some FFT (Famous French Theorist), you are strongly encouraged to dump most of the theory in favor of providing a streamlined version (which really, is preferable of course, but extraordinarily hard to pull off). I have been thinking a lot of the caveat because I have just finished re-reading a book Better than Well that is not only fascinating in its own right but brings the caveat to a stunning art form. The author, Carl Elliot, is a philosopher/bio-ethicist and the topic of the book, broadly speaking, examines how the rise of new enhancement technologies (prozac, plastic surgery, sex change surgery) is bound tightly with longer-standing, distinctly American ideals, such as the autonomous, self-directed and authentic self. It is one of those rare books that can be read by your father, aunt and uncle, tossed over to a willing teenager, and assigned in all sorts of college courses and still manage to impress all sort of academics in all sorts of fields. Part of the reason for his broad appeal is because the book is thoughtful and clever and so chock-full of really interesting examples that you are hooked and want more of his tasty intellectual Kool-Aid. So while he has one main focus, which largely triangulates between enhancement technologies, selfhood, and consumerism, in the process of exploring them, you learn about a bunch of other really neat topics: suburbia, the history of cosmetics and childhood, odd social phobias, long-gone and culture- bound disorders like dissociative, fugue, amputee wanabee’s, extreme blushing, and so much more. Along with crystal clear writing, he also throws in some classically funny lines, my favorite one currently being: For better or worse, suburbia has come to stand for something than can be survived only with minor tranquilizers. Another reason he manages to pull this Houdini-like feat is because of his judicious and artful use of the caveat, which is really the only way he can bring forth complex ideas, in a fashion that is much more accessible than is usually done in a purely academic book. To take on example, when he introduces the usefulness theories of Thorstein Veblen, an economist usually known (and only barely), by academics, he opens in the following way, because in many ways, if you just decided to pick up a copy of Veblen, his style make strike outdated:

Reading Veblen nearly a century after he wrote The Theory of the Leisure Class, it is not easy to know which parts of the book to take seriously. It comes off as equal parts intellectual theory, social satire, and crackpot polemic, (and goes on for a full more paragraph) and then says Where Veblen is prescient, however, is his sense that in a consumption economy, consumer goods would become markers of who we are. p. 103

In this way he can say, ok Veblen is useful because of this specific reason” and yet communicate to his academic readers that he knows the limits of Veblen. No matter how much I love the book, and now matter how I think his use of the caveat is stunning, there are two problems I have with it. In one case, I think he fails to give one of the most important caveats. He paints a picture in which all of American society is ensnared in dominant social codes and mores (which somehow all point back to consumerism and capitalism and a desire to improve the self). While there are points he seems to back away from that sort of statement, and a few rare points where he ascribes his insights to the group I think he should mainly be sticking to white, liberal-leaning middle-class Americans I think there are more instances where he paints a picture of America as far more uniform than it actually is. According to his account, no one is immune to the forces he so eloquently writes of and so in the end the environmentalist activist, is as caught up in the traps of consumer life-style as is the investment banker on Wall Street. It lead hims to say such statements as

Many Americans today learn who they want to be by listening to a Methodist minister or a civics teacher but by watching advertisements for The Gap.

Ok while he bit about the civics teacher may be true, any consideration of lets, say… the religious right in this country, which, as we know from recent elections, don’t represent a teeny-tiny itsy-bitsy minority (and for a fascinating glimpse into the world, I would recommend Jesus Camp), would bring holes, and sizable ones, to that sort of statement. Many Americans do in fact listen to their minster. And this does not only help explain the deep divisions in this country, but I bet because they do listen to their pastors, their notions of the good, the self, etc, are going to be pretty distinct from those he describes (and gain see Jesus Camp to get at this point) It is not that the religious right exists outside of the web of consumerism we are all at least partially caught in, and indeed, a lot of the new Protestant religious movements here and elsewhere as Jean and John’s Comaroff’s work has shown can be all about securing a more robust middle class lifestyle. But we must remember that even something as powerful as consumer capitalism or dominant ideals of an authentic, beautiful self though powerful and more often than not work in concert with each other do not quite have the power to efface all meaningful difference between lets say a white, liberal middle class woman and let’s say, many Latinos, who, do, let’s not forget, comprise a huge portion of America. Many Americans have a very different picture of the ideal female body than the picture he explores, which is skinny and lanky and forever youthful (and hence the appeal of botox and lipo). Let me provide just one example drawn from the annual Puerto Rican day parade and this hold true for the one held either in NYC or Chicago. Along with a blizzard of Puerto Rican flags, what you may also notice is the abundance of really bright spandex being donned on ladies that are not by any standard of the word slim. I am sure that any middle class lady (you know, the type who spends 5 days of the week working out at the gym, wishing her thighs were just a little thinner), would feel morally repulsed in seeing that sort of image, that is if they even bothered to go to the parade. But among many Puerto Rican men (not all) a sexylicious and extra-curvy, meaty Puerto Rican woman, decked out in tight & bright spandex, will like bring on a loud HAY MAMITA, ven ac ”………………… which roughly translates into You are HOT… Like I want you NOW. (more…)

Looking for Earths: The Race to Find New Solar Systems is an excellent introduction book, as a scientific story of exploration and summary of the science of planetary discovery. Alan Boss is a planetary scientist and adviser to NASA on the search for extrasolar planets. He has had a front-row seat in the revolution over the last two decades that has led to the discovery planets outside our Solar system for the first time, leading to 215 known planets at last counting. The book is written in an first-person style that reflects the race to discover the first exoplanets in the 1990s. He describes historical searches for planets in the early 20th Century: the hunt for evidence of planets around Barnards Stara and the meticulous work over decades of Peter Van de Kamp, a good summary of the challenges in proving the case for planets in Astronomy, and explains the techniques used to determine other planets. The heartbreaking difficulties of proving the discovery are well expressed, as well as documenting the leaders of the field at the time. Along the way, he describes the discovery of the first Brown Dwarfs, the border cases between Stars and Planets, and the bureaucratic and other challenges involved in setting up large observatories such as the Keck interferometers capable of doing this work. This is ironic, as the first discoveries were actually made by ground-based observatories. Boss describes the race between the main teams, Geoffrey Marcy and Paul Butler of Lick observatory. The race was finally won by Michel Mayor and Didier Queloz of Geneva Observatory, who discovered the first extrasolar planet around a sun-like star, 51 Pegasi, by looking at radial velocity measurements of nearby stars. This turned out to be a close race, as the planet they had found had a short period of 4.23 days, implying the planet was what we now call a "hot Jupiter", orbiting very close into the Sun. Most teams had been looking for copies of our Solar system, looking for large planets such as Jupiter with orbits of around a decade, and had hence not started to analyse the data they had in hand, expecting to need years of measurements: examining the data showed that, had they analysed data in hand, they could have won. Looking for Earths does a good job of explaining the field of exoplanet research as it was evolving over Boss's careeer and particularly 1995-2005, with theoretical and computer models evolving as data arrived with new puzzles. In some places, the need to give a clear explanation of a topic such as the formation of planets from solar disks slows the pace of the biography, but the book does an excellent job of describing both the science and the life lived by those doing the work. Few books I've read have offered such a good summary of the field to date, along with a good bibliography and I would heartily recommend it both as an introduction to the field and as a model for science writing.

As mentioned in the past I got a new TV this year. It's an LG 32LCD2DB with a native panel resolution of 1366x768. As well as the usual SCART/component inputs it has VGA and HDMI. Currently my homebrew PVR outputs to the TV via a full featured DVB card with onboard MPEG2 decoder, but this limits me to 720x576 output and a basic OSD. My current box is a PIII-800 with a basic onboard SiS graphics chipset, so it's not got the grunt to drive the TV directly itself. I'm thus on the lookout for an upgrade. Let's start with my constraints. I have a Silverstone LC-02 case. I'd previously planned to upgrade to something bigger, but the discovery that LinITX can provide a variety of riser cards to suit PCI-E/PCI as needed means I don't have to. The LC-02 will take a MicroATX board and provide me with 2 slots, one of which is taken up by the PCI DVB card. This box lives in my living room, so it needs to be quiet - the current incarnation is a bit too loud but I believe that's mainly due to using a standard heatsink+fan assembly, so I'm hoping that something specifically designed to be quiet will be better. An lirc dongle and wireless keyboard/mouse are already sorted. I'd like to expand the use of the PVR to be a more general PC as well; up until now it's just been a PVR, but being able to check email/IRC would be nice, as would the ability to play games. Up until now I've run VDR, which takes full advantage of the MPEG2 decoder, but I'd like to give MythTV a decent try. All of this points to wanting more than just a HD hardware MPEG2/MPEG4 decoder. First lets start with the graphics chipset options. The contenders seem to be ATI, Intel, nVidia and Via. From my reading ATI lack any form of XvMC support in both their Free and binary blob drivers, so we can discount them. nVidia have support, but only in their binary drivers. The Nouveau project have support on their TODO list, but I can't see any sign of it yet. I'd really rather avoid non-free drivers, so that leaves us with just Intel and Via. I really like the look of the Intel G965/X3000. They've opened up their driver development and it seems to be quite active from reading the Xorg mailing lists. However they don't have any XvMC support; Keith Packard on the xorg list in February says "For media purposes, the current drivers aren't taking full advantage of the hardware yet", though later on does say "XvMC is on several of our lists; I don't know when someone will pick it up and implement it". Unfortunately I get the feeling it's not a high priority; I've seen/heard several comments about the fact that any processor that'll get hooked up to this chipset will be more than fast enough to cope without the assistance. That may be true, but I don't want my CPU to be spending all its time trying to decode MPEG2 or MPEG4 at 1920x1080i while the GPU sits mostly unused. I'd much rather the GPU was used to the full giving me spare CPU cycles, or perhaps the ability to clock it a bit slower for common use cases, reducing power and heat. I'm keeping Intel on my list because I hope they do get round to proper support sooner rather than later. They've also talked about the fact the GPU is programmable which would make it perfectly possible to add MPEG4 acceleration to the chipset; that would be pretty sweet. It's a bit odd to end up with Via on the list. I mainly think of them as associated with MiniITX boards, but they do also produce various motherboards for Intel/AMD CPUs with integrated graphics. They managed to shoot themselves in the foot for a period of time by limiting the maximum accelerated resolution to 1024x1024, but recently they've released the CX700M /P4M900 chipsets which appear to do 2048x2048. The OpenChrome project have these up and running to a basic level from what I can tell, but work on XvMC support appears to be progressing with various patches and reports flying about on the list. So currently it looks like Via has the best option (albeit through the Free software community, rather than a concerted effort on their part), while Intel has something that could be very appealing if the driver was more complete. The other factor is the CPU. 3 contenders this time; AMD Intel and Via. My current PIII-800 is rated at 20.8W TDP. Modern processors are in general a lot hotter, but I need to keep in mind that I'm looking for a quiet machine, and that the case doesn't have a huge amount of room for big cooling systems. AMD's dual core chips all start at 89W or more, though some of their single core lower end CPUs are more like 67W. Of course the Intel graphics won't work with it and I'm not 100% sure Via has a suitable Athlon chipset at present either (the 2 I found were for Intel/Via). Intel's P4 offerings aren't much better for power consumption, with many of the highest end chips being over 100W. Core 2 Duo looks promising; 65W, so more than the current CPU, but a lot more grunt. Via come out tops here; 20W for their 2GHz top end processor. However this is only single core and compares poorly to the equivalent clock speed of Core 2 Duo. A MiniITX board with a 2GHz C7 and a CX700M would probably make a fine PVR, but I'm not convinced about there being enough grunt for anything else. The Via chipsets appear to have more active in-progress support for media acceleration, which suggests a P4M900 + Core 2 Duo. That's contrasted with what looks to be the more powerful X3000, that actually has a manufacturer who seems to want to get full Free support out there. I'm probably a couple of months off actually making a decision; partly because I want to watch how it all plays out in the hope that the Intel chipset will get some more support, or that the Via chipset will be proven to be reliable in operation. And assuming I do make a video chipset/CPU decision I then get the joys of trying to find a motherboard with DVI + SP/DIF. I know the G965 can do DVI out with an ADD2 card in the PCI-E slot, but I don't know if the P4M900 supports the same thing. I can't see an Intel MicroATX 965 board with SP/DIF out - there's an HD audio header, but this doesn't seem to be a direct mapping. Can I get a converter?

We are having a release party on Saturday the 14th of April. We meet at mid-day under the clocks at Flinders Street Station and then go somewhere convenient and not too expensive for lunch.

All welcome.

Update:

The event was moderately successful. There were only six people including me - that was quite a bit smaller than the Debian 10th birthday party we had in Melbourne, but it was still enough to have fun.

Everyone there had a good knowledge of Linux and Debian and many interesting things were discussed. We had lunch at a Japanese stone-grill restaurant - their specialty is serving raw ingredients along with a stone that's at 400C (or so they claim - I would expect a 400C stone to radiate more heat than I experienced on my previous visit). As it was a warm day we skipped the stone grill and ordered from the lunch menu (which was also a lot cheaper). Some of the guys had never tried Sake or Plum Wine before, they seemed to like it. Strangely the waitress always wanted to deliver alcohol to a 15yo in preference to almost anyone else.

One of the topics of discussion was Linux meetings and the ability to attend them. A point was made that if you are 18yo and rely on your parents' permission to do things then a meeting that finishes at 9PM isn't a viable option. It has previously been noted that for people from regional areas an evening meeting is also inconvenient.

Maybe we should have occasional LUG meetings on a Saturday afternoon to cater for the needs of such people?

I've been meaning to attend the ACCU Conference for some years and finally decided to pay my own way for a couple of days this year. It was an opportunity to hear world experts on C++ and other programming topics and to a smaller extent to meet and socialise with other professional programmers. I attended the following sessions: Keynote: Improving Collaboration in Open Source Projects, Mark Shuttleworth This was a somewhat surprising choice of speaker and subject since I think most attendees work on proprietary software, but I think any sensible developer in the proprietary world will try to build on free libraries under non-copyleft licences, where appropriate. Mark talked about governance and leadership in "open source" projects (actually praising Debian for having a clear constitution) and about the need for good communication between projects, for example about release schedules. He seems to have accepted that Launchpad cannot be a single hub, and called for standard formats for, for example, exchanging information about related bugs between bug trackers. But it doesn't sound like he's ready to take the lead on that. Choose your Poison: Exceptions or Error Codes, Andrei Alexandrescu Andrei looked at the strengths and weaknesses of various error reporting mechanisms in C++ and introduced a technique for making error handling more flexible. Normally a function is designed either to indicate errors through its return value or to throw an exception on error. If a function returns an error indicator, it's easy for callers to ignore it. If it throws an exception on error, then a caller that provokes errors more often than the called function's author anticipated pays a high cost in processing time for those errors. Andrei's solution involves a class template Likely<typename T> whose instances hold either a return value of type T or an exception. A function that can fail has a specialisation of this template as its return type. The caller can check for failure if it knows how to handle it, or it can ignore it - in which case the conversion to T or the destructor will throw the exception. This is clever but doesn't seem to be entirely satisfactory. The destructor which throws does first check that no exception is already being processed, avoiding collision of the two exceptions and consequent abrupt termination of the program, but this can result in errors being unexpectedly ignored. Introduction to Component-Level Testing, John Lakos A marathon 3-hour talk on designing and testing software, particularly C++ programs (the subject of his well-known book) as a set of well-defined components. Lakos first defined these components as being "physical" i.e. sets of source files - normally a header file defining an interface, an implementation file, and a test driver file. They may also include metadata for the build system. He talked about the value of reusable components (as if this wasn't obvious!) and the risk of introducing circular dependencies - which essentially turn many components into one and reduce reusability - if we fail to keep track of dependencies. Software built out of components can be viewed as a hierarchy or stack defined by dependencies. In a large system, components with similar dependencies and dependents can be grouped together into packages or package groups to simplify a view of these dependencies. He explained that the test driver's dependencies count just as much as the implementation's, because we cannot reasonably test a component until we have tested its dependencies. Test drivers should also be written to avoid depending on environmental settings and configuration, so far as possible. Finally, and perhaps most importantly, he spent a long time talking about how to construct test cases and test data. I might try to summarise this in a later entry if anyone's interested. The Appliance of Science: Things in Computer Science that every practitioner should know, Andrei Alexandrescu Andrei began by complaining that OpenOffice Impress was even worse than PowerPoint, but being able to use Linux (specifically Ubuntu) more than made up for the pain. He briefly presented four key ideas that he believes programmers should understand and be ready to make use of:

• Dynamic programming. The Wikipedia article summarises this as "a method of solving problems exhibiting the properties of overlapping subproblems and optimal substructure (described below) that takes much less time than naive methods". As a simple example, Andrei presented a Fibonacci number generator. But since no-one really needs Fibonacci numbers, he also showed its application to calculation of the Levenshtein distance between words which is important in spell-checking and fuzzy string matching. A naive approach to either of these problems is so inefficient as to be useless.
• Garbage collection and its connection to type-safety. Any object model can only provide 2 of the following 3 features without losing type-safety: mutable objects, aliasing (multiple pointers/references to the same objects), and explicit reuse of memory (via free, delete or similar). C and C++ have all three of these. Garbage collection eliminates the need for the third. However it does require more virtual memory and/or more processing time (there is a trade-off between these). (He quoted numbers from Hertz and Berger, Quantifying the Performance of Garbage Collection vs. Explicit Memory Management, 2005. However, these numbers show the cost of GC in Java, specifically Jikes, not as an addition to C or C++.)
• Machine learning. Sometimes we don't know how to solve a problem, but we can have the program gather feedback that will allow it to learn how to do it better. This depends on the "smoothness assumption": small changes in inputs have a small effect on the result, rather than making sudden changes. Examples: image recognition, deciding whether changes to web page layout are helpful, disambiguating search terms.
• Transactional memory is the most promising approach to achieving scalability across massively parallel systems. Most hardware performance improvements over the next 10 years will come from greater parallelism, not higher clock speeds.

Writing for ACCU (BoF) I think I've been convinced to write an article about standardisation of multithreading in C++. C++ Threads, Lawrence Crowl Crowl gave an overview (similar to this) of the extensive work that's been done on standardisation of multithreading in the C++ language and library. This is one of the most important features in C++0x due to the increased parallelism mentioned above. The current semantics of multithreaded programs are not standardised, resulting in subtle but potentially serious differences between current C++ implementations that support multiple threads, and in the need for assembly-language code in programs that use lockless synchronisation. Much of this is also relevant to C and is being considered by the C standard committee. C++0x Initialisation: Lists and a Uniform Syntax, Bjarne Stroustrup Stroustrup recapped the 4 forms of syntax for initialising objects in C++, some inherited from C and some necessarily invented for C++, none of which are entirely generic. He noted the lack of a simple syntax to initialise the elements of containers, which violates the general principle that class types should have the same status as built-in types in C++. He then introduced a new initialiser syntax that he and others have defined for C++0x, which is a brace-enclosed comma-separated list of values, similar to that used for arrays and C-style structures (aggregates). Container types can define a constructor with a parameter of type const std::initializer_list<T> & and when constructed with this new form of initialiser they will receive this wrapper for a constant array of element values. For types that do not, the values in the list are treated as arguments to some other constructor, if one matches. Otherwise, for compatibility, this may be treated as aggregate initialisation. C++ Standard Library report, Alisdair Meredith There was far too much information here for me to even begin to summarise. Suffice to say there are lots of good things coming bu the library committee will have its work cut out to get them all properly specified in time for the Committe Draft coming late this year.

---

I also met old friends and new, put faces to names from newsgroups and books, and got too little sleep.

Debian Etch has been released lately, as you may know, and the work on Debian Lenny is already starting. For some of the DDs the work is way much different than for the rest of the DDs: the good ol' brave porters of m68k.
Stephen Marenka asked on debian-release what is needed to get back and be able to release with Lenny?
The answers are shaking:

1. To get back to testing: Basically, the release team didn't mind the
state we had with m68k in testing recently - basically, we just ignored
it, but it was still there. The release team didn't asked for full
dropping from testing, we just didn't mind either way. We also wouldn't
mind for m68k to be back in testing - as long as we can just continue to
ignore it.

2. To get released (or a realistic chance to): Basically, make sure that
the toolchain works (see the other mails), and get really fast buildds
(otherwise, the security team would probably veto the inclusion). The
second might happen with Coldfire, but - the how is your part, not ours
(i.e. if you do it some other way, that's ok as well of course).

Having said that, I can understand if the ftp-masters don't want to have
an architecture be in testing unless there is reason to believe it is
possible to include it in the next stable release, but that's not the
domain of the release team.

ad 1)
Ah, ok... as long as we are ignored, everything is fine. But how will testing m68k get updated when the testing scripts ignore m68k? Pardon me, but isn't this a little bit strange, at least?

ad 2)
Getting really fast buildds - good joke, indeed! Or is this a Friday, 13th habit like April Fools Day?

Conclusion)
Let's summarize: we can release with Lenny, when we get back in shape - but testing is needed for this, where we're ignored for. And without faster buildds for an arch such as m68k, there's simply no way back to make it into a release again - because of this.
Describing Coldfire as such a possibility for faster machine seems a little bit strange to me. CF is totally new, there's not progress yet on the CF front to my knowledge and a combined m68k/CF port may introduce other drawbacks, which nobody can predict for sure today. Do you really believe that ftp-masters or release team will allow such a port to get released? I don't.
Getting faster buildd in a reasonable amount of time is illusory for m68k. We can get more buildds online, but not "really fast buildds". Despite one older blog post of me, I'll receive just another '060 m68k soon (to be hosted by a fellow DD). A few days ago, two other m68k buildds were added to the m68k buildd rotation list. That will make 3 more buildds for the m68k.

Anyway, in most cases your first impression is the correct one and my first impression of the Vancouver Massacre/Proposal was: this is a plan to drop m68k!
Well, the lastest incidents confirm this impression, IMHO.
After all, I think that the m68k port would be best served by dropping Debian instead of being dropped by the project. The m68k port - de facto - has been dropped already. I'm disappointed.

In his “Init followup” post, Erich posted a reference to his Debian-Wiki post about a proposed Debian HackFest after Etch was released (which would be about 5 days ago<smile />). Anyway, since that page at the wiki is protected, which means I can’t edit it, I’m posting my thoughts here. I agree with Erich and some other commentors at Gunnar Wolf’s blog post that it doesn’t make sense to add X init-script-only-packages for any daemon to support X init systems. Instead, each package containing one or more daemons should contain the meta information needed to create all init scripts. Basically, this would probably include script snippets which do the following operations:

• Pre-check: Check wether the package actually is installed rather than in removed/configured status.
• start: Start the daemon in background mode.
• run: Start a daemon in foreground mode (so that an exiting daemon can immediately be recognized by the init system).
• stop: Stop a daemon running in background mode.
• stop-running: Stop a daemon running in foreground mode. This should only be needed if the daemon doesn’t shut down nicely on a SIGTERM but instead needs some sort of message/semaphore to do so.
• status: Return current running status.
• reload: Reload configs, reopen logs (if supported by daemon).

Additionally, some control information would be needed including, but probably not limited to:

• Dependencies: Should allow for alternatives, lists daemons which need to be running before this daemon is started.
• Provides: Similar to package-provides, this should be used to allow things like replacing inetd with xinetd or something else providing similar functionality.
• Short Description: For init systems that are capable of showing a short description next to the name of configured daemons
• Run-Sets: Not strictly like sysvinit-runlevels, but similar, should allow the admin/user to configure different sets of daemons to start, selecting at boot by a kernel cmdline-parameter or at runtime through some command (”init 1″) which set should be running.

The script snippets listed above should allow basically any operation on a daemon, including the force-reload and try-restart commands not yet implemented by all current sysv-initscripts.

Apparently animal control picked up a cat matching Leo's description on Taylor St (1 block away..) on Monday. I'm waiting for a call back from arresting officer Boggs. (Live updates on this important case as it happens..)

I just rewrote my aggregator (schcyrssmerge2) which still works roughly on this algebra from 2004 (still the basic set theory rule of blog aggregate generation: aggregate_i+1 = (blogs/aggregate_i) u (aggregate_inblogs)) but now calculates agg1 a different way. First, there's agg0 - the items from the input RSS file - and I store only the post ids of agg0 as agg0i for speed. Previously, I was reading in all the blogs and doing the above set theory calculation in one go. With a couple of ill-behaved blogs (full-content feeds of a few hundred kb), mzscheme's memory usage was just getting silly, topping out at hundreds of megabytes to merge 4Mb of feeds into a 3Mb aggregate. I think some of the problems are PLT's - reading a 3Mb RSS file in with

"(define a (call-with-input-file "friends.rss" read-xml))"

seems to result in mzscheme (v352) holding 100Mb. What's with that? Anyway, now I've written a newitems function which extracts new items not listed in agg0i and old items which still appear in a blog and adds them to lists. Then, there's a function which tail-recurses over all the blog filenames, parsing the RSS, calling newitems on each one and building the lists of old and new items. Finally, agg1 is the new items appended to the old items. That is only calculated as it gets written out as a RSS file. I'll give it a few days of testing, then I'll publish a tarball. I use this to build my all.rss feed from my various source feeds, in case you didn't realise, as well as to run some planets for public and private use. Anyone got a suggestion how best to reduce the read-xml memory consumption? Upgrade? Switch dialect? I'd like some XML read/write functions and the SRFI list functions.

Those who know me even moderately well (as well as every doctor I have ever seen), knows that my real first name as “Enid.” That is the mysterious E. that sometimes precedes the Gabriella. My mom’s intention was to call me Gabriella, the first name of some famous Italian Cabaret singer, Gabriella Ferranti. But when Enid, my aunt on my fathers side, passed away a few months before I was born, I was given the name Enid Gabriella. We have always used Biella or Gabriella but I like that I have Enid in there and have fancied from time to time to start using the name Enid. By all accounts, Enid was an amazing and energetic woman, who reared her four kids with passion, was very open to friends and family, and who, despite living a solidly upper middle class Jewish life, was also involved in interesting political work(like helping Americans doge the draft by escaping to Canada). My mom held a special fondness for her because, well, honestly I think she was one of the only members of my dad’s family who she deeply loved. And Enid always went out of her way to show her care and concern, as when she immediately went to Caracas after my mothers first child unexpectedly died of a high fever at the age of five months. Today as I was writing away, I received an email from my father that he sent to me and a bunch of cousins and other siblings where he attached a 9 page document of remembrances and memories of Enid. My dad, though in no way as bad off as my mother (health wise), is no spring chicken. And I think as he fast approaches 80 years old, he is committing a lot to writing and thus, keeping his memory alive for us. In fact, this reminded me of a really beautiful quote I recently came across on memory:

“You have to begin to lose your memory, if only in bits and pieces, to realize that memory is what makes our lives. Life without memory is no life at all, just as an intelligence without the possibility of expression is not really an intelligence. Our memory is our coherence, our reason, our feeling, even our action. Without it, we are nothing.” Luis Bu uel

But what was a little odd (but nonetheless very endearing) about most of the account is that it was not organized by stories, or date, but by car models. Yes, by technology. My dad organized the stories about Enid by virtue of the cars they had, which struck me a little strange because it is not like he was a car buff or anything (growing up we always had the most unsexy cars, like Ford Tauruses). The cars he covers are the following: The Model A Ford Convertible
The 1941 Oldsmobile
The 1948 Buick Convertible
A Chevy Convertible Once you read his little tribute, it becomes immediately clear that his choice of talking about cars is also way for him to talk about history which is my dad’s great love (he can talk to you straight for 5 hours about some odd event in WW II and why he should have become a historian) as it is about Enid. Case in point here:

This was the first General Motors car with automatic drive. It was called Hydromatic and even though this car had a powerful 8-cylinder engine, this first automatic drive was very sluggish. Forget about 0 to 60 miles an hour in 7 seconds. This was in minutes. It was the car that Abe used to teach both Enid and I to drive. We both had to have additional lessons with a stick shift car, because the driving test was only given on stick shift cars. I learned to drive in 1944, when I was 16. Enid took lessons from Abe and learned to drive in 1945 when she was fifteen. This was against the law, but the law in the name of Tom, the policeman that covered our neighborhood, liked Enid and looked the other way.

For those who care to read more (it may only be amusing to me and those few people that are into American car history), I have included all the cars and here are the main cast of characters. Ruth = My Grandmother
Abe = Grandfather
David = Dad
Enid = My Aunt, David’s sister (more…)

This is part of my ongoing series of posts wherein I am the last person on the planet to discover various things. (this is not a planned series, it's just how life is. :) )

If I ask Wikipedia about Virtual Server, I get an article about a Microsoft Hproduct. If I ask it about Virtual server, I get a page on server virtualization. Presumably if you know enough Wiki-lore, this makes sense.

Unsurprisingly, neither article gives me a clue about how I might go about renting a virtual server to avoid the hassle of maintaining hardware or which providers (if any) are reasonably trustworthy.

I've been a bit offline during the last two weeks due to being in the middle of a ISP switch at home, which took me offline for a longer time than expected. Additionally, when I finally got the connection up, it was Easter time, and I ended up going to Vall, after cancelling a cycling trip with some friends down the Via Verda Ojos Negros (but this time, not during the night and spending a few days to complete the route) in the last minute, due to the horrid weather forecast. It apparently was a good idea: the river that goes along Vall overflowed, and for some reason the mobile phone service went down for more than 3 days. On Monday night I came back to Val ncia, and I figured that the DPL election results would be out by the time. When I opened Debian's webpage, I found out some other big news: Debian 4.0 was released the day before! Soon after, I looked for the vote results, to find Sam, my candidate of choice, was the winner, very closely followed by uncle Steve. Congrats Sam, no nos falles! And congratulations to the rest of the Debian project for yet another successful, well done release. Reading comments on news sites gives a fuzzy warm feeling. Even though we were slightly delayed, people show how etch is going to make their lives easier, or how trustable Debian is at work and at home. That's the kind of stuff that keeps me and many Debian people going. I'm pondering improvising some Etch Release Party (as the release managers deprived me of a IRC party by secretly releasing while I wasn't looking) this weekend in Barcelona, where I will be visiting, after giving up on being able to be in A Coru a for DudesConf. Anyone up for it?