QNAP recently released an upgrade for u-boot, the boot loader used on most QNAP devices, that adds a recovery mode. With this recovery mode, a backup image is requested via TFTP and then written to flash. This is useful in case there are problems during the installation or an upgrade of Debian. While Debian itself works well on QNAP and another NAS devices, we get reports from users every once in a while that their machine stopped booting (either after an upgrade or for no good reason) and it's usually impossible to say why since these devices are headless. The recovery mode allows them to put an image into flash that is known to work or an image of the installer that can be used as a rescue option. Essentially, the recovery mode removes the need for a serial console in many cases. I've added information about the recovery mode for the QNAP TS-109, TS-209 and TS-409/TS-409U, including installation instructions of users already running Debian.

Yesterday, I removed my new server from the rack and brought it back home, after the problems with the nVidia network chip (forcedeth) took down the NIC to the point that the IPMI chip, which is routed through the primary interface, wasn t reachable anymore. Even though a soft reboot fixed the problem, a bit of large-packet traffic, like downloading via IPv6, broke the card again. Since IPMI is also affected, I cannot remotely manage the machine and thus can t leave it in the rack. In fact, I am strongly considering to make use of the try&buy contract and return the thing. I cannot rule out a software problem, but given that the NIC goes into a state in which it gets unusable even to the IPMI system, which is completely independent of Linux, I somewhat doubt it. Instead, I suspect a hardware error, beyond the known problems with nVidia network chips and segmentation/checksum offloading. On the other hand, it s not news that drivers can break hardware, and the fact that I am using Linux is reason for hope. One alternative, which would allow me to potentially help in fixing this bug, is to use a riser card to stuff a different network card into the server. This would mean I didn t invest all the time into the server for nothing. Unfortunately, this workaround comes with extra costs, and would require Init Seven to allocate another switch port for the IPMI card, which I am not sure they ll be keen about. The bottom line of the story is that I will avoid nVidia even more in the future, and you might want to do so as well. Companies that produce crap hardware and do not cooperate with people writing free drivers for them do not deserve the money. Unfortunately, almost everyone out there uses the MCP55 chipset these days, and deny any problems with it. I guess I will take a look at HP and IBM, although I d really prefer not to pay for their brands, and not to enslave myself to their customer support standards. NP: Neil Young: Dead Man

Trying to put my new Nokia E71 to use, I was positively surprised to see that it has an IPv6 stack. Even though the integrated web browser does not care about it and insists on IPv4, it still made me happy to realise that Symbian (manufacturers of the OS) aren t totally missing the beat of time. But when I tried to get the builtin SIP client to speak to my Asterisk PBX, I ran my head against a wall. It didn t take me long to find out why it wasn t working, though:

<--- SIP read from 192.168.14.62:5060 --->
INVITE sip:echo@sip.madduck.net SIP/2.0
Route: <sip:sip.madduck.net;lr>
Via: SIP/2.0/UDP [2001:41e0:ff12::xyy:zzff:feaa:bbcc]:5060;branch=[...]
From: <sip:e71@madduck.net>;tag=i4a43mn949hc7vu5633b
To: <sip:echo@sip.madduck.net>
Contact: <sip:e71@[2001:41e0:ff12::xyy:zzff:feaa:bbcc]>
[...]
User-Agent: E71-1 RM-346 110.07.127
[...]
o=Nokia-SIPUA 63396745194593125 63396745194593125 IN IP6 2001:41e0:[...]

This is Asterisk s debug dump of the SIP INVITE packet, which initiates a connection. You will note that it arrives via IPv4, since Asterisk does not speak IPv6 and thus doesn t listen on IPv6. You will also notice that the Nokia phone doesn t give a flying food, but puts its IPv6 address into the headers. That s like writing a letter to your grandmother and telling her to answer by e-mail. You can choose between IPv4 and IPv6 for GPRS connections, but not for Wifi. There is also no way to turn off IPv6 altogether, at least none that I found. This really makes me wonder about the development process at Symbian, which must exclude testing and QA, or else I could not explain how such braindeadness could make it into a published product. On the other hand, we are all well aware of the lack of quality in software products that come force-bundled with hardware, like phones or plain computers. After Nokia acquired Symbian, they open-sourced the operating system (thanks, Penny, awesome girlfriend, for reminding me. Happy now? grin). After a bit of searching, I am pretty convinced that this was just marketing buzz, because I failed to find any information on how to obtain the code or how to put it onto the phone, six months later. I am not sure how to move on. I can either return the phone (wouldn t be the first time I had to return a Nokia E series phone for lack of quality), switch from Asterisk to some IPv6-enabled VoIP software (like FreeSwitch, which has not been packaged for Debian yet, mostly because the FreeSwitch guys are acting up about the changes Debianisation would require), or find some hack around this limitation. Ah, the joys of being an early adopter NP: Neil Young: On the Beach Update: Faidon Liambotis, who was also influential in my decision for the E71, found the problem: the phone s DNS cache. sip.madduck.net used to be a CNAME pointer to the machine running the asterisk server, wall.oerlikon.madduck.net, which also has an AAAA (IPv6) record. I thought about this myself and removed it, but the problem persisted. Faidon suggested to use the IP instead, which worked, and a reboot of the phone cleared the cache and allowed me to use the DNS name again, which is now a plain A record to the same host. As soon as DNS no longer advertises the IPv6 address, the phone s SIP stack no longer gets confused.

What started with a little host naming theme riddle, and spread as a meme across various planets, has come full circle today, as I installed a new machine, khyber.madduck.net in the racks hosted at the LayerOne colocation site in Z rich. Init Seven, my favourite Swiss ISP, are sponsoring the rack space and connectivity: a routed /28 IPv4 subnet and a /64 IPv6 subnet. The machine is a Transtec Calleo 331 1U server with two quad-core AMD Opteron 2354 processors, 16Gb of RAM, and 4Tb of disk space, configured into a 2Tb RAID1 with LVM on top. It will be used to host a couple of KVM instances for a number of projects I currently operate off my main, personal server, pulse.madduck.net. Unfortunately, Transtec (as well as most other vendors I checked out) uses nVidia s MCP55Pro chipset, which had me sceptical long before I sent the order. nVidia is known to suck at thinking open-source, and the Linux kernel driver for their network chips, forcedeth, had to be reverse-engineered, because nVidia failed to cooperate. Apart from that, nVidia s chips are also often simply crap. Many of their motherboards come with broken APICs and the network chips often wreak havoc on subnets. I find it curious that a search for MCP55 or MCP55Pro on the nVidia website yields no results. Given these expectations, I insisted on a try-and-buy contract, which are not default in Switzerland (as opposed to the EU). My fears proved right, it wasn t long until I encountered the first problems with nVidia s crap: the network chip is unable to deal with segmentation offloading for larger packets, e.g. those with IPv6 payload in a bridging context, and generic segmentation offloading has to be turned off on the interface:

ethtool -K eth0 gso off

This fixes the issue, and so I stuffed it into /etc/network/interfaces and decided to keep the machine, especially after having invested the time into the server to figure out how to work the watchdog and the IPMI card. The folks behind Transtec s support hotline are helpful, but it took me a bit of time to get the information I wanted out of them. At least they deemed it perfectly natural that I wanted to run Debian, and never questioned that. Let s document some of the more internal specs here for posterity: The BIOS gives the impression of two separate watchdogs, one on the IPMI card (a SIMSO+) and one on the mainboard itself (a SuperMicro H8DMU+). Transtec told me that SuperMicro disabled the IPMI watchdog (called BMC watchdog in the BIOS) with firmware 1.29, leaving only the one on the motherboard. It took a bit of time to find out that this was a W83627THF and supported by the w83627hf_wdt driver, which I configured with module options timeout=120 nowayout=1. I left the BIOS setting at disabled since that would otherwise interfere with booting e.g. the awesome grml live system by rebooting the machine after the set amount of time. It also took a bit of time to get SOL working with the IPMI card. In the end, I found it to work best by configuring the console redirection in the BIOS to use COM2 with 38400/n/8, using hardware flow control, redirection-after-POST always, and vt100 emulation ANSI and vt-utf8 emulation were horrific. I instructed the bootloader to pass console=tty0 console=ttyS1,38400n8 to the kernel (order matters), and configured agetty in /etc/inittab like this:

T0:2345:respawn:/sbin/getty -8hL ttyS1 38400n8 vt100

To guard against the worst, I also left a grml CD in the drive, to be able to boot a rescue system via SOL in case everything else was broken. The following kernel boot parameters enable me to use the rescue system via IPMI:

vga=normal noeject noprompt console=tty0 console=ttyS1,38400n8 forensic

Michael Prokop of the grml project tried to create a customised ISO image with these options for me, but I kept getting medium errors trying to read it, independent of the burner, CD-writing-software, operating system used to burn, medium, and drive used to read, so it s possible that the ISO image is faulty. Michael used the following command line to create it (supporting files are here):

grml-live -t ~/templates-madduck -c GRMLBASE,GRML_MEDIUM,AMD64 -o \
  /grml-live/grml64-medium_2008.11-madduck -a amd64 -s sid -v \
  2008.11-madduck -g grml64-medium -r Schluchtenscheisser -V -b

Until we figure out the problem with this, the grml64 0.2 CD in the drive will do. The machine is now operational, but the IPv6 prefix I have still arrives at vera.madduck.net, a Xen-Instance hosted by Init Seven, which I will no longer need, once I find the time to migrate all the services it hosts. NP: This Will Destroy You: Young Mountain

Per Andersson ported the Debian installer to the Kurobox Pro this summer as part of a Google Summer of Code project. Along with Riku Voipio, I acted as Per's mentor and gave him advice while he was trying to figure out all the details that were needed to get Debian running on the device. Since I spent the summer in Israel and didn't have my Kurobox Pro with me, I never performed an installation on my own though. Yesterday I finally found time to play with my Kurobox Pro. Per did a great job and the installation worked without any problems. I also investigated how the recovery mode works and added various new information to my Debian on the Kurobox Pro pages. The Kurobox Pro seems like a nice machine, but I hope we'll add full support for the Linkstation Pro and Live soon since these devices are much more easily available. It shouldn't take too much work since these devices are quite similar to the Kurobox Pro.

My posting about receiving a Conceptronic CH3SNAS a month ago prompted Matt Palmer to work on the installer. Matt did a fantastic job and had patches for everything within a few days: he added support for the revision B of the DNS-323 to the kernel, added code to the kernel so the MAC address is parsed from flash, and added DNS-323 support to various components of the installer. Finally, he wrote a really good porting guide that will hopefully inspire other people to port the installer to more NAS devices. Porting to another Orion based device usually doesn't take much now that we have the infrastructure in place. While Matt's patches came too late for inclusion into the initial release of lenny, the release team seems agreeable to the idea of adding support for the D-Link DNS-323 and Conceptronic CH3SNAS to a stable update of lenny. To this end, the dns323-firmware-tools package which is needed to create proper firmware images for the DNS-323 was accepted for lenny a few days ago. Alan Fletcher also kindly agreed to make a serial cable for me, so hopefully I'll get a chance to test Matt's patches soon and integrate them into the installer. In the meantime, I created a few simple pages about Debian on the D-Link DNS-323 which I will extend once support has been integrated into the installer.

It is often argued that companies have to work with the FOSS community and there are good reasons for doing so. I've tried to collect a number of case stories of good and bad community interaction that may help as a starting point for further exploration of this topic:

• NVidia is probably the best example of a company that is not interested in providing open source drivers for their graphics chips. There are lots of folks who won't buy hardware with NVidia chips for this reason. Intel is the number 1 choice at the moment because they work closely with the community. Related to this, the Linux Foundation and kernel community released a statement regarding open drivers.
• When Sun finally made Java available as open source, they argued that it would help inclusion and distribution of Java (e.g. inclusion into Debian). Sun also felt that the GPL provides the strongest protection "against misbehaviour by monopolists in the Java platform".
• The Novell/Microsoft deal was not perceived well by the community, which led to web sites like http://boycottnovell.com
• Nokia recently had an insightful blog posting about the problems when nobody knows about the open source contributions you make: for example, you cannot influence decisions in a project as easily.
• Sun is often criticized for dominating all open source projects they run. They can be used as a good example that you have to give up some control in order to get outside participation.
• The fact that Xen is not in the mainline kernel is a key reason why a number of companies (e.g. IBM, Red Hat) are looking at KVM (which is in the mainline kernel and actively developed in the community). In fact, "looking" is probably not the best word. IBM is actively working on KVM to make it a viable solution and Red Hat recently acquired Qumranet, the company behind KVM.
• Oracle got fairly bad press for copying the Red Hat distribution and changing Red Hat to Oracle, without engaging in the Red Hat community.
• There's a paper that looks at "empirical evidence on the incentives of firms that engage in OS activities." They look at 146 Italian companies supplying open source solutions, but unfortunately the study doesn't include any major company.

Can you think of other examples? (Originally published on FOSSBazaar where comments are possible)

I started building the Debian archive with GCC 4.4 ten days ago to report build errors. I've completed the archive build now and reported about 220 bugs (the majority with patches). There are roughly 30 build failures left that I haven't analyzed yet. There are also about 35 packages that fail because the boost headers don't work with GCC 4.4. I'll try to build them when the boost headers get fixed. The majority of GCC 4.4 build errors are trivial. The large majority of failures is because of missing #include statements. There are also about 20 build errors because of improved preprocessor checks. I'll try to do another archive build when the gcc-4.4 package is in Debian.

After just three days of beta operation I could already make screenshots.debian.net go live. Within the first day I fixed a few typos, optimized database queries and added proper HTTP headers for caching. We got a huge load spike after my announcement on debian-devel-announce. I’m very happy and proud to have this service running and appreciate the help from the SQLAlchemy, Pylons and Debian community. Michael Vogt has already added screenshots support to the Synaptic package manager. Martin Stigge has joined the admin team to speed up approving screenshots in the moderation queue. (It would nice if someone else volunteered who is from .us or .au to deal with uploads while we sleep.) And above all I’d like to thank ‘zepolen’ from car.gr for allowing me to host the web application on his server. I think neither of us estimated so much interest in the service. May his server not melt under the load. Honestly the first feedback wasn’t very motivating (developers tend to point out errors first) but I enjoy seeing how quickly the news is spreading. And thanks to everybody for uploading further screenshots. I’ll keep on watching the moderation queue and enjoy how others blog about it.

There have been a number of improvements to the Debian installer on Network Attached Storage (NAS) devices in the last few months and they are available to users now that RC1 has been released. We have added support for Marvell's Orion platform. Orion is a system on a chip (SoC) that integrates an ARM CPU, Ethernet, SATA, USB, and other functionality in one chip. The majority of NAS devices that have come out within the last two years are based on Orion chips, so it's exciting to have support for this significant platform in Debian. Specifically, we support the following devices based on Orion: QNAP Turbo Station (TS-109, TS-209, TS-409), HP Media Vault mv2120, and Buffalo Kurobox Pro (with more to come later). Here are some other newsworthy improvements and changes:

• When a static IP address is set in the original system that is the default from the vendor, this address will now be used. In the past, the installer would use DHCP in this case but users found this confusing. This affects the Linksys NSLU2 and Thecus N2100.
• If a static IP configuration is used in the original system but this configuration is incomplete (i.e. IP address or DNS are missing), then the installer will use DHCP (instead of hanging during start). This affects the Linksys NSLU2 and Thecus N2100.
• On the Linksys NSLU2 and Cobalt devices, all required installer modules are automatically installed now and no longer have to be selected manually from a list.
• initramfs will use MODULES=dep rather than MODULES=most. In other words, only modules that are actually needed on your system will be included in the ramdisk.
• /etc/default/rcS will be configured on supported NAS devices to contain FSCKFIX=y, so e2fsck will attempt to repair the filesystem without prompting the user for input. This is useful on NAS devices since they are usually headless.

Finally, the armel port is recommended for new installations now. Debian lenny has two different and incompatible ARM ports: the old ABI port (arm) and the new EABI port (armel). Debian lenny is the last release with support for the arm port and future releases will only support the armel port. It's therefore recommended to use armel for new installations of lenny.

C++ header dependencies got cleaned up in GCC 4.3, which broke a lot of code which relied on headers to be included indirectly through some other headers. I found some new build failures with GCC 4.4 related to missing #includes; in particular, #include <cstdio> is missing in a lot of code. Typical errors look like these:

error: 'sscanf' was not declared in this scope
error: 'EOF' was not declared in this scope
error: '::fseek' has not been declared
error: 'uint32_t' does not name a type

Below is a table showing which header needs to be included for a number of common functions:

Functions and defines	Header
fopen, fwrite, fclose	cstdio
fread, fseek, feof	cstdio
sscanf, sprintf	cstdio
rename, open	cstdio
EOF	cstdio
memset, memcpy, strdup	cstring
va_list	cstdarg
int16_t, uint32_t	stdint.h

Yesterday I took part of the fourth inter-state bike ride, requesting the construction of proper and safe cycling ways. Tens of Mexican bike-rider organizations were part of the organization, althought the effort is basically grouped under the Ciclopistas y Ciclov as Interestatales project - For further details on the route we took, you can look at the M xico-Pachuca road map, although it was not followed literally.
I am very happy I decided to take part of this - I went with Adri n, but after the first rest/grouping we lost track of each other, and decided the best would be for each to go at his own pace. He managed to do the 95Km ride, I decided to stop at about 85 (I set my target to the first houses of Pachuca, so I could say I arrived ;-) ) and took a ride from the barredoras that were trailing us. Still, 85Km in about six hours (including the two rests) are well over what I expected to endure. And although the conditions were not ideal (i.e. there was some re-pavement jobs in a large portion between Tizayuca and Pachuca, which led to poor road conditions in some areas, and the dry, horrid smell of tar in others; we cycled along the vehicles in the very busy highway, so we didn't exactly get a dose of clean air), it was great. And I thought each of my muscles would hurt like hell today, but no, they are just feeling lazy ;-)
The GPS tracking on Nokia SportsTracker, The GPS tracking on OpenStreetMap

GCC 4.4 will show more preprocessor errors when compiling code, partly because some new checks have been added and partly because the full preprocessor directives are now checked. So let's review some common problems. Let's take some code like this:

#ifdef A
#elif
#endif

This will now give:

t.c:2:6: error: #elif with no expression

The reason is that an #elif always needs an argument. Looking at the code, it's obvious that a #else should be used. Another common issue is this one:

#define B
#ifdef A
#elif B
#endif

The problem here is that you're trying to check whether B is defined, so the third line has to be:

#elif defined(B)

Finally, the following code:

#ifdef A
#elif define(B)
#endif

will give:

t.c:2:13: error: missing binary operator before token "("

It took me a minute to see what was wrong with the code... but define is a typo and what you really want is defined.

debian-installer rc1 is going to be officially announced next week. However, the netboot images are already available. I'm now looking for people who are interested in testing these installer images on ARM and MIPS based machines. If you have a spare ARM or MIPS machine or want to reinstall your machine for some reason (for example to move from arm to armel), please see my messages on debian-arm and debian-mips for more information. I've used this opportunity to update all my installation instructions to lenny. See here for Debian on Linksys NSLU2, Thecus N2100, QNAP Turbo Station, HP mv2120 and Cobalt.

A couple of years ago, I started what has probably been the best job I've held so far, as a Business Development Manager for Artec Group where I focused on marketing and selling the ThinCan LTSP client. During that time, I used a combination of Guerrilla Marketing techniques to spread the word about this cool Estonian embedded platform in its LTSP client configuration and defined an extremely tight market-oriented focus that saw this relatively obscure electronic design start-up rise to the forefront of the LTSP hardware market and also brought the company commendable notoriety in the Coreboot community, thanks to its Programmable LPC Dongle, a low-cost ROM emulator that can be used to bootstrap various embedded hardware and test firmware images. Looking back at close to 3 years with Artec (if we include the stint I did at Linutop), I most fondly remember how I managed to bring the Estonian and Turkish nations closer together in collaborating on Innovation. On my first visit to Turkey, I had noticed that very little is know about Estonia in Turkey, even though both countries have a collaboration that dates back to the 1920's, so my tactic was to introduce Estonia's achievements as a whole, to establish confidence in Artec's offering. It worked: Among other things, my idea to organize an Estonian ICT Conference during the visit of Estonian PM Andrus Ansip in Turkey created a lot of extremely positive buzz that resulted in Estonia being mentioned as a trendy country in a prime time Turkish TV series. During this time, I've also made a lot of contacts among the Estonian and Turkish business communities and, more surprisingly, among the Estonian diplomacy who, much to my amazement, welcomed my ideas for better promoting Estonian interests abroad with great enthusiasm. Come December 2008, my time at Artec will become a page in my employment history. While the Thincan remains one of Artec's key products, current marketing and sales resources are focused on new markets and new technologies that completely fall outside my core expertise, which is why the company decided to let me go. I thus welcome offers from interested parties in Coreboot or LTSP markets. Other refreshing offers from outside the box - such as in business diplomacy - are equally welcome, as I've been pondering a career change for a long time.

The Open Source Repository and Observatory (OSOR), a new site sponsored by the European Commission to foster the exchange of FOSS related information and software among European public administrations, recently published guidelines on the procurement of open source software. Public administrations in Europe have to follow public tender procedures and the new guidelines give practical and legal advice on how open source software and related services can be incorporated into the procurement process. Rishab Ghosh, who presented the guidelines at the Open Source World Conference in Malaga, argued that the procurement guidelines were needed because of two reasons. First, they studied recent tenders and found that many explicitly mentioned proprietary applications. 16% of 3615 software tenders explicitly asked for products from top 10 software vendors, such as Microsoft, SAP and Oracle. This practice may be illegal because public tenders generally have to describe functional requirements in a general way instead of specifying specific products. Second, many public administrations don't have any experience with the procurement of FOSS. In fact, they often don't know whether or under which circumstances they are allowed to adopt and ask for FOSS solutions. The guidelines are specifically designed in order to clearly and simply explain how public administrations can acquire open source and they don't assume that a country has adopted a specific policy regarding open source. The guidelines include a long section about open standards, open source and how they relate. Both open standards and open source align very well with the needs of public administrations who have an "obligation to support interoperability, transparency and flexibility, as well as economical use of public funds". The guidelines argue that the exit cost, i.e. the cost incurred in moving to another IT system, is also an important consideration but one that is often neglected. The adoption of a proprietary solution without open standards may limit the future choice, thereby increasing the long-time costs and giving the proprietary vendor an unfair advantage in future tenders. The procurement guidelines describe two ways of acquiring FOSS: it is possible to go the usual route of publishing a tender for the supply of software (possibly with related services). However, in the case of FOSS, it is also possible to download the software directly from the Internet. This is possible because the software is not only free of charge but comes with no contractual obligations. If there were any obligations involved with the download (such as fees, the agreement to an EULA or the requirement to purchase services in the future), software download is not an allowed method. What I like about the guidelines is that they explicitly say that downloading software has to be part of the formal procurement process. You have to think about your requirements, look at various alternatives, and so on, and not just blindly download something from the Internet. When it comes to the procurement of FOSS, the guidelines don't suggest that tenders should explicitly ask for FOSS. Instead, they should describe the functional requirements of the software as well as certain properties. For example, a tender could specify that the public administration as well as third parties must have the right to study, distribute and modify the software. In a sense, the guidelines suggest that tenders should include the principles of the Free Software Definition along with justifications for these requirements. Personally, I think there is a great need for these procurement guidelines. There are many public administrations that don't know how to acquire FOSS and these guidelines offer clear advice. Furthermore, I find the guidelines very balanced. They don't recommend that you should always ask for FOSS but incorporate FOSS principles into tenders where it makes sense. It remains to be seen whether the procurement guidelines will have an impact on the FOSS adoption in Europe, but I surely hope so. (Originally published on FOSSBazaar)

Sound Juicer "Old Man Take A Look At My Life" 2.25.1 has been released. Tarballs are available on burtonini.com, or from the GNOME FTP servers. Everyone's favourite Frockney did a huge amount of work on this, and I'm still talking to him after he admitted that the master plan is to replace Sound Juicer with Rhythmbox in Fedora!

• Chain the metadata lookups (Bastien Nocera)
• Finish the libmusicbrainz3 metadata fetcher (BN)
• Add a GVFS metadata fetcher as fallback (BN)
• Make libcdio option, as it breaks the GPL+Exception license (BN)
• Export ASIN, Discogs, Wikipedia in the internal metadata (BN)
• Lots of other cleanups to the metadata code (BN)
• Remove copy of the id3mux plugin, assume it exists now (BN)
• Remove Encoding field from desktop file (Pacho Ramos)
• Add Audio to desktop categories (Patryk Zawadzki)
• Correctly parse CDDA URLs (Matthew Martin)
• Don't free the option context

From the “Software that recently rocked my pants” department:

• Bitlbee: talk to your Jabber/MSN/Yahoo contacs with your IRC client. I was aware of its existance, never found the time to start using it. Shame on me! I run it on my laptop rather than on a server.
• Matplotlib: plotting library for Python, and I find the results very pretty. Looks quite powerful, though I had slight problems figuring out how to do certain stuff.
• Schroot with LVM: brilliant, particularly if you make use of sessions.
• KVM with libvirt and virt-manager: seems to work well, almost as easy as VirtualBox, and (tada!) thanks to VNC you get detaching for your guests (no more Windows reboots if you restart your Xserver).

I also thank Martin F. Krafft for helpfully updating the encryption howto I followed for my previous laptop to mention that using a single encrypted device and LVM on top of it is (possibly) preferred nowadays. And to Simon McVittie for his idea of a small unencrypted Debian installation for recovery purposes in laptops without an optical drive. P.S.: I can’t believe this shit about blogging every day in November.

Michael blogs about Critical Mass.
What is Critical Mass in case you are too lazy to go to Michael's or to the Wikipedia? A cyclist-awareness movement, showing how bikers are safer (i.e. more visible) when there are more of them. The (dis)organizational nature of this movement (at least according to Wikipedia's information) seems quite fun and interesting.
However, I have to oppose what Michael says is a strong point of CM in Austria - At least, given my country's culture.
People who don't bike often say we have the least bike-aware culture, and that this city must be like hell to cyclists. It is not - Mexicans tend to believe this is the worst place possible on many accounts, and I'm happy to prove the contrary. I do feel that bringing people out to the streets, as our local government's Mu vete en bici program pushes, is completely right: It shows people how fast they can move in real streets in the city, taking away the fear of being run over by a bus, and people will gradually understand we can all excercise the right to use the streets without polluting, and gives us a better idea on how to behave with traffic (even if the traffic is made of fellow bikers) around us. I know this program works - At least, because it worked on me. Whenever possible, I go everywhere in this (not small or friendly by any measure) city by bike.
Anyway - What criticism do I have for Michael's post? That he states they:

Bicycling ludicrously slowly for a good hour, we managed to claim some fairly busy streets while many people tried to get home by car.

IMHO, what we should be doing is to demand the drivers to respect us, not to make them want to run us over. They should not be driven into hating bikers because of the chaos they generate - It is terrible to sit in a car for two hours when you usually take 30 minutes. There is simply no justification for that.
When I took part of the World Naked Bike Ride, some people wanted to take all four lanes of Reforma. Fortunately, reason prevailed, and we took only the lane we were assigned. And we should keep that in mind! Whenever possible, we should protest and make ourselves heard, but without interfering, without damaging, other people's lives!
Oh, by the way: If anybody in Mexico wants to have some nice hours of healthy fun: I am still pondering whether to join, as it is a huge effort, but I am very inclined to do so. Next week, November 9, we will go by bike from Mexico City's Z calo to Pachuca. We face 95Km and close to four hours. The road to Pachuca is basically flat, and going in a large group is a great experience. Hope to see you there!

Recently, people have picked up on OpenSSH s new feature : visual SSH fingerprints. It hurts to see this feature in a software like OpenSSH, which is so integral to everything we do, because it s a waste. It s additional code, and thus an additional risk of bugs, and it has a net security benefit of zero, NULL, zilch, nada, nothing, nix, nadje, oomph! The theory is that you learn to recognise the general shape of the visual fingerprints of your hosts, which is easier for us to remember than strings of hexadecimal numbers. So, for instance, if you ssh to pony.debian.net, you get to see something that s not entirely unlike a pony:

Host key fingerprint is 45:2f:a5:d8:13:95:ba:03:51:c4:8d:ac:82:a8:4c:6a
+--[ RSA 2048]----+
          ==+o.    
         .++=o     
    . .  .o*..     
  .. . . o..o      
 +.     .S. .      
 oE        o       
 .          .      
                   
                   
+-----------------+

Rejoice! Because now, should pony.debian.net ever present a new SSH fingerprint, when OpenSSH screams at you:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.

then you can look at the picture and say: yeah, I knew that , because your pony has suddenly transformed into the visual representation of a giant fart. On the other hand, the new feature makes day-to-day interactions a lot easier. Imagine you need to ssh into a new host. You take a piece of paper and call up the admin to ask for the fingerprint, but instead of a series of hexadecimal digits, he says it looks like the easter bunny and a bit like southern Italy . Great feature . Thanks. I would appreciate if this sort of crap stayed out of important software. Dan Kaminsky might have some good ideas, but most of the time he s on crack. Get a grip. Stop being a fanboy. NP: Kinski: Alpine Static