Note: The title is intentionally unclear; it can be read both as virtual failures and failures of virtual hardware , and I'm not sure which one is the better for the cases below. One of the funny things about virtualization is how virtual hardware fails. It often happens that my NFS-stored virtual machine images suffer an NFS glitch or something, at which point one can see in the kernel logs:

kernel: mptscsih: ioc0: attempting task abort! (sc=ffff880018320100)
kernel: sd 0:0:0:0: [sda] CDB: Read(10): 28 00 00 00 00 38 00 00 08 00
kernel: mptscsih: ioc0: task abort: FAILED (sc=ffff880018320100)
kernel: mptscsih: ioc0: attempting target reset! (sc=ffff880018320100)
kernel: sd 0:0:0:0: [sda] CDB: Read(10): 28 00 00 00 00 38 00 00 08 00
kernel: mptscsih: ioc0: target reset: SUCCESS (sc=ffff880018320100)
kernel: mptscsih: ioc0: attempting task abort! (sc=ffff880018320100)
kernel: sd 0:0:0:0: [sda] CDB: Read(10): 28 00 00 00 00 38 00 00 08 00
kernel: mptscsih: ioc0: task abort: FAILED (sc=ffff880018320100)
kernel: mptscsih: ioc0: attempting task abort! (sc=ffff88001eefcc00)
kernel: sd 0:0:0:0: [sda] CDB: Read(10): 28 00 00 98 01 a7 00 00 08 00
kernel: mptscsih: ioc0: task abort: FAILED (sc=ffff88001eefcc00)
kernel: mptscsih: ioc0: attempting target reset! (sc=ffff880018320100)
kernel: sd 0:0:0:0: [sda] CDB: Read(10): 28 00 00 00 00 38 00 00 08 00
kernel: mptscsih: ioc0: target reset: SUCCESS (sc=ffff880018320100)

While the NFS transient issues are probably a real bug, I have this image of a state machine inside the driver trying over and over the same error paths, in a futile attempt at fixing the hardware , and not locking onto/matching the real hardware behaviour. Or, this most recent case during boot and resource probing:

kernel:  e1000: 0000:00:08.0: e1000_probe: The EEPROM Checksum Is Not Valid
kernel:  /*********************/
kernel:  Current EEPROM Checksum : 0x031a
kernel:  Calculated              : 0x031a
kernel:  Offset    Values
kernel:  ========  ======
kernel:  00000000: 08 00 27 f6 f3 9b 00 00 ff ff 00 00 00 00 00 00
kernel:  00000010: 00 00 00 00 08 44 1e 00 86 80 0e 10 86 80 40 30
kernel:  00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
kernel:  00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
kernel:  00000040: 00 00 61 70 0c 28 c8 00 c8 00 00 00 00 00 00 00
kernel:  00000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 06
kernel:  00000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
kernel:  00000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1a 03
kernel:  Include this output when contacting your support provider.
kernel:  This is not a software error! Something bad happened to your hardware or
kernel:  EEPROM image. Ignoring this problem could result in further problems,
kernel:  possibly loss of data, corruption or system hangs!
kernel:  The MAC Address will be reset to 00:00:00:00:00:00, which is invalid
kernel:  and requires you to set the proper MAC address manually before continuing
kernel:  to enable this network device.
kernel:  Please inspect the EEPROM dump and report the issue to your hardware vendor
kernel:  or Intel Customer Support.
kernel:  /*********************/
kernel:  e1000: 0000:00:08.0: e1000_probe: Invalid MAC Address
kernel:  e1000: 0000:00:08.0: e1000_probe: (PCI:33MHz:32-bit) 00:00:00:00:00:00
kernel:  e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection

This is an emulated Intel NIC under VirtualBox. I have never seen it before, and it went away after a reboot. The most funny thing is the This is not a software error! message well, it definitely is :), but the driver has no way to know that. I think that these software-driven failures probably trigger some obscure error handling paths; I assume that the usual failures for real versus virtual hardware are quite different in nature, and that recovery is again different. This leads to using the wrong strategy for recovery, but fortunately nothing is really broken, just in the wrong state Since I'm not familiar with low-level driver details, I might be wrong of course; I'm just speculating on what I think goes on inside the driver. I'm not even mentioning virtual clock issues, as those are no longer funny

One of the things that I love about our Local LUG is the people. At our LUG, we have our resident geek artist, Antonio Roberts (aka hellocatfood) who, on the odd occasion, gets harassed into doing a talk for us. His talks are always fairly awesome. His previous talk about FLOSS + Art is the video with the highest views on our video archive, and tomorrow night, Thursday 16th September, at 19:30pm BST, he ll be delivering his next talk about his experience in the FLOSS community as an artist to us. In his own words:-

This talk extends greatly on what was said and goes into issues of copyright and what experiences I ve had as an artist in the open source world

His previous talk was a bit of an eye-opener to me, as a pure geek with barely a trace of artistry in me, and it s always good to see the FLOSS world from the eyes of someone who doesn t exactly fit the stereotype of what you d normally expect to see. The video will be available after the event, at some point, but for those who re interested in gaining an insight into artistry and FLOSS, we ll be broadcasting the talk live over the interwebs. <script type="text/javascript"> var flattr_wp_ver = '0.9.11'; var flattr_uid = '34168'; var flattr_url = 'http://www.sourceguru.net/freedom-creativity/'; var flattr_btn = 'compact'; var flattr_hide = 0; var flattr_lng = 'en_GB'; var flattr_cat = 'text'; var flattr_tle = 'Freedom in Creativity'; var flattr_dsc = 'One of the things that I love about our Local LUG is the people. At our LUG, we have our resident geek artist, Antonio Roberts (aka hellocatfood) who, on the odd occasion, gets harassed into doing a talk for us. His talks are always fairly awesome. His previous talk about FLOSS + Art is the video with the highest views on our video archive, and tomorrow night, Thursday 16th September, at 19:30pm BST, he\'ll be delivering his next talk about his experience in the FLOSS community as an artist to us. In his own words:- This talk extends greatly on what was said and goes into issues of copyright and what experiences I ve had as an artist in the open source world His previous talk was a bit of an eye-opener to me, as a pure geek with barely a trace of artistry in me, and it\'s always good to see the FLOSS world from the eyes of someone who doesn\'t exactly fit the stereotype of what you\'d normally expect to see. The video will be available after the event, at some point, but for those who\'re interest'; var flattr_tag = 'art,artist,floss,lug,presentation,sblug birmingham lug,streaming,talk,video'; </script> <script src="http://api.flattr.com/button/load.js?v=0.2" type="text/javascript"></script>

Today, registration for the 2011 Paris Marathon (Apr 10th 2011) and 2011 Paris Half-marathon (March 6th 2011) was opening. I just registered for both. One will note that about 3 hours after the online registration opened, already more than 1200 people registered. As there are "only" 37000 places (plus 3000 for travel agencies and sponsors), people will, as usual, need to hurry (the half-marathon has 28500 places).

I was asked for advice on how to start learning Linux. Rather than replying via email I m writing a blog post for future people who ask such questions and also to get comments from other people which may provide information I missed. Join a LUG The best thing to do is to start by joining your local Linux Users Group (LUG). Linux International maintains a list of LUGs that is reasonably comprehensive [1]. Even if there isn t a LUG near enough for you to attend meetings you can learn a lot from a mailing list of a LUG that s close to your region. There is usually no great reason not to join the mailing list of a LUG in a different region or country, but a local LUG is that the advice will often be tailored to issues such as the local prices of hardware and the practices of your government. Also note that Linux International doesn t list all LUGs, the MLUG group in Melbourne [2] and the BLUG group in Ballarat [3] aren t listed. Anyone who joins LUG (the group based in Melbourne, Victoria that I m a member of) will be advised of the smaller groups in the region if they ask on the list. As an aside it would probably make sense for the main LUV web page [4] to have links to local LUGs and to the LI page of users groups and for other LUGs to do the same. It s pretty common for a Google search to turn up the web site of a LUG that s near the ideal location but not quite right. Also it would be good if LUV could have a link to the Victorian Linux Users Group in Canada this should reduce the confusion a bit and they have a link to us [5]. Play with Linux Get a spare PC (with no important data) and try installing different distributions of Linux on it. Make sure that it never has anything particularly important so you can freely try things out without worrying about the risk of losing data. Part of the learning process usually involves breaking a system so badly that it needs to be reinstalled. Linux can run on really old hardware, an old system with 64M of RAM will do for learning (but 128M will really be preferred and 256M will be even better). Learn with other Beginners LUV has a very active beginners group, with a beginners mailing list and special beginners meetings. A group that has such things will be more helpful as you can easily learn from other people who are at a similar level to you. Also you can spend time learning Linux with friends, just spend a weekend with some friends who want to learn Linux and play with things you can often learn more by trying things than by reading books etc. Do some Programming One of the advantages of Linux (and other Free Software OSs) is that it comes with a full range of programming languages for free. You can get a much greater understanding of an OS by writing programs for it and a typical Linux distribution gives you all the tools you need. Any other Ideas? Does anyone have any other suggestions? Please leave a comment.

• [1] http://www.linux.org/groups/
• [2] http://www.mlug.org.au/
• [3] http://www.blug.asn.au/
• [4] http://luv.asn.au/
• [5] http://www.vlug.org/linux/lugs.html

I'm using Twitter plugin for Contacts and Conversations to twitter on my N900.

Twitter recently moved to OAuth. Problem is the Maemo package is outdated and seems to be unmaintained.

I did some research and came across a blog entry about exploring OAuth-protected APIs and some code. Nice idea but not usable for me.

I ended up sitting down and writing a small python script that will re-route your HTTP requests to api.twitter.com after adding all the OAuth bills and whistles, read the reply from twitter and send it back. Neat ? :-)

There's also supertweet.net which I've discovered after I finished writing my script but seems they don't support all of the twitter API call while my script does that.

The script is simple without much error checking but it's been working for me for a few days already.

Last thing, I'm not interested in running a service like supertweet. I'll not be implementing the full OAuth protocol. Need to use it ? Register your own application.

Get the code while hot!

Next step: Thinking of maintaining the twitter plugin for Maemo. I already compiled the latest code and it sort of works fine :-) read more

dpkg-source is the program that generates the Debian source package when a new package version is built. It offers many interesting command-line options but they are often not used because people don t know how to ensure that they are used every time the package is built. Let s fill that gap! It is possible to forward some options to dpkg-source by typing them on the dpkg-buildpackage command line but you d have to remember to type them every time. You could create a shell alias to avoid typing them but then you can t have different options for different packages. Not very practical. The proper solution has been implemented last year (in dpkg 1.15.5). It is now possible to put options in debian/source/options. Any long option (those starting with -- ) can be put in that file, one option per line with the leading -- stripped. Here s an example:

# Bzip2 compression for debian.tar
compression = "bzip2"
compression-level = 7
# Do not generate diff for changes in config.(sub guess)
extend-diff-ignore = "(^ /)config.(sub guess)$"

Notice that spaces around the equal sign are possible contrary on the command line. You can use quotes around the value but it s not required. The debian/source/options file is part of the source package so if someone else grabs the resulting source package and rebuilds everything, they will use the options that you defined in that file. You can also use debian/source/local-options but this time the file will not be included in the resulting source package. This is interesting for options that you want to use when you build from the VCS (Version Control Repository, aka git/svn/bzr/etc.) but that people downloading the resulting source package should not have. Some options (like --unapply-patches) are only allowed in that file to ensure a consistent experience for users of source packages. You can learn more about the existing options in the dpkg-source manual page. Read it, I m sure you ll learn something. Did you know that you can tell dpkg-source to abort if you have upstream changes not managed by an existing patch in debian/patches? It s --abort-on-uptream-changes and it s only allowed in debian/source/local-options. Be sure to subscribe to the RSS feed or to the email newsletter to not miss useful documentation for Debian contributors! 3 comments Support my work

Hello Following a discussion on #debian-perl IRC channel, I ve proposed to provide a script to parse DEP-5 files. The goal is to be able to parse *and* validate DEP-5 files. DEP-5 is a
proposal to make debian/copyright machine-interpretable. This proposal is driven by Lars Wirzenius. With Config::Model, any evolution of DEP-5 specification will
be easy to include in the DEP-5 model read by Config::Model. What DEP-5 model ? To keep a long story short, let s say that DEP-5 model is a description of DEP-5 syntax and semantic that can be used by Config::Model to perform validation. For more detail on how to create a model, please read this doc. In other word, DEP-5 model is DEP-5 document translated into a special format. First step was to directly edit the doc and munge it into a YAML document describing the structure of DEP-5. Here s a small extract of this YAML file (slightly edited to remove most long descriptions) :

 
---
class:
  Debian::Dep5:
    class_description: >
       Machine-readable debian/copyright
    accept:
      name_match: X-.*
      type: leaf
      value_type: string
    element:
      Format-Specification:
        mandatory: 1
        type: leaf
        value_type: uniline
        description: >-
          URI of the format specification, such as ...
      Name:
        type: leaf
        value_type: uniline
      Files:
        type: hash
        index_type: string
        ordered: 1
        cargo:
          type: node
          config_class_name: Debian::Dep5::Content

During this YAML file creation step, the problem raised by the License keyword became obvious because of License properties:

• Limited number of valid License (no problem, let s use an enum)
• License names are not case sensitive (optimism goes somewhat down)
• License names have version number and an optional + suffix (ok, let s use a regular expression with Config::Model s brand new match specification)
• License can be combined with and or or . (uh oh, the match regexp will not be enough. A grammar would be better.)
• License can specify an abbreviation or the full text of the license.

Long story short, I had to add to Config::Model the possibility to specify a Parse::RecDescent grammar to validate a value. More on this later. Of course, the first draft of a model in YAML was far from being perfect. So the second step was to load it with config-edit-model. I had to fix a number of YAML errors and then some errors in the model description. Then, I had to write a parser to load the DEP-5 data into Config::Model tree. I first used Rapha l Hertzog s Dpkg::Control::Hash module. But this one is not able to cope with repeated fields without clobbering them. So I had to provide my own parser. The parser is divided in 2 parts:
- the parse function to load DEP-5 data in a simple data structure
- the read function to load the simple data structure into Config::Model s configuration tree You can view the code on Config::Model repository. Then the model is divided in 3 configuration classes:

• Debian::Dep5: the root class
• Debian::Dep5::Content: To represent Files specification
• Debian::Dep5::License

And the full model of Dep-5 can be also read on Config::Model repository:

• Dep5.pl.
• Dep5::Content
• Dep5::License

(The models are biggish because they include help text taken from DEP-5 documentation) Now some explanation is required on how is performed the License validation. The trick is that each License used must be listed in Dep5 s license parameter which is specified this way (in YAML syntax):

 
License:
  type: hash
  index_type: string
  allow_keys_matching: '^(?i:Apache Artistic BSD etc... other)[\d\.\-]*\+?$'
  cargo:
     type: leaf
     value_type: string

So this License element contains the list of licenses with their full text and only Licenses whose name matches the regular expression are accepted. Now, let s explain how the files are tied to the declaredlicenses. The Debian::Dep5::Content class had a License element that represent the relation between the files and the License(s). This bond is represented by Debian::Dep5::License configuration class. The abbrev and full_license elements are fairly obvious. The abbrev element is another matter. Here s its declaration (minus the description and help):

 abbrev:
 type: leaf
 value_type: uniline
 default: other

So far, so good. Now the meaty part: the validation requirement based on Parse::RecDescent

grammar: "license (oper license)(s?)
          oper: 'and'   'or'
          license: /[\\w\\-\\.\\+]+/i\n
               # PRD action to check if the license text is provided
               $return = $arg[0]->grab('! License')->defined($item[0]);
               "

This grammar specifies:

• The syntax of the License line itself (hence something like Perl or GPL )
• An action performed when the grammar is matched. Using Config::Model API, this Perl snippet checks that the License abbreviation has a corresponding License declared in Debian::Dep5 License hash

This way, an abbreviation cannot be used without a proper License statement. This code is the first stab. Some more work is to be done soon:

• Implement exception parsing
• Provided DEP-5 writer
• Provide config-edit-dep5 cli

Anyway, I ll soon release Config::Model with this first version of DEP-5 parser. As always feedback are more than welcome. All the best update: added missing Parse::RecDescent link

How pivot_root won against a stupid RAID controller This post is brought to you by a very stupid 3ware 9650SE RAID controller, which doesn't understand the concept of growing a RAID array after all disks have been replaced by bigger ones. Or, well, it can, but the procedure, involving sending array dumps to the technical support, then receiving a program to run under DOS (!), doesn't inspire me with confidence. Furthermore, this stupid RAID card doesn't allow easy reordering (if it's possible, and I just missed it, please let me know) of the RAID arrays at runtime, only from the BIOS screen, and I didn't have access to that (only poor man's serial console under Linux). So, after buying new harddrives, and replacing the original ones in the RAID1 array with double the capacity, I realised I have to do a manual conversion. Basically, go into single-user mode, remount all read-only, split the RAID1 array into its (identical) components, change root directory to the second disk, re-partition the first disk, copy the data from the 2nd to the 1st disk, then re-add the 2nd disk to the 1st one (repartitioned) to re-establish the RAID1. All this, on a headless (no keyboard, no VGA) machine, just with a serial console. Of course, if this is just your local machine, you can easily reboot from an external media, and do all this easily from a full user-space. In any case, I'm writing this down, as there seem to be no easily findable guides on how to do the resize on a 3ware with its restrictions. Procedure Disclaimer: you might lose data via this, there are no guarantees. Have up-to-date backups. First, make sure you have power control (you can power-cycle the box if needed) and the serial console works. Also, make absolutely sure that the RAID array is fully consistent, and that you don't have any bad sectors on the drives, as you will lose redundancy during the operation. If /usr is not on your root file-system, then you need to copy /usr/sbin/chroot to somewhere on it. Also, if you have tools for the array that are not on your root file-system, you should copy them there now. In my case, that was tw_cli. First reboot Reboot into init=/bin/sh. Note: I've tried to simply go into single-user mode, or to reboot with emergency, but this doesn't work, because in both modes, beside the init process with PID 1 and your shell, there's another init process (the parent of the shell), and I didn't know how to tell it to re-execute itself. To the main init process it's easy, you just run telinit u, but that child keeps the old root directory mounted. If it's possible to re-exec that child too, then this step can be skipped please let me know how! Changing the root mount Make sure everything is mounted read-only (should be), then split the raid array into its component drives, using whatever tool the card needs. For me, it was:

# tw_cli /c0/u0 migrate type=single

The second drive now should be visible e.g. as /dev/sdc, so mount it somewhere, and pivot_root to it:

# mount -o ro /dev/sdcX /mnt
# cd /mnt/
# pivot_root . mnt/
# exec chroot .

At this point, the new root (on some partition on /dev/sdc) is mount at the root, and the exec call replaced the current shell with another one that has the right root directory. So nothing should keep the old root directory (at /dev/sdaX) in use, and umount /mnt (or umount /dev/sdaX) should succeed now. Recreate the first raid array Now, since it's no longer in use, you can delete and recreate the first raid array. Once it's available, you have two choices:

• either do a bit-for-bit copy, using dd, from /dev/sdc to /dev/sda, then run sfdisk -R /dev/sda to re-read the changed partition table on the target drive
• or repartition /dev/sda if you also want to change the partition layout

I did the latter, since I wanted to use the new alignment standards (the initial installation was still using sector 63 for the boot partition, etc.) as a future preparation for either SSD or 4K-sector drives. So I used:

• fdisk -cu /dev/sda, and created partitions accordingly
• then re-did my physical volume for LVM, but with --dataalignment 1024k, to have the same megabyte alignment (yes, I went a little overboard)

In any case, either copy the entire disk, or each partition in turn, or possibly pvmove from the old to the new disk, etc. Switch back the root mount At this point, /dev/sdc is no longer used, and you can again change the root directory. This is similar to the first pivot_root, but now using /dev/sda as a target. All the instructions are the same. Convert back to RAID1 Now, since (in our example) /dev/sdc is no longer in-use, you can delete that drive and rejoin it to the first drive, recreating the RAID1 array. In my case:

# tw_cli
/> /c0/u2 delete
blah blah [y/n] y
/> /c0/u0 migrate type=raid1 disk=X

At this point, the machine is again redundant (or will be once the resync finishes), but it still needs one more step or it won't boot correctly. Reinstall the boot-loader Now, for reinstall the boot loader, you'll probably need to mount /boot (and mount it read-write), and do whatever you need. In my case, I re-ran lilo, but grub-install /dev/sda should also work. Final reboot And now, you only need to reboot into the normal, resized system. Since you can't easily use shutdown when booted with /bin/sh as init, just use /proc/sysrq-trigger to sync/unmount/reboot. Thoughts While I use a hardware RAID controller for the battery backup it offers, I have never thought it cannot do such a simple operation (compare with mdadm --grow /dev/mdX --size=max). Second, I knew about pivot_root but have not used it before. It's a very very nice thing, and the only downside is that you can't really use it with more than a few processes, since it's hard/impossible to change a random process' root directory. But anyway, it works, and it's damn handy for doing things to the root file-system or in general to the root drive (e.g. just repartitioning it) when you can't boot from another media (e.g. remote machine).

The Exoclimes conference ended on an interesting perennial problem: what should we call these things we work on? The climate folks pointed out what the astronomers have grown used to: the telephone numbers we use as planet names. The two most studied Hot Jupiters, for example, are HD209458b and HD189733b. Come on, we could do better than that. In fact the naming worries started earlier when Frank Selsis asked people to avoid calling the planets he works on "super-Earths" (or should that be Super-Earths?). Dimitar Sasselov had accidentally kicked up a kerfuffle in the media a few weeks back by calling them "Earth-like" planets, when he meant "Earth-sized" planets. Selsis pointed out non-scientists will interpret "super-Earth" to mean "like Earth, only Better!", when we mean its just a bigger ball of rock and ice than Earth. But what to call them? Well, at least one planet already has a name, sort of: HD 209458b is frequently called 'Osiris'. And there is a published list of possible planet names. But Osiris the Egyptian god is more famous than Osiris the planet, confusing google. And people are going to assume things based on the planet names: are we really going to name a planet Vulcan? One suggestion was that if we found a system with seven planets we could call them after the Seven Dwarfs, but this was ruled out: don't mention the war (but dwarfs could also mean brown dwarfs!) At the end of the conference, there was show of hands: who agreed with naming planets? of about 100 present, all in favour, none against. The delegate to the IAU commision on the matter, which had voted against, duly noted. Perhaps we will name them then. Tags names, exoplanets, astronomy

[Nothing related to Debian here, move on if you don't care about my recurring obsession with the end of the world, Cassandra pains, or Big Phat Living Room Revolution yearnings].

Although I am still looking for a community of anarcho-primitivists that want to accept me joining their frugal living, and simply slip off the social construct, the system, the fucking face of earth, call it what you will, I could find some comfort in my favourite feminist blogger's take on the subject of my midlife crisis regarding ecology, capitalism, patriarchy, child bearing, overpopulation, meat consumption and all the rumination of consuming thoughts that (still) make my life miserable and have kept me running away from human contact for a year.

[Emphasis mine]

At what point does human culture depart from the Natural? With the invention of computers? TV? Cars? The cotton gin? Electricity? Taco stands? Gunpowder? The printing press? Written language? Shoes? Crop cultivation? Yurts? The wheel? Did humans become unnatural when the good old days of picturesque, endless agrarian toil, feudal oppression, unchecked disease, ignorance, and death from dysentery at 35 turned into the bad new days of urban post-industrial capitalism where a pound of fair-trade organic coffee costs $12.99 and your email inbox is full of spam?

ah. Everything humans do, or have ever done, is natural. We can t do anything else. The idea that modern culture is un-natural is nostalgic and inaccurate. Living off the grid in a yurt is good in some absolute sense, whereas driving an SUV from a suburban bungalow to the stripmall is bad ? Come on. This a romantic, but misguided view. The cosmic reaction to a 20 Ford Expedition is the same as to a sanctimonious Prius: bupkis. The universe doesn t give a fuck about you or your lifestyle choices. It doesn t give a fuck about the economy, oil spills, or civil unrest in Blargistan. It doesn t give a fuck about katydids. Eventually our whole planet will be erased from space, and the galaxy won t bat an eye. The inevitable extinction of our species (imminent, according to research here at Spinster Laboratories) via the exhaustion of available resources is as natural as a fresh-picked peach. As Andre 3000 and other dude philosophers have observed, nothing is forever.

Yes, yes, when people use the word natural what they really mean is free of chemical additives and maybe some of the assorted hippie concepts that go with that narrative. Barter economies, home furnishings made from bamboo, vegan cookbooks, living in the country. While I would argue that it is just as natural for people to put chemical additives in things as it is to not put chemical additives in things, I admit that it is appealing to fantasize that the source of human misery is an unnatural isolation from Nature, and that doing yoga on an organic rubber mat and drinking organic spinach smoothies will put me back in sync with the cosmos.

But alas, I m already in sync with the cosmos, and so are you. In other words, this is it. This is what we ve become, and this is what we get. Which is not to say that a person can t fantasize about a verdant paradise full of songbirds and polar bears and Bengal tigers, untouched by human influence. Only, that world isn t a world we could actually live in. The minute you add contented children, lazy from a carefree day at the swimming hole, eating ripe plums on the porch at sunset to that scenario, natural history changes, and it s right back to our scorched-earth dystopia. Our giant brains use up resources, it s as simple as that.

As long as we re still here, though, we might as well try to make the best of it.

http://blog.iblamethepatriarchy.com/2010/06/19/heads-up-art-week-starts-on-monday/

Though the comfort is somewhat ephemeral, because deep inside, I know she's wrong, I know another way is feasible, but I have given up already, I have very well come to terms with extiction, I get an enormous pleasure from the thought of the very well deserved human mass suicide-by-cop^Wnature, and in fact, I trust and hope it will save me personally from facing the hard times ahead, as I am a damn coward, paralized by fear, hopeless about the flock ever getting it (is it so hard, really?), while doing as much as I can but completely overwhelmed by the need of changing a world everyone seems to like just as it is. I can certainly empathize with much more disturbed ways of airing similar anguish, among many other examples, such as The Unabomber, or The Weather Underground. I don't even want to go there as I know violence all too well and it is not fun to be on the receiving end. But I see the screaming desperation behind the motives of acts I am not at the liberty to discuss here. I wonder if consumption of resources in the form of books will numb the disorder or make it worse and what sort of medical arrangement the stablishment has for it. As you click away the previous links will mean nothing to you because a)it is Wikipedia after all, and b)you probably don't even understand what the problem of eating animal corpses is, humans are omnivores after all, and what is all this nonsense about dropping language altogether.

WTF, there was no comfort after all, and I am still a nutjob.

Currently upgrading Debian Lenny to Squeeze is not that easy, because PostgreSQL 8.3 from Lenny is getting to be removed while PostgreSQL 8.4 won't be installed because of some dependency issues:

# apt-get install postgresql-8.4 postgresql-8.4-postgis postgresql-contrib-8.4
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation: The following packages have unmet dependencies.
postgresql-8.4: Depends: libgssapi-krb5-2 (>= 1.8+dfsg) but it is not going to be installed
Depends: libkrb5-3 (>= 1.6.dfsg.2) but it is not going to be installed
Depends: libpq5 (>= 8.4~0cvs20090328) but 8.3.11-0lenny1 is to be installed
Depends: postgresql-client-8.4 but it is not going to be installed
postgresql-contrib-8.4: Depends: libpq5 (>= 8.4~0cvs20090328) but 8.3.11-0lenny1 is to be installed
E: Broken packages

Well, yes, I know Squeeze is still Testing and such, but as libkrb5-3 and libgssapi-krb5-2 are required but seem to be unavailable, I wonder when this issue will get solved? There seems no bug report for postgresql-8.4, libkrb5-3 or libgssapi-krb5-2. Is that for a reason? Or is the reason for uninstallable postgresql-8.4 something else? UPDATE:

# apt-cache policy postgresql-8.4
postgresql-8.4:
Installed: (none)
Candidate: 8.4.4-2
Version table:
8.4.4-2 0
500 http://ftp.de.debian.org squeeze/main Packages

# apt-cache policy libkrb5-3
libkrb5-3:
Installed: 1.8.3+dfsg~beta1-1
Candidate: 1.8.3+dfsg~beta1-1
Version table:
*** 1.8.3+dfsg~beta1-1 0
500 http://ftp.de.debian.org/debian/ squeeze/main amd64 Packages
100 /var/lib/dpkg/status

UPDATE 2:
This issue seems to be caused by #596678. Thanks Rhonda & Martin!

I recently moved withing Canonical from being a paid developer of Bazaar to take on a larger challenge Technical Architect for Launchpad. Its been two months now, and its time to put my head up out of the coal face, have a look around and regroup. When I worked on Bazaar, every day when I started work got up I was working on a tool anyone can use, designed for collaboration upon sourcecode, for people writing software. This is a toolchain component right at the heart of the free software world. Bazaar and tools like it get used everyday to manage, distribute and collaborate on the sourcecode that makes up the components of Ubuntu, Debian, Fedora and so forth. Every time someone new starts using Bazaar for a new free or open source project, well I felt happy happy that in my small part I m helping with this revolution we re carrying out. Launchpad is pretty similar to Bazaar in some ways. Obviously they are both free software, both are written in Python, and both are sponsored by Canonical, my employer. And they both are designed to assist in collaboration and communication between free software developers albeit in rather different ways. Bazaar is a tool anyone can install locally, run as a command line, GUI, or local webserver, and share code either centrally (e.g. by pushing to Launchpad), or in a peer to peer fashion, acting as their own server. Launchpad, by contrast is a website which (usually) folk will use as a service in their browser, from the comand line FTP (for package building), ssh (for Bazaar branch pushing or pulling), or even local GUI programs using the Launchpad API service. This makes it more approachable for first time collaborators, but its less able to be used offline, and it has all the usual caveats of web sites : it needs a username and password, it s availability depends on the operators on the team I m part of. So there s a lot less room for error: if we do something wrong, the system is unavailable, and users can t just apt-get install an older release. With Launchpad our goal is to to get all the infrastructure that open source need out of the way, so that they can focus on their code, collaboration within their team and almost uniquely collaboration with other teams. As well as being open source, Launchpad is free for all open source projects to use Ubuntu is our single biggest user they use it for all bugtracking, translation and package building, and have a hugefraction of the total storage overhead in the database. Launchpad is a pretty nice system, so people use it, and as a result (on a technical basis) it is suffering from its own success: small corner cases in the code turn up every day or two, code written years ago to deal with a relatively small data set now has to deal with data sets a thousand or more times larger (one table, for instance, has over 600,000,000 rows in it. For the last two months then, I ve been working on Launchpad. As Technical Architect, I need to ensure that the things that we (users, stakeholders and developers of Launchpad) want to do are supported by the structure of the system : the platform(s) we re building on, the way we approach problems, coding standards and diagnostic tools. That sounds pretty dry and hands off, but I m finding its actually very balanced. I wrote a presentation when I started the job, which encapsulated the challenges I saw in front of the team on this purely technical front, and what I thought I needed to do. I think I was about right in my expectations: On a typical day, I ll be hands on in a problem helping get it diagnosed, talking long term structural changes with someone around how to make things more efficient / flexible / maintainable, and writing a small patch here or there to help move things along. In the two months since I took on this challenge, we ve made significant headway on the problem of performance for Launchpad : many inefficient code paths have been identified and removed, some new infrastructure has been created as is being rolled out to make individual pages faster, and we ve massively increased the diagnostic data we get when things go wrong. We ve introduced facilities for responding more rapidly to issues in the software (but they have to be rolled out across the system) and I hope, over the next 4 months we ll reach the first of my performance goals: for any webpage in Launchpad, it will complete rendering in 99% of the time. (Note that we already meet this goal if you measure the whole system, but this is biased by some pages being very frequently hit and also being very small).

There has been much made of recent reports that roughly half of Americans have an unfavorable view of Islam. And as usual, there are those who will try to claim that Muslims really aren t all that bad, and that Sharia is just set of nice, abstract principles which are all about the protection of life, family, education, religion, property, and human dignity. And on the other side, we have people pointing out that using Sharias as justification, there are countries which are stoning women and chopping off poor people s hands and then forbidding Muslims from arguing about whether such things are just. Worst yet, some of the more public moderate Muslims , such as Iman Rauf, refuse to criticize organizations such as Hamas, on the ground that he is a bridge builder , and it wouldn t help to criticize Hamas s terrorist activities as being anti-Isalmic. OK, so let s grant for the sake of argument the claims that Shariah really is far more than just criminal sanctions, but mainly about exhorting people to live a moral life, and that of the 1,081 pages of the two-volume Arabic text which Sherman A. Jackson (the Arthur F. Thurnau Prfessor of Arabic and Isalamic Studies at the University of Michigan) used to study Shariah, only 60 pages were devoted to criminal sanctions (i.e., the stoning and the cutting off of hands), and only 19 were devoted to Jihad. Let s even further grant the claims made by Humaira Awais Shahid that most Muslims reject Political Islam and are not even arabs. OK. But that case, wouldn t there be more Imans publically disavowing the people who advocate terrorism and suicide bombs as not being Islamic? Not all of them are bridge-builders, are they? And if so, some of them might be better deployed towards saying what Islam is not, and saying that perhaps people who espouse those beliefs are being profoundly unIslamic and saying this loudly outside of their Mosques. Oh, I understand that many Muslims feel that they shouldn t be asked to repudiate the sins of a few crazy terrorists ; just as all Christians shouldn t be held accountable for disturbed crazy rants of a small-time pastor from Gainsville, Florida. But at the same time, it seems to me that Islamic leaders should be eager to say, loudly, that what is being done in the name of their religion in Iran and Nigeria is wrong, and to denounce it. Maybe, some would say, that they are doing that and the media isn t paying attention to them. Well, the Media is surely paying attention to people like Iman Rauf, and he refuses to denounce Hamas! I would gently suggest to those Islamic leaders who feel that they and their faith haven t been given a fair shake, to hire a better PR agency; and make sure that active denunciations of that which they claim does not represent true Islam is shouted from the rooftops; published in press releases; made in press conferences. And actively denounce your fellow Muslims that you feel are shaming your religion, instead of complaining about American Islamophobia. Trying to pretend that there is absolutely no truth in why Americans might be afraid of terrorists who have been hiding under the mantle of your religion is not going to help your cause. There may be truth in the fact that many Americans don t know as much as they should about Islam and Shariah. And there may be truth that American unswerving support of Israel, despite the fact that they acted in profound and unjust ways against the Palestinians, is not only morally and ethically wrong, but has hurt American interests. I certainly believe that to be to true; I am no friend to fundamentalists of any stripe, whether they are Christian, Jewish, or Islamic; and I think the Jewish fundamentalists have almost completely taken over the Israeli political discourse. But all of that is irrelevant if the goal is reduce people e negative views towards Islam. And in any case, if you really believe that attacking innocents, and coercing religion by threatening Muslims who have fallen away from their faith with the death penalty is wrong, then it s wrong regardless of whether those innocents happened to vote for politicians who have been influenced by way too much money from AIPAC. So instead of trying to lecture Americans about their uncritical support of Israel, why not just stand witness to the fact that killing innocents is wrong, and that people who do that are not Islamic, no matter what they claim or how impressive their turban might happen to be? And maybe it might be a good idea to speak out against those who would lend support, whether moral, or financial or logistical, to people who do these unIslamic things in the name of Islam? And it may not be enough to say it once; it needs to be said again and again. Which is why it s important to hire a good PR agency. No related posts.

Gnash 0.8.8 was released on the 23rd of August, a bit more than two weeks after the freeze. There are very important features in this new release that made 0.8.8 by far a better option than buggy 0.8.7 for Squeeze:

• 100% of all YouTube videos should work now. If you have problems, delete all YouTube cookies and refresh.
• Gnash can switch at runtime between the Cairo, OpenGL, and AGG renderers.
• It can also switch media handlers at runtime, between FFmpeg and GStreamer.
• Gnash can now decode video quickly on hardware compatible with the VAAPI library (a few NVidia, ATI, and Intel graphics processors). Debian packages by default do not have this feature activated until FFmpeg in Debian supports VAAPI, so that will be in Wheezy.
• It compiles faster due to reduced internal dependencies.
• It has Scriptable Plugin support so Javascript in the browser can work with ActionScript in Gnash.
• There is an improved input device handling when using a raw framebuffer.
• Lots of bugs fixed.

Today, the Release Team has unblocked 0.8.8-2, which has already reached Testing, so I m proud to announce that Squeeze will be released with latest Gnash. Thanks guys!

Most people won't need this, but for testing things like Debian bug #596009, it is very handy. A few posts on the internet say this doesn't work, or not reliably, so here is my recipe. System: VirtualBox from sid (3.2.8), and VMs created with Enable IO APIC, Enable PAE/NX, Enable VT-x/AMD-V (I have an AMD Phenom II 940), and finally Enable Nested Paging. I don't know if all these are absolutely needed, but with this config the final guest runs nicely for some quick tests. There are just a few gotchas that I stumbled upon:

• having CPU hotplug enabled will break Xen, so run vboxmanage modifyvm $VM --cpuhotplug off
• using virtio NICs softlocks the CPU as soon as any traffic is done; while this is not the default, some people might have it enabled. I've tested the Intel server NIC and it works fine
• I've seen one hang when dom0 was assigned more than one CPU, so for best results, even if the whole VirtualBox VM has more than one CPU assigned, restrict dom0 to one (either via maxcpus=1 or via xm vcpus-set 0 1)

If however dom0 hangs, you should activate the first serial port in the VirtualBox config (raw file), and then you can get at least a kernel trace. As for the pure CPU, speed, the results are interesting; I've used openssl speed rsa to do a quick test. Host (non-virtualized):

                  sign    verify    sign/s verify/s
rsa  512 bits 0.000089s 0.000009s  11176.2 116018.4
rsa 1024 bits 0.000422s 0.000024s   2370.9  41914.3
rsa 2048 bits 0.002643s 0.000075s    378.4  13255.5
rsa 4096 bits 0.017623s 0.000272s     56.7   3680.9

And domU guest (double-virtualized, that is):

                  sign    verify    sign/s verify/s slowdown
rsa  512 bits 0.000051s 0.000009s  19620.1 111644.0    3.78%
rsa 1024 bits 0.000390s 0.000026s   2561.1  38929.4    7.13%
rsa 2048 bits 0.002752s 0.000080s    363.4  12566.9    5.20%
rsa 4096 bits 0.018628s 0.000288s     53.7   3474.3    5.62%

So we have less than 10% for pure CPU work, nice. I'm not able to do I/O testing since my VirtualBox machines are using write-back cache, not write-through, so I end with this unrealistic speed:

# dd if=/dev/zero of=big-file bs=1024k count=127 oflag=direct
127+0 records in
127+0 records out
133169152 bytes (133 MB) copied, 1.21597 s, 110 MB/s

So no, this should not be used for any kind of benchmarking; but for testing and debugging issues, it's a good way to fire up a Xen box without having to change any config or risk breaking your main machine

A lot is being said on how Ruby is packaged in Debian and Ubuntu. In this post, I m trying to go through the most common myths and give my position as a Debian Ruby maintainer. Note that those are my views, not necessarily those of the other Debian Ruby maintainers. Myth: Ruby is completely outdated in Debian and Ubuntu There s a culture in the Ruby community of always using the latest bleeding-edge version. There s also a culture (though this one has recessed a bit, I think) that it s perfectly fine to change APIs in incompatible ways if it makes the software slightly better. In Debian (and Ubuntu) stable releases, we try to provide a rock-solid version of Ruby that won t be allowed to change API during the support lifetime of a release. Bugfixes for important bugs can be applied, but that s basically all. So it s not surprising that Ruby in released versions of Debian and Ubuntu is behind the latest upstream version. In development branches, we are following the latest upstream versions quite closely. Debian 6.0 squeeze , to be released by the end of the year, includes Ruby 1.8.7-p302, and will include 1.9.2-p0 (the currently of Ruby 1.9.2 in squeeze is currenty a SVN snapshot from beginning of august). There are people interested in installing a packaged Ruby that just works, and other people interested in installing their own version of Ruby (through RVM and such). People in the Ruby community tend to forget about the first category, and consider that, because they install Ruby from source or with RVM, that should be the solution for everybody. We need the Ruby community to respect that different people have different ways of using Ruby, and to stop recommending that everyone using Debian and Ubuntu should install Ruby from source. We also need to leverage the backports services for both Debian and Ubuntu to provide a way to install the latest upstream version on stable releases. The only reason why we are not doing it yet is lack of time. Myth: Ruby is split into a myriad of packages in Debian In the past (pre-2005), a decision was made to split some libraries from the standard library into separate packages. This was motivated by:

• the size of some libraries, like REXML
• the fact that some libraries, like OpenSSL, readline, gdbm and tk require other library packages to be installed
• licensing concerns about shipping some code (a .so) linked with OpenSSL, and some other code (another .so) linked with readline, in the same package.

Most of the split was undone a very long time ago, and the readline and openssl splits were undone this year. The current package in Debian squeeze has:

• ruby1.8: binaries (ruby itself, irb, rdoc)
• libruby1.8: the standard library, except ruby-tk
• libtcltk-ruby1.8: ruby-tk (merging it with libruby1.8 would add several megabytes)
• ri1.8: contains both the ri binary and documentation
• ruby1.8-dev: development headers (to build applications or gems linked against the Ruby C API), and statically built version of the library
• ruby1.8-elisp: Ruby emacs mode
• ruby1.8-examples: Examples
• libruby1.8-dbg: debug symbols

It is always possible to merge more packages, but merging any of the other packages would significantly increase the size of what you get by default, and might discourage people to use it in some contexts (disk space is not always cheap. Think embedded systems and smartphones). Myth: Rubygems is crippled in Debian There are two differences in the rubygems Debian packages. First, gems are installed in /var/lib/gems, not /usr/local/lib/gems. That is because rubygems are seen as state for the Rubygems package, not independant software installed separately. A change for this is currently being discussed, and should be done after the squeeze release. (I don t think that it s reasonable to push that change now). A consequence of installing to /var/lib/gems is that gems binary are outside of $PATH. After the change, gems binary would also be installed in /usr/local/bin. Second, gem update --sytem is disabled in the Debian package, because that would replace code from the Rubygems Debian package with code downloaded from the Internet, and can break your system in subtle ways. We have changed this (in SVN, not in any package in the archive yet) to allow gem update --system if a specific environment variable is set, which gives us the opportunity to display a warning message. Myth: Ruby is slow on Debian Ruby is built with the pthread threading code, because not using it breaks many native Ruby libraries (Ruby-gnome2, for example). And other Linux distributions are doing the same. There are some very old benchmark results floating around in some blogs that show that the pthread code has a performance impact of about 20%. There are been patches for that for a long time (applied in Ruby Enterprise Edition), but they were never properly sent back. Actually, all the discussions about this issue were rumors and blog posts, and there wasn t even a bug report about it! After the bug was reported properly, it was fixed in a timely manner. The fix is not yet included in the Ruby 1.8.7, but is being applied as a patch to the Debian package since 1.8.7.299-2. (So the Debian package is actually newer and faster than upstream Ruby in that regard). What makes Ruby so difficult to maintain in Debian? The main problems we have with Ruby are portability issues. The only officially supported platform for Ruby is IA32 (i386 in Debian), and everything else is best effort. It means that it is not even supported officially on x86_64/amd64! Debian supports a dozen of architectures, and the Ruby package has to work on each of them. Ruby 1.8 is mostly OK nowadays thanks to the help of Debian porters, but we still have serious problems with 1.9.2, since the test suite fails on sparc, hppa, ia64 and Debian GNU/kFreeBSD. Why doesn t Ruby use the alternatives system on Debian? The alternatives system provides a way to switch between different software providing the same functionality. Currently, if you want to use Ruby 1.9.2, you need to use the ruby1.9.1 executable (1.9.1 = ruby compatibility version here). The alternatives system would allow to switch ruby to ruby1.9.1 on a system-wide basis. However, the situation of applications and libraries working only with Ruby 1.8 should be clarified: those should use /usr/bin/ruby1.8 instead of /usr/bin/ruby. Another problem is that the way to specify packages dependencies still need to be determined. There s nothing impossible to do about that, it just needs someone to do the work. Where do we go from here? The Ruby developers (or expert users) community is generally very hostile towards Debian. Many harsh words and insults are used in discussions mentioning Debian in the ruby-core@ mailing list, and there are frequent recommendations to avoid the Debian packages and install from sources, which is quite demotivating (Actually, what prompted that blog post is someone calling Debian-specific changes unforgivable). This atmosphere makes it hard to recruit people, and the Debian Ruby teams are completely understaffed, which is clearly the major blocker to improving the situation further. We are 3 co-maintainers for the interpreter packages, and I m the only Debian Developer that is really active on a regular basis in the pkg-ruby-extras team (that does libraries and applications packaging). We desperately need help, but at the same time I have no time to improve our documentation and make it easier to join the team. While I haven t reached a final decision yet, I am also likely to stop doing Ruby work in Debian after squeeze is released, as I am getting increasingly tired and demotivated.

I've heard, over the years, of people spending insane amounts of money on office chairs. On the one hand I accept that you spend a lot of time sitting in chairs when you're working upon a computer. On the left I find the idea of spending 750+ on a chair a little insane. For the past few years I've had a kneeling chair over time this has gotten pretty "squished" and "flat". (Specifically the part where my knees go.) So I decided to get a new chair. What did I buy? a large rubber ball! It's a little weird to walk into the room and see this green ball in front of the keyboard, but it's actually pretty great to sit on. I'm gonna ignore all claims of "excercise" and "healthyness". Sure I find myself shifting around slightly to retain balance, but I'm not at all convinced that such small movements, even over the course of many days, will make any appreciable different to my muscles. Anyway .. That is all I have to say today. ObQuote: "Don't tell anyone we went to war over a woman. " - Mongol (2007)

I'm just back from ExoClimes 2010: Exploring the Diversity of Planetary Atmospheres. An excellent conference: the PDFs of the talks and posters are now online, and they are putting the videos of the talks up soon. But in particular the organizers deserves thanks for bringing exoplanetary scientists and observers together with climate modelers doing Earth (and Mars, Titan, Venus, ...) models. The last talk on Friday was by Peter Cox on Climate change and exoplanet sciences that was far better than expected for the "graveyard shift". One theme of the conference was the need for a 'heirarchy' of models, from simple energy-balance models to full circulation (GCM) models: using progressively more complex models to understand more bits of whats going on. Exoplanet workers mostly use simpler models, progressing now to GCMs, while Earth modellers are moving beyond GCMs to "Earth system" models including biology, etc. Peter pointed out the two styles of work: the exoplanet modelers are short of data, and risk being too speculative. We know little of what the planets are like, and concentrate on implementing physics in the models to see what they might be like. Earth modelers on the other hand are if anything swamped with data: the tendency here is to make the model fit the data, by adjusting parameters until it does so. The danger of this approach is that the model will then not work away from current present-Earth conditions. Tim Lenton pointed out some work that was done with the Met Office model, where they took the radiative transfer part of the model and tested it for other planets, and paleo-Earth conditions. The model blew up : it wasn't capable of x2 or x4 current CO2 levels. (This has since been corrected). Over dinner there were interesting discussions on the different styles within the communities. While the underlying GCMs used come from the Earth sciences, its quite common within the exoplanetary community for a researcher to work on all parts of the model: dynamics one day, radiative transfer the next. In Earth climate work people have become more specialized and someone is a 'radiative transfer' person, and won't touch other parts of the code (even if they can follow them in the huge codes we have today!). On the other hand, there is a greater tradition of model inter-comparison in Earth sciences, where we compare the model outputs to each other for some known test cases ( Held & Suarez, the CMIP5 project, etc.) Apart from some initial work by Emily Rauscher, little has been done on this in exoplanetary models; it was agreed more of this would be a good idea. Radiative transfer (the interaction of 'sunlight' with the atmosphere, where it gets absorbed, scattered and re-radiated) in particular seems to be an area that could benefit from this. In this middle ground Francois Forget showed the work on the LMDZ model and applying GCMs to terrestrial planets. They've successfully applied this model to Mars, Titan, and partially to Venus (a much tougher problem, due to its heavy clouds giving a long radiative timescale). There are problems with correctly explaining super-rotation though. This is where the atmosphere rotates faster than the planet: on Venus for example the planet rotates every 243 days, while the clouds rotate around the planet every 4 days. Sebastian Lebonnois described the possible mechanisms for Venus and Titan; Johnathan Mitchell so did some interesting work on this recently. Different regimes are involved for different rotation rates of the planet. Ralph Lorenz pointed out the lack of "real paleo-Earth" climate work at the moment. While geology has inspired a lot of work on the atmospheric composition, what with the different gas mixtures (meaning earth-model radiative transfer codes don't work) and the faster dynamics meaning super-rotation could apply (Earth's day was about 8 hours long in the Archean era), we don't have a model of the climate yet. It looks like we should treat Earth as an exoplanet. Tags astronomy, climate, exoplanets, conferences

Today I went to HantsLUG at IBM Hursley. I delivered a talk on the Debian Perl team aimed at end users, which was well received - I got a head start by getting people in #debian-perl to review the slides beforehand, which was very helpful. I'm told there will be a video uploaded in a month or so. I also plugged SmoothWall Express on Debian to some new people, and there was interest. My most recent discovery is that I probably need to extend netcfg in the debian installer to allow configuring more than one network interface.

While SSDs are all the rage nowadays (and for good reason), I don't trust them yet for my important storage, as I'm not familiar with their failure behaviour. So when one of my hard-drives recently started misbehaving, I bought the new WD Raptor model. Since some people might be interested in how it performs in some synthetic tests under Linux, here are some fio results. Now, I admit that 10K RPM for desktop is a want versus need discussion, but nevertheless, these hard-drives are (for their capacity) quite affordable, compared to SSDs, and faster than a regular 7200 RPM drive. So:

# smartctl -i /dev/ 
 
Device Model:     WDC WD6000HLHX-01JJPV0
Serial Number:    WD-WXA1C20U0627
Firmware Version: 04.05G04
User Capacity:    600,127,266,816 bytes

The older hard-drive I'm comparing to is also a WD Raptor, the WD3000GLFS model (yes, I'm a sucker for shiny hardware). A few of the SMART capabilities seems to have changed (e.g. a new Phy Event Counter has been added, CRC errors within host-to-device FIS, and the SCT Status Version is now 3 instead of 2, the Temperature History Size is now 478 instead of 128), but nothing significantly different that I can see. First, the IOPS test: nothing changed here. To be honest, even the WD3000 model had pretty good performance. The fio job definition is:

[global]
filename=$ DRIVE 
iodepth=$ IODEPTH 
bs=$ BS 
ramp_time=10
runtime=120
[rate-iops]
rw=randread
ioscheduler=noop
ioengine=libaio
direct=1

I did tests for block sizes of 512 and 4096 bytes (but the results were so close that I only used the 512 bytes ones), and at queue depths of 1, 2, 4, 8, 16 and 24 (not 32 as AFAIK the SATA protocol only allows a max queue depth of 31, and I wanted to test only the drive's queue). So: As I said, nothing really changed, but starting at 130 IOPS and reaching more than 200 IOPS at queue depth 8 (which again, is not so much used at home) is nice. Next, the bandwidth tests. This uses the standard disk-zone-profile job shipped with fio:

[global]
bs=64k
direct=1
rw=read
ioengine=libaio
iodepth=2
zonesize=256m
zoneskip=2g
write_bw_log
[disk_zoning]
filename=$ DRIVE 

Here the changes are significant. Whereas the previous generation topped at around 110MB/s, the new model tops at over 140MB/s: I'm not sure what makes the old model vary so much at the start of the test (I repeated the measurement twice, and it looks the same), but in any case, there a few conclusions to be drawn:

• the new model is fast; the logs tell me that in the first 30 entries (zones), there are 10 entries with speeds of over 150000 KB/s (147MB/s)
• even though the capacity has been doubled, the time to read the entire drive (in zones) has only increased by ~62%, which is good
• I'll need more than Gigabit Ethernet to be able saturate just one of these drives in my storage box; even at the slowest, the drive is over 90MB/s

So, I can say I'm pretty happy. The 300GB model was a tiny bit too small for me, but the new size is great, and it seems the sequential read/write speed is also good. Let's see how long they will last though, HDD failures are (unwanted) friends of mine