A few years ago, Terah and I got to visit the beautifully-restored Kansas City Union Station. What a sight. A train station designed to hold 200,000 people, and saw over 200 trains pass through in its heyday. So many people had stories of traveling through Union Station, of arranging to meet someone under the station's iconic giant clock. Maybe they were meeting a husband or wife back from a long trip or fighting in a war, or maybe they were meeting a relative they hadn't seen for years. Walking through Union Station one quiet evening, you can almost hear all the activity still there. Taking the train there, walking in through Amtrak's small boarding area, then stepping out into the dazzling expanse of the station is quite the experience too. It wasn't just a static relic; it was a true piece of history that we can feel.

Decades ago, one of the busiest airports in the country was in Wichita, Kansas. At its peak, the Wichita Municipal Airport saw a flight land or take off every 90 seconds. Its beautiful art deco terminal saw off many an excited traveler. From the Wichita Municipal Airport, you could see buildings owned by Boeing, could drive a minute or two and see Cessna, and other major aircraft manufacturers were also in Wichita. The airport saw many cutting-edge flights, perhaps thanks in part to this. Movie stars were known to fly through Wichita frequently. And Wichita was part of one of the first cross-country air travel routes, New York to Los Angeles, which then took "only" 48 hours. Due to lack of radios and lighted runways, people would fly during the day and ride onboard a train at night to minimize travel time.

Due to an incredible fluke of history, the Wichita Municipal Airport terminal building and control tower still stand. I've never been in an airport that still feels like the 1940s. Other great airports of the era have continued to expand, grow, and generally be replaced as demands for jet service rendered them obsolete and unusable for air service.

You can walk into the building and stand on the main floor lobby (see photos) where people once waited to catch their flight. You can walk down the single departure gate to the tarmac. Obviously we were witnessing a different era -- one in which planes carried only a few passengers each, not the hundreds that they carry today. Three to five planes would line up, and you would simply walk to yours and walk on up and into it. The control tower, a new addition in 1941, still has the high-powered red and green lights that were used to signal airplanes in the days before radio contact was common. The outside of the building has been beautifully restored, but the interior needs a lot of help (and funding) yet. You can still see some areas where the original decorative paintings and tile work survive, but all too many areas have been stripped to the concrete. Outdoors, you can find everything from one of the few surviving B-29s, to some of the earliest small airplanes, to a FedEx jet transport and other quite large planes.

Up in the control tower, they have a radio tuned to air traffic control frequencies. You can hear aircraft being routed to various Wichita airports. On the counter sit several photo albums. As you look down on the ground where historic airplanes sit, you see photos of airplanes lined up, ready to receive passengers. In this building, too, you can really feel the history.

Volunteers were all over. They were all eager to share about the building, the planes, everything they knew. One of the people working on the restoration of the B-29 saw us approaching, and excitedly asked, "Would you like a tour?" Of course!

Though you don't really see 1940s airports anymore, this situation was unique. In 1951, the United States Air Force announced plans to seize the airport and use it to establish an air force base in Wichita. They intended to do so within three weeks. Due to much legal wrangling, including a landmark court case in which the Air Force was forced to honor a contract it had signed with the City of Wichita, the Air Force couldn't quite kick everyone out until 1954, when a new airport in Wichita was completed.

Between 1954 and 1984, the building was an office used by the Air Force. It was abandoned between 1984 and 1991, when the City of Wichita purchased it for use as a museum.

Despite years of neglect, it still stands as a grand old airport. Standing in the airport today, you can see the sign for the Boeing Co. off in the distance, the runways in the other direction, and excited people scurrying about. In a way, it's the same scene that you would have seen 60 years ago -- though nobody was wearing a suit.

GMsoft reported a few weeks ago, that kernels on his A500 were hanging on startup with CONFIG_PRINTK_TIME enabled. Knowing that all this does is prefix the kernel messages with a timestamp, I was interested to find out how this could possibly be causing a hard hang. Obviously, the first thing to do, is to try and reproduce the problem. But I was completely unable to reproduce it on my RP3440… How very strange. Ok, well, let’s poke at the A500 and see if it will happen there. It does! Spooky…[1] Well, now I was really interested. Let’s see what CONFIG_PRINTK_TIME actually does… In kernel/printk.c::vprintk, around the if (printk_time) section, we see that after printing the priority level tag, such as KERN_INFO, etc., we attempt to print a timestamp obtained with cpu_clock. The returned value from cpu_clock is in nanoseconds, so before it’s printed, it is munged into two smaller integers, the whole-seconds portion, and the decimal portion. Ok, this gives us a great place to start looking for ways PA-RISC could be tripping up on these codepaths. The first was a fairly fruitless search of the cpu_clock call chain, which turned up nothing suspicious, aside from a maze of CONFIG_ options. Turned out, on non-x86, this code reduced into some fairly trivial stuff, none of which could really have been causing a hang. However, we now had a basis for a fairly good hunch. If it wasn’t the cpu_clock going awry, the do_div routine, or sprintf must have been causing it. A quick boot-test to comment out the do_div routine and replace it will a fixed value resulted in a working system. Hooray. Then it hit me like a freight train, when I saw what was being printed. This was the banner line… the very first thing printed in init/main.c, right after jumping into the kernel in virtual mode at start_kernel.
Linux version 2.6.27-rc5-00283-g70bb089 (kyle@shortfin) (gcc version 4.3.1 (GCC) ) #2 SMP Sat Sep 6 19:45:05 PDT 2008
FP[0] enabled: Rev 1 Model 20
The 64-bit Kernel has started…
console [ttyB0] enabled
Initialized PDC Console for debugging.
Seeing the “FP[0] enabled” line immediately caused me to smack my head at the obviousness of the problem. We were attempting to do a division, which, because of how the kernel and libgcc are compiled, is attempting to use the fpu. However, this is faulting on the very first printk in the kernel, well before any of the architecture-specific initialization is done. A quick hack removing any printks before we initialized the fpu fixed the problem as well. But, dirty hacks are not appropriate for mainline. I thought long and hard about a nice way to fix this, but, really, open coding firmware calls in assembly didn’t strike my fancy. There is, however, another easy way to solve it. I ended up replacing the jump to start_kernel in head.S with my own function to turn on the fpu, and called start_kernel from there. Kind of ugly, but at least the fix is entirely contained to arch/parisc, instead of leaking all over the tree. The patch is available, but I’ve been too busy to push it this last release-cycle (and, didn’t really want to tempt fate at pushing a not-quite-actually-serious-fix outside of -rc1 time.) This has been another post brought to you by the maintainer of an inconsequential architecture. We do hope you enjoy it. 1. This ended up being due to either 1) the fpu being enabled by firmware on the PA8800, or 2) the fact that I was doing warm resets instead of cold starts.

Two reasons:

1. 'foo FTBFS on m68k' is not RC. 'foo FTBFS on m68k because it segfaults during the build since it does bar and baz, which just happens to result in a segfault on m68k at startup but might randomly result in a segfault on every architecture, really' in most cases is.
2. It, well, is just fun to debug someone else's code. On m68k, it's easy to do that, too, if you know a bit of assembly language.

Today's (and last week's) bug: #497262. Xemacs21 segfaults at startup on m68k (and FTBFSes because of that), which is RC for m68k. Reason: confusion between a pointer and its value. In other words: the sanity check might succeed, or it might not, depending on your luck. In fact, the first time the code flows through this buggy path, it does not bomb. Once we do get through this bit, it's also very likely that regular error handling will catch it—the only reason why xemacs segfaults here is because we're still in initialization, and the error object in the lisp stuff hasn't been initialized yet, so we get a nice null pointer dereference... That alone isn't enough to make it RC everywhere, but it's good enough to make it important and fixable for the maintainer. Like I said, fun. Sorry for those of you who want to release Lenny ASAP, but I think I'll be making your life a bit harder :-> Next week's bug: a similar issue in emacs, or the build failure of ghc6 on m68k, depending on time and complexity.

Since some time ago I was pointed out by somebody that my feed's urls provided by planet.d.o were giving 404's.
Today I was again notified about that issue and finally decided to investigate what was going one.

---

This time it was Lisandro P rez Meyer (those who attended DC8 might remember him) who notified me, so first thing I asked was the link he was using to open my blog post, and to my surprise it was:
http://my.op era.com/atomo64/blog/2537614

Which of course throws a 404 as it is not a valid link. Next question was where he was obtaining that link from, and it was then when I found the culprint: Google Reader

A quick execution of curl and grep demonstrates how dumb Google Reader is:

$ curl -s http://my.opera.com/atomo64/xml/atom/blog/ grep 'http://my.opera.com/atomo64/blog/2537614'
<id>http://my.opera.com/atomo64/blog/2537614</id>

Anyone familiar with the Atom 1.0 specs will quickly notice how wrong Google Reader is by assuming that the id is an URL. The specs (text html) state:

The "atom:id" element conveys a permanent, universally unique identifier for an entry or feed.
...
Its content MUST be an IRI, as defined by [RFC3987]. Note that the definition of "IRI" excludes relative references. Though the IRI might use a dereferencable scheme, Atom Processors MUST NOT assume it can be dereferenced.

Note that it refers to just an identifier (an IRI, actually), not to a URL.

It leaves me one question: why does it do that?!
I mean, the specs define the atom:link element as a "a reference from an entry or feed to a Web resource", what makes Google Reader believe that an identifier is better than a reference to a Web resource? :rolleyes:

Continuing from yesterday's post, I beutified the script's code and made it able to take multiple files as input, and added support for Sources files. Additionally, I've added it to my misc-devscripts repository and pushed it.

---

So, the list of packages with most build (+ indep) dependencies for sid as of today:

openoffice.org:107 (no surprise)
jifty:107
vlc:72
gcj-4.3:59
xorg-server:59
gcc-snapshot:59
gcj-4.2:57
debian-installer:57
control-center:54
evolution:52
wine:51
mplayer:51
gnome-applets:51
totem:51
gpc-4.1:49
php5:48
gcc-4.3:48
gcc-4.1:46
gnat-4.1:46
libcatalyst-modules-perl:46

For those interested in the script, it can be downloaded from:

http://git.debian.org/?p=users/atomo64-guest/misc-devscripts.git;a=blob_plain;f=countPkgsDeps.pl;hb=HEAD

or the whole git repo can be cloned from: git://git.debian.org/git/users/atomo64-guest/misc-devscripts.git

Xen-Hosting

Two years ago I started running the xen-hosting.org setup, offering Xen hosting for 7 people for a reasonable price. (Basically to subsidise my own desire to have a big guest and not pay too much for it) At that time I was charging £11.50 for a Xen guest with 256Mb of memory and 10Gb of disk space. Each year since then we've managed to increase the spec. For the same price. Two years on this means I'm now hosting 7 Xen guests with 1Gb of memory, and 40Gb of disk space, for that same price of £11.50 a month. Nice to see how things can improve as time goes on :) In other news - It is just past our two year anniversary.

DNS Blacklist

Thanks to the people who said nice things about the DNS blacklist I setup the other day. I suffered a couple of DNS-problems earlier in the day, but things should be back up and running for good now. I hope. The ultimate cause was using ":" not "&" records with tinydns. Sigh.

ObFilm: Teenwolf

Do you know this experience: A program, in my case subversion, has a bug and starts to eat memory. You can not interact with your system any more, only watch the memory and swap run full (if you have a display for that). Then it takes a while, while the kernel kills the (hopefully right) program. Things start to move again, until they are fully recovered from the swap and you can continue your work. Or the kernel does somehow not kill the right program, and you are screwed.During regular work, though, your swap is hardy ever needed. Only after a while, a few megabytes of never-used RAM is swapped out, to make space for using the RAM as a file cache.I d like to see the kernel not give out more memory to processes than there is physical memory, because that s plenty for normal work, and if there is more requested, then that s most likely wrong. But I still want the kernel to use the rest of the memory for caching files, and also move some unused RAM pages to the swap file.Unfortunately, there does not seem to be a settings that achieves this directly. But if you happen to have the swap about the same size as your RAM, then these settings, when written to /etc/sysctl.d/vm.conf, will do the job:

vm.overcommit_memory = 2
vm.overcommit_ratio = 0

The first one is to make sure the kernel does not hand out more memory than you tell it to, and the second is to make sure that it only hands out (swap size + 0 * RAM size) to processes.Beware that things go wrong if you happen to have no swap any more for some reason, beause then the kernel will hand out zero memory! Therefore, you need to make sure that these settings are applied after swap was enabled. On a Debian machine, rename /etc/rcS.d/S30procps to /etc/rcS.d/S37procps. This would not be possible if you could also specify the ration of swap memory to be used. Then I could set that to zero and the RAM ratio to 100.If anyone knows better ways to achieve this, I m interested to hear them.Update: For my qemu based armel package builder, this is not enough it seems. I m now running it with overcommit_ratio = 50.

I found this here: http://www.predictablyirrational.com/?p=291 It's particularly entertaining for me, as I started my programming career at an ad agency.
http://view.break.com/542649 - Watch more free videos

While some people think that Googles new open source webbrowser Chrome is a great example of code reuse I think the opposite is true. He found at least 25 open source libraries used by the browser. So far this is not a problem but what is a problem is that it embeds all of them in the upstream source tarball instead of depending on the system-wide copies. I know that it might be problematic if people have to install 25 libraries on their own (they could provide static builds though) but for distributors this is just a nightmare if security issues pop-up in one of the used libraries (famous libraries who had issues in the past: webkit, libpng, libjpeg, libxml, ...).

In this case the distributors can't just fix the security issue in the shared library and all applications using it are fixed, no they also have to fix all the copies in software like Chrome. Same if you installed Chrome from source, if a security issue pops out in one of the embedded libs you have to go and install a new Chrome version. Google also needs to additionally maintain upstream and security fixes in their embedded code copies but I guess they have enough manpower to do so.

I didn't yet look at the Chrome source code but I hope it has at least a way to link against the system-wide copies without patching the makefiles.

I saw that the inimitable Steve Kemp has cranked out an RBL for hosts that do brute force SSH attacks within seconds of thinking about doing it. As I have a passing interest in such things, and discovered that his sample submission client is really more geared towards people using iptables with the LOG target (and I use the ULOG target), I cranked out this moderately flexible Python client for logs written by ulogd this evening. If you use Netfilter rules like mine, you can use my script after /var/log/ulog/syslogemu.log gets rotated with:

$ ./report_iptables_ulog.py --log /var/log/ulog/syslogemu.log.1 --prefix SSH_brute_force

I recently announced that German and French reached 100% completion in unstable for po-debconf translations (by the way, both are now 100% in lenny as well). However, l10n efforts also happen for many languages in that area, so it's time to highlight them as well:

• Third is Portuguese at 98.3%. Nearly all complete. It would need some overview by the team, lead by Miguel Figueiredo, to complete the currently incomplete files.
• Czech if 97.85%. The effort is a very longstanding one by Miroslav Kure, nearly alone. Miroslav has small difficulties to cope with changes in eth->lenny release cycle which explains why, despite they once were virtually 100%, cs could never reach it. This will happen for squeeze
• Vietnamese is 84.97%. Clytie Siddall fights with changes and her real life conditions and still succeeds in keeping the l10n effort up. I'm admirative
• Dutch is 80.72%. The Dutch team is an "old" team in Debian with a thorough, but sometimes slow, QA process. I have no doubt about the quality of their work. The manpower seems fairly short, though, with people involved in many other areas in Debian and outside.
• Swedish was slowly vanishing until Martin Bagge recently resurrected it. They even passed over Russian again at 78.76%. Congratulations.
• Russian is constantly progressing. Kudos are due to Yuri Kozlov who efficiently leads the team. They'll make it at 100%, I don't doubt it. 78.71% for now.
• Galician is the longstanding one-man effort by Jacobo. He already described in details his work process and took great advantage of my NMU campaigns to progress constantly. 76.80%: will he pass over Swedish and Russian before lenny?
• Spanish is an "old" team. I expected to see a good progress, which doesn't really happen. The NMU campaigns do not benefit them and I don't see that many bug reports. What's happening there? Tis team is one I'm most worried about.
• Finnish took great advantage of the NMU campaing with Esko Ar j rvi following it very closely. He bumped the stats from less than 40% to 66.5%
• Japanese slowly goes its own way. The effort is less constant than others, but they successfully manage to stay around 60%
• Basque is also constantly progressing. Under the lead of Piarres Beobide, the team reached 60% after starting below 40%
• Brazilian Portuguese is more focused on DDTP these days (they have impressive stats, thanks to Felipe can de Wiel's work) so they just manage to stay around 55%

Other translation efforts are more hectic. I'd like to point the slow decrease of the work on Catalan, probably due to low manpower and other areas of interest for the old timers. I'll try to soon make such report for other areas of translation effort in Debian.

Some time ago I wrote a small shell script that counted the number of dependencies of each package. It used to take lots of time to perform such a simple operation, so today I decided to rewrite it from scratch in perl and even made it able to sort the packages according to the number of pre-/dependencies.

---

So, here are 20 packages from sid, which are in the top 20 of most number of pre-/dependencies:

texlive-full:103
libjifty-perl:82
brdesktop-gnome:74
rhythmbox:72
evolution:66
xorg-dev:65
epiphany-gecko:58
gnome-control-center:55
epiphany-webkit:55
iceweasel-l10n-all:55
anjuta:53
gnucash:52
gnome-core-devel:52
brdesktop-common:52
gnome-desktop-environment:51
mplayer:51
beagle:50
dtc-common:49
totem-gstreamer:49
gnome-power-manager:49

Note that ORed dependencies are, correctly, counted once only.

Here's a usertagged list of bugs I filed when I computed the values with the shell version of the script to see what was the reaction of the maintainers. Here's the list of the 20 packages with the more dependencies on sid as of ~2008-05-02.

103 texlive-full
79 brdesktop-gnome
68 rhythmbox
65 xorg-dev
60 evolution
57 epiphany-gecko
54 gnome-control-center
53 epiphany-webkit
51 screenkast
51 iceweasel-l10n-all
51 beagle
50 vlc-nox
50 python-gnome2-extras
50 brdesktop-common
50 anjuta
49 dtc-common
48 totem-gstreamer
47 python-gnome2-desktop
47 awn-applets-c-core
46 gnome-main-menu

So, it looks like we are only going up but not down :(

The FSF is celebrating the birth of the idea that is GNU. There is a video which I have mirrored here for local users. So I plan to sing "Happy Birthday to GNU" on 27th September 2008 as well. It seems like some people are not quite so happy. One correspondent wrote that it was not the 25th birthday of the "GNU Operating System" since that would mean the GNU+HURD which he feels is still not ready. In my opinion the term "GNU Operating System" represents in loose terms "a free alternative to Unix" (free as in mukta). And that idea was born 25 years ago.² I think that the HURD was just the "concept of a notion of an idea" 25 years ago. (The first article about the HURD was on the net about 1990 or so). Moreover, in comparison with Unix of 25 years ago, the GNU+HURD combination could be considered "ready". Thus, there is indeed much to celebrate. For example,

1. There is not one --- there are many free alternatives to Unix. In fact, there are perhaps no non-free Unixes visible anymore! Does this owe a lot to the resolution made by RMS 25 years ago? Absolutely. Of course, it also owes a lot to the resolve of the hackers who followed up on this and took it well beyond what he had in mind.
2. One can run the GNU tools + HURD combination to get an environment as good or better than what was available as Unix 25 years ago. Does a general member of the public really need to do this? No. There are currently a number of far superior solutions. Does the software community need this? Yes. (See below.)

I think that there are a lot of people who disagree with RMS and FSF today on a number of issues --- and these detractors may even be right. Perhaps this makes some people begrudge FSF celebrating the 25th anniversary/birthday of GNU. I offer the following points for their consideration:

1. The vision and resolve RMS and the FSF put behind the vision --- starting 25 years ago --- have got us here.
2. The FSF's astuteness in getting a rather well-known person like Stephen Fry ¹ to celebrate GNU. If any of the distros had managed it, it would have been considered a coup!
3. While Linux may be the dominant player in Unix today, the alternatives like *BSD, Solaris and even the HURD have an important role to play in the development of free software.
4. That chocolate cake looks really delicious. :-)

So here's to (at least) another 25 years for GNU!

Penny keeps me updated on New Zealand terrorism and it s depressing to hear about it: 18 people detained and tried as terrorists for peace activism, protesting against environmental issues, and fighting for M ori rights. I d like to help spread the word and hope that avaaz.org picks up this issue soon! If you would, please pass this on. NP: Stars: Set Yourself on Fire

Ever thought that there should be an automated way to handle ssh keys? Do you know the administrators of your servers, and wish that SSH could verify new host keys from them automatically, based on your personal connections to the web-of-trust? Do you wish you could revoke and/or rotate your old SSH authentication keys without having to log into every single machine you have an account on?Do you administer servers, and wish you could re-key them without sowing massive confusion among your users (or worse, encouraging bad security habits among them)? Do you wish you could grant access to your users by name, instead of by opaque string? Do you wish you could rapidly revoke access to a user (or compromised key) across a group of machines by disabling authentication for that user?A group of us have been working on a public key infrastructure for SSH. Monkeysphere makes use of the existing OpenPGP web-of-trust to fetch and cryptographically validate (and revoke!) keys. This works in both direction: authorized_keys and known_hosts are handled. Monkeysphere gives users and admins tools to deal with SSH keys by thinking about the people and machines to whom the keys belong, instead of requiring humans to do tedious (and error-prone) manual key verification.We have debian packages available which should install against lenny (for i386, amd64, powerpc, and arm architectures at the moment), a mailing list, and open ears for good questions, suggestions and criticism.If you have a chance to give it a try (as a user or as an admin), it would be great to get feedback.

I've been too busy to follow GCC development recently and haven't done any testing of development snapshots during the GCC 4.4 development phase so far. However, GCC 4.4 moved to stage 3 yesterday, the development stage dedicated to bug fixes and documentation. Given that GCC is now in stage 3 and that Debian unstable has fairly little churn because of the freeze, it's an ideal time to do some archive rebuilds. I started archive rebuilds on amd64 and powerpc last night and added ia64 today. I also tried to build GCC on armel, alpha and sparc but there are compiler errors during bootstrap. mips builds fine but I haven't started any archive rebuilds. I found and reported 9 compiler errors so far. Most of them have already received some attention and one of them has been fixed in the meantime. I'm not looking at build failures of packages at the moment since that's very time consuming and I'm not sure whether I'll find the time to report build failures later as GCC becomes more stable, but we'll see.

Here are my notes on growing a KVM disk image’s root filesystem. I had a few 4G partitions that really needed to be bigger. This shows how to get a report on the sizes of the disk images, convert them to raw, work on the partition tables, grow the root filesystem, and rebuild the swap partition with the original UUID. With some work, it could probably become fully scripted, but since the partition layout may not always be the same from VM to VM, the “fdisk” step needs human interaction to delete and rebuild the partition table. Note that the method below also maintains the sparseness of the images.

# Look for files to change
for i in /vmware/*/* vmdk,qcow2 ; do qemu-img info $i; done
...
# Pick one...
cd dir...
ORIG=64bit-Ubuntu-7.10-desktop.vmdk
SIZE=8G
ORIG_TYPE=$(echo $ORIG   awk -F. ' print $NF ')
TARGET_TYPE="qcow2"
TARGET_BASE=$(basename "$ORIG" ."$ORIG_TYPE")
TARGET_RAW="$TARGET_BASE".raw
TARGET="$TARGET_BASE"."$TARGET_TYPE"
qemu-img convert -f "$ORIG_TYPE" "$ORIG" -O raw "$TARGET_RAW"
trunc "$TARGET_RAW" "$SIZE"
sudo kpartx -a "$TARGET_RAW"
SWAP_PART=$(for i in /dev/mapper/loop0p*; do sudo vol_id $i   \
    grep -q ^ID_FS_TYPE=swap && echo $i; done   head -n 1)
UUID=$(sudo vol_id "$SWAP_PART"   grep ^ID_FS_UUID=   cut -d= -f2)
sudo kpartx -d "$TARGET_RAW"
# use losetup otherwise fdisk doesn't know cylinder count
sudo losetup /dev/loop0 "$TARGET_RAW"
# FIXME: Need to automate fdisk (detect swap partition size, etc)
# I'm deleting the swap and growing the root partition, then re-adding swap
sudo fdisk /dev/loop0
sudo losetup -d /dev/loop0
sudo kpartx -a "$TARGET_RAW"
sudo e2fsck -f /dev/mapper/loop0p1
sudo resize2fs /dev/mapper/loop0p1
sudo mkswap -U "$UUID" "$SWAP_PART"
sudo kpartx -d "$TARGET_RAW"
qemu-img convert -f raw "$TARGET_RAW" -O "$TARGET_TYPE" "$TARGET"
rm "$TARGET_RAW"
# FIXME: change disk image path
sudo vi /etc/libvirt/qemu/THING
# FIXME: have the daemon notice the file change
sudo /etc/init.d/libvirt-bin restart
if [ "$ORIG" != "$TARGET" ]; then rm "$ORIG"; fi

The “trunc” command above is based on my network backups post, but is now a general script I use:

#!/usr/bin/perl
# Copyright (C) 2006-2008 Kees Cook <kees@outflux.net>, License: GPLv3
use strict;
use warnings;
my $filename = $ARGV[0];
die "Need valid size also\n" unless ($ARGV[1] =~ /^(\d+)([KMG])$/);
my $size       = $1 + 0;
my $multiplier = $2;
$size *= 1024 if $multiplier =~ /^[KMG]$/;
$size *= 1024 if $multiplier =~ /^[MG]$/;
$size *= 1024 if $multiplier =~ /^[G]$/;
#die "Not trunc’ing existing file\n" if (-e $filename);
die "$filename: $!\n" if (!open(FILE,">>$filename"));
die "seek: $!\n" if (!(seek(FILE,$size,0)));
die "truncate: $!\n" if (!(truncate(FILE,$size)));
die "close: $!\n" if (!(close(FILE)));

Since we're considering a move back to the US, I've been idling perusing job ads; a number of which seek "rock star" this and "ninja" that, which sound ludicrous, to put it in polite terms. On the other side of the coin, once an HR department has you in their clutches, you cease to be a person, and are a "resource", as in "we had two resources working on the problem". Maybe they should just come out and say they are looking for "rock star resources".

I hate September because it is in September that I finally get my mobile phone bill from GUADEC.

Total of 5 Calls while abroad 00:23:20 £31.402

Money grabbing tight fisted evil bastards. This includes a rate of £1.25 a minute to receive a call. NP: Los Angeles, Flying Lotus

I’ve been seeing a bit about Canada recently, what with plastic-bottled water (more on that next month), the airline I used for my last trip (Zoom) going bust and stranding passengers and being a fan of Co-op Radio’s documentaries, so I was particularly interested to see this news:

“FACIL, a non-profit association, which promotes the collective appropriation of Free Software, contests the Quebec government purchasing methods for software [...]” (first seen at Lawsuit, etc - Diary of a CrazyFrench)

In England, discrimination against free software has been less obvious, with the whole national, county and district government system being officially open to free software (or rather, open source that meets gov.uk’s own definition of the term), but very biased towards large service providers. Like most countries, England doesn’t seem to have large pure-free-software service providers yet, so this usually means that the best we can do is get some mix of free and non-free software. This only gets beyond token gestures towards free software when lots of the project development and leadership is internal, as in nearby Bristol City Council, or the Department for Innovation, Universities and Skills. I’m surprised that Quebec has been overt enough to make a lawsuit possible and I’m very encouraged that FACIL is the group to do this. I’ll suggest to SPI and a few other groups that they should join to show support, but I don’t know whether the “political interventions” policy of FACIL will cause problems for non-profits.