Before anything else: Please excuse some grammatical mistakes I've made in this post. You should understand the topic is really upsetting, and typing while searching for links, listening to news, and gathering the basic information for a five month old conflict is not exactly compatible with me spewing out proper English ;-)
Just to re-state the obvious: Mexico is, once again, on fire. This posting is mainly written with the Debian people in mind - An important number of them, after Debconf 6, went to visit Oaxaca - In late May, during the first weeks of this incredible, stupid and scary conflict we are now facing.
I've written in my blog every now and then about our political situation. Many of us had high hopes on our current government. We thought that the authoritarian regimes were a thing of the past, we hoped for real democracy, we hoped for a government that would honor human rights and solve long-standing topics for our society - Yes, we all knew president Fox came from a right-wing party, and didn't expect much advance in the social agenda -which many of us perceive as the real problem in Mexico- but still, hoped for openness and reconciliation with the past.
I won't repeat what I've extensively said over and over - The thing is, Fox's government continues to amaze us with its stupidity, with its near-sightedness, with its hypocresy. Fox's term is really close to an end - In one more month, the govt. will change hands to the first de-facto president since Carlos Salinas (going over another story we hoped to forget).
As some of you wittnessed, there was a popular protest taking place mainly in Oaxaca - Basically, the State's public elementary school teachers demanding better payment for their work. Such a protest is already a common occurrence in Mexico, as public school teachers are among the worstly paid workers (no wonder, then, our country is still undeveloped - Make public education worse, and you have the warranty of an unprepared, ignorant population). The teachers went on strike in early May, briefly returned to classes on late June to properly close the 2005-2006 lective year, but went back on strike afterwards.
Of course, the local government (Mexico is a federative republic, each state is autonomous and makes decisions independently) took a very long time to act - and acted the worst way possible: By sending policemen to forcefully throw the teachers from their camps in the downtown streets, with no negotiation, no answer, not a drop of common sense.
That led to the formation of the (pleonasmicaly named) APPO: Popular Assembly of Oaxaca's People - A group of people, partly formed by the unhappy teachers, mainly demanding the Oaxaca state governor to step down, after he proved he is inept for his office. And yes, I'm oversimplifying here, but I don't want to dig too much - There is fortunately plenty of available information in this regard.
That happened over four months ago. APPO kept control of the city. Nobody denies that this has caused Oaxaca, a city that attracts national and international tourism like few others in the country, a great deal of economic damage - Oaxacan people are, however, still sympathetic to APPO's demands. Governor Ulises Ruiz (from PRI, the party that ruled the country for over 70 years) has not been able to be seen in public in his state for some months already. The legislative power has also been unable to work properly, and the judicial power is half-dead, doing only its most basic tasks. Renowned jurists, such as Miguel ngel Granados Chapa, have repeatedly stated that this is enough for the Federal Senate to declare the governing powers in Oaxaca have disappeared - This would put an end to the conflict, leading to immediate elections, but the Senate has denied taking this course of action. Not only that, but the Federal government took the command of the local security forces, tacitly recognizing the local government is unable to coherently excersise their authority. After almost five months, last week they issued an unanymous -but mild- exhort, asking Ulises Ruiz to consider stepping down.
So far, 15 people have been killed in the different represive actions taken, first by the local police under local command, later by the local police under federal command, and starting last week, by the federal police. Today, it seems the army is getting in the conflict as well, despite promises of not doing so by the federal authorities - Of course, they have become masters in the art of breaking promises.
Why is the federal government upholding Ulises Ruiz? Simple: After the undeniable electoral fraud we had some months ago, there are too many indicatives pointing out that our (supposedly) elected president Felipe Calder n (FeCal, as he is better known as) will have a hard time becoming the president, and many people doubt he will be able to hold the authority for the six years. So far, he has shown no better aptitude as a statesman than Vicente Fox: Instead of boldly facing the claims of fraud, he just chickened out and has spent many months hiding from the public, appearing only for selected, friendly audiences. For many months already we have heard "Ulises ya cay , le sigue Calder n" (Ulises has fallen, Calder n is next). This country has not been so badly shaken in decades - Of course, Great Statesman Vicente Fox insists the country is in peace and there are no red spots. Fox even was stupid/blind enough to state that the problems in Oaxaca would be dealt with easily and successfully, just as the problems in Chiapas and Atenco were doing his term. During Fox's campaign, he promised to solve the centuries-old Chiapas problem (that resulted in the EZLN uprising in 1994) in just 15 minutes - He just has not had time to do so. Atenco? Yes, in 2002 an angry people made him step back from the most important project of his term (a new airport for Mexico City). In May 2006, Atenco sprang again to the news because of a massive repression - I'm not going into details on Atenco right now, as it would be off-topic, but you can look at my article in FeCal.org.mx or watch a very strong video by Canal Seis de Julio (both in Spanish only) for further details.
Last Friday, however, something was different. In a repressive action, a USA citizen, the Indymedia reporter and cameraman Brad Will was killed by a paramilitary group. Even more, he was killed while doing his work, and we can clearly see this evidence on his last tape. Of course, the US ambassador issued a warning, asking the US citizens not to go to Oaxaca. And, as Lorenzo Mayer says, hay de muertos and muertos - There are different categories of dead people. A highly visible US citizen is more important than the other 14 dead Mexicans, and now the Federal Preventive Police is clashing in Oaxaca.
What should be shocking, but is not so much to those of us who know this beaten country, is the attitude of the authority when taking the city. After five months of occupation, the Oaxacan people have got used to living with APPO - be it for good or for bad. Tourism has diminished, but the people's living sources have not been attacked. Of course, as soon as the Federal Police took the downtown areas, all sorts of reports of looting have been reported. The policemen are robbing even sodas and chips, and up to TVs and microwaves. As many people state, this is a very Kafkian country.
Of course, we don't know what will come next. Most of the city has been "freed", and the APPO is holding at the University. The University is autonomous, and the PFP commands have promised not to break its autonomy - but we don't believe that. There are fights very close to the University. The Rector himself spoke a couple of hours ago at Radio Universidad, the main broadcasting point for real news on this subject (I am following on the news thanks to KeHuelga, 102.9MHz FM in Southern Mexico City, or at their webpage, from where they link to many other underground or Internet radio stations joining in the broadcast), and the reports are dramatic. Dramatic, as well, is the way all of the commercial news sources are ignoring the facts.
I want to keep you updated, as one of the very few reasons things are not worse is the public opinion and, even more, the international pressure. I'm sorry I'm not giving more links right now, but I will soon. I don't want, of course, to flood people that read my blog through the different syndications with a technical profile, so updates via my blog will be quite sparse. If you can read Spanish, we have posted many articles at FeCal, and many other individual sites are also joining in. A couple of links, and I'm off for now.

• APPO main site
• Spanish Wikipedia article on APPO
• La Hora del Pueblo
• Several videos in this regard in YouTube
• Centro de Medios Libres M xico
• Sendero del Peje

Program terminated with signal 6, Aborted.
#0  0x41050c14 in ?? ()
(gdb) bt
#0  0x41050c14 in ?? ()
#1  0x41050a2c in ?? ()
#2  0x41050a2c in ?? ()
Previous frame identical to this frame (corrupt stack?)

gdb, you are not helping me here.

…is yes, rather Edgy. Yesterday:

apt-get --download-only dist-upgrade    # grab pkgs at work
apt-get dist-upgrade                    # go home and do the dist-upgrade
apt-get dselect-upgrade                 # WTF?!? I had a lot of held-back pkgs?!?
                                        # Seems dselect-upgrade is more aggressive...
apt-get install xserver-xorg            # Funny apt-get tried to sneak away
                                        # my xserver-xorg (I lost it after dist-upgrade)
aptitude dist-upgrade                   # Hmmm, perhaps even better than
                                        # dselect-upgrade...

Today: (I ran out of Smart 3G prepaid credits last night :/)

apt-get update                  # Hmmm, apt's rather verbose lately
                                # with locales and stuff
apt-get install kubuntu-desktop # Heh, somehow I figured that was missing...

After all this, I seem to have a completely-upgraded Kubuntu system now (verified by doing dist-,dselect-, upgrade again,) despite the lack of a proper updating tool for Kubuntu (Ubuntu has its own Update Manager.) Still, FWIW I had to go through some hoops along the way (like all those multiple dist-upgrade invocations; I’ve done that before (twice) on the Breezy -> Dapper path, but thrice on Dapper -> Edgy? Just, wow…) but I got to learn some new stuff too (like pairing perlis and elric (my new 3G phone) via Bluetooth on the console. However, if I was in a hurry, I would have just e2mkfs‘d my partitions and started over. But then again, would I have had to move from Dapper to Edgy if I wanted to do that install dance all over again? Granted, the upgrade process needs some improvement: either elevate dist-upgrade’ capabilities to an even higher, godlike status, or make use of a different upgrader (dselect and aptitude does seem to have the upper edge’ compared to apt-get…) I guess there’s still some advantage of me not following the Edgy development process too closely (SoC, getting a new job, and school makes such a busy mix but I’d love to jump back again in Feisty, now that I do have the means to follow development more closely. Update: Looks like the dist-upgrades corrupted my swap partition, preventing me to do hibernates. A mkswap, followed by the subsequent edit in /etc/fstab and a reboot, fixed that. Update 2: Seems hibernate still doesn’t work (although suspend to RAM works absolutely fine.) A look of the resume process seems to show similarities between this bug, but I’ve yet to confirm.

After visiting Google for the Summer of Code Summit the other week, I thought I might actually try out some of the web services they’ve come up with, rather than just sticking with search and maps, and see if they did anything for me. To my surprise – as a certified hater of webapps generally – a couple did. Writely, the web-based word processor, was kind-of interesting, but in the end didn’t work for me. The potential killer feature for me would’ve been SubEthaEdit or Gobby -like interactive collaboration, which seems like something Google ought to be able to do with their whacky AJAX techniques. Unfortunately, it seems to just be some sort of automated merge-on-commit, which does nothing for me. What I’d really like as far as online document editing goes, is actually to be able to do Gobby-like editing of (moinmoin) wikis, rather than having to deal with advisory locking. I poked a bit further at that, and I suspect it ought to be possible to hack something up by using a tool like editmoin to edit wikipages with an editor rather than a webbrowser, and using gobby to do the editing, via a sobby server hosted on the same site as the wiki. It ought to be possible to automate all that complexity using an application/gobbymoin mime type; but I didn’t get anywhere because sobby seems to require IPv6 support. Oh well, maybe some other time. I’ve played with GMail and Google Talk before, with minimal impact. GMail is kind-of nice, but I like to be able to read my mail offline, so whatever. It is useful as a backup email address if my regular one goes down though. Google Talk doesn’t seem to handle voice/video under Linux, so it’s just a Jabber server. Which is fine, since I hadn’t ever actually gotten any of these whizbang IM things setup. What’s less brilliant is that Gaim is a bit of a pain when it loses connectivity, which happens everytime I suspend my laptop, which is everytime I stop using it. But I need GMail in order to even try some of the interesting Google services these days, so whatever. Google Calendar isn’t really something I expected much of. Sure, it’s a calendar app, but I’ve never gotten much use out of appointment diaries or planners or whatever anyway. Having it be web-based actually changes that a bit though, since it makes it trivial to publish to other people, and that even makes a calendar a little bit useful for me too. Having it be able to send reminder SMSes is also neat, at least now I’ve worked out how to default that behaviour to off… Oddly, though, I’ve found I’m getting more value out of it in listing things I’ve done rather than things I’ve got coming up. I guess it’s nicer to have a list of things you’ve actually done, rather than a list of things you should have done (but often didn’t), or a list of things you’ve got to do… But the real winner is definitely Google Reader even if it’s still in Google Labs, rather than even being “beta”. While I’ve tried some aggregators in the past, none have remotely grabbed me, and I’ve been tending to just remember the URLs for the blogs and webcomics I like, and type them in when I’m feeling bored. That has the benefit that it limits the number of each I read, but the drawback that I waste time typing URLs and waiting for pages to load even when there haven’t been any updates. The keyboard interface to Reader is pretty pleasant, with the only drawback I’ve found a slight lag in loading entries at the start of the day. Having it be in my web browser is perfect, since I generally want to follow a few links from blog posts anyway. It’s also made it easy enough that I’ve added a few feeds from real newspapers (or news channels), which is probably a good thing as far as balancing my take on what’s going on in the world. There’s a couple of downsides. One is that a lot of webcomics don’t have RSS feeds, or, if they do, don’t seem to include the actual comic, just a link to it. I don’t think there’s much of a reason for that – there are a few blogs I read that include ads in their RSS, so that doesn’t seem difficult to handle, and I can’t see any other potential objections. Also annoying is that posts that get aggregated on multiple planets (such as Planet Debian and Planet Linux Australia) show up multiple times, though admittedly I pretty much expected that. Probably the major downside is that it’s so easy to read stuff that I keep adding feeds to it, though…

It's a beautiful day here in wt:Los Altos Hills, wt:California, where my parents live. It's been unseasonably warm this week, ever since we hit the ground on Thursday, and we've been enjoying the warm weather to the fullest. Amita June is storing up vitamin D (a precious commodity in the Canadian north) for use during the rest of the autumn and winter. We had an early flight into wt:San Francisco from Montreal on Thursday. There's only one direct flight from Trudeau airport to SFO on Air Canada per day, and it takes off at 8:30AM. Maj is pretty convinced that we need to take direct flights with no stops while we have the baby; I'm mixed on the issue. I think a break every 2-3 hours makes it easier on all of us -- everybody gets some exercise and a little change of scenery. But Maj wisely points out that the takeoff and landing is the hardest part of flying with a little one, so direct flights minimize those. I dunno. Anyways, the 6 hour flight was uneventful, except for people coming up to us to comment on how good our baby is. The movie was "Click", which as I've mentioned before is the worst movie of 2006 bar none. It was pretty disappointing to see it come on -- I like watching movies on the plane. It was bright and sunny at SFO when we landed, and my mom met us at the baggage claim. We had a bit of a struggle getting out to the short-term parking -- for some reason the elevator queue at SFO is out of control; probably all the people loading and unloading luggage from the elevator. In any event, they now have elevator attendants and structured lines to make sure things go in an orderly, if slow, fashion. Back at the house, we had a late lunch of tuna salad and then Maj, Amita June and I did a big group nap. My mom had set up a toddler bed for AJ, and she's been sleeping in it since we got her. I think she's just turning the corner where having a little more space in the bed for herself is more important than nursing all night. Which I think is better for all three of us. Thursday night my dad came home from work in wt:Morgan Hill and we had take-out burritos with my parents, my sister-in-law Pam and Amita's two cousins Elena (3) and Tessa (10 months). The three girls got along like gang-busters; Elena seems to like being the older sister showing the younger girls what to do. tags: california travel los altos hills amitajune elena tessa

Jagi's Birthday Party Friday night we went up to the City for my brother Nate's annual Halloween party. Nate lives on a precipitous incline in North Beach, the Italian-Beatnik section in the northeast of San Francisco with steep hills, great caf s and a significant dearth of parking. We managed to get Amita June down to bed for the night, gave her grandparents far more instructions than were actually needed, and then sped off into the night. We were running late, but we stopped on the way to pick up Maj's brother Brian, who lives in Noe Valley. It was the first time we'd seen his new apartment and we probably took longer than necessary there, but we finally got off towards North Beach around 7:30PM. And... we drove and drove. Every street I drove down was packed, and I kept doing U-turns and trying alternate routes to get where we were going. Finally, on Van Ness Avenue at California Street, we got stuck in a gridlock that wouldn't move at all. Friday nights are pretty bad for traffic in San Francisco, but at this point we sat through 5 red-and-green light cycles without any motion whatsoever. Unable to turn, unable to go forward, unable to go back. When traffic finally started moving again, we saw what the problem was: the last dregs of the Critical Mass rally were just passing through. Critical Mass is a bike rally that happens on the last Friday of each month in San Francisco and elsewhere; hundreds of bike riders take over streets and block traffic. It's really fun if you're riding; it's infuriating if you're driving. We drove down further on Van Ness to go through the Broadway Tunnel into North Beach, but it was blocked by... Critical Mass! They'd turned about and come to block our way again. This time, I was able to do a U-turn and get over to Nate's house through side streets. We had a good time at the party itself. Nate and his roommates have been having a Halloween party for years, but increased size and complaints from landlord and neighbors have made them move the party to a nearby bar, Woody Zip's. With two stories, two bars and a dance floor, it was just about the right size for their event. Nate was dressed up as Buzz Lightyear from "Toy Story"; Brian had a huge fat suit and a sumo-wrestler outfit. Maj and I were millionaires, with tiaras and top-hats. We all looked pretty good. Woody Zip's even let the guys bring their own Jagermeister machine, affectionately known as "Jagi". They got the machine for one of their Halloween parties a few years ago, and they've made special costumes for it each year (this year: Spongebob Squarepants). We had a shot of Jager and toasted the machine's maturity, then moved on to karaoke and dancing. But only for a while; by 10PM we had to start heading home. We worried quite a bit about Amita June, but when we got back she was asleep in the arms of her Pappou in the TV room. The "parent curfew" is a little hard to deal with, but on the bright side it makes sure you can find babysitters so you can go out in the future. tags: halloween nate north beach party jagermeister san francisco

Baby Circus Last night we went to visit our friends Zach and Wendy in wt:El Cerrito, in the East Bay. Zach and Wendy have been our friends for... oh, more than 10 years now, I guess. They had a handsome little cowboy son two years ago, on the same weekend as my bachelor party in wt:Las Vegas (making it easy to remember his birthday... better than I remember that weekend, is for sure). They have a nice house just near the BART station, with lots of room... although about 2/3 of it is taken up with Wyatt's toys. Wendy is a Web developer for Nolo Press, the do-it-yourself law book publisher. Zach is a hard-working computer genius, one of my favorite people to work with, but he's hung up his spurs to be a full-time stay-at-home dad and go back to school. We had dinner at the Kensington Circus Pub, just up the hill from Wendy and Zach's house. It was a great place; an English-style pub with Fuller's ESB on tap, and a kids' play area underneath the dartboard. Amita June and Wyatt ran around playing while we had fish-and-chips and burgers. It's a great recipe for getting young parents to come to your restaurant; I wish more places would use it. We spent the rest of the night talking about wikis and web sites and all the opportunities there are available to share information in creative ways. We dragged home after Wyatt's bedtime, and Amita fell asleep in the car on the way back home. Greatest thing in the world! tags: zach wendy wyatt el cerrito kensington circus pub

I learn fire I had drinks with Hugh McGuire, founder of Librivox, at La ka on St. Laurent last Wednesday. It was a real good time -- Hugh has had similar experiences "leading" that public domain audiobook project that Maj and I have had with Wikitravel. Another project he's working on Collectik.net, an interesting tool for sorting and organizing podcast streams. I have to admit that I've been skipping the podcast wave -- much like I skipped blogging before it -- and I don't listen to a lot of podcasts. But Hugh got me interested, and now I'm looking around at it. I find there are a lot of interesting tools for podcast catching for Linux; even Rhythmbox, the Gnome music player, can handle podcasts. I'm finding it interesting to listen to them; DestinyLand and Chris DiBona's FLOSS TV are both interesting, as well as the CBC podcasts. I haven't figured out how to listen to Vu d'ici, though -- m-c doesn't seem to have an RSS feed with just the podcasts in it. Or am I missing something? tags: podcast destinyland flosstv vudici rhythmbox librivox collectik laika hugh macguire

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

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

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

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

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

Dear old Mutt, ... My MUA of choice is Mutt. I've been using it for something like 8 years now and I like it: it's quick, powerful and well integrated with the Unix way of handling mail (e.g. procmail). But we all know that. My feeling today is that sooner or later I will be forced to abandon it. The main reason is that it seems to be a dead product, upstream development is not dead but I fail to see an overall plan for my beloved MUA. Other text based application have understood that they should be integrated in some way with the desktop and/or windowing environment in which they are run: Vim for example is able to deal with the mouse wheel event when run in an xterm or even has developed a GUI which is well integrated with the Gnome session mechanism. Why Mutt is not? Such feelings of today has been originated by Tomboy, a wonderful note taking tool with Wiki-like capabilities, integrated with Gnome. It has a plugin for drag and dropping Evolution mails on notes automatically providing links from the notes to your mailbox: that's ... wow, great! I'm already using Evolution as my organizer and I already have Gaim integrated with it for contacts. I fear the moment I will try it for mails because I'm pretty sure it also has an UI which can be easily used with keyboard without the need of the mouse. Since I'm using all this on my laptop which is always with me (and this means that the argument "Mutt can be used remotely using a 9600 GSM connection" is bogus), it seems I'm running out of arguments for sticking to Mutt. Oh, right, there is the procmail stuff, my last feeble chance of keep on using Mutt ...

My girlfriend got a new notebook two months ago. She wasn't happy with Windows, and asked me to install Linux. Unfortunately, the Ubuntu 6.10 installation failed during boot, and presented me a nice busybox shell. A similar problem occured when booting the Debian Etch installation, it couldn't find the CD-ROM drive. Then I remembered that SuSE added some SATA patches from 2.6.19-rc to their OpenSuSE 10.2 Beta1 kernel, so I downloaded and tried that, just to see if it works, but it also failed. Looks like I have to tell my girlfriend that Linux doesn't work on her notebook... Update: No, libata.atapi_enable=1 didn't help, tried that already.

Right. Ubuntu 6.10 has been out for sometime now. Go dist-upgrade! Or get the DVD image, as I’m doing now via rsync diff-update. It appears that CD images aren’t available at cdimage.ubuntu.com yet, but it doesn’t matter since I had the previous Beta DVD image on hand and I can just do the rsync dance. But I really should take my own advice and dist-upgrade; I haven’t done so since I’ve been pretty much content with Kubuntu Dapper running smoothly between hibernates. I know I will have to dist-upgrade though, since the Ubuntu-PH LoCoTeam will have a Release Party in a couple of weeks, just in time for the arrival of Edgy pressed CDs, and we definitely would want to show off a fresh ,Ed,K,X ubuntu Edgy by then I just need a venue, a time, and a couple of drinks; suggestions, anyone?

Telling gpg not to use the key in the card So, I created the subkeys for the OpenPGP card, and it works. Now I'd like to upload some Debian packages, but the uploads fail because my new subkeys aren't yet known to the Debian keyring. I tried to push my subkeys to keyring.debian.org, but uploading afterwards still was rejected. Maybe it takes some time for propagation, maybe there's some other procedure to follow, I don't know. I didn't manage to figure out what is the procedure for getting a new subkey in the Debian keyring. I wish to replace this paragraph with proper details if I'll ever find out. Now, failing to use the subkeys, I had to convince gpg to use my good old main key. The quick and dirty way was to make a backup of the keyring, delete the subkeys, sign and upload. Seconds after hours of searching terminated in the above crude hack, as it normally happens, someone (Holger in this case) suggested the correct way to do it: use --default-key and append an exclamation mark at the end of the key ID. This was in the gpg manpage, but nowhere near the documentation of --default-key:

Note that you can append an exclamation mark (!) to key IDs or fingerprints.
This flag tells GnuPG to use the specified primary or secondary key and not
to try and calculate which primary or secondary key to use.

So, now I'm happy:

$ gpg --sign  --default-key '797ebfab!'
You need a passphrase to unlock the secret key for
user: [...]
$ gpg --sign
gpg: signatures created so far: xx
Please enter the PIN
[sigs done: xx]

Now that Ubuntu 6.10 (“The Edgy Eft”) has been released, we’re starting to see reviews of it; while largely positive, one common theme is that Edgy isn’t quite as edgy as people were expecting. Mark’s original announcement is certainly the likely reason for this expectation. In it he set the scene for a bold, brash, bleeding edge release to counter the boring dapper release. Unfortunately, the simple truth is that reality set in. When planning the release schedule for edgy, we realised that if we wanted to get back to our original six-monthly release schedule, we were only going to have four months in which to develop it. That’s still enough time to throw everything to the wind, and shove out a “release” at the last moment when the CD happens to be installable. It’d be edgy in the extreme sense. Unfortunately while exciting, we felt that such a release would ruin Ubuntu’s reputation. It’d be a release that, for all intents and purposes, would only be interesting to Ubuntu developers. Mark has already touched on this in his blog, citing a conversation he had with Matt (the Ubuntu CTO). Especially noteworthy is the mention that the kinds of itches that developers get are not the same as those users get. We get itches because the installer still relies on devfs-style paths, or because it’s not possible to boot the system without race-conditions. None of these things are noticeable to the end-user. We’re drawing up the list of topics to be discussed at UDS Mountain View in two weeks time, this is as good a guide as any for what we’re thinking about for feisty, the next release. At the end of that summit, we’ll have a list of approved specifications, assigned to developers throughout the community for implementation in the feisty schedule. Obviously some of those won’t make it due to time constraints, but the best thing about a six-monthly release cycle is that they’re not delayed for long.

upstart is a replacement for the init daemon, the process spawned by the kernel that is responsible for starting, supervising and stopping all other processes on the system. The existing daemon is based on the one found in UNIX System V, and is thus known as sysvinit. It separates jobs into different “run levels” and can either run a job when particular run levels are entered (e.g. /etc/init.d/rc 2) or continually during a particular run level (e.g. /sbin/getty). The /etc/init.d/rc script is also based on the System V one (and is in the sysv-rc package), it simply executes the stop then start scripts found in /etc/rcN.d (where N is the run level) in numerical order. Why change it? Running a fixed set of scripts, one after the other, in a particular order has served us reasonably well until now. However as Linux has got better and better at dealing with modern computing (arguably Linux’s removable device support is better than Windows’ now) this approach has begun to have problems. The old approach works as long as you can guarantee when in the boot sequence things are available, so you can place your init script after that point and know that it will work. Typical ordering requirements are:

• Hard drive devices must have been discovered, initialised and partitions detected before we try and mount from /etc/fstab.

• Network devices must have been discovered and initialised before we try and start networking.

This worked ten years ago, why doesn’t it work now? The simple answer is that our computer has become far more flexible:

• Drives can be plugged in and removed at any point, e.g. USB drives.

• Storage buses allow more than a fixed number of drives, so they must be scanned for; this operation frequently does not block.

• To reduce power consumption, the drive may not actually be spun up until the bus scan so will not appear for an even longer time.

• Network devices can be plugged in and removed at any point.

• Firmware may need to be loaded after the device has been detected, but before it is usable by the system.

• Mounting a partition in /etc/fstab may require tools in /usr which is a network filesystem that cannot be mounted until after networking has been brought up.

We’ve been able to hack the existing system to make much of this possible, however the result is chock-full of race conditions and bugs. It was time to design a new system that can cope with all of these things without any problems. What we needed was an init system that could dynamically order the start up sequence based on the configuration and hardware found as it went along. Design of upstart upstart is an event-based init daemon; events generated by the system cause jobs to be started and running jobs to be stopped. Events can include things such as:

• the system has started,

• the root filesystem is now writable,

• a block device has been added to the system,

• a filesystem has been mounted,

• at a certain time or repeated time period,

• another job has begun running or has finished,

• a file on the disk has been modified,

• there are files in a queue directory,

• a network device has been detected,

• the default route has been added or removed.

In fact, any process on the system may send events to the init daemon over its control socket (subject to security restrictions, of course) so there is no limit. Each job has a life-cycle which is shown in the graph below: The two states shown in red (“waiting” and “running”) are rest states, normally we expect the job to remain in these states until an event comes in, at which point we need to take actual to get the job into the next state. The other states are temporary states; these allow a job to run shell script to prepare for the job itself to be run (“starting”) and clean up afterwards (“stopping”). For services that should be respawned if they terminate before an event that stops them is received, they may run shell script before the process is started again (“respawning”). Jobs leave a state because the process associated with them terminates (or gets killed) and move to the next appropriate state, following the green arrow if the job is to be started or the red arrow if it is to be stopped. When a script returns a non-zero exit status, or is killed, the job will always be stoped. When the main process terminates and the job should not be respawned, the job will also always be stopped. As already covered, events generated by the init daemon or received from other processes cause jobs to be started or stopped; also manual requests to start or stop a job may be received. The communication between the init daemon and other processes is bi-directional, so the status of jobs may be queries and even changes of state to all jobs be received. How does it differ from launchd? launchd is the replacement init system used in MacOS X developed as an “Open Source” project by Apple. For much of its life so far, the licence has actually been entirely non-free and thus it has only become recently interesting with the licence change. Much of the goal of both systems appears initially to be the same; they both start jobs based on system events, however the launchd system severly limits the events to only the following:

• system startup,

• file modified or placed in queue directory,

• particular time (cron replacement),

• connection on a particular port (inetd replacement).

Therefore it does not actually allow us to directly solve the problems we currently have; we couldn’t mount filesystems once the “filesystem checked” event has been recived, we couldn’t check filesystems when the block device is added and we certainly couldn’t start daemons once the complete filesystem (as described by /etc/fstab) is available and writable. The launchd model expects the job to “sit and wait” if it is unable to start, rather than provide a mechanism for the job to only be started when it doesn’t need to wait. Jobs that need /usr to be mounted would need to spin in a loop waiting for /usr to be available before continuing (or use a file in a tmpfs to indicate it’s available, and use that modification as the event). This is not especially surprising given that Apple have a high degree of control over both their hardware and the actual underlying operating system; they don’t need to deal with the wide array of different configurations that we have in the Linux world. Had the licence been sufficiently free at the point we began development of our own system, we would probably have extended launchd rather than implement our own. At the point Apple changed the licence, our own system was already more suitable for our purposes. How does it differ from initng? Initng by Jimmy Wennlund is another replacement init daemon intended to replace the sysvinit system used by Linux. It is a dependency-based system, where upstart is an event-based system. The notion of a dependency-based system is interesting to talk about at this point. Jobs declare dependencies on other jobs that need to happen before the job itself can be started. Starting the job causes its dependencies to be started first, and their dependencies, and so on. When jobs are stopped, if running jobs have no dependencies, they themselves can be stopped. It’s a neat solution to the problem of ordering a fixed boot sequence and the problem of keeping the number of running processes to a minimum needed. However this means that you need to have goals in mind when you boot the system, you need to have decided that you want gdm to be started in order for it, and its dependencies, to be started. Initng uses run levels to ensure this happens, where a run level is a list of goal jobs that should be running in that run level. It’s also not clear how the dependencies interact with the different types of job, a dependency on Apache would need the daemon to be running where a dependency on “checkroot” would need the script to have finished running. Upstart handles this by using different events (“apache running” vs. “checkroot stopping”). Again while interesting, Initng does not solve the problems that we wanted to solve. It can reorder a fixed set of jobs, but cannot dynamically determine the set of jobs needed for that particular boot. A typical example would be that if the only dependency on the job that configures networking is the mount network filesystems job, then should that job fail or notbe a goal (e.g. because there are no network filesystems to be mounted) the result is that network devices themselves will not be configured. You could make everything a goal, and just use the dependencies to determine the order, however this is less efficient than just ordering the existing sysv-rc scripts (which can be done at install time). Another example is that often you simply don’t know whether something is a dependency or not without reading other configuration, for example the mount network filesystems may be a dependency of everything under /usr or may just be a dependency of anything allowing the user to login if it just mounts /home. The difference in model can be summed up as “initng starts with a list of goals and works out how to get there, upstart starts with nothing and finds out where it gets to.” How does it differ from Solaris SMF? SMF is another approach to replacing init developed by Sun for the Solaris operating system. Like initng it’s a dependency-based system, so see above for the differences between those systems and upstart. SMF’s main focus is serive management; making sure that once services are running, they stay running, and allowing the system administrator to query and modify the states of jobs on the system. Upstart provides the same set of functionality in this regard, services are respawned when they fail and system administrators can at any time query the state of running services and adjust the state to their liking. Will it replace cron, inetd, etc? The goal of upstart is to replace those daemons, so that there is only one place (/etc/event.d) where system administrators need to configure when and how jobs should be run. In fact, the goal is that upstart should also replace the “run event scripts” functionality of any daemon on the system. Daemons such as acpid, apmd and Network Manager would send events to init instead of running scripts themselves with their own perculiar configuration and semantics. A system administrator who only wanted a particular daemon to be run while the computer was on AC power would simply need to edit /etc/event.d/daemon and change “on startup” to “on ac power”. What about compatibility? There’s a lot of systems administrators out there who have learned how Linux works already and will not want to learn again immediately, there’s also a large number of books that cover the existing software and won’t cover upstart for at least a couple of years. For this reason, compatibility is very important. upstart will continue to run the existing scripts for the forseeable future so that packages will not need to be updated until the author wants. Compatibility command-line tools that behave like their existing equivalents will also be implemented, a system administrator would never need to know that crontab -e is actually changing upstart jobs. Does it use D-BUS?

“To D-BUS people, every problem seems like a D-BUS problem.” —Erik Troan

The UNIX philosophy is that something should do just one job, and do it very well. upstart’s one job is starting, supervising and stopping other jobs; D-BUS’s one job is passing messages between other jobs. D-BUS does provide a mechanism for services to be activated when the first message is sent to them, thereby starting other jobs. Some people have taken this idea and extended it to suggest that all a replacement init system need do is register jobs with D-BUS and turn booting into a simple matter of message parsing. This seems wrong to me, D-BUS would need to be extended to supervise these services, provide means for them to be restarted and stopped; as well as deal with being process #1 which means cleaning up after children whose parent’s have died, etc. It seems far simpler to arrange for D-BUS to send an event to init when it needs a service to be started, and focus on being a very good message passing system. The IPC mechanism used by upstart is not currently D-BUS because of various problems, however it’s always been expected that even if init itself doesn’t communicate with D-BUS directly, there would be a D-BUS proxy that would ensure messages about all init jobs and events would be given to D-BUS and D-BUS clients could send messages to init to query and change the state of jobs. What is the implementation plan? Because this is process #1 we are changing, we want to make sure that we get it right. Therefore instead of releasing a fully-featured daemon and configuration to the world, we’re developing it in the following stages:

1. Principal development; at the end of this stage the daemon has been implemented and can manage jobs as described.
2. Replacement of /sbin/init while running the existing sysv-rc scripts. This is the shake-down test of the daemon, can it perform the same job as the existing sysvinit daemon without any regressions?
3. /etc/rcS.d scripts replaced by upstart jobs. These consitute the majority of tasks for booting the system into at least single-user mode, and contain many of the current ordering problems and race conditions. If the daemon solves the problems here, it will be a success.
4. Other daemon’s scripts replaced by upstart jobs on a package-by-package basis; this will be an ongoing effort during which upstart will continue running the existing sysv-rc scripts as well as its own jobs. During this time the event system may be tweaked to ensure it truly solves the problems we need.
5. Replcement of cron, atd, anacron and inetd. This will happen alongside the above and result in a single place to configure system jobs.
6. Modification of other daemons and processes to send events to init instead of trying to run things themselves.

The current plan is that we will be at least part of the way into stage #3 by the time edgy is released, with that release shipping with upstart as the init daemon and the most critical rcS scripts being run by it to correct the major problems For edgy+1 we hope to have completed stage #5 and be at least part of the way into the implementation of stage #6. From the start of development of edgy+2, no new packages will be accepted unless they provide upstart jobs instead of init scripts and init scripts will be considered deprecated. What state is it in now? The init daemon has been written and is able to manage jobs as described above, receiving events on the control socket to start and stop them. This has now been uploaded to the Ubuntu universe component in the upstart package for testing before it becomes the init daemon. We welcome any experienced users who want to help test this; install the package and follow the instructions in /usr/share/doc/upstart/README.Debian to add a boot option that will use upstart instead of init. If your system boots and shut downs normally (other than a slightly more verbose boot without usplash running) then it is working correctly. Other types of events will be added as required during development and testing. Currently only a basic client tool (initctl) has been written, compatibility tools such as shutdown will be written over the next week or two before it replaces our sysvinit package.

Here at Canonical Towers we have several staff who worship at the altar of Extreme Programming, and as such many of the methodologies and rituals prescribed by that religion find their way into our day-to-day working practices. A few of these came together in an interesting way a few weeks ago, and it was suggested by a cow-orker that I blog about it so he could give the URL to people. The first ritual is that of the sprint, I don’t think this is orthodox XP but rather something inspired from it that we picked up from the Python community. With all of the Canonical developers scattered across the globe mostly working from their own homes, it’s become a useful tool; particularly for the Launchpad team. The basic idea for those that haven’t heard of it is simple, and perhaps obvious; you get a selection of the team together in one place, sit them around the same table with particular goals to complete. In effect it’s highly compressed facetime and high bandwidth interaction to nail those tasks that need it, before you head off again and work at a more sedate pace. The second is directly from XP doctrine and is that peculiar observance known as pair programming, something that is often coupled with sprints. For anybody who hasn’t encountered this before, it’s something I’ve always found rather odd. You get two programmers together, both itching to code, and you take one of them’s laptop away; and you don’t just force them to fight over the keyboard either, the laptop-less soul isn’t allowed to touch it. The theory here is that it frees the deprived individual of the hassle of coding and allows them to direct the programmer in ways that may not be immediately obbious, or alternately think about the next bit of work that needs doing. Another interesting side-effect is it can be an interesting way to learn code you’ve not worked with before, if you’re the one doing the coding and you’re being guided what to do by a sage who already knows it. I have a funny story here, so I’m going to digress from the main stream for a moment to tell it. A few months ago I was working in the London office, Mark had been up all night coding and had then given me responsibility to get his changes landed onto the Launchpad mainline. I’m not that hot on quite a bit of Launchpad, and fade to utterly clueless the nearer the code gets to the web application itself; and when trying to merge the two there were conflicts which I needed Mark’s help to resolve. Now as anybody who’s met Mark knows, he’s a pretty good example of a Type-A personality, yet he suggested that we do a spot of pair programming to get the code in and I’d be the one with the laptop as it’d help me get to grips with the affected parts. This hilighted something I’ve always seen as a problem with pair programming, dealing with it when the a person with the keyboard has a totally different way of working to you. In particular, I’m an emacs user, whereas Mark is a die-hard vim user; but also right down to the working directory I would work from, how I test results, etc. When you’re the one without the laptop, this can be quite infuriating, as you know exactly how to solve a problem and the idiot with the keyboard is dithering about doing things you don’t understand just to get there. If you’re a Type-A personality, you generally snatch the laptop away at this point and do it yourself; or at least you would, if you could drive the strange editor the other person uses. I swear Mark was sulking as he gave the laptop back and let me do it. Anyway, there is some relevance to that and we’ll come to it in a moment. The third and final methodology is the concept of unit tests and more specifically test driven development. For anyone who hasn’t come across this before, I highly recommend it; I was suspicious too when Robert Collins took it upon himself to teach me the true way, but now I’m sold. Simply the idea is that if you have any code that doesn’t have another piece of code in a test suite that checks that it’s working correctly, that code is broken. More particularly unit testing involves checking just one feature or requirement at a time, and stacking them together to test all of the code paths. I’ve actually found that this improves the APIs I design, as I write the code in small blocks and functions to make them easier to test. Test driven development takes it even further, you write the unit tests first, before you write the code they’re supposed to test; usually one or two at a time. Obviously these tests will fail at first, it’s then your job to write as little code as possible to make them pass. If your code isn’t right, you add a unit test that will fail, and modify the code to make it pass. This really comes into its own when you’re fixing bugs later, once you’ve identified the bug you write a test case or two that cause the problem; these will of course fail. You can then modify the code to make them pass, and at the same time be sure you’ve not broken other functionality because of the existing test suite. I’ve also found it really useful for particularly complicated or tricky pieces of code, especially those intricate algorithms that do particularly heavy lifting. So onto the event itself, this was a sprint in our London office to indoctrinate Gustavo Niemeyer with the various projects he’d be working on. The goal for this sprint was decided to start the conversion of HCT to Bazaar-NG, and to do this Gustavo and I would pair program. Now my last experience of pair programming had been that story with Mark (see, it had some relevance) and I knew I’d be just as bad if I wasn’t allowed to have the keyboard. I was also acutely aware that if Gustavo was just sitting by and watching, he wouldn’t get much benefit from it either, so he needed to be actively involved in the coding so he could learn the things he’d be working on. I came to what I thought was a pretty neat, and obvious, solution to these problems. We set up my laptop with the code we’d be working on, and on my display were two side-by-side terminals both running screen sessions. Gustavo then set up two same-sized terminals on his, ssh’d into my laptop from both of them and joined the screen sessions. In the left-hand one he ran vi, and in the right-hand one I ran emacs. Thus we both had keyboards, and both had editors, yet could see each other working and even steal the keyboard without danger of violence. We didn’t just sit side-by-side and code on different things though, that’s not pair programming and is just ordinary programming with a bit of a voyeuristic twist. What we did was: in my terminal I started writing the test cases for the code we needed, it was Gustavo’s job to write the code that would make them pass. We actually added a third terminal in which we could run the test cases themselves; so I could run them when I’d added something that would fail, and Gustavo could run them when he thought he’d made them pass again. This turned out to be a rather fun way to work, and at one point I was almost able to try and convince myself that the code was writing itself to pass the test cases I was writing. It also got me thinking that it’d be really neat to use genetic algorithms to breed code to pass test cases.

I've chosen Turbogears for a recent web project. Up to now, I was pretty happy with this choice, as it allowed me to made changes to the application rather easily, I happen to like KID templating, and it all was rather painless. However, I'm stuck at two place right now. One is a rather expensive database query I have not yet added - I know that it's going to be expensive, and I'd need some way of caching the results easily. I havn't found a "turbogearish" way of caching these interim results yet. Since that brought me onto the performance thing - when writing an app you don't really know yet how it will be implemented, you best postpone performance considerations a bit, so you don't optimize too early - I did some measurements. And was pretty disappointed by the results. The testing virtual machine (sorry, I don't have hardware specs for the actual machine) is rather slow. But still, static apache can serve some 450 requests per second. Turbogears will serve static files at ~22 r/s and the main page of the webapp at just 4.5 r/s (measured with siege, when it's not crashing). I tried switching from sqlite to mysql in Turbogears, but unfortunately that just makes the application crash altogether at some point (no SQL queries succeed anymore: 'Page handler: "Commands out of sync; you can't run this command now"') Notice that this was by no means a fair benchmark of Turbogears (I'm not a turbogears expert, and the little documentation I've found so far didn't help me at all in optimizing it's performance). I was just evaluating where I'm at, and now I'm about to decide where to go next. So can anyone point me to some docs on how to get turbogears up to an acceptable speed (where acceptable would probably be >20 r/s on this hardware)? Otherwise I guess I'll start a rewrite now, maybe using Java JSF and Facelets. They seem to be a good choice if you want XML-based templating. Don't even suggest PHP to me, it's crap. And I won't be trying Ruby on Rails next, either. I don't need rapid prototyping anymore, but can go for the high-performance implementation now, even if it will be harder to read, write and modify. I have now a better grasp for what I need and how the architecture of the app should be like.

Uses of Debian in Venezuela I'm just back from the IV Foro Mundial de Conocimiento Libre that happened in Matur n, Venezuela from the 17th to the 21st of October. Besides it being a great event and a great opportunity to meet great people (here are photos taken by Ana), it gave me the chance of seeing a bunch more uses of Debian that I didn't know about. Jos Parrella kindly provided me with a list that should open a short series of blog posts:

• SAPI - Servicio Autonomo de la Propiedad Intelectual (the Patents Office which will hold all of the Cuban and Venezuelan patents) uses Debian in all of their servers, including the HP StorageWorks 9.5 TB. They are listed in Who's using Debian.
• MCT - Ministerio de Ciencia y Tecnolog a (the Ministry of Science and Technology), is on charge of the migration process to Free Software. All the decision-makers uses at least dual boot, but most of them use exclusively Debian. At the conference I had a pleasant conversation with one of their representatives, discussing various aspects to keep in mind when choosing a piece of Free Software to use.
• PNAT, the National Plan for IT Literacy, uses Debian (or Ubuntu) in all laboratories around the country.
• CONATEL (the local FCC) uses Debian in servers and Internet Access Points.
• PDVSA (the national oil company) uses Debian in some areas, most notably they've setup videoconferences using OpenH.323 or MBONE using Debian in the PDVSA side.
• FONDAFA (the government fund for agricoltural development), uses Debian in their servers.
• SECODENA, the local Pentagon, uses Debian in their servers.
• DGIM, the local CIA, also uses Debian. Which is kind of creepy. The website runs on ASP, but they have a complete PDC/BDC and Mail Servers using Debian Sarge.
• EDELCA, an energy company in the southern states of the country, is implementing Debian right now. They have several hundreds of desktops already running Debian, and they're migrating network services (LDAP, Mail servers, etc.). There are two huge hydroelectric dams they operate.

More to come as I get back to other people I've met there.

Tuxpaint could be a poster child for l10n. It has translations now for 68 different locales. The large number of locales poses somewhat of a problem for testing¹. Tuxpaint 0.9.16 just released. During the release preparation, the manual testing of all of these locales drove me nearly insane. So to help out next time, I created the following bash script using xautomation², imagemagick and xprop (from xbase-clients):

#!/bin/bash
testname="tuxpaint" 
root_geometry= xprop -root _NET_DESKTOP_GEOMETRY  cut -d= -f2 
root_x= echo $root_geometry  cut -d, -f1 
root_y= echo $root_geometry  cut -d, -f2 
xc=$((root_x/2-1))
yc=$((root_y/2-1))
capture_tuxpaint ()  
   tuxpaint --startblank --nolockfile --lang $1 --640x480 --windowed --nosound &
   sleep 1
   xte "mousemove $xc $yc" 
   xte "mouseclick 1" 
   sleep 1
   xte "key Escape" 
   sleep 2
   import -silent -window "Tux Paint" $testname-$1.png
   xte "mousermove -120 -40" 
   xte "mouseclick 1" 
 
for lang in  tuxpaint --lang help  awk '$1~/^[[:lower:]]/  print $1 ' ; do
   capture_tuxpaint $lang
done

I’m not entirely happy with it, but it’s at least a starting point. Ideally, I’d make .pat files to use with visgrep to find coordinates for the button images instead of hardwiring the approximate button positions. Also, the script needs a companion script to configure the system for testing (i.e. perform the locales configuration and install all fonts). Here are the resulting screenshots which show up a few problems with the translations. It looks like the quit dialog strings have been updated since they were first translated, so now we need retranslation for several languages. Also, there are some languages, like Swahili and Klingon, for which there are no locales in glibc in Debian. I’ll have to talk to the glibc maintainers about that. And for that matter, I don’t even know if a DFSG-free Klingon font exists. In any event, I’m delighted with the results, and look forward to using xautomation more for GUI testing.

¹ For one thing, several languages require special fonts. For another, there is no way to get tuxpaint to tell you what locales it supports. Granted, there is --lang help, but this is a crude approximation, as the mapping between language and locale is arbitrarily hardwired (which hmh on #debian-devel irc pointed out to me is just plain wrong). It doesn’t help me at all in the arduous task of configuring glibc locales so I can test them. For that, I need to look at i18n.c.

² I tried using xmacro at first, but xmacrorec just made my pointer jiggle back and forth. It seemed like it was updating the position for a short distance, and then X was resetting it back to the former position of the pointer. Some strange interaction with my window manager, perhaps? But ultimately I am happier with the xautomation approach anyway.

I&aposve been dawdling and delaying writing about our trip to wt:Halifax (Nova Scotia) two weeks ago for some reason, but I&aposm bound and determined to get some info down on, uh, electrons about it right now.

Hella facts about Halifax We flew out of Trudeau airport eeeeearly on a Friday morning; I&aposd shopped a bit on the Air Canada site and got $99 each-way tickets from Montreal on their wp:Air Canada Tango program, but they required that we be on the 7:50AM flight. Air Canada used to be one of my favorite airlines, but they have been getting continuously disproportionately high prices and conversely worse amenities (pillows and blankets now cost extra, thank you very much). Discount flights in Canada are pretty sparse these days, with the collapse of Jetsgo in 2005 and the recent repositioning of CanJet for charters only. So, you just have to take what you can get. The flight to Halifax was quick and painless; Amita June slept most of the way there. The airport there is pretty small (yay small airports), so we buzzed through baggage claim. Cabs into town were a pricey flat-fee of $52, which got our hackles up, so instead we waited half an hour and took the Airporter shuttle ($16/person) into Halifax proper. We got to see a lot of the Nova Scotia countryside from the shuttle -- lots of leaves turning and conifer forests. We had reservations at the pretty and historic Lord Nelson Hotel, well away from the waterfront, but still in the downtown area, near Dalhousie University. The Lord Nelson is in the "Splurge" section of Halifax hotels on Wikitravel, but since this trip was for my birthday and our 2nd wedding anniversary I thought it&aposd be nice to stay there for one of the 4 nights we were in town. But when I called to make a reservation, I was able to get a very competitive rate, mostly due to a healthy 40% CAA discount, and I booked us for all 4 nights. I&aposd asked for early check-in, but our room wasn&apost ready at noon, so we tried the Lord Nelson Pub for lunch and a beer. The food was tasty and the atmosphere was, uh, pubby. We pawed through the stack of tourist-info documentation that we&aposd picked up at the info desk at the airport, then went up to our big and well-lit room for a mid-afternoon nap. Yes, all three of us. When we woke up, Maj and Amita June went for a walk across the street to the pretty wp:Halifax Public Gardens. It&aposs a very nice Victorian-era public park with disturbingly large geese roaming about. When they got back, the three of us headed down to the waterfront for an early dinner. Halifax&aposs streets are very steep -- they virtually plummet into the water. But we walked straight down to Water Street then meandered along looking at the sights. Our intention was to eat at the Privateer&aposs Warehouse, a building with a bar and two restaurants stacked on top of each other. It&aposs part of the Historic Properties on Upper Water Street, a collection of restored buildings with shopping and food. But the Warehouse turned out to be too rambunctious for us on a Friday night, so we instead went around the corner to Salty&aposs for a slightly more sedate meal on the water. We had good food; Maj had some very nice crab cakes and I took on a large seafood salad. Amita June chomped on really tasty fish and chips. The walk back up the hill was a bit tough, so we stopped in the Rogue&aposs Roost brewpub on the way home for a little strengthener. Unfortunately, as it was after 8:30PM, the baby wasn&apost allowed into the pub. So, we had to leave her tied to a parking meter while we had a... just kidding. We retired to bed after a long day, all three. tags: halifax travel amitajune nova scotia

California Dreamin&apos All the leaves are brown, red, orange, chartreuse and saffron here in Montreal, yet we&aposre off to wt:San Francisco tomorrow morning (early) to visit friends and family. I love going to see my parents and brothers and sister-in-law and nieces, but I also like going back to see the wt:Bay Area (California). It hasn&apost always been like this. It used to be that when I went back, it felt like I&aposd never left, and that the life that we&aposve made here in Quebec was just a story I told myself. San Francisco seemed real; Montreal seemed distant. San Francisco was where I was supposed to be; Montreal was where I stubbornly and irrationally insisted on staying. (The fact that I stayed in a room in my parents&apos house didn&apost help with the stepping-backwards feeling.) But it&aposs been a few years, and Maj and I have been married here, had a baby, and made a business for ourselves. Even though we don&apost own a house (yet), we&aposre putting down roots. Now when I return to California, it feels like a visit -- like traveling to just another destination. And you know what? California is a fabulous place to visit. Northern California even more so. San Francisco is a spectacular place on the edge of the ocean with music, art, redwood trees, organic food, and a sense of humor about itself that no other town quite has. It will be good to get back to SF for a while. It will be nice to take the baby around to see people and things that she hasn&apost ever seen before. We&aposll be in wt:Palo Alto to stay with my folks, visit my brothers in wt:San Francisco, up to wt:Petaluma and wt:Oakland to visit friends, and maybe even down to wt:Big Sur for a campout next weekend. I&aposve got the Web 2.0 Conference that I&aposm covering for LinuxWorld. And I&aposm sure there&aposll be more in there; we need ot dip the baby&aposs toes in the Pacific sometime soon. tags: california montreal home

As you may know, the future of the US world is again at stake in two weeks. Elections for the United States Senate and the United States House of Representatives will be held on November 7. Most general indicators are favorable to the Democrats (only 40% approve Bush administration, 46% vs. 34% think that Democrats would handle Iraq better than the GOP, 55% think US shouldn’t have invaded Iraq), and it seems they will likely get a majority in the House (latest polls show a 13-18 seats Democratic lead). Democratic Senate majority sounds far-fetched though. First of all, the members of the US Senate (which has 100 members, two per state, regardless of population) are elected by classes. The Senate is formed by three classes, so in this election only a third of the senators are challenged, which makes a turnover more difficult. Right now the Senate is composed by 55 Republicans, 44 Democrats and 1 Independent (who usually caucuses with the Democrats). Only 15 out of the 33 contested seats are held by Republicans, so Democrats would have to gain 7 of those 15 to get a majority (as a tie is broken by the Senate President, who happens to be the Vicepresident of the US, Dick Cheney). There are four close races that should be taken into account (Tennessee, Missouri, Virginia and New Jersey). Democrats would need to win three out of these to achieve majority. The amazing fact is that according to the latest polls they can make it. I’m not really fond of Democrats either (IMHO they are as right-winged as usual European right-winged parties), but lots of Dem Senate candidates are taking solid anti-war positions, which is quite good. In addition, I would say that anything that can take some power out of Bush hands it’s good news for the world. I just hope the anti-GOP wave is big enough. So, please, fellow American reader, on November 7th, vote the GOP out of the Senate and the House