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.

I'll visit Barcelona with Elizabeth for four days. No laptop, no beersigning, no electronic stuff. Only sightseeing and enjoying time together without any geek or work thinking. That was desperately needed..:-) Back on Monday...

So, the last day of my class on hacking, we are going to spend some time on geeky comics and talking about this pictorial genre. I have started collecting a set of examples that I think are particularly strong and funny reflections of geek/hacker life but I am looking for more. So what are some of your all-time favorite episodes/examples from a comic strip? I am looking for stuff that someone who is not necessarily technically oriented will understand but who will be armed with a fairly broad sense of this world too. Any suggestions would be really appreciated.

So, the last day of my class on hacking, we are going to spend some time on geeky comics and talking about this pictorial genre. I have started collecting a set of examples that I think are particularly strong and funny reflections of geek/hacker life but I am looking for more. So what are some of your all-time favorite episodes/examples from a comic strip? I am looking for stuff that someone who is not necessarily technically oriented will understand but who will be armed with a fairly broad sense of this world too. Any suggestions would be really appreciated.

Someone recently asked me whether it was difficult to fill up my syllabus for my hacker course. I wish. The hard part is actually deciding what to put on as there is too much. This is what I have so far but it will likely change over the summer. I have read a lot of the material but what I most excited about is teaching/reading Richard Sennet’s new book on Craft, which was recently reviewed in depth and in relationship to open source (which Sennet does discuss briefly) by Siva Vaidyanathan in the Chronicle of Higher Education (an article that I co-authored also got some props in the review, which is always nice). The question of what type of activity programming is a complex and deeply interesting one. Its craft-like roots, in part, have to do with the UNIX tradition, something written about humorously by Neal Stephenson and more seriously by other folks like Peter Salus and Chris Kelty in his wonderful rich chapter on UNIX. But craft is not enough to understand coding either. The aesthetics of coding also is a literary affair and the two pieces that capture the aesthetics of code in this light are the following two, also on my syllabus: Black, Maurice
2002 At the Edge of Language: The Art of Code. (a PhD Dissertation from the Department of English at UPenn) Chopra, Samir and Scott Dexter
2007 Free Software and the Aesthetics of Code. In Decoding Liberation. I am excited to review this material, as I need to work through my own chapter on software coding, which is less about the aesthetics of code and more about the tension between collaboration and individualism in production (which obviously maps onto questions of craft and aesthetics but is not quite the same thing).

Someone recently asked me whether it was difficult to fill up my syllabus for my hacker course. I wish. The hard part is actually deciding what to put on as there is too much. This is what I have so far but it will likely change over the summer. I have read a lot of the material but what I most excited about is teaching/reading Richard Sennet’s new book on Craft, which was recently reviewed in depth and in relationship to open source (which Sennet does discuss briefly) by Siva Vaidyanathan in the Chronicle of Higher Education (an article that I co-authored also got some props in the review, which is always nice). The question of what type of activity programming is a complex and deeply interesting one. Its craft-like roots, in part, have to do with the UNIX tradition, something written about humorously by Neal Stephenson and more seriously by other folks like Peter Salus and Chris Kelty in his wonderful rich chapter on UNIX. But craft is not enough to understand coding either. The aesthetics of coding also is a literary affair and the two pieces that capture the aesthetics of code in this light are the following two, also on my syllabus: Black, Maurice
2002 At the Edge of Language: The Art of Code. (a PhD Dissertation from the Department of English at UPenn) Chopra, Samir and Scott Dexter
2007 Free Software and the Aesthetics of Code. In Decoding Liberation. I am excited to review this material, as I need to work through my own chapter on software coding, which is less about the aesthetics of code and more about the tension between collaboration and individualism in production (which obviously maps onto questions of craft and aesthetics but is not quite the same thing).

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

The CIO and the Office For Technology of New York State (USA) just released a new report on electronic records strategy, titled A Strategy for Openness: Enhancing E-Records Access in New York State. I submitted my own comments during the call for public comments earlier this year -- apparently there were only 114 comments submitted by the public (you can see the call for comments and an overview/analysis of the responses). I wish there'd been more, since it looks like the 59 individual commenters were overwhelmingly supportive of a requirement for the Gov't to use ODF. The rest of the comments were from governments, NGOs, and businesses, and they don't seem as unanimous as the individual commenters. Looking at the metadata for the executive summary shows just how far we have to go:

[0 dkg@squeak doc]$ pdfinfo PartIerecordsStudy.pdf    egrep '^Title Producer Creator'
Title:          Microsoft Word - PartIerecordsStudy.doc
Creator:        PScript5.dll Version 5.2.2
Producer:       Acrobat Distiller 8.1.0 (Windows)
[0 dkg@squeak doc]$ 

And in a message sent to commenters announcing the report, they seem to be aware that they're not quite doing their best at interoperability:

(Please note this is the first time any of NYS government's agencies has ever published a document in ODF format. We ran into problems this morning not caused by the format, but rather with some controls on our systems which were not prepared to encounter such documents. So the website links to ODF versions are not working at the moment, but will be repaired soon).

What web server are they running that is having trouble "encountering" ODF? No surprise:

[0 dkg@squeak doc]$ wget -S -O/dev/null 'http://www.oft.state.ny.us/policy/esra/erecords-study.htm' 2>&1   grep Server
  Server: Microsoft-IIS/6.0
[0 dkg@squeak doc]$ 

Sigh. My initial reaction to the report (i've only read the executive summary, not the supporting documentation) is disappointment. While they claim that "openness" is an important feature, they fall far short of taking a strong stand for free and open formats. The main thrust of the executive summary seems to be (paraphrasing here, i welcome corrections):

• it's a bad idea to mandate a single particular technology because technologies will change faster than law.
• we need an Electronic Records Committee (ERC) to provide regular, executive guidance on electronic record storage and maintenance
• "openness" is good, but needs to be weighed against (ill-specified, at least in the executive summary) "other features"
• we're not going to make any concrete recommendations about what to do next

While these are unsurprising conclusions, they don't take the strong stand i'd like them to take. They seem aware of the "chicken and egg" problem of wide adoption and vendor support, and aware of the anti-democratic effects of proprietary formats. But they don't seem to be willing to act as a catalyst to push free formats explicitly. If they did, they could break the chicken/egg vendor lock-in cycle and facilitate better open government practices while simultaneously encouraging a healthy information ecosystem. At this point, i suppose my biggest hope from the process is that the proposed ERC forms pilot groups with long-term goals modeled after Munich, but i'm not holding my breath. If there are any advocates or participants in the Munich process who want to share what's been working for you (and what hasn't), i'd be interested in hearing about it.Tags: government, odf, policy

Recently I have mostly been "behind". I've caught up a little on what I wanted to do though over the past couple of days, so I won't feel too bad. I've:

made a new release of the chronicle blog compiler, after recieving more great feedback from MJ Ray. un-stalled the Planet Debian. updated the weblogs hosted by Debian Administration, after help and suggestions from Daniel Kahn Gillmor. stripped, cleaned, and tested a new steam engine. Nearly dying in the process. discovered a beautiful XSS attack against a popular social networking site, then exploited that en masse to collect hundreds of username/password pairs - all because the site admins said "Prove it" when I reported the hole. Decisions decisions .. what to do with the list... released a couple of woefully late DSAs. started learning British Sign Language.

Anyway I've been bad and not writing much recently on the Debian Administration site, partly because I'm just sick of the trolling comments that have been building up, and partly due to general lack of time. I know I should ignore them, and I guess by mentioning them here I've kinda already lost, but I find it hard to care when random folk are being snipy. Still I've remembed that some people are just great to hear from. I know if I see mail from XX they will offer an incisive, valid, criticism or a fully tested and working patch. Sometimes both at the same time. In conclusion I need my pending holiday in the worst way; and I must find time to write another letter... ObQuote: Dungeons & Dragons

When recording changes in some software there are basically three approaches, with their different advantages and disadvantages.

• One approach is just record modifications chronologically. Each modification is just a little diff (or some glorified variant of diff, or if you insist something that is no diff but just has some similarity). Advantages are:
  • It keeps itself out of the way. You just do modifications and store them somehow one after the other.
  • You can reconstruct all past points, so can regain missing documentation by looking at the evolution in time.
  So it is no surprise that essential every tool (i.e. all the VCSes) to handle non-packaging work on software essentially uses this way. If you have an canonical other source for the software (like an upstream for an package), it has quite some severe drawbacks:
  • Reviewablity does not scale. While every single diff can easily be reviewed, the mass is not. Most changes are relative to past versions of the software. If something introduces a problem or and upstream change introduces a problem with that, the fix might only show up years later, separated by tons of other changes in between. (The effect especially with changing upstream always depends a bit on the later merging, but the worst case is still the same).
  • For the same reason changes cannot be easily extracted. Single commits usually are fine, but what of those past changes is needed to make some specific change in the functionality is easily lost after some time, some improvements and updates to new upstream versions. The whole approach degenerates to having a single large .diff.gz file of the package. (Except one has a bit of history recorded, so when sorting out the stuff in that diff one can better guess what effect a single unattributable line has).
• The next possibility is to store modifications sorted by topic and against upstream (either as .diff files relative to the upstream source, as topic branches, or or or). Advantages:
  • As you have to send the patch upstream anyway, you have to create such an patch initially, anyway. Also each is in a format that if upstreams wants to apply a single one, each is in the correct format for this.
  • Branches relative to a (relatively) fix point are usually use to store in VCSes.
  • When other people want to pick a subset of those patches, they only have to do the merging, and not dismerging with the missing ones first.
  On the other hand, there are some disadvantages with this:
  • As the differences are relative to the upstream code, multiple patches are in general not applicable without additional merging.
  • Because of this, those patches cannot be used to generate the source to build the Debian package.
  • Thus those patches by itself are never directly used, unless the maintainer regularly tests them, they are essentially untested and will see bitrot.
  • As those are not the changes to the package because of the missing merge, they are nice for a cursory review, but if you want the review the actual changes, you need to review the merged variants.
• Last but not least, there are stacked patches, i.e. patches that are supposed to be applied in a specific sequence. Advantages:
  • The patches itself are actually used. Thus they get wide testing and bitrot cannot happen that easily.
  • Equally, reviewing the actual changes can be separated into the different patches, as connected changes are next to each other and the files describe the changes without pitfalls in merges.
  • If someone else wants to use multiple patches from the start of the sequence, no merging is necessary. They can directly be applied.
  Given these advantages, it is no big surprise that all Debian specific patch management tools (like dbs) and other programs to deal deal with multiple patches against other people's code (like quilt) use this approach. Though there are also some disadvantages:
  • Ordering patches is not important. Only unrelated patches can be skipped to have later patches applied cleanly, so ordering needs to predict what patches are more likely to be used by other people.
  • Testing only happens for the whole stack. If some match modifies parts that a later patch removes, bitrot can still happen.
  • Extracting those patches from the currently available VCSes is not trivial.

So the format most suitable to Debian packages (stacked patches) is the total opposite of a format most suitable when you are upstream yourself and nothing is suitable for everything. There are many different thinkable ways to combine the different things to get more of the advantages, though many are a bit lacking (like storing quilt series in a VCS as text files), not yet possible or non-trivial with the current tools. Hopefully the future will improve that.

Quick newsworthy item related to coreboot, which I wanted to mention a lot earlier, but then forgot about it: Silicon Mechanics is shipping their Rackform nServ A236 with coreboot pre-installed if so desired by the customer. From the coreboot News page:

Chris Watson at Silicon Mechanics says: "We will commit to offering coreboot preinstallation on the Rackform nServ A236 with a specific set of hardware and software. In the future, we may expand the program to additional platforms based on customer interest." The A236 is a nice 1U server with 4 drive bays and a dual Opteron board (Supermicro H8DMR), which is supported in coreboot v2.

Nice to see more and more vendors shipping their products with coreboot pre-installed...

We just came back from my three-month visit with the surgeon. Everything is pretty much going well: The x-rays looks good - the hardware hasn't shifted, screws haven't come loose (They need a CT scan to tell how well the bone fusion is happening. Too much hardware in the way in the meantime). The biggest concern he has is that because I spent 2 weeks throwing up and lost something like 15kg, most of my movement restrictions haven't changed, nor has the diet emphasis. So still no lifting, twisting or bending. I can, however, now reach out with both hands. So I can help chop veggies for dinner and such.

I also got some clarification on the photo.
(Warning, 1.7megs. (c) 2008 Dr. P Mummaneni, All Rights Reserved, posted with permission. Lots of blood and meat, you've been warned!)

It's the same one as before, but now I've actually gotten a chance to ask questions about it. I was pleased to know that most of my guesses had been right. =) I'll try to answer the questions people had:

I'm face down in the picture, my head is to the left. The yellow around the incision really is my skin, covered with iodine and such to minimize infection. The black bits are cauterised to minimize blood loss and such. The thick white cord down the middle is the spinal cord itself. The white covering is the dura.

To do this operation, they take away the bone on top, then take out the surrounding tissue, then take out the bone on the bottom. As someone guessed in the comments, the spinal cord sits in front of the titanium cage.

The medal bits on the bottom of the picture are the places where the second rod got bolted in.

Neat the leftmost metal thing, you can see a nerve coming out of the cord. In the middle of the picture there isn't any, which is why I have some sensation loss through my armpits and such.

Dr. Mummaneni said that he'll try to put the rest of the pictures onto a CD for me, so I'll probably get them at my next appointment in 3 months. In the meantime, I'm cleared to fly, and I'm cleared to return to work at the beginning of next month. Yay!

Oh, and it turns out that I might set off modern metal detectors. So I now have a doctor's note to travel with. I'll find out later this week. =)

In other news, Leif is doing much better. So far it looks like the inhaler was needed just to him over this cold. I'll post more on that another time. This post is getting long.

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

I'd not long written about lunching at the other end of Kewstoke Toll Road yesterday when I read this news of another Toll Road crash. I hope the three people carried from the wreckage recover. I fear the press will have another field day about how dangerous the road is, instead of primarily blaming whatever caused the accident. (The fishmonger crashed while avoiding a loose dog, by the way.) That road is not up to modern standards and I don't believe it was designed for the volume of traffic that's been using it since they stopped collecting the toll, but there is a very low speed limit (25mph) and warning signs all over it. Neither car left the road this time, as far as I can tell from the reports. I hope the press proves me wrong.

A brilliant commentary on how the mindless war in Iraq has been effecting the lives of people in the USA, In the Valley of Elah says a lot without speaking much. By the end of the movie, a father -- the same who tells his disturbed soldier-son over the phone: "it is your nerves speaking" -- hangs the US flag upside down.

A full week of high fever kept me down and even the "low hanging fruit" of life went undone. Then, another few days of blood-red eyes, thanks to some stiff antibiotics that I was on. The cause for this recurring fever seems to be an infection of the throat and tonsils, so it looks like I might have to consider getting my tonsils removed. To some extent, In the Valley of Elah shook me out of my moroseness. H says that Charlize Theron is a very cerebral actress and I must agree.

On a related note, I was pointed to this neat article titled Why Do They Hate Us? in which Mohsin Hamid says that the question that US-o-American's should be asking is Why do they love 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 :-)

I've seen a lot of people talk about simply reinstalling Ubuntu with the latest CD in order to update it to the latest version. I think that's a bad habit from other OS's. For as long as I've used Debian and its derivatives, the ability to update the system has been one of its strong points. Here are some reasons to run the updates instead of upgrading via a fresh install:

• You don't lose your old configuration information, and by choosing to see the diff's in configuration files, you can even choose which config files to update, and how.
• No need to shut down a running system.
• By keeping an eye on obsolete packages, you really don't build up any cruft at all, so that's not a reason to do a fresh install.
• With a decent internet connection, it's probably just as fast, if not faster, when you consider it takes a bit of time to get everything installed just the way you want it.

Indeed, yesterday, I upgraded a server I run in Texas from Ubuntu's edgy eft to hardy heron, remotely, with one reboot at the end to make it pick up the new kernel, and the whole thing came off without a hitch!

One of the most interesting debates concerning new technologies is whether human enchantment technologies have any reseamblance to the older practice of eugenics. One of my favorite articles on this subject is by The Case against Perfection, which simply stunned my students (and they are pretty hard to stun). Recently, the Chronicle of Higher Education published a couple of articles on the topic, and I wrote a response to one of them, (which as you will see, irked me some) here. While I agree with the author that medical genetics is not eugenics, it is still worth our while thinking through today’s genetic and reproductive technologies through the eyes of historical instance of eugenics.

The Japanese post-rock band Mono delivered an amazingly powerful album in 2006: You Are There. It features beautiful and spacious sound scenes produced with real instruments (as opposed to electronic music), in some ways much more so than Mono s other, earlier albums, which I adore as well. This album captivates me to the point that I can t really to work to it; yet, it s also just too good to turn off. I am stuck between a rock and a hard place, it seems. On a related note: I am going to see Explosions in the Sky in Zurich s Abart club next week. The music is very similar, not only because both bands are published by the same label, Temporary Residence (along with many other really good artists). And I am excited about this for two reasons: first, because they rock. And second, because I ll be with a certain someone then, whereas now I d have to say that you are there . NP: Mono: You Are There