I think there's a certain special sloth that Americans get to experience on the day after Thanksgiving that we don't get on other parts of the year. Something about the combination of gluttony and wholesomeness makes Black Friday a very mellow, enjoyable time. Maybe it's the fact that it's officially now The Holiday Season, but the stressful tasklist of December hasn't started yet. Or maybe just that it's a day off of work for no good reason except it just is. Maybe it's the fridge full of leftovers that still taste kind of good. I dunno. We had a good Thanksgiving dinner yesterday evening. Maj, Amita June and I had planned to go visit family in New Brunswick (New Jersey) for the holiday, which was really nice to do last year. But our visas are running out in December, and although we're (probably) not going to have a problem renewing them, our lawyer said it was a bad time to leave the country. So, we stayed in Montreal for Thanksgiving. Canadians have their own Thanksgiving, of course, on the 2nd Monday of October, but not having grown up with that day as Thanksgiving, and with most of our family celebrating in November, it's hard to get motivated around Canadian Thanksgiving. And it's just not that big a deal in Quebec, anyways. So we had a good dinner here; John Usher, Niko, Jeff Waye, Meg and Patti all came over and had a good time of it. I cooked my first Thanksgiving dinner -- a big salmon, potatoes and sweet potatoes, roasted broccoli and wax beans, a great big salad. Every family has a Thanksgiving dish tradition -- one of the Prodromous' is a big pot of macaroni and cheese. So I made that, too. We all ate pretty well, drank some wine, talked about the future of music and how fun it is to play hockey. Unfortunately, I managed to miss my Blinky Hockey practice last night -- I tried to put the (overtired) baby to bed at 10PM and ended up falling asleep myself. All in all a good TG, even though far from family. tags: thanksgiving family montreal black friday dinner canada

Speaking of home All of Canada is abuzz right now about a recently-proposed bill by the ruling Conservative Party in Parliament to declare the Quebecois to be a nation within Canada. Sovereignty of Quebec has been an extremely contentious issue in Canada over the last 50 years (two sovereignist parties are major players at the federal and provincial level), and this form of recognition is an interesting step. The whole thing began with Michael Ignatieff, a candidate for the leadership of the opposition Liberal Party. He has stated publicly that Quebec is indeed a nation, and his followers are pushing to have that be part of the Liberal Party platform. The sovereignist Bloc Quebecois tried to steal their thunder by introducing a bill in parliament to the same effect. Their thunder was in turn stolen by the Government with the latest bill, which now has the support of all the parties and will almost definitely pass. The wording of the bill is interesting. First, it calls the Quebecois a nation -- the people themselves, not Quebec qua territory or government. Although the government has stated that this includes all people in Quebec, it's still pretty obviously targeted towards recognition of an ethnic group, French-speaking Quebecois, more than everybody who's living inside the borders. Second, it recognizes this group as a nation within Canada -- deflating the suggestion that it may become an independent state. I have to admit that the ambiguous nature of Quebec's status is one of the things I find fascinating about living in Montreal. As far as I can tell, few sovereignists hope for anything like a total split with Canada, but instead are looking for some sort of autonomous status. On the other side, even the staunchest federalists have seemed comfortable with granting Quebec more of an international profile, such as giving Quebec a formal role in UNESCO. My guess is that the nature of Quebec's relationship with Canada will change gradually until it reaches some stable point where everyone's comfortable. I don't know where that stable point is, but I think it'll be interesting to find out. At the turn of the 20th century, if you had told people that the British, Austrian, Turkish and Russian Empires would be dissolved and almost forgotten within 100 years, they would have scoffed. But in that short span of time, the idea of empire, spheres of influence, and Great Powers has passed from the world stage. We simply don't think in terms of Empire any more, but in terms of nation-states. My guess is that the 21st century will see a similar change in the idea of nation-state. With pressure from supranational organizations like the UN, EU, GATT and the International Criminal Court, as well as pressure from unrecognized nations like Quebec and Catalunya and Wales, I think the firm borders of the nation-state are going to loosen up a lot. What it will mean is anyone's guess, but I think if we're lucky we'll have a richer tapestry of nations and people participating in global politics and culture. And I think Quebec will be an important part of those changes. tags: quebec nation autonomy nation-state

Thanks, Biella! I'm glad to see that Biella is going to give us the goods on PR. Our Wikitravel 2007 Get-together is going to be on the island of Puerto Rico, and Biella's from there, so she's going to make up a list of good places to check out. Great news! tags: thanks biella coleman puerto rico wikitravel

When you DJ or - as I do - dance a lot, the beats-per-minute values of songs are interesting. However, counting them manually is a pain, especially if you have lots of them. GJay is a software that can calculate the BPM (using a clever algorithm from BpmDJ). However, it stores the information in it's own database. Whenever you move the file, you'll likely have to recalculate it. And so on. However, the ID3v2 format has a TBPM field for beats-per-minute information, so why not store it there? gjay from CVS (sorry, the Debian package doesn't include this yet; I also do not know if this works for Windows) has a standalone mode for analyzing. So I wrote a tiny python wrapper which can mass-process files, runs them through gjay, parses the XML output via ElementTree and tags the files with mutagen. So get the dependencies - gjay from CVS, python-elementtree and python-mutagen - then run my script. Or modify it to suit your needs, it's free software. [Yes, I am aware that there are songs which change speed. So what? I'm not expecting the BPM value to be exact, or to apply from the very first bit to the last...]

There has been an interesting thread on the debian-isp mailing list talking about control panel software for virtual hosting. I’m biased against several of the available control panels, but there are certainly times when I wish there were a simple solution or two which I could try that didn’t involve throwing away all my current setup and migrating all at once mail, web, etc. I’ve ruled out several systems due to :

• Lack of roadmap.
• No support for software I like
  • exim4, for example.
  • No simple way to customise modules enabled on a per-domain basis. (PHP is icky and I don’t want it.)
• No real predictable support, or development activity
• Security issues
• PHP issues.

Every now and again I think about updating my hosting scripts such that they could be driven by a graphical control panel. But each time I get this thought I decide against it because:

• I too mandate certain software and that might not sit well with potential users.
• Most of the hard parts of a control panel are the GUI/presentation
  • I suck at making “pretty” interfaces/sites.

The other reason not to do it is that I have a system which is portable, well understood (by myself at least!) and isn’t hard to migrate away from if I wished in a piecemeal basis.

The Debian desktop development page, debian-desktop mailing list and debian-desktop alioth project that were three disconnected things are now being used, maintained and in some ways managed by some members of: pkg-gnome, pkg-kde and pkg-xfce.

What will be waiting for you in Etch:
- Three tasks, one for each desktop environment project cited above that can be installed using d-i or your favorite package manager (eg.: aptitude) after a base system install. I'll publish detailed information about the package selection soon

What's still being worked out:
- Common artwork! pkg-gnome, pkg-kde and pkg-xfce are working very hard to point their artwork stuff (login screens, splash and wallpapers) to the desktop-base source package already being maintained in debian-desktop svn repository (it was in pkg-gnome svn repo). GNOME is already using the artwork, the GDM theme needs some last minute fix, KDE and XFCE will be done soon
- I've asked Joey Hess input on the possibility of build 'desktop cd sets' (3 cds) containing: gnome-desktop, kde-desktop and xfce-desktop tasks and its dependencies each. This is needed because to install GNOME or KDE desktop from d-i you will need the 1st DVD or netinst or 1st CD with broadband connection
- Debian Live CD project hopefully will join us soon, but i've sent a patch to their live-package that will turn the GNOME, KDE and XFCE images use the same set of packages that tasksel. With that in place, we can generate official Live CD images with the same set of packages that the 'desktop cd sets' proposed above

While cleaning up my hard disk, I found the beginning of an outline for a book on Bazaar (bzr), the version control system. I wrote it one weekend this summer, when I felt I had lots of free time. I don't, and won't, for the foreseeable future. Therefore I'll dump the outline here in my web log, so that perhaps someone will be inspired to write it for me. The Bazaar distributed version control system For most of the 1990s, the free software world relied on CVS for version control. It was the best free system for the purpose. During the early 2000s, a number of new systems started getting into public knowledge. One such system is Bazaar. This is the outline for a book to explain how Bazaar is used in different kinds of scenarios. The book is not a reference manual: the software's own documentation is best suitable for that; this avoids having to constantly update the book. The book is structured as a series of case studies of common scenarios, starting with the simplest one, and getting increasingly more complicated. This approach allows the reader to quickly learn the things they need for a particular kind of situation. Introduction This chapter explains what version control systems are, and gives a summary of their history so far. It explains various basic concepts, such as centralized versus distributed, but briefly; these will be expounded on later in the book. It compares Bazaar to other well-known systems. It explains the cumbersome naming history of Bazaar. It explains how to install Bazaar by referring to the website and to the package repositories of various Linux distributions. Quick overview This chapter is intended for those with some experience with other version control systems, such as Subversion. It gives a quick run-through of the central concepts of Bazaar, and how to do common tasks on the command line. The web page project This is the first case study chapter. It explains how to use Bazaar to keep track of changes to a web site. A web site only changes linearly: only one version exists at a time. My little program This chapter explains how to use Bazaar to maintain the source code for a one-person programming project. The program has a stable version, which gets bug fixes, but no new features. There is also a development version, which gets the new features. Sometimes a bug needs to be fixed in both, and Bazaar can help with this. Additionally, sometimes it is not clear whether a new feature can be implemented cleanly, or there are several possible approach to how it can be implemented. Thus, the chapter also explains these so called feature branches. Further topics for this chapter include making releases, and using repositories to avoid excessive disk usage. Tight teamwork This chapter explains how to use Bazaar when the one-person program becomes an internal project in a company, with a well-defined set of developers. Thus, we discuss how to set up a centralized branch in a way that all the developers can commit to it. Distributed free software development This chapter concentrates on a typical successful free software project, with contributors from all over the world, and the problems that this involves. Thus, we discuss how to publish a branch for anyone to see (but not change); how to share changes (patches/bundles) between developers; how to co-ordinate the development of the whole project (at least from the version control point of view). Switching a project to Bazaar That's it. If you write it, please send me a note when it's published so that I can get a copy. Thanks.

I have not written anything on this blog for a long time and after someone told me about it I decided that I could do it today; the long delay between posts comes from the fact that I'm quite busy with my current jobs and they don't leave me free time to work on Debian or Free Software related projects in general. Today I've been on the 2nd gvSIG Conference, a two day conference related to the gvSIG project, a GPL'ed Java based GIS (Geographical Information System) promoted by Regional Council for Infrastructures and Transportation (CIT) of the Valencian Government. I know about this project since it was made public, but I never tried it because I have a very poor GIS knowledge and I always try to avoid Java based software if possible (luckily one of the main reasons for that will change soon). Some months ago I tried the tool, but I left it soon because I found its interface quite weird and had no data to play with. Today I've seen a presentation about the raster capabilities that will be included on the next version of gvSIG and I have to admit that I've been quite impressed by them. I don't think I will use the tool much, but it is good to see free software projects like this one succeed; having local GNU/Linux distributions is not bad, but IMHO projects like this one are a much better way of using public money and promote the use and development of Free Software. My only complaint about the project is that the project development is not as open as I would like it to be (there is no public revision control system, no bug-tracker, ...), probably because almost all of the work is done by local software development companies that don't like to share their work until it is finished and don't have a free software development culture... ... but hey, nobody is perfect... ;)

Live CD on a removable disk Eros is a hardware guru that happened to be the unknown guy sitting next to me on a plane. He happens to be a happy Kubuntuer. While chatting, he told me one of his systems is an external hard drive made by copying a Kubuntu live CD image on it. Why did you do so? I asked. Because this way I can plug it in any computer, and it'll do hardware detection at boot. However it's a hard drive, so it's fast, and I can keep my home and all my customisations on it. I had never thought of it. That's an interesting and smart (ab)use of a live CD. Now I wonder: what would be required to plug the live CD boot time hardware detection infrastructure on an existing Debian or Ubuntu instalation? Update: slh on IRC suggests (a bit edited by me):

A lot of the former "obscure black magic" for live CDs isn't needed anymore. What is needed is: a kernel with static usb-storage, libusual, ehci-hcd, ohci-hcd, uhci-hdc (or an appropriate initrd/ initramfs). udev takes care of most h/w detection issues these days. As long as everything needed to boot is contained in a single partition you don't need a fstab: udev, hal and pmount take care of the rest, procfs, sysvfs, devpts, usbfs, shm are mounted by sysvinit. All what is left is a tool to create the xorg.conf while booting (those tools exist and just need to be called early). Everything else is just a matter of convenience: enhancing the live span of the USB key by changing data into tmpfs, etc.; if passwordless logins are required then xsession and inittab need to be changed; new ssh host keys generated on boot; small stuff. With ordinary flash storage, jffs2 and something to reduce write access is a good idea: perhaps unionfs for /var/ and /home/, bind mounting /tmp/ on /var/tmp/), but that's also not strictly necessary. Mostly it boils down to running the xorg-creation script at every boot time. There are various tools to do that. Some are here, but there is surely more. (Enrico's note: do we have anything in Debian that we can install and just does that?) Since USB and PS/2 mice share the same device since kernel 2.6, that part of xorg.conf doesn't strictly need to be detected, same for the keyboard (alps and synaptic touchpads can be easily detected) and X.org can use the screen's ddc info although it's not always reliable. It can boil down to just detecting the video chipset: something like this, that uses PCI IDs from discover1-data. It can also become a lot easier with X.org's own ddc detection, which almost boils down to configuring input devices and selecting the video driver. If I understand Daniel Stone correctly, X.org will soon improve its detection routines (fail safe X (auto-)configuration) as well in X.org 7.3. xresprobe is in debian: it's pretty similar to ddcxinfo-kanotix, both forked off RedHat's kudzu package - and all fail miserably on amd64. That's why ddcxinfo has a fallback to 1024*768 @75 Hz which "always works (+manual overrides)".

Writing tests is virtuous. It's the wholemeal bread of programming. Do it, and you'll be so much fitter. Except it tastes like cardboard and gets in the way of consuming the yummy treacle sponge of programming. But now I've got the testing religion. I view the lack of tests with the disapprobation of a reformed smoker tutting and huffing at the merest suggestion of a Marlboro Light. How did this happen and how can I be sure I won't backslide? The moment of transition was the first time that a test saved me from releasing software with a bad bug in it. The theoretical knowledge of virtue was translated into the palpitating relief of not disgracing myself in public. After that happened a few more times, I found myself desperately uncomfortable with the idea of releasing anything that didn't have decent test coverage. And so a virtuous habit is formed. It's not just driven by fear. With the right tools to hand, writing tests can be a lot of fun. You don't always need to be "in the zone". If you've got a spare half hour here and there, you can use it to increase the coverage of your tests. Getting better at testing is one of the ways I've become a much more proficient Rails developer over the last year of work on Expectnation. In case it helps anybody else, I thought I'd share some of the tools and techniques that are part of making Rails testing fun and effective. Continuous testing Whenever a checkin is made to our source repository, tests are run and the results emailed to everybody working on the project. As with the "you broke the build" disincentive, you need to be kept honest by frequent running of the tests. There are a variety of tools around to help you do continuous integration with Rails, most of which have some dependence on you using Subversion for source control. In the event, I just created my own script to do what we required. Coverage reports One of the big mental hurdles with testing is knowing how many tests you should aim for.  You can't prove a negative: even if your tests are all passing it still doesn't tell you much about the tests you haven't written that might fail! We use rcov as part of the continuous integration process, and post the results to our project web site. The pretty red and green bars give you some idea of when you're starting to get adequate test coverage, and the line-by-line breakdown is invaluable. Tainting strings One of the easiest errors to make in Rails templates is to miss the call to h(), to escape any HTML in an output string. The only real way to catch these errors is through automation. The wonderful safe_erb plugin helps you do just that. By using Ruby's tainting mechanism for strings, it throws an exception if you render any external data unescaped. One of the beneficial side effects of safe_erb is that you then become very particular about ensuring your functional tests properly cover every action in your application.  Tests such as get 'index', which before seemed mundane and redundant, are now essential, as you want to test for tainted strings. In addition to the above techniques, there are a lot of fun shiny gadgets to help you write tests, such as ZenTest, but the three things above are the ones I've found to be of significant value. I ought to conclude with words of praise for Rails. It goes out of its way to make testing an important part of the development lifecycle, and the availability of the of unit, functional and integration test functionality makes it easy to get started. Every time I teach somebody about Rails' testing features, they end up finding it very enjoyable.
Don't forget, testing can be fun!

For about five months now the Debian package of pbbuttonsd builds a package on i386, too, since it might actually be useful to have these available on MacBook (Pro) machines as well. What I don't know (since up until now I never actually used or even saw a MacBook with Linux installed) is whether any significant part of the functionality is working there or if it all depends on hardware that was specific to the PowerBooks and iBooks (e.g. PMU). I've decided that I will remove the i386 binary again before etch if nobody claims that it has proven useful too him. So if there are any users out there that would actually miss that package, please speak up now...

For about five months now the Debian package of pbbuttonsd builds a package on i386, too, since it might actually be useful to have these available on MacBook (Pro) machines as well. What I don't know (since up until now I never actually used or even saw a MacBook with Linux installed) is wether any significant part of the functionality is working there or if it all depends on hardware that was specific to the PowerBooks and iBooks (e.g. PMU). I've decided that I will remove the i386 binary again before etch if nobody claims that it has proven useful too him. So if there are any users out there that would actually miss that package, please speak up now...

There has been a lot of interest recently in the VFX VoIP service launched by WorldXchange (WXC), no doubt partly driven by the fact that there is no monthly charge until April 2007. I had a spare Linksys PAP2T so I thought I would try the service out to see how it performed. The signup process didn’t go anywhere near as smoothly as it did when I signed up for my WXC DSL connection. The online signup form tried to force me to select a new WXC DSL Plan (I don’t want to do that, I want to keep my old plan with free National traffic). Despite trying several times and making sure that the only checkbox ticked was VFX each time, it refused to let me go any further. Giving up on the web form, I rang the WXC helpdesk who answered promptly. It is easy to see why WXC won the 2006 award for best call centre. Every time I deal with them over the phone it is a pleasant experience. This time was no exception. The CSR I was talking to explained that the webform was dying because I tried to use a VFX username that differed from my WXC DSL username. There was no mention of this restriction on the website! Anyway, 15 minutes later, with my MAC address taken down and my voice recording completed, I was told we were all done and that I would receive my welcome email and account details with 2 working days! 24 hours later I received the email with the details, followed promptly by a phone call from WXC CSR who was ready to talk me through the process of setting up my PAP2. Configuring the PAP2 was a simple procedure, I had to copy and paste a URL into the Provisioning Rule field of the web interface and reboot the device. It then downloads configuration information directly from WXC (based off the device MAC adddress) and configures itself. I was up and running with dial-tone about 2 minutes after receiving the email. Very smooth. I understand that the process is even easier if you purchase a pre-configured PAP2. The downside to the whole scheme is that in trying to make the process as simple as possible WXC has locked the entire system down very tightly and remove a lot of the flexibility that I would desire. In particular my PAP is now completely locked, I can’t access any of the web interfaces, and even the dial-in prompt on the PAP2 replies with a curt “cancelled” before hanging up. There is no way for me to configure the second line of the device to talk to a second SIP provider. Apparently WXC will create a custom configuration for me so that I can still use the second line, but I imagine this requires giving them all my account details for my second SIP provider, which I’m not sure I’m comfortable doing. It also appears that WXC has an arrangement with Linksys such that every PAP2 now sold in New Zealand comes pre-configured to be used with WXC. I haven’t had a chance to look at one of these PAP2s yet, but if it were to turn out that I had to contact WXC to remove the locking on my PAP2 before I was able to use it with another VoIP provider I would be fairly annoyed. The MyVFX portal is very underwhelming. It insists on opening itself in a new browser window, and isn’t integrated with the rest of the WXC/VFX website. From what I can make out it’s just a branded frontend on to the management system that WXC has purchased. The user interface is reminiscent of the design of the 1990s. I think there is a lot of potential for WXC to improve the experience in this area and I doubt that the average user would be comfortable updating settings via MyVFX in its present state. On the technical side of things the VFX service seems to be fairly well designed and secured. The devices are provisioned and configured using the Linksys/Sipura provisioning tools, which appear to encrypt all conversations with the device. The setup process downloaded two configuration files and a firmware file (v 3.1.10) to my PAP2. Both of the configuration files were binary and appear to be encrypted. Interestingly it appears that WXC downgraded the firmware from 5.1.1 to 3.1.1 during the provisioning process. The MyVFX portal and SIP server appear to be using some sort of BroadWorks device. The device fetches it’s configuration file from the WXC server every time it is powered on, so it will be easy for WXC to push out updates and configuration changes as they desire. The VoIP side of things is performed using SIP, which appears to be using standard HTTP Digest authentication. The username and passsword for this being hidden inside the encrypted configuration files which are downloaded to the device. The voice data uses the G.729 codec inside an RTP stream, and from a few short calls seems to be relatively good quality. Conclusion
Overall, VFX seems like a very easy to use and simple service. Simple being the keyword. By locking down the devices so securely and preventing people from using softphones and devices other than Linksys equipment I imagine many people like myself are excluded from the potential market. I can’t see myself keeping the service after I have to start paying money for it. But I would definitely recommend it to friends and family who are looking for a simple, easy to use VoIP system.

Debian Jr. development revived Recently there has been some lively discussion on the Debian Jr. list about how to arrange an account for a child of 1 to 3 years of age. Suggestions included using set-top box software like Freevo, tailoring DEs with panels and large buttons, using simpler WMs like fvwm, or using an “activity centre” app like Gcompris. Now, I respect those parents who hold that a child this young should interact more with the “real world”. While I wouldn’t go so far as to outright prohibit my young ones from computer use, I can see the wisdom in keeping it to a minimum. But, for better or worse, our family is one of several who have some experience helping our youngest members use our Debian systems. We would like to share what we’ve learned through the Debian Jr. project. Getting started with live.debian.net To that end, last week I was inspired to follow the Debian Live ISO Howto to produce my first rough draft of a Debian Jr. live CD built from scratch on Etch. For the final product, we’ll want to use a local partial Debian archive mirror, as it not only optimizes fetching packages for several build iterations, but also can be kept stable, which is important as we near release. But for this draft, I ran into trouble building the complete package list to populate the partial mirror, as cdebootstrap, which make-live uses, has no handy --print-debs switch like debootstrap does. So for now, I rely on approx to cache packages for optimization only. A straightforward process to create a working live CD The rest of the process was straightforward: using live-package, I created a package list¹ containing Gnome and the Debian Jr. metapackages, I configured /etc/make-live.conf to point at my proxy, and then I ran the make-live script on the package list. The end result was ./debian-live/binary.iso, which successfully booted under qemu. At this stage, there is not much to show. To be truly useful, the live CD needs to be set up so that children and their guides can immediately find and use the material intended for them. We will need not only one live CD user, but four, varying in age range and role. (More about this in a future article.) However, it is an encouraging start, and shows that we may be able to produce something usable by the time Etch releases.

¹ For this exercise, I simply combined /usr/share/make-live/lists/gnome with the junior-* metapackages in Etch, and added mozilla-firefox-gnome-support to satisfy Gnome’s web browser dependency and cut down on redundancy, resulting in the following list.

junior-art
junior-doc
junior-games-card
junior-games-gl
junior-games-net
junior-games-sim
junior-games-text
junior-gnome
junior-internet
junior-kde
junior-math
junior-programming
junior-puzzle
junior-sound
junior-system
junior-toys
junior-typing
junior-writing
mozilla-firefox-gnome-support
eject sudo
console-common locales
gdm gdm-themes gnome-desktop-environment gnome-cups-manager gnome-screensaver
gnome-themes-extras
rhythmbox synaptic
x-window-system-core

Universal are one of my least favourite companies because of their work on bad laws like TPM and the French DADVSI. Universal Music Group: iPod/MP3 device owners are thieves [drake.org.uk] describes the creation of a Microsoft-Universal axis of evil as far as free culture is concerned. These protectionists are stealing free culture with lobbying for term extensions and other cunning plans, yet they dare call the population thieves. Culture belongs to the people, not Universal. However, there is a falling out among the band of culture thieves, with Universal taking on Murdoch in MySpace sued by Universal Music [BBC NEWS]

In two weeks (Dec 3rd) there will be presidential elections in Venezuela. This will be the third time where Hugo Chavez, the current President, will be participating in the elections. The first time, in 1998, he won by 62%, then dropped to 59% in 2000 and currently some polls are giving him between 50 and 60 percent of vote intention. Since 1998, we’ve got a very active electoral movement and controversial situations which have raised very diverse opinions about our electoral system. If I recall correctly, in 1998 people voted using optic forms. In that moment, spanish Indra was the company in charge for the machines and most of the technology used in the elections. That was the time where the Supreme Electoral Council depended on the Executive power, i.e., the President. In 1999, Chavez proposed to rewrite the Constitution, and the National Electoral Council became an independent power. This Constitution was approved in two referenda in 1999, where touchscreen machines were used. In 2000, after the new Constitution was approved, new presidential elections were made. The same touchscreen machines were used and we made a transition between Indra and a multinational holding named Smartmatic. In 2004, after two millions and a half of signatures were gathered to recall Chavez presidency, the revocatory referendum was made, using the Smartmatic machines. Almost six million people voted to maintain Chavez in power. Of course, after eight years of the same party in the power, as well as other problems (namely a national strike and a Coup d’Etat in 2002), several ideas arised regarding the legitimacy of the election process.
Today, the National Electoral Council released a flyer in the press, where they try to issue these topics. I must recognize that, being a newbie voter, I was unaware of several of the things they published today. For example, 8 of every 10 venezuelans over 18 are signed for voting in the elections. That’s one of the higher percentages of public awareness about elections in Latin America, higher than, for example, Colombia. That means 16 million people are able to vote, and we’re used to get around 60 percent of participation. We do vote with touchscreen machines, and the results are completely computerized. The military guards all the equipment, and provides security to the randomly elected civilian which work as temporary personnel. Members of every involved party are present in all the election centers, as well as national and international observers. After you’re checked to vote, you have to give your fingerprint in a special biometric device. This is transmitted live, were possible, avoiding two people voting in the same day. After you vote, your finger is marked with silver nitrate, which goes away after two days or so. Of course, you’re only allowed to vote if you don’t have the mark in your fingers. The touchscreen machines prints a paper which you put into the traditional box. After the voting has concluded, more than half of the boxes will be opened and checked against the information in the machine. The boxes subject to this check are randomly selected, as well. A brief thought about the software used in the machines. In 2004 or so, we (the Free Software Community in Venezuela) struggled and made pressure to the National Electoral Council to reveal the code and publish it wide open. This has been achieved until some point, since every interested person or organization is allowed to take a peek at the code. Dozens of organizations have already done so and are impressed by the features that are now present in the code. Before the first vote is registered, the machine prints a zero-vote confirmation, and then subsequently randomizes the order of the votes registered in memory. Only after all the election centers are closed, the machines start transmitting information. This year, three hours past the closing time we’ll have the results. The final and most important, from my point of view, argument held to support our election system is the random queue organization at the election centres. The registry is sorted by ID number, the votes are randomly stored in the memory and the biometric device is used in a per-arrival basis. Therefore, since nobody takes the same time to vote, the queues will be unarranged therefore making it quite difficult to determine a possible vote sequence. This has been certified lately by the European Union, the Organization of American States and other organizations. Whoever wins this election, I’m quite confident about our election system. I just hope that other institutions in our Country start using reliable systems (for example, the national ID office) in order to give at least the feeling of being in a rightful State.

There was very funny thread about CDBS and kitten. I think any other solution is better than plain Makefile. Long time ago I adopted the YADA. It's wonderful tool for anybody who hates Makefiles. Yes, the project is still alive. Unfortunately I don't have too much time for promoting this project. Just one month ago some developer did NMU for my package (see Bug#391753). He wrote that YADA is quite unfriendly for NMUers. I really wonder, how it could be unfriendly as far as plain Makefile don't support even separate patch files... I think it would be much better if Debian had only one tool for packaging. The RPM's SPEC file as single source for package is more friendly for maintainer than thousands of separate debhelper's files. So the YADA came. But... I understand it is just an option. It is my choose how to package my packages. My own right to decide. I can live with Debian and CDBS, YADA or other packaging helpers.

Amita June got her 12-month vaccinations two days ago. She had to get four shots -- two in each chubby little thigh. She's really building up a phobia about going to the doctor's office, screaming her head off each time we go in. Maj thinks it's a bad memory from the time she was sick and Maj took her to the nurse for an emergency checkup, which required getting her temperature taken... from the wrong direction. After her 12-month appointment (earlier last week), Maj bought her the book about Caillou going to visit the doctor, and a little doctor's bag that she waddles around the apartment clutching. We did some practice "shots" with the syringe from the toy doctor's bag, and played with the stethoscope and such. I think it helped a little bit, but still... 4 shots in one day is too much for anybody. Chuck Norris doesn't get 4 shots in one day without a few tears. The worst part, I think, is that the vaccinations give her a little bit of a fever, and she's supposed to get some chicken-pox spots next week sometime. She's been a bit irritable -- easy to understand -- which has made everyone in the house a little tense. When the baby's mad, we're alllllll mad. She's not sleeping well? We're not sleeping well, then. Anyways, hopefully this passes soon. tags: amitajune baby vaccinations

Web server twiddling for dummies Two fun things I did on my server today. First, I finally got around to installing mod_redir_to_servname, which turns out to be rockingly simple and useful. Thanks to Simon Richter for the good insight. The other thing I did was set up awstats for each of the domains hosted on the server. Much more fantastic than my grungy old Webalizer configuration, that's for sure. Even if it doesn't give me everything I want, it's pretty darn good. tags: web server redirecttoservname simon richter awstats statistics

PmWiki upgrade Another thing I did today was move the SonaUiki to my main server, and upgrade it from PmWiki 1.0 to version 2.1. That's something I've been waiting to do for a while -- the site has been really carpet-bombed by spammers, and I haven't been able to add any anti-spam extensions since the version was so old. The upgrade process was pretty painless, and the site is now cookin' with gas. I'd like to go back and update some of the PmWiki Cookbook extensions I wrote a few years ago, like the 404-caching extension and the Dublin Core metadata one. PmWiki's a neato piece of software -- well-crafted, compact, easy to extend and use. If someone bothered to configure Wikiwyg to work with it, I'd give it a serious thumbs-up. tags: pmwiki sonauiki upgrade cookbook wiki wiki engine

Video interview in The Deal I forgot to mention that there's an interview with me in the The Deal Blogs, the blog network for The Deal magazine. It's a pretty tough crowd at The Deal, so I'm pretty glad I came out looking as good as I did. We'll see how the print article looks, but for now I think I'm pretty OK. tags: the deal video blog interview me

As you may know, initial uploads of new packages in Debian need to go through the NEW queue for several reasons. As you may not know, I do store all my own packages I did, do and will do, as well as all the packages I did and do sponsor on my homepage for archive reasons. Currently, there are a few packages of mine waiting in NEW to be reviewed by one of the ftp-master team member. As some of them maybe are of generic interests, I do list them here for your convenience, so you can get them already now while they are waiting in NEW. These are, in alphabetic order:

• botan1.4 - multiplatform crypto library, version 1.4
• botan1.5 - multiplatform crypto library, version 1.5
• ipw2100 - Source for the Intel PRO/Wireless 2100 (ipw2100) driver
• ipw2200 - Source for the Intel PRO/Wireless 2200BG and 2915ABG (ipw2200) driver
• ipw3945 - Source for the Intel PRO/Wireless 3945ABG (ipw3945) driver
• kqemu - Source for the QEMU Accelerator module
• netbeans - IDE for Java Development and More
• pxfw - Plextor firmware updater

Paramount Comedy silences the word "ass" in That 70s Show before 9pm. Trouble quite happily leaves it un-silenced even when shown at midday. For a show that contains the phrase "dumbass" at least once per episode the Paramount Comedy approach is very annoying.

I've been pretty interested in making Web sites WebSoftwareFriendly for a while, so I'm pretty psyched to see that Yahoo and Microsoft have embraced the Google Sitemaps format. They've started a site for the format, http://www.sitemaps.org/ , which lists out the protocol, which seems to be unmodified from the original Google version. Sitemaps have been a necessary part of Web sites for years. Netscape -- back when it was a browser -- had an RDF-based sitemap format that had a brief flare of popularity just before Netscape went into its weird late-90s spiral. Then RDF people got really abstract and academic, and decided that sitemaps weren't what RDF was all about, and RDF sitemaps were forgotten. So sitemaps went off the air, and we've had to wait for a standard on the idea until today. Yahoo lets you submit sitemaps today, as does Google; Microsoft Live supposedly will support it sometime in 2007. One thing that's interesting is a new "ping" protocol, for when the site is updated. I'm not sure how well it works or if it's even implemented, but it's interesting to see it working. I think the weak part of this whole thing is that site owners have to submit sitemaps to each search engine; it would be nice if there were some sort of discovery, like an HTML <link> element, so that other types of Web software besides the big search engines would benefit. tags: sitemaps web software friendly yahoo microsoft google

Knowing when to hold 'em From O'Reilly's wrapup of the Web 2.0 Summit, I got a good link to some other Evan's Knowing When to Hold Em. It's a little discourse on the growth of Web 2.0 sites after they've been acquired. Evan Williams, the author and the guy who sold Blogger to Google, knows whereof he speaks. He has some graphs that show traffic for various Web 2.0 sites sloping precipitously upwards after their sale to some big company. The implication being, I guess, that the sites would have been more valuable to sell later. He also points out that few of the sites have benefited visibly from being acquired. I'm not sure the argument makes sense. Traffic is a cost centre as well as a potential source of revenue for companies. Keeping servers up, running, and cogent is hard work. Most small Web sites have been throwing labor and cash into their sites for a while, and the ability to keep such a site going into the Alexa top 100 is beyond most small companies. Paying for a lot of servers, developers, designers, sysadmins and bandwidth for another couple of years may make the site bigger and more desirable for acquisition, but it's a big risk to take. My favourite part of the discussion is that my friend Kevin Fox shows up at the end with some good points about when and how to invest. tags: web2con evan williams blogger traffic web 2.0 selling out

Free Software Java I've been programming in Java off and on since the first beta versions of the VM and JDK in 1995. The language has always had a certain cachet with the Open Source set -- the free-as-in-beer tools, good documentation, and cross-platform compatibility made it an Open Enough system, roughly equivalent to proprietary C compilers shipped with every Unix variant. Its release was roughly synchronous with the growth of the Web, and Java applet support in Netscape made the first round of rich client applications conceivable, if not exactly elegant. And then Java grew onto the Web server; and into other parts of the network; and then all of a sudden everything had to be Java. The system grew from this nifty little tool to The Enterprise Solution For Your Enterprise. Serious people worked on Java. I worked on Java when I needed to be serious. Java stopped being fun. Early efforts at getting Open Source Java VMs and development kits working were pretty successful, but they just couldn't catch up with the rapid pace of development on Sun's core product. But inclusion of the language in the Gnu Compiler Collection, the great JBoss J2EE system, the growth of Apache's Jakarta project, and the growing Java Community Process made Java less and less a regular product, built in a silo behind a corporate firewall, and more of an Open-Source-y project. So I guess it was inevitable that Sun would either Open Source its codebase, or end up irrelevant. They probably squeezed just about all they could out of it without going Free, so that's pretty impressive. I think Free Software advocates are supposed to be grateful about this; my main reaction is: why did you put everyone through all this crap for so long? You've wasted 12 years that could have gone into making Java really incredible. We'll see what happens. My main interface with the JVM for the last year or so has been through scripting languages like Rhino JavaScript engine (very fun) and Pnuts. Who's got time for Java programming any more? tags: java gpl jboss floss jakarta gcc jcp