Tomorrow (Thu 29th) at 7.30pm is the Kewstoke annual village meeting. That should be my first meeting as a councillor, if I get back from London in time. (I hope I do - councillors who miss meetings get this sort of criticism but at least village councillors aren't paid that much: I think expenses for all 12 or so councillors totalled under 60 last year.) Apart from the two reports, the agenda is a good summary of the challenges affecting the village this year: Cygnet Liaison, Sand Bay Management and the Toll Road.

The first meeting of the new Bristol and Bath Perl M[ou]ngers is tonight (Tue 27th) at 7pm, according to this mailing list post. Despite their rules, I've already been well-flamed by one member, so it will be interesting to see what sort of group it becomes. Hopefully the flamers are nicer in real life.

Michelle’s post‡ today on laptops in the classroom (in a similar vein to this article I read last month on the suggestion of Glenn Reynolds) reminded me that I had a few items from the past few weeks still in my Google Reader queue of “things to blog about” related to Margaret Soltan’s continuing crusade against the use of PowerPoint* and its ilk, and specifically Timothy Burke’s partial rebuttal:

What’s the difference between bad usage of PowerPoint in lectures and bad lectures that involve hand-outs, overhead transparencies and writing on the chalkboard? Are we just complaining about old wine in new bottles here? Is the real culprit professorial droning at classrooms of 200+ students followed by recite-repeat-and-forget examinations? I think it’s at least plausible that the technology is just giving us a new reason to pay attention to a pedagogy whose effectiveness has been suspect for two generations.

I dare say I’m among the last doctoral students who was “trained”—and I use that word loosely—to teach prior to the widespread use of PowerPoint. Four years of full-time in-classroom experience, mostly with small lectures and seminars, has brought me basically to agreement with Burke on this point—complaints about PowerPoint essentially boil down to complaints about either instructional laziness or the whole nature of lecturing, or as a Burke commenter puts it, ”[e]xactly how does one teach even 80† students at once without succumbing to passive data transfer?” The non-use of PowerPoint or some other form of instructional technology seems to me to be a luxury confined to those who only teach small seminars and graduate students, and while my personal career aspirations lean in that direction the reality is that I’m several years away (in terms of research productivity) from being there—if I ever get there. Burke in his comments hits the nail on the head, I think, when it comes to any sort of visual presentation in class:

It seems to me that the absolutely key thing is to avoid speaking the slides literally. They’re best as definitions, key concepts, images: the kind of thing you’d stop your flow of lecturing to write on the chalkboard. They’re not the lecture itself.

I think there are three useful aspects to a lecture: what you put on the board (or slides), what you say, and the general outline. If you’re preparing a handout or something to stick on Blackboard for students, the outline or outline-plus-slides is what they need, along with space to fill in the gaps. An alternative approach is to make the slides/board material the outline; several of the more effective teachers I had (my high school history teacher and a political science professor at Rose-Hulman) took that approach. But you can’t shovel your script into PowerPoint and expect that to work well, any more than you’d expect that writing it up on the board, or for that matter reading a paper verbatim at a conference would be a good presentation, to work. All this discussion leaves aside the question of teaching anything that involves symbols (chemistry, mathematics, statistics) which I think requires a different approach than bullet-points. In class, mathematics and statistics (and, by extension, social science research methods courses) lend themselves to a combination of “passive” PowerPoint-style presentation and more spontaneous problem-solving and brainstorming; for example, one of my early activities is to have the class try to operationalize (define in terms of a measurable quantity or quality) a concept like “globalization,” which you can’t really do with a static slideshow even though you can define terms like “operationalization” that way. Similarly, while you can step through the process of solving a problem in a slideshow I think it’s more effective to demonstrate how to step through the process on the board. Unfortunately, many classrooms aren’t set up to allow you to present and use a board simultaneously; some of TAMIU‘s lecture halls have a nice design where the projection screen is above the board, so you can write on the board without having to do anything special with the slideshow, but rooms most places are designed for “either-or” which can be a real pain—fiddle with the control system to blank the screen, raise the screen, write on the board, then lower the screen, switch the screen back on. After a few iterations of that in a single class, you’ll never do it again. I freely admit I haven’t figured everything out yet; my current methods slides are pretty good lecture notes but pretty rotten for projection. One of my projects for this summer (postponed from last summer after I learned I wouldn’t be teaching any methods courses this year) is to work on my research methods lectures to incorporate advice from Andrew Gelman’s book so I can lay the groundwork for my plot to take over the world effort to produce a workable, but rigorous, methods curriculum at both the undergraduate and master’s levels for political science, sociology, and (at the grad level) public administration. More on this theme from Laura at 11D, who takes note of some of the more positive technological developments associated with academe. And, another of Burke’s commenters links this hilarious example of what not to do with your slides.

* I use “PowerPoint” as shorthand for the use of a computer-projector based slideshow-style sequential presentation of items associated with a lecture, a technique obviously made famous by the Microsoft software package but also available with many other software packages such as Apple’s Keynote, OpenOffice.org Impress, and several PDF viewers including Adobe Reader, xpdf, and GNOME‘s Evince.
† I’d put the cutoff significantly lower, at around 30–40 students. Beyond that point, one might as well just blow the cap off the class.
‡ By the way, it’s nice to see Michelle’s blog back from haïtus! (Where else would I keep up with current Mexican politics?)

As well as choosing a licence, various other non-code or pseudo-code tasks are needed in all upstream projects and I have been working on some of these in my upstream project, estron.

1. Documentation - Quietly converting the old docs (XML comments) into SGML (docbook content) for use with yelp. Comments have no particular structure so it takes time to add docbook structure to what was just a block of arbitrary text in comment tags.


2. MIME - Not sure if I've got this right still - I don't see the icon for .estron files and I get a warning when trying to double-click on an "Estron file" (the file type is recognised but gets confused with the XML inside). I'm following code samples from grisbi and drivel to try and get things together.


3. configuration support - estron will use dbconfig-common in Debian for the internal estron database but I need to set upstream to be able to read in the data created by dbconfig in a non-Debian-only manner, probably using GIO to provide configuration that can include a filename of external config data.


4. cross build support - a few quibbles in that area but I'll sort them before release. Can help catch architecture-specific problems in the code that would cause a FTBFS on the Debian buildd system.

Other tasks already covered:

• make distcheck - important upstream test that simplifies the process of packaging for Debian by ensuring that the distributed tarball really does contain the necessary files and in the right places.


• translation support - one little task left for that one, ensuring that applications written in estron support independent translation. Support is in place but not ready for a string freeze at this time.


• API documentation - doxygen.


• Wiki - ikiwiki


• Mailing list - alioth


• Access to source code - alioth/debian.


• Bug trackers - for upstream, alioth.

I have actually been doing some code too - in QOF due to a bug identified by testing and developing estron and in estron itself to bring 64bit time handling to estron and prevent time overflows in 2038 should you use estron on 32bit machines.

Last weekend I was at FOSSCamp. Since I live in Prague I wanted to go to Ubuntu Developer Summit (UDS) each day, but unfortunately I had some exams, so I only went on Wednesday and Friday.

On Wednesday I first met Lars Wirzenius:


we agreed to go to pub in the evening. Then I did a little work, there was quite a nice view from the window (Prague castle on the horizon):



and I went to the #ubuntu-devel-summit IRC channel and pinged Scott Kitterman, whom I new from the Debian Python Modules Team (DPMT), but didn't know how he looks like. We met and once I knew Scott, it was easy to get around, so he introduced me to Steve Langasek (pronounced Lang ek). We agreed to go to pub as well. Steve lives in Portland, OR, where I spent the summer 2005 and Scott is from Baltimore where I spent the summer 2006.
Then I also met Riku Voipio, Martin B hm, Christian Reis (whom I asked if it's possible to support Debian unstable on Ubuntu Personal Package Archives and he said that it will probably happen, so that's really cool -- I also offered my help with this) and others, so in the end, there were 14 of us going to the pub, so I chose again the same pub as with the FOSSCamp people and it seems it tasted good again:




Notice the sv kov na smetan above, my favourite meal. Good choice Scott. :)





Ok, that was on Wednesday. On Friday I arrived at around 3pm, looked at the schedule table and noticed that Matthias Klose should be at UDS too, so I started IRC and pinged him. Fortunately, Emilio Pozuelo Monfort, whom I know from DPMT as well, replied first so we met, it was cool and he showed where Matthias is. I am very glad I met him, so we discussed python-central and python-support packages and why we have them both, also with Scott later on.

When I was waiting for Matthias, I sat next to Nicolas Valc rcel, started my laptop and begun looking at some SymPy bugs and Nicolas noticed that and said -- "You are developing SymPy?", I said "Yes.", flattered. And he showed me a bug with plotting and Compiz, so we immediately reported that to pyglet.

In the evening people continued to some kind of a party, but unfortunately, I was already going to some other pub.

Overall, even though I was there for only two afternoons, it was just awesome and I utterly enjoyed meeting all the people I knew from mailinglists and IRC.

Yesterday, I wrote about bicycling to work, pointing out that it's a safe, inexpensive, way for many people (including office workers without access to showers) to get to work. There were a lot of thoughtful comments there too.

Today I'd like to provide some tips for getting started commuting on a bicycle. As I'm just getting started on this, these are mainly things I've learned from poking around online, so I'll be including lots of links.

The Bicycle

This varies from person to person, but as a general rule: if you have a very short ride -- say a mile or less -- you can probably just use any old bike and a bicycling helmet. Don't try to use a motorcycle helmet. It won't vent your head, so you could overheat. Also, it won't be comfortable.

Most people will have a longer ride and will want to get a bike that works specifically for them. Each model of bicycle comes in different frame sizes. It's important to get a bicycle that is the right size for you. Also, you'll want to get a quality bicycle that will let you be fast and won't break down along the way.

For all these reasons, I -- and every single other person I've ever seen talk about this -- highly recommend that you buy your bicycle from a bicycle shop. Don't buy a bicycle from a "big box" store like Walmart or Target. They may be cheaper up front, but you'll pay for it in the long run because they won't last as long, won't fit you as well, and may even be unsafe. Bike shop staff will help you find a bike that fits you, which is important for avoiding aches and pains and even injury. They'll be able to help you find appropriate accessories for your bike, as well as repair it. Here is a helpful article on this topic, written by a bike shop.

Generally speaking, bike shops can repair bikes bought at any other bike shops. However, they can instantly recognize bikes bought at big box stores. Many will repair those too, but some refuse to work on some of those bikes on the grounds that it is impossible to bring them to the level of service they expect their mechanics to do.

Aches and Pains

With any sport, when you start it, you can expect a little bit of aches and pains at first, as you start using muscles that you may not have really used at first. Bicycling is no exception, but it's easy to deal with.

Your first stop if you have aches and pains might be the where does it hurt page. It provides detailed, helpful advice. There are also some common things that go wrong for people.

First on the list is wrong size of bike or improper adjustment of your bike. You want a bike frame that is the right size for you, and you want the seat and handlebars adjusted properly for you. A bike shop can help you get this done easily. If your feet can reach the ground while you're on the seat, you almost certainly have the seat too low, which is a common mistake.

Sometimes the way you position yourself on the bike, or your technique, could be to blame.

Also, clothing can be a problem. A good place to start here is with some cycling shorts. Another common complaint from new cyclists appears to be blisters on the feet. This can be caused by improper positioning on the pedals, or by using the wrong type of sock. Typical socks absorb moisture and trap it next to the skin; bicycling socks will wick it away and let it evaporate. In fact, cycling clothes: socks, shorts, and jerseys (shirts) are all designed to wick moisture away from you and let it evaporate, which keeps you cooler and more comfortable. Bicycling gloves are cheap and can help your hands stay comfortable.

Expense

You can easily save thousands of dollars by riding a bicycle instead of driving a car. Bicycles do need periodic maintenance, just like a car. Usually you can do a lot of that yourself. It probably will pay off to take your bike in to the shop for an annual tuneup. If you have no bicycling equipment at all, and buy your equipment at a bike shop new, you can probably get started for around $500. Even that will probably pay for itself in less than a year if you average riding your bike at least a few times a week.

Safety

Safety on a bicycle can usually be summed up with three rules: be visible, be predictable, and ride with traffic.

Unless there are dedicated bicycle-only lanes or paths, the safest way (in the United States) to ride your bike is on the road, riding with traffic (acting like a car). Don't ride on a sidewalk, and never ride against traffic. This may sound counter-intuitive, but it is backed up by solid research. It all has to do with being predictable. Nobody is looking for something the speed of a bicycle to emerge from a sidewalk to cross a road or driveway. Sidewalks often aren't that visible and frequently don't provide enough room to pass. Sidewalk-riding cyclists get into accidents all the time with cars backing pulling out of driveways, making turns, or even just driving down a road where the cyclist cuts in front of them to cross a street.

A great book for learning how to ride in traffic can be viewed free online: the Bicycling Street Smarts book. There are also some safety videos online that are helpful.

Staying visible is certainly important. In some places, like cities where cyclists are common, drivers are going to be on the lookout for you already. In my case, I'm riding on rural roads that have some hills, where cyclists are rare, so I'm putting extra effort into this.

Staying visible in the day or at night starts with high-visibility clothing. A "screaming yellow" jersey or an ANSI safety reflective vest (less than $10) are good ways to do that. Several people recommend a Cateye TL-LD1100 flashing tail light for use at night, or even for daytime use when visibility is critical (such as my situation). If you will ever ride at night, laws require you to have the proper reflectors on your bike. And, you must also have a white headlight that does not cover up your front reflector (in some locations, you may also be required to have a red tail light that doesn't cover up your reflector). Companies like Cateye carry those products as well.

Other tips: avoid drainage covers; they sometimes have slats that a bicycle tire could fall into.

Accessories

Here are some suggestions you might consider as a commuter.

Start with pannier bags. They mount over your rear tire and are cooler for you than a backpack because your back can still breathe. They're more aerodynamic than a front basket. You can get bags suitable for carrying papers, laptops, a change of clothes, etc.

Next on your list might be a bicycle lock, to help keep it from being stolen. Your local bike shop can make suggestions here.

You might want to consider a spare inner tube (about $5) and tire-changing tools (also about $5) to carry with you in your bag. You wouldn't want to have to walk 5 miles if you get a flat.

Along with that goes an air pump. I suggest a frame pump -- it's a small pump that can clip on to your bicycle's frame, so you always have it handy. Obviously you will need this if you have to change a tube, but it could be handy even if you don't.

You can find some more suggestions from bicycling.about.com and from Mike or your local bike shop.

Where to buy

Besides your local bike shop, you can buy a lot of accessories online. I wouldn't suggest buying a bicycle online, because you really want to get a good fit at a bike shop.

When I asked at bikeforums.net, readers suggested three online stores:

www.pricepoint.com
www.bikenashbar.com
www.performancebike.com

You can also find some bicycling accessories at general-purpose stores like Amazon or sporting goods stores like REI. I personally wouldn't recommend local "big box" sporting goods stores any more than I would Walmart or Target for this stuff, though.

More info

For more information, check out my bicycling links at del.icio.us.

Just got back a little earlier from running the 2008 edition of the JP Morgan Chase Corporate Challenge. And again a record crowd of now just over 23000 in Chicago -- announced to be bigger than those at the JP Morgan Chase races in Boston, San Francisco or New York! This year the weather wasn't quite as stunning as it has often been in the past. But at least, temparatures in the high 40s and an overcast sky make for good running conditions. This time, two colleagues and I tried to make it close enough to the starting line to not waste too much time 'surfing' around slower runners who for whatever reason think they have to be up at the front. And that seems to have worked: despite a still crowded start, I ran even, steady and fast enough to beat the PR from 2005 by a decent margin with a (hand-stopped) time of 20 minutes and 46.65 seconds. That yields 5:5619 min/mile (or for Christian, 3:4132 min/km) which seems too fast given the splits I saw at miles two and three. Oh well -- same cours as as the other five times that I've run this, so I trust the course is USATF certified. And as always, good to hang with folks from work for a cold one or two afterwards. Given the temperatures, I didn't last very long though.

The first step is to copy /images/xen/vmlinuz and /images/xen/initrd.img from the Fedora (or RHEL or CentOS) DVD somewhere convenient, I use /boot/OS/ (where OS is the name of the image) but other locations will do. Now choose a suitable Ethernet MAC address for the interface (see my previous post on how I choose them [1]). Create a temporary block device for the install, I use /dev/VG0/OS-install (where OS is replaced by the name of the distribution, “f8” or “cent5“), it’s a logical volume in an LVM volume group named VG0. The device should be at least 2G in size for a basic Fedora install (512M for swap, 1G for files, and 512M free after the install). It is of course possible to use DOS partitions for the Xen block devices, but this would be unreasonably difficult to manage. An option for people who don’t like LVM would be to use files on an XFS filesystem (Ext3 performs poorly when creating and removing large files). When configuring Xen on Debian systems I generally use /dev/hda type device names. The device name seems quite arbitrary and /dev/hda is a familiar name for hard drives that many people have been used to for 15+ years. But the Fedora install process doesn’t like it and I’m forced to use /dev/xvda etc. I often install Fedora on a machine that only has 256M of RAM spare for the DomU. For recent versions of Fedora 256M of RAM is about the minimum for an install at the best of times, and a HTTP install takes even more because the root filesystem used for the install is copied via HTTP and stored in a RAM disk. It might be possible to use less RAM with a CD or DVD install or even a NFS install, but I couldn’t get CD/DVD installation working and I generally don’t give Xen DomU’s NFS access if I can avoid it. So I had to create a swap space (an attempt to do an install with 256M of RAM and no swap aborted when installing the kernel package). I expect that most serious use of Xen will have 256M of RAM or less for the DomU, part of the problem here is that Xen allocates RAM not virtual memory. VMWare allocates virtual memory so the total memory for virtual machines can be greater than physical RAM and thus this problem will be less common with VMWare. I believe that the best way of configuring virtual machine images is to have the virtual machine manager (Xen in this case) provide block devices to the virtual machine and have the virtual machine implement no partitioning (no LVM or anything equivalent). The main reason is that DOS partition tables and LVM configuration on a block device used by Xen can not be used easily in the host environment (the Dom0 for Xen). I am not aware of how to access DOS partition tables (although I’m sure it’s possible somehow) and while LVM can be used it’s a bad idea due to the fact that there is no way to deactivate a LVM volume group that is active, and the fact that there is no support for having multiple volume groups of the same name. The lack of support for multiple volume groups of the same name is a reasonable limitation, but an insurmountable problem when using a virtual machine environment. It’s quite reasonable to create several cloned instances of a virtual machine and renaming an LVM volume group would require more changes inside the virtual machine than you would want. Also using snap-shots of old versions of the virtual machine data is difficult if the same volume group name is used. So for ease of management I want to have filesystems on block devices (such as /dev/xvda) instead of partitions (such as /dev/xvda1). Unfortunately Anaconda (the Fedora installer) doesn’t support this. So I had to do the initial install with DOS partitions and then fix it afterwards. So use the manual option and create a primary partition for the root filesystem and then create a non-primary partition for swap (when using small amounts of RAM such as 256M) so that swap can be used during the install. The root filesystem needs to be at the start of the disk to make it easier to sort this out later. After installing Fedora and shutting the virtual machine down the next step is to copy the block device to the desired configuration (filesystem on an unpartitioned device). If the root filesystem is the first partition then the first 63 sectors will be the partition table and reserved space so dd can be used to copy the data with the following commands: dd if=/dev/VG0/OS-install of=/dev/VG0/OS bs=512 skip=63
e2fsck -f /dev/VG0/OS
resize2fs /dev/VG0/OS The next step is to mount the device /dev/VG0/OS in the Dom0 to change /etc/fstab, I use /dev/xvda for the root device and /dev/xvdb for swap. Now to remove the cruft:
Avahi is a network service discovery system, mainly used for laptops and isn’t needed on a server, it is installed by default on all recent Fedora, RHEL and CentOS releases but it is not useful in a DomU (any unused network service is a security risk if you don’t disable or remove it). Smartmontools is for detecting impending failure of a hard drive and does not do any good when using a virtual block device (you run it on the Dom0). It might be considered a bug that smartd doesn’t exit on startup when it sees a device such as /dev/xvda. The pcsc-lite package for managing smart cards is of no use to me and all the other people who don’t own readers for smart-cards, and it can therefore be removed. Bluetooth networking support (in the package bluez-utils) is also only usable in a Dom0 (AFAIK), and the only bluetooth device I own is my mobile phone so I can’t use it on my computer. The command “yum remove avahi smartmontools pcsc-lite bluez-utils” removes them. For almost all of my DomU’s I don’t use NFS or do any printing, so I remove the packages related to them. Also autofs is in most cases only useful for servers when mounting NFS filesystems. I remove them with the command “yum remove nfs-utils portmap cups autofs“. The GPM daemon (which supports cut/paste operations with a mouse on virtual consoles) is of no use on a Xen DomU, unfortunately the vim-enhanced package depends on it. I could just disable the daemon, but as I like to run small images I remove it with “yum remove gpm“. I may have to reinstall it on some images as some of my clients like the extra VIM functionality. It’s unfortunate that debootstrap doesn’t work on CentOS (and presumably Fedora) so installing a Debian DomU on a CentOS/Fedora Dom0 requires creating an image on a Debian machine or downloading an image from www.jailtime.org . Sample Xen Config for the install: kernel = “/boot/OS/vmlinuz”
ramdisk = “/boot/OS/initrd.img”
memory = 256
name = “OS”
vif = [ 'mac=00:16:3e:66:66:68, bridge=xenbr0' ]
disk = [ 'phy:/dev/VG0/OS-install,xvda,w' ]
extra=”askmethod text” Sample Xen Config for operation: kernel = “/boot/cent5/vmlinuz-2.6.18-53.el5xen”
ramdisk = “/boot/cent5/initrd-2.6.18-53.el5xen.img”
memory = 256
name = “cent5″
vif = [ 'mac=00:16:3e:66:66:68, bridge=xenbr0' ]
disk = [ 'phy:/dev/VG0/cent5,xvda,w', 'phy:/dev/VG0/cent5-swap,xvdb,w' ]
root = “/dev/xvda ro”

• [1] http://etbe.coker.com.au/2007/03/27/xen-and-eth-device-renaming/

Share This

It sometimes funny to review web server stats to see what people are looking for in my blog. I usually expect something like my name and projects I participate on. But there are some surprises:

1. cihar
2. gammu
3. dosbox games
4. pissing
5. mpd sonata
6. wammu
7. phpmyadmin
8. project names
9. sound juicer mp3
10. phpmyadmin themes

For most of them I'm in first page in Google results, even though I have no idea why are my posts ranked so high even for such generic things as "product names", but I don't care. What surprises me most is "pissing". I guess I know what are people looking for when they enter this word to Google ;-). But according to Google webmaster tools, I'm somewhere near 110th position. Why the hell does somebody look so deep in results? And why does he go to one line blog post? I really don't understand this. Maybe I should focus on this word and bring my post to first page of Google results ;-).

I just wrote about the system administration issues related to the recent Debian SSL/SSH security flaw [1]. The next thing we need to consider is how we can change things to reduce the incidence of such problems. The problem we just had was due to the most important part of the entropy supply for the random number generator not being used due to a mistake in commenting out some code. The only entropy that was used was the PID number of the process which uses the SSL library code which gives us 15 bits of entropy. It seems to me that if we had zero bits of entropy the problem would have been discovered a lot sooner (almost certainly before the code was released in a stable version). Therefore it seems that using a second-rate source of entropy (which was never required) masked the problem that the primary source of entropy was not working. Would it make sense to have a practice of not using such second-rate sources of entropy to reduce the risk of such problems being undetected for any length of time? Is this a general issue or just a corner case? Joss makes some suggestions for process improvements [2]. He suggests that having a single .diff.gz file (the traditional method for maintaining Debian packages) that directly contains all patches can obscure some patches. The other extreme is when you have a patch management system with several dozen small patches and the reader has to try and discover what each of them does. For an example of this see the 43 patches which are included in the Debian PAM package for Etch, also note that the PAM system is comprised of many separate shared objects (modules), this means that the patching system lends itself to having one patch per module and thus 43 patches for PAM isn’t as difficult to manage as 43 patches for a complex package which is not comprised of multiple separate components might be. That said I think that there is some potential for separating out patches. Having a distinction between different types of patches might help. For example we could have a patch for Makefiles etc (including autoconf etc), a patch for adding features, and a patch for fixing bugs. Then people reviewing the source for potential bugs could pay a lot of attention to bug fixes, a moderate amount of attention to new features, and casually skim the Makefile stuff. The problem began with this mailing list discussion [3]. Kurt’s first message starts with “When debbuging applications” and ends with “What do you people think about removing those 2 lines of code?“. The reply he received from Ulf (a member of the OpenSSL development team) is “If it helps with debugging, I’m in favor of removing them“. It seems to me that there might have been a miscommunication there, Ulf may have believed that the discussion only concerned a debugging built and not a build that would eventually end up on millions of machines. It seems possible that the reaction would have been different if Kurt had mentioned that he wanted to have a single source tree for both debugging and for regular use. It also seems likely that his proposed change may have received more inspection if he had clearly stated that he was doing to include it in Debian where it would be used by millions of people. When I am doing Debian development I generally don’t mention all the time “this code will be used by millions of people so it’s important that we get it right“, although I do sometimes make such statements if I feel that my questions are not getting the amount of consideration from upstream that a binary package destined for use by millions of people deserves. Maybe it would be a good practice to clarify such things in the case of important packages. For a package that is relevant to the security of the entire distribution (and possibly to other machines around the net - as demonstrated in this case) it doesn’t seem unreasonable to include a post-script mentioning the scope of the code use (it could be done with an alternate SIG if using a MUA that allows selecting from multiple SIGs in a convenient manner). In the response from the OpenSSL upstream [4] it is claimed that the mailing list used was not the correct one. Branden points out that the openssl-team mailing list address seems not to be documented anywhere [5]. One thing to be learned from this is that distribution developers need to be proactive in making contact with upstream developers. You might think that building packages for a major distribution and asking questions about it on the mailing list would result in someone from the team noticing and mentioning any other things that you might need to do. But maybe it would make sense to send private mail to one of the core developers, introduce yourself, and ask for advice on the best way to manage communication to avoid this type of confusion. I think that it is ideal for distribution developers to have the phone numbers of some of the upstream developers. If the upstream work is sponsored by the employer of one of the upstream developers then it seems reasonable to ask for their office phone number. Sometimes it’s easier to sort things out by phone than by email. Gunnar Wolf describes how the way this bug was discovered and handled shows that the Debian processes work [6]. A similar bug in proprietary software would probably not be discovered nearly as quickly and would almost certainly not be fixed in such a responsible manner. Update: According to the OpenSSL project about page [7], Ulf is actually not a “core” member, just a team member. I had used the term “core” in a slang manner based on the fact that Ulf has an official @openssl.org email address.

• [1] http://etbe.coker.com.au/2008/05/18/debian-ssh-problems/


• [2] http://np237.livejournal.com/17981.html


• [3] http://marc.info/?t=114651088900003&r=1&w=2


• [4] http://www.links.org/?p=328


• [5] http://advogato.org/person/branden/diary/5.html


• [6] http://gwolf.org/node/1743


• [7] http://www.openssl.org/about/

Share This

Since development kernels 2.6.26-rc*, the iwlwifi drivers (iwl3945, iwl4965) have LED support. While LED support is nice to have (making it easy to see when the wireless connection is available), the blinking of the LED whenever there is data transmitted is annoying.In most networks, there is a constant chatter on the net. Windows server browsing and announcing, Zeroconf/Bonjour announcements, Printer discovery. When you're using some instant messaging or chat such as IRC there is some data transmitted all the time. Your email program might be polling for new emails, and your weather applet might be fecthing the latest forecasts. So basically, there always is ome network traffic. Often in the range of less than 1k/s, but there is.The new iwlwifi drivers don't flicker the LED with each packet received, but apparently will just set the LED to a blink mode when they received or transmitted some data, which if find rather irritating.Fortunately, this can easily be configured in Linux, just save this script in /etc/network/if-up.d/iwl-no-blink and make it executable:

#!/bin/sh
if [ "$IFACE" = "wlan0" ]; then
	for dir in /sys/class/leds/iwl-phy*X; do
		echo none > $dir/trigger
	done
fi

This is a quick hack, but it does the job well for me - when the device is connected it will stop blinking on data. It will still blink when connecting (leds:iwl-phy*:assoc) and indicate if the connection is available (leds:iwl-phy*:radio).

TED has a post about the design of the new OLPC [1]. I never liked the previous OLPCs [2], for my use a machine needs a better keyboard than the tiny rubber thing that they had. I understand why they designed it that way, for use in places where it would be an expensive asset it is necessary to make it resistant to water and dust to the greatest possible degree. But in a first-world country where a computer is a cheap item, having a better interface makes sense. I’m sure that I could have plugged a USB keyboard into a OLPC, but having a keyboard integrated as well as an external keyboard is just kludgy. The new design of the OLPC with two panels (at least one of which is a touch-screen - I hope that both are) is very innovative. With the keyboard displayed on a touch screen there are much greater possibilities for changing alphabet (teaching children to write in multiple languages is a good thing). Of course a touch-screen keyboard won’t allow proper touch typing, but it should still be possible to plug in a USB keyboard - with the additional benefit that it could use both panels to display data when an external keyboard is used. One of the new uses of an OLPC machine is to play two player games with the players sitting opposite each other. The next logical extension to this idea is to have a multi-user OLPC machine so that two people can use it at the same time (a machine that can run copy of a program that compares to the GIMP can surely run two programs to display electronic books or read email). A large part of the design of the OLPC is based around the needs for children in the developing world, in such cases one computer per home is likely to be common so it would be good if two children could do homework at the same time (or if a parent could check email while a child studies). Finally the new design is much better suited to reading documents, while they show a picture of a book being read in two panes (similar to the way that paper books are read) I think that a more common use will be to display book text in one pane while using the other pane for writing notes. That would mean that instead of having a full-sized (by OLPC standards) keyboard on the touch-screen they would have to use a small keyboard (maybe with a stylus) or an external keyboard. It is awkward and distracting to hold open a paper book with one hand while writing notes with the other, using one half of an OLPC to write notes while the other half displays an electronic book would be a significant advantage. The potential utility of the new OLPC design for reading documents is significant enough to make me want to own one, and I expect that other people who have similar interests to me will have similar desires when they see the pictures. While the OLPC isn’t really designed for the use of people like me, it’s unnatural for me to use a computer without programming it - so I expect that the new hardware developments will encourage new developers to join the OLPC project.

• [1] http://blog.ted.com/2008/05/xo_laptop_redes.php


• [2] http://laptop.org/

Share This

Been rather busy, so I haven't had a chance to continue recording the trip... We got into Zurich (albeit late), without incident. Immigration was the biggest joke ever. There was no paperwork at all, and we just handed our passports to the guy, who just looked at them casually, and waved us through. No stamp, no scan, no nothing. It was a bit disappointing really. We got our rental car, and drove around aimlessly for a bit, until the GPS got lock, and then headed for Prague. We went through Austria, where the guy at the border did give our passports a more thorough inspection, more because we were confused and were waving them at him. He also gave us a stamp. The woman from Hertz told us we needed to buy some sort of highway sticker for the car to drive in Austria (wow it's hard to type "Austria", "Australia" just keeps coming out from muscle memory), so we bought one of them and stuck it on the windscreen, and then promptly entered Germany. The autobahns in Germany are wicked! Everyone's screaming along at a ridiculous pace. The fastest I got up to was 180 km/h. The roads themselves were surprisingly quiet, and only two lanes. We stopped off for dinner somewhere in Germany, and finally arrived at the hotel in Prague at about 1am on Sunday morning, so it took about 7 hours instead of the 6 that we'd estimated. We got to bed by about 2am. I woke up at about 10am, then went back to sleep until about 2pm. We finally ventured out for a bit of exploration at about 3pm on Sunday. One observation about Czechs: they seem like a pretty dour bunch. Here we were wandering around, being all wide-eyed and touristy, smiling at everyone, and they'd just scowl back at you, no matter how hard we tried to get a smile out of them. After that initial wander, we discovered that there was a Metro station right across the road from the hotel in another direction, so we caught that to go and check out Prague Castle. The Metro system is another one of those great subway systems that I love. It ran regularly, so you didn't need to concern yourself with a timetable. The ticketing was a bit bizarre. It seemed totally honor-system based. There were no barriers to stop you getting in or out. It was fairly late by the time we got to Prague Castle, so we just wandered around the grounds, took a look inside Saint Vitus's Cathedral, and caught an orchestral performance in Saint George's Basilica, then headed back to the hotel. Everything at Prague Castle was pretty mind-blowing. The size of grounds. The view. Saint Vitus's Cathedral. The Cathedral was huge. When you stepped inside and looked up... words can't describe it. It was amazing. Unfortunately, we didn't bring a camera with us, so we don't have any photos from the Sunday excursion, but Sarah went back this afternoon, and her photos are here. I think the thing that struck me the most was that here were some seriously old buildings - older than my home country, and they were in amazingly good condition. They really built things to last back in the day. The weather so far has been pretty miserable, and if the forecast is anything to go by, will remain miserable until we drive out on Saturday. We've survived, language-wise. The default language of the hotel staff seems to be English, and most random people we've had to interact with seem to speak English. I feel really arrogant and rude just speaking in English to people without first asking if they speak English, but I'm also getting really sick of starting every conversation with "Do you speak English?" The printed language is by and large indecipherable. The currency, which in English is called a "crown" is crazy. One US dollar buys about 16 Czech Koruny, and the prices are ridiculous. A glass of wine at the hotel is maybe 250 CZK. Granted, the hotel prices are obscene, but seeing triple-digit prices for a glass of wine seems totally bizarre. The prices in general seem pretty steep. Sarah said she got a 2 koruny coin in change today. We've got no idea what you'd actually use that for. Last night, after the conference had finished for the day, we wandered off in a different direction again, and wandered through the grounds of Vy ehrad Castle. The Cathedral of Saint Paul and Peter has an amazing graveyard in it, including the grave of the composer Dvorak. We grabbed some dinner at a nearby restaurant, which was substantially cheaper than the hotel restaurants. Again, we forgot to take a camera with us.

The recent OpenSSL incident can not be hidden. It was a very important blow to the Debian project's public face and reputation. A major hole slipped under the door in the form of a bugfix - and with all the good intention. This was not a deliberate attack, nor was it the result of a bad or sloppy maintainer - It was a honest, although painful, human mistake.
Several people started laughing at our processes and supposed strengths right away. I do, however, feel this shows how Debian is stronger security-wise than any other system. And it also shows how this saying, with enough eyeballs, all bugs are shallow, not only didn't lose validity, but was reaffirmed. Free Software development was also proved to be better than security through obscurity again.
Why?
Because were it not because of OpenSSL (and in this case in particular, Debian's packaging) being Free and subject to a code audit, this problem would have never been found. I have been asking to some friends who are part of different black-hat groups, and looking for this kind of information on the Web, it seems that -were it not for Luciano's work, we would still be running cryptographically weakened versions of OpenSSL for a long time. After all, 32768 possible keys is still quite a lot for a black-hat group to find as uneven noise, as a lead to showing the undeniable weakness.
It took two years to find the bug, yes. But it was found doing quality assurance work on publicly available source code. It was promptly fixed, mitigating (as far as possible) as much damage as could be caused. Tools for finding and fixing the defective keys were crafted and freed together with the announcement. Yes, there will be some compromises due to this, I'm sure, but an embarassing hole has been dealt with in the best way possible.
Anyway... I am very happy - I was going over Luciano's NM report, and found something I only suspected but was not sure about. I can now state clearly: I have never been so happy to advocate somebody to become a DD.
Luciano wrote a very good blog post (in Spanish) with his viewpoints on the Debian OpenSSL incident. If you happen to understand Spanish and are reading this blog, please drop over Luciano's.
Luciano: Once again, my hat goes off for you :-)