P. W. Singer gave an interesting TED talk about the use of robots in war [1]. He briefly covered some of the ethical and social issues related to robot soldiers as well as showing many pictures of existing robots. Since November 2007 there has been a request for Google Gears to support Iceweasel (the Debian name for Firefox due to trademark issues)[2]. Apparently supporting this different name is not easy for the Google people. If you visit the Google Gears Terms and Conditions page [3] then it will work with Iceweasel on the i386 platform - but not for AMD64 (or at least not my Debian/Lenny AMD64 system). Charles Moore gave a disturbing TED talk about the Great Pacific Garbage Patch [4]. Pollution in the oceans from waste plastic is worse than I realised. Ressuka documented how to solve the Time went backwards problem on Xen DomUs [5]. Run echo jiffies > /sys/devices/system/clocksource/clocksource0/current_clocksource or use clocksource=jiffies in your DomU kernel boot parameter list. Nassim Taleb [6] has written Ten principles for a Black Swan-proof world [7], this is in regard to the current US financial crisis. It s worth noting that he made a significant amount of money due to successfully predicting some aspects of the crisis. James Duncan Davidson has some good advice for speakers based on his experience in filming presentations [8]. Some of the ones that were not obvious to me were:
Take off your name-tag - it doesn t look good
Stay in the part of the stage with the best light

• [1] http://www.ted.com/index.php/talks/pw_singer_on_robots_of_war.html


• [2] http://code.google.com/p/gears/issues/detail?id=313


• [3] http://gears.google.com/terms.html?platform=linux


• [4] http://www.ted.com/index.php/talks/capt_charles_moore_on_the_seas_of_plastic.html


• [5] http://ressukka.net/blog/posts/20090305_XenServer_and_non_citrix_kernels/


• [6] http://en.wikipedia.org/wiki/Nassim_Taleb


• [7] http://www.fooledbyrandomness.com/tenprinciples.pdf


• [8] http://duncandavidson.com/2009/03/dear-speakers.html

Today was the season opener for Tripoli Colorado at their launch site on the buffalo ranch near Hartsel, Colorado. After huge snowfalls along the front range of the mountains in the last few days, we were a little tentative about going, but it turned out to be nearly perfect flying conditions! There was apparently much less snow this week on the high plains west of the front range, and by this morning the snow had almost entirely disappeared, the skies were clear and blue, and the winds were calm except for a few gusty bursts in the afternoon. This launch site is really something special, at 8800 feet above mean sea level, in the middle of a huge area of wide-open short grass prairie. We love flying there, and today the drive to and from the launch site through the snow-covered Colorado Rockies was just beautiful! Son Robert and I flew three rockets today, including his LOC/Precision Lil Nuke with added payload section on an Aerotech G54W-M reload, and our Polecat Aerospace 5.5 inch Goblin kit on one of the relatively new Aerotech I245G-M "Mojave Green" green-flame reloads. But by far the highlight of the day was flying my Giant Leap Vertical Assault on a Cesaroni J335 red-flame reload... with serial number 1 of TeleMetrum on board collecting our first-ever flight data! From the ground, it looked like a textbook perfect dual-deploy flight, with a small drogue chute out at apogee around 4000 feet above ground, and the main chute deploying at 700 feet above ground for a beautiful, soft landing only a couple minutes walk from the launch rail. The ejection events were controlled by a PerfectFlite MiniAlt/WD. The data recovered from it shows a big negative spike in the altitude right at apogee, coincident with firing of the apogee deployment charge. I have to assume this means the aft bulkhead on the avionics bay in the reconstructed coupler section isn't sealing well, and some pressure from the apogee deployment charge leaked in to the avionics bay "fooling" the altimeter into thinking the altitude was lower for a sample or two. Clearly, that needs to get fixed before that airframe flies again. Further evidence that we had a mighty kick from the apogee ejection charge was discovered when we went to clean the motor casing. The Cesaroni reloads are packaged in a plastic liner tube that slides into the reusable aluminum case. When we pulled the spent reload out of the case, it was significantly shorter than when it was loaded, suggesting that the ejection charge forced the forward closure on the reload backwards compressing the heat-softened plastic. This could be evidence that the reconstructed coupler was slow to separate from the booster airframe due to excessive friction? The flight data recovered from the TeleMetrum board looks great until apogee, when the data collection stopped. Since I flew firmware that was compiled and flashed on the flight line from Keith's latest git commit as of this morning, it's entirely possible that there was a software bug that caused data collection to terminate at apogee. We'll investigate that. But I personally think what actually happened is that we experienced a temporary short in the power supply at the time the apogee ejection charge fired. On extraction of the electronics sled from the avionics bay this evening, I noticed that one of the mounting screws has gone missing. If it wasn't snug enough, and vibrated loose during flight, it could have been torn loose at the time of the ejection event and shorted something as it rattled around in the avionics bay. The screw is now just missing, but may have fallen out when we were extracting data on the flight line just after the flight without being noticed at the time. So I'm not inclined to worry much about this, at least until we can get some more flight data! Keith post-processed the raw flight data and presented me with a plot showing two traces, acceleration and barometric altitude. The data from the accelerometer closely matches the published data for the motor we flew, which is a really cool result, and my 10-year-old son enjoyed figuring out why the rocket showed negative acceleration after the motor burn out but was still climbing. (See, there really is some science education hidden in the fun!) All in all, we had a great time, and it's totally cool to have data from a first flight of TeleMetrum! Can't wait to fly it again!

Since I enabled comments in this blog, I finally needed to configure a split DNS for my network. There are various reasons why one needs a split DNS and as it's usually pointed out, the reasons are usually non-technical. In my case the reasons are technical: I have a NAT in my local network that allows me to host this website locally. What causes problems is that the domain name ressukka.net points to the external IP address and that doesn't work from the inside. So split DNS it is. There are various ways of building a split DNS, one can use the views feature in bind9 or you can set up 2 separate DNS servers that provide different information (and redirect your local resolver to use the internal server). The latter is more secure if the internal zone is sensitive. I decided to use a hybrid solution. I already knew that PowerDNS Recursor was capable of serving authoritative zones (think pre-cached) so I decided to leverage on that. Setting this up turned out to be simpler than I expected. First I made a copy of the existing zone and edited it to fit my needs. I changed the IP address of ressukka.net to point to the IP address on the local network. I also adjusted some other entries that pointed to the local network. Next I modified bind to listen on the external IP address. This can be accomplished by adding a listen-on 1.2.3.4; ; to the options in the configuration. I also disabled the resolver by adding recursion no;, this forces the bind to work as authoritative only. Then I installed the PowerDNS Recursor (pdns-recursor package in debian) and configured it to listen on the internal address only (local-address=10.0.0.1) and added the pre-cached zone to the configuration with auth-zones=ressukka.net=/path/to/internal-zone Now, after restarting both daemons, I had a working split DNS with minimal configuration. I was also able to change the external DNS to authoritative only mode, which is a good idea in any case.

I've been doing consulting for a while now, and while I'd like to branch out and do some kind of product that provides a bit more stability, it's not a bad life. I have enough going that I can turn down the odd request or two if I don't feel they're a good fit, so almost all my clients are enjoyable to work with and good experiences in their own ways. However, I wanted to write a bit about one kind of client that's great to find, the "easygoing client", for lack of a better term. These are the people who may not pay the most, or provide the most interesting technical challenges, but who are simply easy to work with, and happy with what you do, and satisfied with letting you guide them in terms of technology. It's easy to develop long term relationships with these clients, because they're generally happy with what you do, and you get to know what they need, and can therefore provide them with good service at a reasonable price. Depending on the situation, you can also work together to try out new technologies, perhaps with the client receiving a discount for being something of a guinea pig. For instance, for several years, my friend Cristiano's book shop ran on a combination of Rivet and a Tcl/Tk application installed locally. When it came time to redo the site several years ago, we agreed to experiment with doing the whole thing via the web, utilizing Ruby on Rails, which I was fairly new to at the time. It worked out well for him because he got an improved system at a good price, and I got to test out something new, which has gone on to become part of my repertoire. (BTW, we just redid the site again - if you're looking for antique Italian books, it's worth a look: http://www.libreriaminerva.it/ ). It's good to have a variety of clients, and having a few 'easygoing' ones makes a nice counterpart to others where there is more money on the line, and more pressure (which is justified if they're paying well, of course) to charge in and start making a difference right away.

For some time I've suffered from the infamous clocksource problem with all Linux hosts that aren't running the Citrix provided kernels. I'm bit old fashioned and I want to run Debian provided kernels instead the Citrix ones, mostly because the Debian kernel receives security updates. During the fight with my own server last night, it finally dawned to me. The clocksource problem appears after you suspend a Linux host and the kernel in the virtual machine starts spewing this:

Mar  5 09:24:17 co kernel: [461562.007153] clocksource/0: Time went backwards: ret=f03d318c7db9 delta=-200458290723043 shadow=f03d1d566f4a offset=143675d9

I've been trying to figure out what is different with Citrix and Debian kernels, because the problem doesn't occur with the Citrix provided kernel. The final hint to solving this problem came from Debian wiki. The same issue is mentioned there, but the workaround is not something I like. I perfer making sure that the host server has the correct time and the virtual machine just follows that time. But the real clue was the clocksource line. It turns out that the Citrix kernel uses jiffies as the clocksource per default, while Debian uses the xen clocksource. It would make sense that the xen clocksource is more accurate since it's native to the hypervisor. So by just running this on the domU fixes the problem:

echo "jiffies"> /sys/devices/system/clocksource/clocksource0/current_clocksource

There is no need to decouple the clock from the host, which is exactly what I needed. To make this change permanent, you need to add clocksource=jiffies to the bootparameters of your domU kernel. You can do this by modifying grub configuration and adding clocksource=jiffies to the kopt line and running update-grub. Or you can use XenCenter and modify the virtual machine parameters and clocksource=jiffies to boot parameters. It's also worth noting that this problem does apply to plain vanilla Debian installations as well, so reading that whole wiki page is a good idea.

About a year ago I was looking for a "support system", to allow people to report issues and then allow myself and my partner to handle them. I looked at several packages and eventually decided upon roundup. (Minimal dependencies, included in Debian Stable, Simple to setup.) Over time my annoyances with this package have grown, so its definitely time to look again at the support landscape. For the moment I decided to give in to pressure and try RT. Unfortunately this was very quickly the result:

[Tue Mar 17 18:54:23 2009] [crit]: <rt-3.6.7-5189-1237316062-367.1-3-0..>
Could not send mail: Couldn't run /usr/sbin/sendmail:
  Cannot allocate memory at
    /usr/share/request-tracker3.6/lib/RT/Action/SendEmail.pm line 334.
Stack:
  [/usr/share/request-tracker3.6/lib/RT/Action/SendEmail.pm:334]
  [/usr/share/request-tracker3.6/lib/RT/Action/SendEmail.pm:288]
  [/usr/share/request-tracker3.6/lib/RT/Action/SendEmail.pm:107]

How much memory does the system have? 400Mb "real" and 256Mb "swap". I've bumpted it up to 512Mb + 376Mb respectively. Lets see how that helps. I'm reminded, once more, that in theory a support system is a small piece of software. In terms of my RT install all I did was install it, configure it such that when a new user submits a ticket they get back an autoreply with login details and can view/edit/close their own ticket via the web interface. This wiki page helped.

This is a step up from roundup which has a weird idea of security - if you allow a ticket submitter to use the UI they can see all open/closed tickets.

Anyway I'll keep testing it for a couple of days and if the memory helps then I guess its a small price to pay but .. ugh. Maybe the home made solution is the more practical solution.. ObFilm: Leon

I finally decided that it's time for me to upgrade my Xen installation. It used to run etch with backported Xen, because the etch version was increasingly difficult to work with. I also acknowledge that some of the issues I've been having are simply caused by yours truly, but even still the Debian Xen installation is way too fragile to my taste. I've already considered installing XenServer Express locally and running the hosts on it. The big drawback has been that XenCenter (the tool that is used to manage XenServer) is windows only and it doesn't work with wine. So you can imagine my desperation... Anyway, the latest upgrade from etch to lenny was painful as usual. The first part went smoothly, bit of sed magic on sources.list and a few upgrade commands (carefully picking the Xen packages out of the upgrade set). So in the end I had a working lenny installation with backported Xen. Next I made sure that there was nothing major going on in my network (one of the virtual machines acts as my local firewall) and took a deep breath before upgrading the rest of the packages. I knew to be careful about xendomains -script which has reliably restored my virtual machines after reboot to a broken host so I had always ended up restarting my virtual machines after reboot. I carefully cleared XENDOMAINS_AUTO and set XENDOMAINS_RESTORE to false in /etc/default/xendomains so that the virtual machines would be saved but not restored or restarted on reboot. After the normal pre-boot checks I went for it. Oddly enough everything worked normally and the system came up after a bit of waiting. I checked the bridges and everything appeared normal, so it was time to try and restore a single domain to see that everything actually did work as planned.

Hydrogen:~# xm restore /var/lib/xen/save/Aluminium
Error: Device 0 (vif) could not be connected. Hotplug scripts not working.

Oof, Googling for the issue revealed that there were others that had suffered from the same problem on various different platforms the problems were caused by different things. One would assume that the problem is in the vif-bridge script that is mentioned in the xend-config.sxp file as the script that brings up the vif, but after many hours of tial and error and pointless googling (over gprs connection), I couldn't find any solution to the problem. It was time to call it a day (it was almost 3 am already...) During the night I had a new idea about the possible cause. What if the problem isn't in xend, but somewhere else. I fired up udevadm monitor to see what udev saw and it wasn't much. I'm not an expert with udev, but from previous encounters I had a vague feeling that there was supposed to be more events flying around. I wasn't able to pinpoint what was wrong so I decided to purge xen-utils, of which I had 2 versions installed: 3.2-1 and 3.0.2. I also removed everything related to xenstore. After reinstalling the current versions and restoring my configuration files the first host came up just fine. I still had problems resuming the virtual machines and I ended up rebooting them again, which was nothing new, but at least they were running again. In the end I don't know what was the actual cause for udev not handling the devices properly, but I'm happy to have them all running again. And I learned a valuable lesson of all this: udev is an important part of Xen, make sure it works properly.

I was very pleased to wake up this morning to the news that National has delayed the introduction of S92A via an order-in-council. It s a nice short-term victory, but I ll save the champagne until the law is fundamentally rewritten. The most pleasing aspect of the decision is simply that it was made at all. Within two weeks, a small band of protesters were able to harness the power of the Internet to direct international attention and place enough pressure on a Government, whose Prime Minister admitted to not having read the bill prior, that he then took the time to understand the issues and personally announce the delay in implementation of the law. We owe much thanks to the Creative Freedom Foundation for all the effort they put into co-ordinating the protest and ensuring that a single coherent message was presented. Just a little bit of my cynicism and belief that politicians never listen to public opinion outside of election campaigns was chipped away today. The reason I m not breaking out the champagne yet is that we ve only achieved a temporary reprieve in the commencement of the law. While those present at the press conference seem somewhat confident that John Key didn t like what he found in the law and would have repealed it if given the chance, all that has actually been done is delay it in the hopes of an agreement between the TCF and the rights holders (aka big media companies) on how to implement the still fundamentally broken law. The Government has given until late March for that to occur. To put this into a more global context. My happiness as I took the bus to work after reading about the decision to delay the law was short lived as the front page of the local paper declared that Eircom (Ireland s equivalent of Telecom) has voluntarily agreed to block sites such as The Pirate Bay upon request by the media companies (this comes a week after they also announced an agreement to, again voluntarily , implement a 3-strikes S92A style policy). Now, with the biggest ISP in their pocket (so to speak), the media companies have sent threatening letters to the remaining ISPs in the country demanding they implement the same procedure. To me, this illustrates one of the fundamental problems with S92. The concept that an ISP is liable for the conduct of its users, or for policing where on the Internet users should and shouldn t be able to connect to does not belong in our laws. Most ISPs already have provision to disconnect customers for illegal activity in their terms and conditions. If an end-user is doing something illegal, that is an issue between the rights holder and the end-user to take up in the courts just like every other sector of society must do when wronged, at which point the existing ISP terms and conditions can be invoked and access terminated. The big media companies, having decided that it is too expensive/hard/inconvenient to follow standard legal procedures to resolve their grievances are launching multi-pronged attacks to shift the playing field in their favour. In countries like New Zealand, where our politicians yearn for a Free Trade Agreement with America, they use their lobbyists to ensure that S92 style laws are part of the conditions. In other jurisdictions, like Ireland, they use strong-arm, divide and conquer style bully tactics outside of the political and legal process. I don t support copyright infringement. I rely on copyright to protect much of the work I place on the Internet, I want strong laws that protect me when my rights have been infringed. I don t believe that such laws should come at the expense of due process, our legal tradition and the basic principle of fairness! I don t believe that copyright infringement is such a heinous crime that it demands punishments stronger than those we deliver to paedophiles, stalkers or any other class of criminal who uses the Internet to enable their crimes. To me, today s (yesterday s - depending on your timezone) decision is only the first step in clawing New Zealand back from the dangerous path that the big media companies have been leading our law makers down. From here we need to press on and demonstrate to the Government over the next month that even if the TCF and rights holders are able to come up with some sort of workable code of practice, the law is still fundamentally flawed. It is based on premise that we are guilty by accusation. Even if guilt were to be proved by a competent legal body (eg. court or copyright tribunal) we don t need laws placing further liabilites onto ISPs (and remember the definition of ISP under this amendment act includes businesses who provide Internet access to staff, libraries, schools and hospitals) when their existing terms and conditions already prohibit illegal activity. Finally, and most importantly of all, we need to remember that laws exist to serve all sectors of society. Yes, copyright infringement is against the law and rights holders are reasonable in expecting the law to protect their content and allow them to make a fair profit. On the other side of the fence, average New Zealanders are not being unreasonable in their desire to have media available electronically, on demand and non-inhibited by DRM following a legal purchase. The failure of the media businesses to adequately cater to this change in market demand and usage of technology is obviously a contributing factor to the widespread copyright problems that they are facing today. Obviously, I m not condoning copyright infringement simply because the media companies are failing to address demand. Even stupid laws must be obeyed (and the concept of copyright is far from stupid). What I want to see is the Government acknowledging that the problem is not solely with consumers infringing copyright for malicious purposes, and therefore that the solutions do not lie solely in increasing the enforcement and punishments available. Copyright has always been a balancing act between the rights of content producers and consumers. S92 and the act it is contained within are taking us far too far down the road of catering to big business and their outdated business models with far too little concern for the rights of the individual consumer. Despite the many submissions made on this act last year when it was first passing through parliament, there was no comprehensive debate on what copyright means and how it should balance the rights of content producers and consumers in our digital century where copying is a zero-cost, zero-thought activity. Without such a debate we re doomed to continue wasting time arguing over the symptoms of the problem, like S92. So, I m saving my champagne for the day when we as a country address these issues and come up with a fair and workable interpretation of what copyright means today.

If you re reading this post via the website rather than a feed/planet then you will notice that the site has gone completely black in support of the Creative Freedom Foundation s campaign against S92A of the NZ Copyright Amendment Act which is due to come into effect on 28th February 2009. I ve also joined the wave of people blacking out their avatar on Facebook/Jabber/MSN, etc. S92A introduces Guilt Upon Accusation whereby if you are accused of copyright infringement (downloading music and movies, etc) repeatedly (likely 3 or more times) you are at risk of being disconnected from the Internet by your ISP. The law does not require any proof or substantiation of the accusations and the entire process would occur outside of the courts and the established legal system. Not only does it place every user at risk, the wording is very unclear on exactly what type of organisation is considered an ISP and there is significant concern that schools, businesses, libraries and hospitals will be placed in the difficult position of determining whether their users have broken the law and require disconnection. Opposition to the law is not an attack on copyright, or a statement that we should be free to download all the movies and music that we desire. Those sorts of activities are clearly wrong, and I don t have any issue with copyright holders wanting to enforce their rights when their content is illegally copied. However, disconnecting people upon accusation, with no proof or formal legal process to prove guilt is not the right way to go about it. The fact that the law does not require proof of guilt is only the tip of the iceberg in terms of problems with it. For further background on the problems it causes for ISPs by placing them as the middle-man in copyright disputes you should refer to the following posts:

• Russel Brown of Public Address, points out that among other faults the law stipulates a penalty that no court would impose in adjudicating a copyright complaint
• David Farrar of Kiwiblog, has a guest post at the NZ Center for Political Research explaining how the law affects businesses
• Creative Freedom Foundation Background on S92

Finally, I think it is worth pointing out that S92A was removed from the proposed Amendment at the select committee stage, but was later reintroduced by Judith Tizard during the final reading of the bill. Mark Harris has an excellent post on the history of the amendment which includes facts such as the official report on the amendment also recommended removing S92A as it was unecessary given existing ISP terms and conditions which forbid illegal activity. The fact that the select committee (based on public submissions) recognised the problems with S92A and removed it, only to have it added back in again at the last stage when we no longer had any say on it really hacks me off and I cant help but feel the influence of the big money American media companies pressuring our politicians to pass a law that they don t really understand the full consequences of. So what is to be done? The Blacked Out campaign, being run by the Creative Freedom Foundation is gathering steam and international attention. Peter Dunne of United Future (who originally voted for the amendment) has declared that the amendment is wrong, and doesn t do what they thought they were voting to do, we need to convince National and the rest of the house of the same. Time is running out for this to happen before the amendment comes into effect on Feb 28th, but there is still time to write to your local MP and sign the petition against S92A Guilt Upon Accusation . The Creative Freedom Foundation site has a nice easy list of what you can do to register your protest.

As an obligatory note, Debian Lenny was released earlier today. Which means that sysadmins all over the world are starting to upgrade their servers. There is an oddly little known tool that each and every sysadmin should install on at least one server they maintain, called apt-listchanges. It lists changes made to packages since the currently installed version. Sure that information will be overwhelming on major upgrades, but what is useful even on major upgrades is the capability to parse News files in the same way. News files contain important information about the package in question. For example a maintainer could list known upgrade problems there, like is done in the lighttpd package. Or list changes in package specific default behaviour, like is done in Vim package. Sure, you will notice these in time, but it's nice to get a heads up before a problem bites you.

I've been bitten by grub upgrades and installations on Debian family domU servers. Apparently there are others out there who have been bitten too. The bug itself is caused by a missing device entry, probably because of udev. Anyway, grub-probe tries to discover the root device so that update-grub can properly generate a menu.lst. In certain scenarios the root device itself doesn't exist. Here is an example from a configuration generated with xen-tools:

Hydrogen:/etc/xen# grep phy Neon.cfg 
disk    = [ 'phy:Local1/Neon-disk,sda1,w', 'phy:Local1/Neon-swap,sda2,w' ]

While this is a valid configuration, the device sda doesn't exists within the virtual machine. As a workaround the above blog entry suggests manually adding the sda device and the device entry in device.map. This solution does work, but it will fail with the next upgrade. The proper solution is to adjust the Xen configuration so that the root device is created. And since Xen uses different naming scheme for devices we can upgrade to that too. So the above example becomes:

Hydrogen:/etc/xen# grep phy Neon.cfg 
disk    = [ 'phy:Local1/Neon-disk,xvda,w', 'phy:Local1/Neon-swap,xvdb,w' ]

You also need to adjust the existing grub configuration and fstab within the domU. It's a bit more work and requires an additional reboot, but it gives you a peace of mind that the next upgrade will work without a hitch.

Since I keep ending up in situations where I need to clean up postfix queue from mails sent by a single host and always forget the command, I'm posting it here. Maybe someone else will find it useful as well. To begin with, you need to determine the IP address of the culprit you want to eliminate. How you do this, is up to you. Grepping logs or examining the files in the queue both work. But for some reason there doesn't appear to be a good tool to get statistics on the sending IP addresses, only the origin and destination domains. Once you have determined the IP address which you want to purge, you can use the following spell. You might have to repeat the same line for active and incoming queues as well, but usually deferred is the queue I have the most mails. grep -lrE '[^0-9]10.20.30.4[^0-9]' /var/spool/postfix/deferred xargs -r -n1 basename postsuper -d - It's important that the IP address has escaped dots, because dots can account for any character. In the worst case it will end up matching a lot of wrong IP addresses. Another important bits are the '[^0-9]' groups in both ends of the pattern. Those make the IP address only match that particular IP address. Without that extra limitation 1.1.1.1 would match anything that has 1 as the last number in the first octet and 1 as the first number of the last octet. For example: 211.1.1.154 would be a valid match. The other important bit, yet oddly unknown, is the postsuper command. Postsuper modifies the queue and -d flag makes it delete files in the queue by QueueID. For some reason I keep on seeing all sorts of find -exec rm spells all over, which isn't really that nice for the daemon itself. So here it is, one more tidbit I've been meaning to write up for quite some time now. Enjoy!

"You never call, you never write. I hardly know you anymore." Yes, I've been meaning to write up on several things. For some time now, I've been a happy VIM user and a while back I ran in to a blog post where someone mentioned a new feature they found in VIM which got me to explore the vim-scripts package. There are a lot of scripts out there that extend VIM far beyond what it can do by default. And it's quite powerful even without the scripts. One of the neat little scripts I decided to install by default was surround, it allows one to easily replace surrounding parenthesis, tags or quotation marks. There are a lot of scripts in the vim-scripts package, but it's not always clear how to enable the scripts. Thats where vim-addon-manager comes to play, it provides a vim-addon command that allows you to easily enable or disable the scripts. I'm still trying to grasp the full potential of all the new commands available, but it certainly appears that I'll be having even more fun writing stuff. It's kind of odd, at first when you start to use vi-like editors, you struggle. But in the end it's just such a convenient way of editing files that it really does grow on you.

Sami Haahtinen wrote a nice post about usability. I do mostly agree with him, except for one little thing: A few years back, I noticed that I often started as a kind of Joe User with new applications, and often even stayed that way, often wishing that the UI of that application was simpler or at least made it more obvious which options are important and which I could most likely keep at their defaults.
Yet I am a system administrator and programmer/developer, so most people would probably consider me as an advanced user by default (wether that is correct in any given context or not, for example I still don t really grok GIMP).
Also I did have quite a lot of contact with users that have very little experience, knowledge and interest in computers and software and only use them to achive certain goals. Anyway, I m quite sure most readers of this blog are aware that Linus Torvalds once complained about the Gnome printing dialog being simplified way too much. And at that time, I had to agree (note that I didn t check out Gnome again since those days, at least 2 years ago). What I really wonder (especially since I realized this in some of my own applications) is why it is so hard for developers to add some additional checkbox or button that enables/disables advanced options. For example, let s take an applications printing dialog. By default, it would only allow the selection of a printer, orientation (if sensible) and (if the selected printer supports more than one) the paper size. Now advanced options might include duplex printing (automatic or manual), printing mutliple pages on a single sheet of paper, printing in grey on color printers, These options might be of use to anyone, but would most likely confuse beginners. So what I did in most of my little application was to just show the basic options and add an advanced options button which provided access to additional functionality which was not normally needed. As for the issue with firefox updates mentioned by Sami: I don t think it is a problem that firefox asks what to do with extensions. For one, it only lists extensions which are installed but claim not to support the new version of firefox. Second, practically everyone I know of who uses any extension can be considered to be an advanced user. And third: The dialog is pretty straightforward about what it is asking and when I once hit it while a ( dumb user ) friend was sitting with me, he understood what it was about quite easily (I didn t explain the dialog, just what extensions were). So my idea of a good UI is:
As simple as possible for beginning users, but allow advanced users to get to the details ( Details or Advanced options buttons/checkboxes/dialogs).

Some people consider the gnome usability guidelines a nuisance and some consider certain applications way too simplistic. While it is really hard to get the usability right, it's well worth it. We need to keep in mind that as computer oriented people we tend to see things differently. Things that are simple to us aren't really that simple to the "normal people". But one of the simple things we can do the insure that the software we write serve the people it's designed for is to remove all not needed pop-ups and questions. A good way to detect these would be to ask yourself why would a user choose anything else but the most logical option. It's kind of hard to explain, so lets pick an example: Firefox is updated, the first question it usually asks after upgrade is about incompatible extensions. The user is presented with choices, check for updates or cancel. Now, we are dealing with internet browser so the user should be connected to the internet so there is no problem with checking for the updates, we can rule out that scenario. The other scenario that I can come up with is that a developer doesn't want to update some certain extension. So at least I can't come up with any reasonable scenario why someone would want to select anything else but to upgrade the main option of upgrading the extensions. Why not just leave out the option and instead do the upgrade automatically. If you wish to be transparent, you can show the user that you are doing the upgrade. Or you can do like some applications do and just do it without bothering the user with the options. I know I sound like a Google fanboy, but Google generally gets this right. Their applications skip out all upgrade related notices and just do the upgrade. Regular user doesn't want to upgrade because the user has been scared with incompatibility notices and upgrade checklists for so long. Just going ahead with the upgrade in complete silence keeps their software up to date as well. Another example would be from few years back: The Ubuntu installation. Back in the day Debian was working on Debian Installer, which is also used as the main installer in Ubuntu alternative installation media. Debian Installer is capable of doing most things silently, but with Debian it by default asks a lot of questions. It doesn't matter, since most people who install Debian can be categorized as developers. But in my opinion, the thing that made Ubuntu a success was that it doesn't ask the questions that can be answered without asking the user. So, back to usability. There are basically 2 camps, the "normal" users and the developers. Developers want and need to see a lot of the backend behaviour, just to debug problems. Currently a lot of the open source software is focused towards developers while they are gaining grounds on the "normal" population as well. We should start focusing on the users for a change.

David, I m not saying it lightly: the end goal is censorship, no matter how nicely you try to put it. The goal is to discourage people from posting. They call it peer pressure , which is nothing else but the politically correct equivalent expression for intimidation . The end result is censorship. The idea of censoring the mailing lists has actually been mentioned very clearly in the recent discussions on -devel, and I never thought it would go past that, but it s actually happening. By the way, this could actually morph into a shitty karma system that wouldn t let you post past your monthly allowance and credit earned . How s that for you? You refer to those +1/-1 mails; I find them silly, annoying, useless and a waste of bandwidth and CPU time. That used to be called a me too and generally despised and frowned upon. If you actually want to score posts or posters, get a decent MUA and set up its scoring system the way you like. But keep that to yourself. As Aigars told, there are mail to web forum gateways (more like rendering engines for a mail archive, actually) that will present mails to a list in a crappy web forum of some sort that will come with all kind of crap like scoring, karma and whatever. There s an essential difference between web forums and our mailing lists, though: forums of this kind use nicknames all over the place, our mailing lists use real names. There are privacy issues involved, and I m not giving up on that, either. You want to stop flamewars? Stop replying, especially to tell how intolerable it is and other shit. Just let the damn thing die already. Funny how the well-meaning people are feeling harassed on the mailing lists when they, themselves, are harassing people they disagree with. We don t all have the same views, culture etc. We re not all friends, and we probably never will be. Guess what? It s OK! Get over it and work with each other, because that is what we are here for. If you (general) can t get over it, I m afraid this Project is not the appropriate place for you. Imposing a monoculture of politically correct crap is not an answer to the perceived problems .

Speaking of the tactile and the tactical, after seeking some input, I settled on this keyboard a few months ago and I simply love it so much so, today I got another one for my office. I love the key strokes simply cuz they have just the right feel. It takes some, but not too much, pressure to type and it feels great on my finger tips. The fancy blue lighting is a plus but not a central feature. The overview/description on their website is pretty dramatic but I tend to agree it provides for some pretty hefty power, allowing me to launch my email assaults with perfection :

With an awesome host of features, the Razer Lycosa is on an unstoppable mission to destroy and dominate. Execute complex combat maneuvers with swift dexterity. Launch your assaults timed to perfection. Annihilate your enemies and reign supreme on the battlefield. You now have the tactical advantage on every terrain, and your enemies fates are in your hands.
<

I dare say I am fully content with the keyboard but I am still searching, however, for the perfect pen

That is the sledgehammer argument people bring up when others dare to criticize the current release process. I think this question is nonsense. While the bug-fix rate was more or less the same since the last two releases, it looks like in this release we simply started the freeze with much more open RC-bugs than before (~3 times more RC-bugs than with Etch). So it was foreseeable that the freeze would take longer this time. We can t solve the problem by trying to fix bugs faster, we ve tried it several times with mediocre success. That doesn t mean we shouldn t keep up fixing bugs, but we should probably accept that a certain number of people can only fix a certain number of bugs in a given time. In our case roughly 30 RC-bugs per month. So what s the point of asking how many RC-bugs one has fixed? Does that mean only those are allowed to make suggestions, who fixed an RC bug? That pressure doesn t help anyone. I believe unstable being frozen for several months is a very important problem which can have drastic consequences regarding the number of our users, and we will not solve it by suggesting to fix our bugs faster.

Travelling rather a lot this year has left me spending plenty of time staring at showers[1]. There seem to be three broad categories of shower UI design. The first is the one that exposes the raw functionality of the underlying implementation:

(image by bean, reused under cc-by-nc 2.0)
Showers work by mixing hot and cold water and feeding them through a shower head. This implementation allows direct control of the hot and cold feeds. The user can obtain any combination of pressure and temperature that the supply contraints make possible, but at the cost of it being impossible to adjust single variables. Changing the pressure without changing the temperature is difficult. One of the most common alternatives I've seen this year is the following:

(image by anearthling, reused under cc-by-nc-sa 2.0)
Here, power and temperature are unified into a single control. The major problem with this design is that it's generally impossible to have any pressure setting other than full on. The benefit is that the temperature can be altered without any significant concern over the pressure. Simplification through limiting functionality. Finally, we have setups like:

(image by stevec77, reused under cc-by-nc 2.0)
Though not clearly shown, this interface separates temperature and pressure into independent functions. The number of UI elements is identical to the original "hot/cold" case, but the user is now able to set temperature and pressure independently without having to worry about the interaction between the two. This is obviously more effort to implement but improves usability, decreases complexity and doesn't clutter the interface.

So, if this is a solved problem, why do I keep coming across implementations that suck?

YES THIS IS A METAPHOR FOR SOFTWARE DESIGN

[1] Often in a certain degree of confusion, but that's not really the point here