I got a call from one of the researchers from ABC news this evening. Apparently they are planning on doing a segment on Hans Reiser on their 20/20 show, and the researcher knew enough that there were some serious technical inaccuracies with the script (at the level of “so when Hans was creating reiser4, was that software; was he writing a program?” and “does the program run on the hard drive?”), and so they were looking for help on some technical issues on a background basis. She didn’t take any quotes from me; what she needed was help understanding the technical issues around filesystems and Linux. I tried to help explain what a filesystem was that would make sense to a lay person in 15 seconds; I have no idea whether the researcher got it, and whether she’ll be able to make changes in the script that will be vaguely coherent. We’ll see. I spent a lot of time working with Joshua Davis, providing background material for his Wired article, and he still got a bunch of the technical details wrong. The 20/20 researcher did ask me some silly questions such as “whether we were surprised when murder charges were filed against Hans?” Well, yes. What did she expect me to say? “Oh, yes, were always worried someone would get hurt…” Not! Sigh…. I might not agree with Hans’s filesystem design principles or his tactics in trying to get reiser4 accepted, but I always respected him as a fellow open source programmer. The researcher mentioned to me that Hans had done a talk at Google that was available at the Google Video site. Out of curiosity, I took a look at it. It was interesting; the last time I had seen Hans was in 1999, at the Linux Storage Management Workshop in Darmstadt, Germany that was organized by Matthew O’Keefe at Sistina Software. Compared to how he looked back then, and the picture of him in the Wired article, taken a 10-12 months after his talk at Google in February, 2006, I was struck by how much heavier (and older at least compared to my memory of him, which was much closer to this picture from his resume) in the Google Video. I also remember him as being a much more dynamic and energetic speaker, and I was struck by how slowly he spoke, with lots of long pauses and “umms” and “ahhs”. He seemed to be a much better public speaker in Darmstadt, but in the Google talk he seemed very tired as he gave the talk. One of the questions that the researcher asked me was whether I thought he was a genius or not. I told her that I thought he was quite bright in terms of raw intelligence, but that his Social IQ wasn’t as high as you might want for someone to be successful in gathering volunteers to work on an Open Source project, and in working with others in an Open Source development community. Looking at the video, I think that is very much true. He was a terrible public speaker, but some of the points he made about optimizing B-tree algorithms made sense. I might disagree with his philosophy over filesystem design and benchmarking, and I might not be terribly impressed by his social skills, but in terms of being a talented computer scientist, he was and is that. Is he guilty of the crime that he has been accused of? I have no idea. But from looking at his talk and knowing what I know of him, I have the sense of a greek tragedy. He’s been working on some of his ideas since his undergraduate days in UC Berkely in the early eighties — which he entered after finishing his 8th grade. And as research ideas, I think he might have gotten some very interesting results out of trying some of the things that he wants to do around operating system namespaces. (I think they are doomed in a production system descended from Unix, since application programmers are unlikely to rewrite their programs to take advantage of reiserfs’s performance characteristics — which would mean instead of using a Unix-like configuration file, treating a directory hierarchy containing the configuration information like a Windows registry. Still, as an academic, Plan 9-like system, I could have seen it has being a potentially very interesting Systems Research effort.) Unfortunately, his skills at public speaking and his ability to work with other people have handicapped him, and I know that has frustrated him deeply. So I have a lot of sympathy for him, and I hope that he is innocent, and will be found innocent. But only time will tell…. Anyway, according to the researcher, they are currently scheduling their segment about Hans on 20/20 on October 19th. I’m sure that schedule is subject to change, but it’ll be interesting to see how they treat Hans in their coverage. Hopefully it will be fair, and not overly sensationalistic, but unfortunately my faith in today’s TV edutainment-focused news program isn’t terribly high. My impression was that the research wanted to do a good job, but she was burdened by a very tight deadline, and in the end, the decision of what goes on the air and what doesn’t won’t be up to her. So we’ll see.

On the bus yesterday I noticed a graffiti etching clearly left by someone employed by IBM. In fact the guy in the row in front had an IBM tee-shirt on, and I suspect he is the culprit, or possibly one of the OzLabs people. The photo is crap (it's hard to take a photo of a blukhead in the dark from the middle of the back seat on a crowded bus with a phone camera without arousing suspicion) but it clearly says

   I
(heart)
 POWER5

Check out my CSI style image enhancement: If you're ever on Sydney Buses bus number 2660 it can probably still be seen on the driver side window on the back seat. Maybe what Itanium needs isn't higher clock speeds, lower power, faster FSB, etc., but a concerted tagging effort on public transport around the world!

Although I predicted that I'd be a busy boy with my bushfire brigade on Tuesday, I wasn't expecting to get our first "Bush Alight" fire call so quickly. But, yesterday (Wednesday), a few minutes after 1800, off goes the pager, and off I go to the station. Thankfully the high winds that had been a major feature of the day had settled down quite a bit, so it was relatively easy to control and stamp out (we were back at the station by around 2015) I still found it a little overwhelming -- "I'm supposed to help Stop This Fire". At a couple of hectares in size, it wasn't too massive, and it wasn't visually "spectacular" (like the fires you always see on the news) but still... given that my only experience of fire in the past has been small campfires and the occasional bonfire, having an area the size of a football field in front of you glowing with embers and flaring with small clusters of flames, it was certainly a very different experience. The heat, the smoke, the noise (those truck pumps are loud), and the adrenalin, it's a hell of a mix. Being that I'm the newest and least experienced crew there, I got given the unglamourous but important job of controlling traffic, as we had one lane of the one-each-way 100km/h road closed to give our crews more working space around the trucks. Let me just say that I now have an infinitely greater respect for road repair crews, and I think that every person should do an evening of traffic control with a group of their mates on the road behind them, so that they know what it feels like outside their car. Car drivers do the darnedest things. So, I've popped my bushfire-fighting cherry now, and I'd be more than happy if there's nothing more impressive than that awaiting me for the rest of the season.

Yesterday my new NAS arrived, to replace my aging and failing hacked Linkstation. As part of the bundle I also received a Roku SoundBridge, which was a nice surprise. Basically, it's a consumer-orientated device which plays music from iTunes or Internet radio, which you would plug into a hifi or powered speakers. I'd heard of these before but I've been using my old ThinkPad X22 for this duty for a while now, and MPD has served me well. I thought I'd give it a go, and I'm actually really impressed with it. Physically the SoundBridge is pretty good looking: a sliver and black ten inch cylinder about two inches in diameter, with a large LCD panel on the front. When turned on it found my wireless network, asked for the WEP key, and promptly upgraded its firmware. Once all that was done, it let me select from two libraries: Vicky's Music or Internet Radio. Vicky was running iTunes on her laptop which exports the library over DAAP, so I listened to Tori Amos whilst I explored the Internet Radio options. Then I listened to the most excellent Groove Salad on SomaFM (apparently the #4 station on the Roku Radio charts). At this point I discovered that there was a SoundBridge link in Epiphany, the SoundBridge uses mDNS to publish the web control panel: a useful application of clue from Roku. Then it just got better. The SoundBridge will stream from DAAP and UPnP servers (they pimp mt-daapd and SlimServer), and announces the web interface over mDNS and UPnP. There is a web site which indexes Internet radio streams, currently it has over 5000 entries. This site uses a Java applet (currently only tested in Windows though, I haven't installed Java yet) to talk to your SoundBridge so it can show the currently playing station and tell it to play another station. Then I discovered this in the manual.

Geeks - read this. The M-bridge has a command line interface that you can telnet to for piddling abut. You will need to telnet to port 4444. Type "?" at the command prompt to see a list of commands. ... M-bridge has a built-in UPnP AV "media renderer". This protocol can be used to control the M-bridge from your own software.

The SoundBridge supports both a custom protocol (documented in a 200-page PDF) and the standard UPnP protocol for controlling it. They even documented the signals the remote control uses. This is probably one of the most hackable "consumer" devices I've seen for a long time, short of the N800. Well done Roku, you've created a damn neat product which actually does just work out of the box. NP: theJazz, Internet radio

I am currently considering what to do regarding a Zope server that I have converted to Xen. To best manage the servers I want to split the Zope instances into different DomU’s based on organisational boundaries. One reason for doing this is so that each sys-admin will only be granted access to the Zope instance that they run so that they can’t accidentally break anyone else’s configuration. Another reason is to give the same benefit in the situation where one sys-admin runs multiple instances, if a sys-admin is asked to do some work by user A and breaks something else running for user A then I think that user A will understand that when you request changes there is a small risk of things going wrong. If a sys-admin is doing work for user A and accidentally breaks something for user B then they won’t expect any great understanding because user B wanted nothing to be touched! Some people who are involved with the server are hesitant about my ideas because the machine has limited RAM (12G maximum for the server before memory upgrades become unreasonably expensive) and they believe that Zope needs a lot of RAM and will run inefficiently without it. Currently it seems that every Zope instance has 100M of memory allocated by a parent process running as root (of which 5.5M is resident) and ~500M allocated by a child process running as user “zope” (of which ~250M is resident). So it seems that each DomU would need a minimum of 255M of RAM plus the memory required for Apache and other system services with the ideal being about 600M. This means that I could (in theory at least) have something like 18 DomU’s for running Zope instances with Squid running as a front-end cache for all of them in Dom0. What I am wondering about is how much memory Zope really needs, could I get better performance out of Zope if I allowed it to use more RAM? The next issue is regarding Squid. I need to have multiple IP addresses used for the services due to administrative issues (each group wants to have their own IP), having Squid listen on multiple addresses should not be a big deal (but I’ve never set up Squid in a front-end proxy manner so there may be hidden problems). I also need to have some https operations on the same IP addresses. I am considering giving none of the Xen DomU’s public IP addresses and just using Net Filter to DNAT the connections to the right machines (a quick test indicates that if the DomU in question has no publicly visible IP address and routes the packets to the Dom0 then a simple DNAT in the PREROUTING table does the job). Is there anything else I should be considering when dividing a server for running Zope under Xen? Is it worth considering a single Apache instance that talks to multiple Zope instances in different DomU’s?

Share This

After quite a few struggles with power supplies, serial cables, the never-ending pain of minicom and the (almost) solved pain of ethernet over usb, my recently received Balloon3 board it up and running. (i.e. recent = less than 12hrs old. 8 hours of that was spent trying to work if I had a compatible power supply and it's been running for nearly 3 hours already). I can ssh into it from anywhere on the network, I have the basic system installed and I've set the date and time.
The task ahead is now clear:

1. Continue to work with Guillem to merge dpkg-cross into dpkg so that the dpkg-cross transition can release the rewritten apt-cross and the dependent emdebian-tools


2. Test and fix the Emdebian rootfs packages to at least support login to a chroot on the Balloon (which I've called genesis.codehelp)


3. Simplify the installation with sensible defaults in the Emdebian packages and improvements to the emdebian-tools scripts that create and could install the chroot itself


4. Document the process for the CELF tutorial in Austria in 30 days time.

Busy, busy . . .

It's bad enough that we have anti-social fuckwits spamming the world. It's made even worse by morons using broken-by-design challenge-response software like Active Spam Killer to push back-scatter on to the rest of us. I'm depressed that people can be so ignorant, but not exactly surprised. I just got another challenge in my inbox today. *sigh*

Googling around using the rebuildd keyword to find if people were talking about it, I found that patch from Ubuntu. This patch is used to ship rebuildd Debian package in Ubuntu. Wahou. First surprise! So, Ubuntu is fixing bugs and not telling me. I though that people saying "Ubuntu does not contribute back to Debian!" were exaggerating. Seems I was wrong. Nevermind: I take the patch. I read the patch. I apply the pat oh wait: the fix is wrong. lol.

Looking at the web stats, I noticed, that quite a lot of people find something relevant to "environmental" on my pages. As I was not aware of anything related here, I tried that in Google. To my surprise all results are in demo for Ukolovnik. Well I do not want to add any anti spam technique to this simple tool as it will be usually password protected. And this is exactly what I did with demo for now. So if you want to use it, you need to login with user demo and password demo. I hope this will prevent spammers from using this demo, otherwise I would probably have to close it.

Just read that after 6 years the leader(Judd Vinet) of the ArchLinux distribution will step down from his role.

he reason for this is that I do not have the time to devote towards a leadership role in a project the size of Arch Linux, and Arch deserves someone who does.

Referring to his post the new leader will be Aaron Griffin.

[via archlinux.org]

So, now we know what the 1/4 finals will look like:

• Australia-England, Sat 6th, 13:00 UTC, Marseille
• New Zealand-France, Sat 6th, 19:00 UTC, Cardiff
• South Africa-Fiji, Sun 7th, 13:00 UTC, Marseille
• Argentina-Scotland, Sun 7th, 19:00 UTC, Paris Stade de France

France wons quite easily against Georgia (64-7). Nearly perfect match for the French team, except maybe in mauls where cleaning was not always perfect and when setting the ball back in play ("remise en jeu", I don't have the exact English technical term for this). Georgia was playing 4 days after their win against Namibia, which is pretty short for recovering. Lionel Beauxis, for his first selection in RWC, was elected MVP of this match, after a brilliant kick play. Argentina had to either win against Ireland, or lose by less than 7 points. They very brilliantly won (30-15), scoring 2 tries while Ireland scored 2 tries as well, but much less penalties. The Irish couldn't prevent Argentinians th play their game (sloooooooow but efficient). The key to win against Argentina is playing fast with rear lanes and prevent them to slow down the game, which the French failed to do in Paris. As a consequence, there is a great probability that the four major nations of southern hemisphere reach the semi finals:

• Australia had a much more complicated pool than New Zealand but they played all their matches very strongly, without much weakness. I don't really see England beating them, given the current status of their team. But, well, who knows? Noone woud have bet on England in 2003.
• New Zealand seemed invicible in pool play, but their opponents were pretty weak. The weakness of NZ seems to be their defense and maybe the lack of hard fights in pool play. France has still many weaknesses and only a perfect match can lead them to victory. We all know that the French rugby team is always playing its top rugby when not supposed to win (the NZ team probably remembers Oct 31st 1999 in Twickenham, 31-43).
• South Africa does not probably have the most brilliant game but is certainly the hardest team to beat, as they very rarely show weaknesses, contrary to Australia and New Zealand which sometimes play "the wrong side". I really don't see the Springboks fail against Fiji, though the opposition will be really interesting.
• Argentina is probably much too strong for Scotland, which I really don't see winning. Will I be proven wrong?

Rendez-vous samedi Marseille! PS: South Africa-USA will be the last pool match tonight. I'll probably skip it anyway.

Yesterday, New Zealand crushed Romania (85-8), just like they crushed all other teams they faced up to now. Of course, my only hope is that they stop crushing teams...as France is very likely to be the next one. Indeed, the only question about New Zealand is about their defensive skills as all teams they faced scored one try against them. Particularly, their wing players seem to be pretty "weak" in defense ("weak" in terms of New Zealand...:-)). I haven't seen anything of Australia-Canada (37-6). Apparently, the Australians were pretty quiet (6 tries, still!). Very unfortunately, I haven't seen THE match between Fiji and Wales (38-34). The Fiji team created an "half surprise" by qualifying for 1/4th finals. All reports I read talk about a wonderful match, with great indecision, a full commitment by both teams, and 9 tries. Sigh. I screwed programming my VCR and we were strongly disappointed this morning. Finally, Scotland managed to qualify after beating Italy 18-16. Up to the very last minute, Italy hoped to qualify but Chris Paterson scoring 6 penalties out of 6 attempted converted all occasions the Scots had to score points. I'm slightly disappointed for the Italians who played great games all along this World Cup and would have deserved to qualify and meet Argentina, France or Ireland. Today, the final 2 teams for the 1/4th finals will be determined. Argentina has great chances to finish first (they only need one bonus point) and meet Scotland. France needs to win against Georgia. Scoring the bonus point would secure the qualification for them. Ireland has little chances to qualify as they need to beat Argentina without Argentina to score a bonus point, therefore with more than 7 points difference. The most probable ticket is Argentina finishing first and France 2nd (thus meeting New Zealand).

Recently, I added some photo related blogs to my reading list, amongst them strobist, and so I came across a post about the Open Source Wireless Trigger. Being interested in both electronics and free software, I read through most of the posts on the forum as well as the wiki. I also started experimenting a bit with an old Nikon SB-24 flash I had lying around since even if I managed to break it, it wouldn't be that bad. And it's old and robust. So far, I've played around with how to make the flash go off. For the hot shoe, it's just shorting the ground and center pin (I just used a big resistor). For the PC connector, I had to apply a bit of voltage; I used an AA/LR06 battery and that worked splendidly. (Oh, and PC in this context has nothing to do with computers, it's an abbreviation of Prontor-Compur, two shutter manufacturers who decided on the design of the connector back in the 1950s.)

From time to time the question comes up on Debian mailing lists of whether debian directories in upstream tarballs are harmful and what do do about them. I tend hide from such threads, since all upstream tarballs I create contain debian directories. But I realised tonight that the common wisdom from those discussions is wrong, or at least incomplete. Here's why. First, it's important the notice that this is not a problem in the rpm world. Putting an rpm spec file in an upstream tarball is considered good practice. There's no downside; if a packager needs to change how the package is put together, they can replace the spec file. And users can run rpmbuild on the tarball and get an rpm spit out. Handy. So, then, why is the equivilant practice a problem in the debian world? Three intertwined reasons:

1. The tools assume all files in debian/ are good. There's no way to make debhelper not install a debian/init script, or any similar file. Note that this problem only affects helper tools like debhelper; the core deb building tools only care about a few files that are in every debian directory. Effectively, debhelper, and (possibly) cdbs are the only tools with the problem currently.
2. The source package format doesn't support removing files from the upstream tarball. This is a pretty silly limitation that any source format better than the current one should override. If wig and pen was ever implemented, it should support some means of deleting files.
3. Package maintainers fear that they can't get upstream to make changes, or not fast enough, so worry about getting into a mess with files in an upstream debian/ that can't easily be fixed.

I feel that if any of these three problems is solved, an upstream debian directory is ok. #3 can be solved to some extent for some packages, though these solutions will always be the least satisfying. It's tempting to try to solve #1 in debhelper. I could add an --ignore switch, to make debhelper commands not act on a given file in the debian directory. (Update: done in version 5.0.57!) The best place to solve it, though, would be in the source package format. I'd be happy to see wig and pen be implemented, but would be happier to see us moving toward using a distributed revision control system as a source package format. Consider a source format that replaces .diff.gz with .git.tar.gz.

Scott, I would have expected a little more from you than your previous post on why you chose bazaar! Update: my initial post was offensive towards Scott, so I edited it a little, following a good discussion with Scott via Email. Even though his post didn't make it explicit, his post was meant to be a reaction to someone else praising Git above everything else. Or, in his words:

You're responding with a defence of git because I posted a defence of bzr in response to championing of git.

I decided to leave most of the original post untouched, nevertheless, but please read it in this context. I guess the sensible conclusion is (as always): to each their own. Inline updates are enclosed in [brackets].

---

Git is less of a version control system than it is a filesystem and a means to communicate among developers, and when used in that sense, it's extremely powerful and intuitive to use. And it is also a version control system, like Bazaar. It's blazing speed isn't the only killer feature. By no means, however, is it "heavily optimised for the 'I only apply patches' development model, at the expense of ordinary development models" [anymore]. It also supports centralised workflows just as well as it supports distributed approaches, and you can switch between them [this is not really true when compared to how Bazaar mimiques CVS/SVN behaviour; Git cannot do that]. Here are the git commands needed to do the same things Scott showed off in your post:

$ cd myproject
$ git init
$ editor .gitignore
$ git add .    # git rm ...

Let's branch before we commit. checkout -b is a shortcut to create a branch (git branch myproject-foo) and immediately switch to it (git checkout myproject-foo):

$ git checkout -b myproject-foo
$ git commit

Git keeps all branches within the same repository and lets you switch between them. Now, that is a killer feature: whether I'm versioning code or stuff like webpages, I often have external pointers to my code. For instance, I may have libfoo as a sibling of foo-ng and the latter refers to libfoo in the Makefile. If I wanted to try a new approach in libfoo, I'd have to change foo-ng's Makefile to point to libfoo-newbranch instead, or juggle directories around. That sucks. With git, I just checkout a different branch in the same space:

$ git checkout master

And even better: if you don't like it, you could just as well copy the repository to create a separate (remote) branch from which you can later pull or cherry-pick changes to the main branch:

$ git remote add foo ../myproject-foo
$ git fetch foo
$ git merge foo/master

Now back to your steps, and I'll stick to the git way of branching. Note how git does not differentiate between pulling and merging in the sense that you do. If there are no local modifications, git just fast-forwards the branch with the commits on the master:

$ git merge myproject-foo

Even better, say you don't want the last two commits:

$ git merge myproject-foo~2

Unless git can fast-forward, it also treats a merge as a single commit and the ancestry information allows you to inspect its component commits just like you would. gitk is another killer feature, which I believe bazaar copied from git, just like the bazaar folks adopted the concept of rebasing, which basically lets you rewrite history quite freely, another killer feature (which can be quite badly abused if you don't know what you're doing). And then there is git bisect and git-svn and git filter-branch and git describe and git stash and gitweb and, and, and So if I compare the git commands I used to the way you used bazaar, I fail to see much of a difference. Do you? It is true that git comes with an astounding number of additional commands, most of which you never have to use, but which are available to the user [but its interface is a huge improvement over GNU arch, nevertheless, and if only because the commands are named more logically and revisions and branches do not have to adhere to one of the strangest syntaxes ever]. I don't deny that their sheer abundance is overwhelming and confusing at first (a general rule for Git for beginners seems to be just to ignore ever command with a hyphen in it). But once you get out of the newbie stage (it took me about two weeks, the duration of Debconf7 to become an acquainted git user; in fact, David Nusinow placed me among the ranks of real git wizards Pierre and Keith before the conference was over) arghs, I hate long remarks in parenthesis; once you leave the newbie stage, you'll appreciate all these commands, which make it really easy to script complex tools with git, making any plugin architecture pretty obsolete. Finally, I found myself trusting git way more than any other version control system I've tried simply because it's so transparent and you are allowed to edit stuff under .git, which is mostly plan text files (and objects, which you [could but] don't have to touch). It's transparent, and it stays true to the Unix way of letting small tools do their jobs instead of the monolithic approach. NP: Enchant: Tug of War Update: Carl Worth has a similar beef with people thinking that Git is too complicated and has ported a chapter from a book on Mercurial to Git to show how that's not the case. It's a good read. Update: Scott replied (quoted with permission), and I include my replies inline:

"I can tell you why you chose bazaar: because you had to, because you are being paid to use it."

Sorry, that just isn't true. I'm paid to lead the Ubuntu Desktop Team; this has nothing to do with version control, except that the various upstreams and packages use different systems.

I am sorry about this accusation. It was low.

You appear to miss my point about Git, or maybe I didn't make it strong enough. It's not that I don't understand it; it's that I had to take time and effort to understand it. And I've noticed that every reply to my post misses out the fact that with Git, you have to take action to ensure your changes are actually incorporated into the commit; either with git add or commit -a. This exactly the kind of anti-social behaviour that I have issues with.

Well, Git people call this a feature and it is very handy, but I see your point. There is no way to configure git-commit to always include -a, so you'll have to work around it:

git config alias.ci 'commit -a'

This creates git ci to do exactly what you want. You cannot overwrite commit that way though. But it could be trivial to add a configuration option to git-commit, if you think that the way that Git exposes the index is an adoption-stopper:

$ file -L =git-commit
/usr/local/bin/git-commit: POSIX shell script text executable

Your post also introduces yet more over-complication by demonstrating about making a branch (in an empty branch) before you commit.

Your post does the same ("A common operation is realising that the commit you re about to make should really go on a new branch for now"), which is why I did it. You don't have to do that at all.

(Side-bar: bzr's design also permits multiple branches within the same repository.)

So I read the manpage and found bzr init-repository, but no way to add a branch to an existing clone, and also no way to switch between branches within a clone. In your original post, you claimed: " Bazaar s command set works the way you do." Well, the way I work is by "switching" between or "checking out" a new branch in-place, but I could not trivially find the command to do this. This is probably because I have not invested enough time into understanding Bazaar, but isn't that what your claim is all about: that "[you] had to take time and effort to understand [Git]" and that Bazaar just works for you?

My post was why I choose bazaar, and why I have rejected other revision control systems that I have attempted to use.

So why did you post it? Surely because you wanted to express your preference over Git. In doing so, you made a couple of claims about Git which are simply untrue, which is why I replied. And the reason I replied is simply because other people who try to make a choice between Git and Bazaar may find your post and take away from it the information that Bazaar is superior to Git, which it is not.

I'm glad that you prefer a different system; but please don't insult me by suggesting that I'm being paid to use the one I prefer, or that I haven't bothered to learn one I'm "slagging off".

But you did slag Git in that you basically present its shortcomings side-by-side to Bazaar's greatness, which is a common PR/marketing thing to do. So just like I failed to create an in-place branch above because I did not bother to learn Bazaar, you did not bother to learn how to do with Git what you showed off with Bazaar, or else I'll have to assume you would not have written up the comparison as you did.

I have to use git as much as I use bzr, and I simply prefer bzr.

That was not the message I took from your original post.

Randomisation is a good thing for media players, but it must be done properly. What do I mean by this? I mean randomness which only works going forwards. As an example consider the case where you have several films/videos in a directory and you run this:

xine --loop=shuffle *.mpeg *.avi

This appears to do what you want, showing each film in a random order but it is subtly doing the wrong thing. If you're watching film "two", having just finished film "five" you'd expect to be able to return to film "five" by pressing "previous"/Page-Up - however that doesn't happen. Xine decides that "moving backwards" in the playlist means selecting another film at random, rather than the previously viewed film which was selected at random - the two are different - and the current behaviour is both counter-intuitive and plain wrong IMHO. I forget the name of the media player that I used briefly which also behaved like this, but it was enough to make me abandon it almost immediately. So, think of the children. If you have a random mode, make sure that going to previous items actually does return to previously played items and not random ones.

I use a rather simple CRM114-based setup to handle spam in my incoming mail. Nothing really funky here as I essentially used examples from the Debian package's examples/ directory. The only personal touch is using a two-step method for this. All mails are received on my home server and delivered to the "bubulle" user there. A non aggressive CRM114 setup runs there for this user. Mails identified as spam are sorted in a specific folder on the server and are theoretically examined regularly. Indeed, this is something I can't do anymore, given the number of identified spams (about 1000 per day, most of them in Debian mailing lists and Debian BTS). After a quick look, this spam is re-teached as being spam to CR114, then stored as backup in a giant mail folder, which allows me to retrieve a possible false positive later. All other mails are left in /var/mail/bubulle waiting for my laptop to grab them. This gives very few false positives, but still lets a lot of spam slip through. This is why I also run CRM114 on my laptop when mail is grabbed from my home server (I use fetchmail between my laptop and my home server, wherever I am). There, spams are again identified (more aggressively than what's done on my home server) by CRM114. The identified spams are sorted in a folder which I routinely investigate carefully for false positives (there are several a day, but the numbers are low because of the prefiltering done on my home server). Spams are teached as spam to CRM114 and, of course, ham is teached as "ham". I recently added the following to my mutt setup so that SPAM/UNSURE/HAM mails are easy to identify in mutt's index:

spam "X-Spam-Status: Yes"                     "90+/SA"
spam "X-CRM114-Status: SPAM"                     "90+/CRM"
spam "X-CRM114-Status: UNSURE"                     "40+/CRM"
set spam_separator=", "
color index red       default    ~H90    # Spam
color index cyan       default    ~H40    # Unsure

With this, messages identified as "Spam" are shown in red in the index, "unsure" messages are showed in cyan and regular messages have their normal colors. This is really helpful as I can spot messages that are "unsure" and very quickly tell CRM114 that they're ham or spam, with:

macro index \es ""s/home/bubulle/Mail/Administration_systeme/Spams\ncrmlearn --learnspam\n" "crm114 learn as spam"
macro index \eh "crmlearn --learnnonspam\n" "crm114 learn as ham"
macro pager \es ""s/home/bubulle/Mail/Administration_systeme/Spams\ncrmlearn --learnspam\n" "crm114 learn as spam"
macro pager \eh "crmlearn --learnnonspam\n" "crm114 learn as ham"

with the "crmlearn" script being:

#!/bin/sh
 grep -a -v "^X-CRM114"   \
 $HOME/.crm114/mailfilter.crm -u $HOME/.crm114/ $1 --force   \
 grep -a "^X-CRM114"

Shortly speaking, for any cyan message I see in mutt, I hit "ESC-h" if I consider it to be ham or "ESC-s" if I consider it to be spam. Finally, all mails identified as spam are grouped in a dedicated mail folder (/home/bubulle/Mail/Administration_systeme/Spams above) which is sent daily to my home server, where it is used to teach CRM114 about spam, then deleted on my laptop. All this makes spam handling pretty easy with a not so complicated setup (the trickiest part is the nightly laptop->home server synchronization).

(or: Why Everyone Should Learn Some Basic Programming) I am an organisational disaster area. I just can't remember "event oriented" information (like "I need to do $foo" or "I need to do $bar at $time"). I think I've accumulated such a huge collection of technical trivia that it's taken over the event planning part of my brain -- although, since I've never been able to remember event oriented information, even before I became a computer geek, it's more likely that I was just built without that bit of the brain. So I guess I'm the perfect target market for some sort of external brain pack (a la "Ratbert the Consultant"). I've tried paper-based organisers (the mighty Filofax), a few pre-written apps, and I even bought an SL-C3200 Zaurus a while ago (although, to be fair, that was really just for the hack factor, regardless of what justification I may have given to others at the time). None have worked, for various reasons. I can't grep paper, and Other People's Apps bug me because they've got their idea of workflow, and I've got mine, and when they don't match up (and they never do) I just get irritated -- not to mention the fact that the ubiquitous relational database, while wonderful in some ways, does tend to get in the way of ad-hoc faffing with your data. But this article is a success story, not a rant (gasp!), so it's safe for you to assume that I've got something that's working for me. My method is real simple -- plain text files, managed by vim-outliner and a simple shell one-liner I've named 'pda', which just runs vim ~/pda/$1.otl. At the moment I've got a monster todo.otl, which is my world's todo list, and a deeply underused calendar.otl. I'm also using vim-outliner to do some project planning, which has been moderately successful, although I'm a bit freaked out by the idea of trying to manage a large-scale project using it. The really, really cool part of this whole shebang, though, is that because all of my data is (structured) plain text, writing little programs to parse the data and do funky things with it is dead simple. For example, in my project outlines, I put estimated, actual, and remaining times in for all tasks (a la Joel Spolsky's Painless Software Schedules) so I can keep track of my estimates and where they differ from reality (because one day I'd like to not Suck at estimating times, and feedback is the only way I'm going to do that). So, about an hour's worth of Ruby gave me "estimator", a script that reads all that data and does a pile of mathematical gubbins about how far over my estimate I am so far (or under estimate, if that were to ever happen), the percentage of the project complete (based on the estimates and number of tasks completed), and things like that. Similarly, today I wrote a small script (run out of cron in the wee hours of the morning) to read my calendar and send me an e-mail if I've got anything in there for today. Since I practically live in mutt, a morning e-mail is going to be far more effective than my trying to remember to check my calendar every morning (especially since, at present, I'm not using the calendar as often as I should, so there's even less motivation to check it). This, in my opinion, is why everybody (literally, every single person) should learn to program at some fairly simple level, like learning to read and write. By using plain text and small scripts, I've got a workflow that works for me, and it's cost me less time than I'd spend learning some large pre-written app and putting all my data into it. Being able to manipulate data like this is, I think, a fairly important tool in the modern world, and I don't think it should be left to any sort of priesthood of developers -- it should be as universal as most countries try to make literacy and numeracy.

This is more of a reminder to myself to investigate this within GPE. The basic problem is that many events recorded in applications like gpe-calendar have a direct relationship with a specific person in the contact database and can also be linked to records in the expenses database. Expenses are relatively easy if the time of the expense occurring can be related to the duration of the event but a formal link may be more useful for extra granularity.
Relating an event to a person would typically involve the event being a work placement, a project name, a customer name or the name of an organisation. It could link an event to the organiser of the event or provide a quick lookup for the location of the event to eliminate entry duplication. (Why have the address of the event in the event record if the address is already in the contacts database? Equally, why have the dates of an event in the contact record for the organiser of the event when the same organiser may well be putting on a similar event again in the future?)
I'm thinking that gpe-calendar and equivalent applications could have a field within the event record for an ID in the contact database and a preference setting for the "category" of contacts to be shown in that field, e.g. Business or Conferences. Entry of the association would simply be a drop-down box of contacts that have the appropriate category set. A similar associative field can be implemented in expenses.
This all makes creating an invoice much more reliable. The current pilot-qof method depends on the user specifying the name of the contact as the description of the event and the "vendor" or "city" of the expense.
I'm sure there are other uses for associating events with contacts and/or expenses.
No time to investigate this just yet but it is another essential step in migrating PIM into a business-friendly format, SBIM (for want of a better name).
Small business support is lacking in current free software programs, IMHO. The applications that do exist do not work together to ease the administration burden of a small business the way that the system tools work together to ease the sysadmin burden. Understandable, yes, but small businesses need this kind of support to migrate to free software. "Joined-up thinking" is the buzzword but it's basically eliminating duplication in data entry/retrieval, associating business data across disparate data sources and enabling queries and data mining to support tax calculations, business plans, time management, project management, customer data handling ... the usual small office/home office workload.
I'm inevitably concentrating on data integration in an embedded devices like iPAQs, smart phones or blueberry-type handhelds but similar requirements need to be met within the rest of the free software world too. Once I've got time to investigate this, expect some threads on debian-devel looking at how Lenny could be made more business-friendly; not seeking an "Enterprise" version but simply making it easier to administer a small business using Debian.

Davyd Madeley writes about vegetarianism for the environment [1] which is listed in Wikipedia as Environmental Vegetarianism [2]. He links to an article on the Huffington Post [3]. The Huffington Post article in turn links to an article on GoVeg.com about global warming [4]. Mass-produced meat is not only bad for the environment but there are also health issues related to meat consumption (due to bad practices in mass farming, combining the meat of thousands of animals into mince thus increasing the spread of bad meat, and the fact that most people in first-world countries consume significantly more meat than anyone did at any time in history). One thing that doesn’t get mentioned in these posts is the fact that farming is not required to produce meat. In fact the meat that is most healthy (due to lack of carcinogenic chemicals and free-range feeding) and has the strongest flavour (which may be a good or bad thing depending on whether you actually like the flavour of meat) is from wild animals. If you don’t like the taste of meat (which seems to be the case when people don’t like game meat) then why eat it at all? In Australia large numbers of kangaroos are killed because they eat grass more efficiently than cattle (they have evolved over tens of thousands of years to survive in Australian conditions unlike cattle). There are also a number of foreign animals that have run wild in Australia and are considered vermin, this includes rabbit, pig, buffalo, deer and camel (all of which are tasty). Even among native animals there are often times when a cull is needed. If some good seasons allow the population to increase then when there is a bad season the population has to reduce and it’s often better for them to be culled (thus providing plenty of food for the surviving animals) than for all of them to starve. There is a game meat wholesaler I’ve visited a few times that sells buffalo, rabbit, pig, camel, crocodile, possum, emu, kangaroo, and some other animals. All of the meat is from wild animals (apart from rabbit and pig none of those animals can be domesticated). I’m sure that every region has such a wholesaler that will sell to interested individuals if you know where to look (it seems impossible to buy any game meat other than kangaroo retail in Australia). Finally one thing that offends me is people who eat meat but are not prepared to kill the animal. If you aren’t prepared to kill it then you shouldn’t pay someone else to do so on your behalf! Claiming that “the animal was going to be killed anyway” is a pitiful excuse that is only suitable for children. It’s acceptable for children to eat meat without thinking about where it came from. But adults should be able to deal with the fact that eating meat means killing animals - or become vegetarian if they can’t cope with it. The book 3001 The Final Odyssey pioneered the term “corpse food” for eating meat. I believe that the term is accurate and should be used. If you can’t stomach eating corpses then there are many good vegetarian options available. There are many vegetarians in the Linux community. As these issues are getting discussed a lot recently maybe it would be good to have the vegetarians choose some good vegetarian restaurants to have Linux meetings on occasion. Davyd got a bit of negative feedback on his post, maybe if he invited a bunch of his local Linux people to have dinner at a vegetarian restaurant and they enjoyed the food then the reaction to such ideas would be more positive.

• [1] http://davyd.livejournal.com/224276.html


• [2] http://en.wikipedia.org/wiki/Environmental_vegetarianism


• [3] http://www.huffingtonpost.com/kathy-freston/vegetarian-is-the-new-pri_b_39014.html


• [4] http://goveg.com/environment-globalwarming.asp

Share This