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

I finally closed my cooperative's annual accounts for the year to 5 April 2008 yesterday. We wrote off one project (not bad for a year) and now we can start on the annual reports. For day-to-day entries, we're still using my simple scheme/web app called SQL-Journal and I should make a new release real soon now. I've added some features since 1.3 and there's a few more I want to add, but I'm no accountant, so it will remain simple and stupid, but good enough for me. Bristol Wireless's accountant has written some comments on GNUcash which is an interesting view: "not quite there yet" which could help finance software developers. Better searching is one thing I will add to SQL-Journal some time, but it will probably never have features like reporting (I either use an SQL-based report package or export to a spreadsheet) and I know it's no better at handling VAT, mainly because TTLLP isn't VAT-registered yet. I also spotted Finance software in Emdebian, by Neil Williams recently. I wonder if the bursts of accounting interest are connected to the end of the financial year?

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

The way Xen works is that the RAM used by a virtual machine is not swappable, so the only swapping that happens is to the swap device used by the virtual machine. I wondered whether I could improve swap performance by using a tmpfs for that swap space. The idea is that as only one out of several virtual machines might be using swap space, a tmpfs storage could cache the most recently used data and result in the virtual machine which is swapping heavily taking less time to complete the memory-hungry job. I decided to test this on Debian/Etch (both DomU and Dom0). Above is a graph of the time taken in seconds (on the Y axis) to complete the command “apt-get -y install psmisc openssh-client openssh-server linux-modules-2.6.18-5-xen-686 file less binutils strace ltrace bzip2 make m4 gcc g++“, while the X axis has the amount of RAM assigned to the DomU in megabytes. The four graphs are for using a real disk (in this case an LVM logical volume) and for using tmpfs with different amounts of RAM backing it. The numbers 128000, 196000, and 256000 and the numbers of kilobytes of RAM assigned to the Dom0 (which manages the tmpfs). As you can see it’s only below about 20M of RAM that tmpfs provides a benefit. I don’t know why it didn’t provide a benefit with larger amounts of RAM, below 48M the amount of time taken started increasing exponentially and I expected that there was the potential for a significant performance boost. After finding that the benefits for a single active DomU were not that great I did some tests with three DomU’s running the same APT command. With 16M of RAM and swap on the hard drive it took an average of 408 seconds, but with swap on the tmpfs it took an average of 373 seconds - an improvement of 8.5%. With 32M of RAM the times were 225 and 221 seconds - a 1.8% improvement. Incidentally to make the DomU boot successfully with less than 30M of RAM I had to use “MODULES=dep” in /etc/initramfs-tools/initramfs.conf. To get it to boot with less than 14M I had to manually hack the initramfs to remove LVM support (I create my initramfs in the Dom0 so it gets drivers that aren’t needed in the DomU). I was unable to get a DomU with 12M of RAM to boot with any reasonable amount of effort (I expect that compiling the kernel without an initramfs would have worked but couldn’t be bothered). Future tests will have to be on another machine as the machine used for these tests caught on fire - this is really annoying, if someone suggests an extra test I can’t run it. To plot the data I put the following in a file named “command” and then ran “gnuplot command“:
unset autoscale x
set autoscale xmax
unset autoscale y
set autoscale ymax
set xlabel “MB”
set ylabel “seconds”
plot “128000″
replot “196000″
replot “256000″
set terminal png
set output “xen-cache.png”
replot “disk” In future when doing such tests I will use “time -p ” (for POSIX format) which means that it displays a count of seconds rather than minutes and seconds (and saves me from running sed and bc to fix things up). I am idly considering writing a program to exercise virtual memory for the purpose of benchmarking swap on virtual machines. My raw data is below:

time apt-get -y install psmisc openssh-client openssh-server linux-modules-2.6.18-5-xen-686 file less binutils strace ltrace bzip2 make m4 gcc g++ 96M: 0m37.416s
64M: 0m47.607s
48M: 0m55.050s
32M: 1m8.200s
30M: 1m15.010s
28M: OOM process 2 with default initrd, needed MODULES=dep to make it boot
28M: 1m18.694s
24M: 1m25.517s
20M: 1m38.376s
16M: 2m15.594s
14M: 3m14.777s
13M: OOM when the initrd is not hacked to remove LVM stuff and drivers for Dom0 stuff
13M: 4m15.930s
12M: really won’t boot 128000K of RAM in Dom0 for caching (18M cache and 70M free), 256M swap per DomU on tmpfs. 96M: 0m40.121s
64M: 0m48.207s
32M: 1m12.394s
24M: 1m21.929s
16M: 1m59.042s
14M: 2m48.517s
13M: 3m29.391s 196000K of RAM in Dom0 for caching: 64M: 0m47.871s
32M: 1m12.078s
24M: 1m22.360s
16M: 2m0.336s
14M: 2m36.459s 256000K of RAM in Dom0 for caching: 64M: 0m47.949s
32M: 1m11.435s
24M: 1m21.402s
16M: 1m58.884s
14M: 2m39.081s 256000: of RAM in Dom0, three DomU’s: 32M: 3m41.583s 3m40.737s 3m41.071s
16M: 6m16.430s 6m14.832s 6m7.569s hard drive, three DomU’s: 32M: 3m42.100s 3m47.516s 3m46.333s
16M: 6m41.587s 6m50.837s 6m51.795s

Share This

<comment />

Love is For Sharing
Share your Fun, your Joy, your Heart
Best Moments in Life Love is Not to Share
Don't share Birthday Dinner's Bills
Not Forgetable Love is About Talks
Talk a Lot, 'bout Everything
Talks will Hook You Up Love is Not to Talk
Don't Overstate when in Rage
It will Hurt you Both Love is For Spending
Spend Much Time with Each Other
It's just Natural Love is Not to Spend
Hobbies are Fun, but Beware:
Not on Holidays Love is For Writing
Take the Time and Write It Down
Love Letters are Fun Love is a Black Out
No Idea how to Praise Them
Not Able To Write Love is For Thinking
Do Not Forget the Good Things
In Times of Troubles Love is Not to Think
Just be Yourself Where You Go
Let It Drive Itself

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...

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).

Andrew Pollock writes about visiting Prague, coming through Z rich on the way:

Immigration [at Z rich airport] 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.

Hey, this is Switzerland, what did you expect? :-) I don't say that bad experiences don't exist, but so far I always have been able to interact with officials (customs, police, judges, clerks, whatever) on the basic assumption that things will work out without too much hassle. Often the most difficult part is finding the office that is responsible for whatever I should do. Knowing what realistically can be expected and what might not be easily possible helps, too.

Twelve months ago, I stopped being a part-time cyborg. Twelve months ago last Sunday (18th May), I had a kidney transplant. It basically gave me my life back, so Sunday was kind of like a birthday. The kidney was donated by my mother, so she not only gave birth to me back in 1967, she gave me my life again last year. The operation went well, recovery was un-problematic, and aside from a few initial difficulties getting used to all the anti-rejection drugs I have to take, my health just keeps getting better and better. And although the twice-daily ‘pill-salad’ I have to take kind of sucks, it sure as hell beats the shit out of spending about 6 hours trapped in a chair (comfy as it was), hooked up to a dialysis machine, three times per week. Dialysis added up to about 20 or 25 hours a week including preparation time and cleaning up afterwards, equivalent to a half-time job for both me and my partner (I dialysed at home, thanks to the dialysis machine and supplies provided by the hospital. I am so glad that I live in a civilised country with a public health system for all. I’d probably be dead if I lived somewhere barbaric like the U.S. where access to decent health care is dependent on your income or wealth) As well as the enormous improvement the transplant has made to my daily life, I’m looking forward to travelling again. Travel was basically impossibly impractical on dialysis. Post-transplant, it’s quite possible as long as I’m careful and take appropriate precautions (the anti-rejection drugs partially suppress my immune system, so I’m at higher risk for catching some infectious diseases) Best of all, the greatest risk of losing a transplanted organ is within the first twelve months - if the transplant survives that long, there’s an excellent chance that it will survive ten or twenty years or more. And I’m hoping that, if I ever need another kidney, in five or ten or twenty years time they’ll be able to grow me one “to order” from my own DNA, so no risk of rejection. Syndicated from Craig Sanders' Errata: Tech Notes and Miscellaneous Thoughts Twelve Months

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

An interesting thread on openssh-unix-dev points out a way that a compromised remote ssh account or host could potentially trick users into divulging the passphrase for their local secret key. Given that we're all dealing with the potential for compromised ssh hosts lately, i think this is an important consideration. (this has apparently been raised on openssh-unix-dev as far back as 8 years ago). Unfortunately, a couple messages with mangled headers seem to have broken the thread into two chunks in the archive, severing the start of the thread from the part where it starts getting really good: In particular, Damien Miller's suggestion is to forbid in-terminal key-based authentication entirely, and rely instead on ssh-agent. My impression of this strategy is that it's analogous to forcing an out-of-band verification process -- since the in-channel communication is happening in the tty, and the remote host will have some level of control over the tty once authentication succeeds, it's important that any locally-divulged secrets (e.g. the passphrase for the local secret key) are not transmitted over the tty in question. Of course, disabling in-terminal key-based authentication creates something of a usability problem for users who aren't using X11 (and who don't have some other method for an out-of-band ssh-askpass). And it also points out the additional problems with X11 forwarding (e.g. a compromised host allowed to forward X connections could trigger a mimicry of a standard ssh-askpass password prompt). This is something that debian might want to consider, as we've diverged from upstream on the default settings for ForwardX11Trusted. I'm uncomfortable with how Damien's suggestion raises the bar to key-based authentication in general, since users will now have to understand both keys and agents in order to effectively authenticate this way. But maybe that's what's needed, since we desperately need to phase out password-based authentication (and all the security pitfalls associated with it) in this brave new networked world. At any rate, i've adopted the suggestion for now:

[0 dkg@squeak ~]$ tail -n1 .ssh/config
IdentityFile none
[0 dkg@squeak ~]$ 

I'm curious to know if other people have adopted this strategy, or have other mitigating techniques.Tags: security, ssh

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.

It’s not every day that your work is ignored by a founder of Mozilla Europe. From El Pa s:

En Espa a un 23,5% de visitas se dan en Firefox, un ndice que es superior al de EE UU, pero que no llega a los ndices de Polonia donde el 40% del tr fico se da en el navegador de Mozilla. A pesar de estos aceptables datos [Tristan] Nitot ha recordado y pr cticamente hecho un llamamiento para crear una versi n del navegador en gallego: “Hay una versi n en catal n de Firefox construidas por voluntarios que les importa su idioma, al igual que la hay de euskera. Pero a n no hay una versi n en Galicia, muchas veces me lo preguntan y mi respuesta es que si nadie de Galicia se presenta no habr una versi n en gallego, estamos dispuestos a que la gente trabaje con nosotros".

Loosely translated:

“There’s a Catalan version of Firefox built by volunteers who care about their language, and there’s another one in Basque. But there’s no Galician version yet, I get asked this very often, and my answer is that if nobody from Galicia steps up there will be no Galician version. We would like people to work with us".

So, apparently, there’s no Galician translation of Mozilla. I guess that my more than three years’ worth of work were wasted (Dec 2001 - Jul 2004 and Jan 2006 - Aug 2006), that Xis and Galego21 did nothing back in the nineties and noughties, and that what mancomun.org is hosting is an empty XPI file. To not speak of the paralysed/paralysing bureaucracy of the Mozilla Foundation when several groups of volunteers, one after the other, tried to reinstate the official Galician l10n team. I would be pissed off if I cared about Galician. Because, you know, from reading my blog it’s obvious I don’t.

I'm excited by version 7 of debhelper, in particular the opportunity for debian/rules minimization. I suspect this will lower the barrier for rapid, reasonable packaging of simple software tools in a way that should be easy to audit and maintain. The most-minimized debian/rules possible with it is just (from dh(1)):

#!/usr/bin/make -f
%:
	dh $@

And all of the project-specific interesting bits go into nice, clean, well-named files under debian/. However, lintian (at least as of 1.23.48) complains loudly about the minimized debian/rules:

E: xdotool source: debian-rules-missing-required-target binary
E: xdotool source: debian-rules-missing-required-target binary-arch
E: xdotool source: debian-rules-missing-required-target binary-indep
E: xdotool source: debian-rules-missing-required-target build
E: xdotool source: debian-rules-missing-required-target clean

I'm not sure the right way to proceed: should i try to manually add overrides for each package that uses a minimized debian/rules? Should lintian recognize debhelper-specific minimized rules files and accept them? Should debhelper assuage lintian somehow? Or is this rules file minimization actually not as good an idea as I think it is? I notice that mr, which is Joey Hess's first example package using the minimized rules also reports the same errors.Tags: debhelper, lintian, packaging

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.