Maj went out for her birthday party with a passel of ladies, so I stayed home and ate pizza and watched Twelve Monkeys with the baby. We had a good time, but as the baby is approaching 1 years old, my going-to-sleep tricks are becoming somewhat outdated. My main way to put the baby to sleep is to walk her from the front door of our apartment all the way back to the laundry room, and then turn around and walk out to the front door again. I sing during the entire process, mostly Neil Young and Johnny Cash tunes, but also a mix of 80s pop, reggae, songs, and goofy children's songs. Really, it's anything I can remember the words to, or that I can bridge over with some ad-libbing. This worked pretty well when she was teensy-tiny, and it's still the best way for me to get her to sleep. But as she's approaching 15kg, it's getting to be a serious workout for me to slog up and down the hallway 50 times belting out Take the Skinheads Bowling at high volume. We have a few baby books on how to get a child to sleep easier, but I've been taking the path of least resistance. I'll probably have to take the plunge and get her to fall asleep in bed soon -- which will probably mean some angry baby moments. Still, putting the baby to sleep is one of the most satisfying things in my life right now -- I highly recommend it. tags: baby amitajune sleep neil young singing

Programmer hierarchy Luke Welling's programmer hierarchy, based on The Brunching Shuttlecocks' classic Geek Hierarchy, is humorous and accurate. tags: programming languages haha

Tag improvements So, I've made some improvements to the tagging system on this blog. Instead of doing a full-text search at runtime to lookup which pages contain which tag, I instead keep a map of tags to page names in a separate db, and then look up in that index at runtime. The bummer is that I'm not figuring out a way to keep that db up-to-date easily. The best action, of course, would be to have the tags db updated at write time, but I can't figure out how to make that work. I tried it with a write macro, but you can't get the title of the current page with a write macro, unfortunately. I might just add a hook to the commit action -- that's about all I'm coming up with right now. It's annoying that Wiliki doesn't have hooks enabled anywhere. Gar. tags: wiliki tagging optimization

My migration to the new Xen host is 75% complete. DNS changes appear to have finished and I’ve moved all the websites that I intended to move successfully. (Including databases & etc.) I’ve got three domains to move still, but I’m being very careful with them since they tie into “local” things like CVS repositories, or mailing lists + archive creation. The website migrations appear to have been a success, although I only noticed a couple of problems just now. In all cases my problems were:

• Symbolic links not being copied over to the new host correctly, leading to breakage. (e.g. This fine blog had a broken feed link because a symlink got trashed.)
• Missing packages/configuration on the new host. eg. CGI::Application module not being installed.

I’ve tested all the areas I can think of testing now. (e.g. “find /home/www -name ‘*.cg’ -print”; then executing each one in turn!) The next job will be the mail setup. My plan:

• Install new mailserver.
  • Configure virtual hosts.
  • Setup mailing list software (ha!)
  • Setup mail list archive creation.
  • Converting the “original” mailserver to treat the “new” as the mail relay - as per suggestion from Martin Krafft
• Flip mx record(s) over.
• Setup forwarding from old host to new host for a couple of days.
Sounds simple enough. What could possibly go wrong? (Sadly I know all too well virtually everything could go wrong.)

ATI is reported to not plan to release their drivers into OpenSource. Too bad. And I don't plan to buy any more ATI graphics. I'll go with Intel. Actually it would be sufficient if they would release the specifications. We don't really want to see their "patented optimizations" (which probably are just for cheating in known 3D benchmarks anyway, so what would we gain from that?). We'd be happy if we were allowed to distribute the already written independent driver. Which is blocked by an NDA, not by some "patented optimizations". Anyway, I'll buy a new laptop end of this year, and guess what - it will have Intel graphics. They've already released drivers for their next chip to be released. My current laptop, an IBM Thinkpad A31p, has an ATI graphics board. Which is not supported by the ATI driver. Fortunately there is an opensource driver which works fine, with 3D acceleration. Another reason I'm not going to buy any ATI, you never know when they decide to no longer support your board.

If you can see this I’ve not screwed up DNS too badly. Tomorrow I have to move SMTP. Joy. On the plus side moving SMTP should be trivial since all DNS hosts I manage use the same STMP server and there is just a single alias mail.steve.org.uk. I should be able to just setup the mailserver, update that record, then use rinetd, or similar, to proxy connections from the old IP to the new one until the DNS switch propogates. Complications include hosting mailing lists, and having mailing list archives be written to a new machine… Bed now. Beer first.

---

PS for those people that like to argue with Joerg Schilling please stop. It is beyond obvious now that arguing semantics is getting nobody anywhere, for the Nth time. I’ve come to the conclusion that when arguing discussing things with Joerg he will either wilfully ignore your point(s) or deliberately misintepret the evidence to support his stance. The chance of persuading him to change his mind? 0%. Give it up already. Think of the DVD-media children!! It really is time to either drop the cdrecord or fork it. Please. Somebody. Do it.

Debian development expected to halt! In a shocking revelation our reporter exposes a conspiracy to cover up the biggest risk to Debian development, ever! #debian-devel, the secret hangout of Debian movers and shakers, today casually discussed the possibility of the Debian bug tracking system running out of new bug numbers. This was the first hint of the impeding doom. When word leaked to our investigative reporter, he quickly dug into the case. Despite public protestations and secret threats, the truth was soon outed! Debian users will soon be unable to report new bugs. The bug tracking system uses a limited, fixed size integer for doing calculations on bug numbers, and the project is soon reaching its limits. With no new bugs to fix, Debian development can't continue. "We're already at six digits, there's only three more to go", says Lars Wirzenius, the Inquirer's resident technological expert. One wonders where the official annoucement is. Once again the Debian Inquirer delivers the scoop!

I said a few days ago that Ross Mayfield had one of the best blogs about wikis and the wiki business. But Eugene Eric Kim gives him a run for his money. EEK Speaks covers in detail a lot of the public and private aspects of wiki going on right now. Of course, I wouldn't paint EEK and Ross as rivals; after all, they won the Web 1.0 pitch contest at Wikimania together. tags: ross mayfield eek wikimania wiki blogs

Victory is mine (I think) For the last few weeks, some of the more advanced features of this wiki have been blowing up with a 500 Internal Server Error, to my great chagrin. I had switched from using CGI to FastCGI for WiLiKi and I'd seen a real improvement in the responsiveness of the site, but these occasional errors were becoming more frequent. I finally hunkered down to figure out the problem. Annoyingly, there was no error output in the Apache error logs, so I guessed that the problem was sooooo bad that the process didn't even get a chance to scream on stderr before dying. I had all kinds of theories about this. Most of the problems had to do with full-text searches of the database, so I guessed that the underlying cause had to do with I/O and concurrency. Gauche has a nice logging facility, so I threw in a lot of logging printf statements (or their equivalent) and isolated the problem to a few calls into Gauche's dbm libraries. Aha! The problem had to be concurrent DB access. I layered on a big slathery scoop of mutexes and locking and other such good concurrency stuff and... the problem was still there. D'oh! So much for my diagnostic skills. I decided to take a step back. After ascertaining for myself that any writes to stderr from within a FastCGI program should indeed show up in the error log -- by reading and by writing a couple of sample programs -- I turned to the debugging tool of last resort: strace. strace logs all system calls by a program, which can be a lot of information. I couldn't, of course, just start my FastCGI program, so I had to strace the entire Apache process, with lots of command-line flags to divvy up the output on a per-process level. Once I had that going, I could kind of see what was going on. My full-text searches were starting up fine, but about halfway through the search they'd get a SIGTERM and terminate. Holy moly! That wasn't an error in my program -- someone was murdering my poor little FastCGI processes. At first I suspected fratricide -- that the processes were terminating each other when they needed the database resource -- but I realized right away how dumb that was. That only left one suspect -- the parent! I dug a little bit into the fcgid documentation, and sure enough, if a process went too long without giving any output, fcgid would terminate it. I upped the time limit for this wait, and now all my search processes are working fine. I'm going to need to start doing something smarter with these full-text searches. I think doing some indexing at write time is the best bet -- that should probably speed stuff up quite well. But for the time being the processes will run, if slowly. The only bummer is now I have to go dig out all the mutex-y lock-y stuff I wrote earlier. tags: fcgid wiliki strace debugging fastcgi cgi 500

Apparently the government agencies in UK that are managing the current security craze have little to no idea how much their super-paranoid security policies acctualy cost. It appears that direct losses from one day of air traffic chaos costs airlines 175 million pounds. Everyone who has their flight delayed for more then an hour for whatever reason need simply to sue the airlines and further the UK government according the EU regulations. Each person delayed for just 4 hours can claim as much as 600 euros of compensations. I wonder what compensation must a person delayed 24+ hours get, considering missed meeting, needed hotel bookings and other expenses. Now if all passengers and all airlines united and sued the government for the compensations (those can be in billions, considering that no sane business person would fly without their mobile and notebook and no mother would want to fly without toys to keep their children happy, so that will cause huge decreese in flying), then the government will think twice before disturbing lives of tens of thousands of people even when all suspects have been arrested. And we do not even know if there was any terror plot. Last time there was a terror craze in the UK, a road was closed and isolated, a house was raided and then disassembled and a man was shot, but in the end nothing was found. Who will foot the bill this time? The news say that people will not receive any compensation even if they were insured, because “it was an extreme event”. WTF?! That is what regulations and insurance are for!!! And the minister is saying that they think that most restrictions will stay forever. No carry-on baggage? That is ridiculose. SUE THE UK GOVERNMENT!

Yesterday I was back again at the Parish to continue working on arete, the newly-installed Ubuntu Dapper machine. I was back because I had to continue migrating my father’s files from Windows to the new setup, since he wanted to try out Scribus as a replacement for his MS Publisher system for writing the parish newsletter. Anyhow, this reason, coupled with my own urge to seriously try out Ubuntu Dapper (I was running Kubuntu Dapper, doh) made me spend the whole day trying out something new. As I was looking at Dad’s documents folder, I realized that I had a problem: there are so many files here, some of them sizing up from tens to hundreds of megs (actually, stuff worked on thru the Gimp,) and knowing well that disk drive space was at a premium (arete had an 80G drive, yes, but nevertheless its already cramped,) I simply couldn’t accept copying the files from the XP’s NTFS C:\ to arete’s ext3 /home. Moving wasn’t an option either; although Dad would very much like to try out Ubuntu, he still had some projects (especially the newletter) that needed, uhm, proprietary software to work (sigh.) Thus, remembering that Linux already had some way of reading NTFS partitions, I promptly Googled about it. I also knew that the Linux-NTFS guys (who made the ntfsprogs suite and kernel module) were already working on getting full read/write NTFS support on Linux, but it didn’t occur to me that they were able to get a working implementation done so soon… Enter ntfs-3g: the third generation Linux-NTFS driver. Weighing in at around 550K, this seems to be the one thing that I need for my problem. From the looks of it, ntfs-3g can both read from and write to NTFS partitions, allowing one to create, delete, and update files and directories on the system; it can even allow access to certain metadata that even Windows XP hides from its users. Furthermore, its built from the ground up as a filesystem-in-userspace driver, using the Linux fuse subsystem. It certainly looks very attractive indeed. So, being the sysadmin for arete that I was, I quickly decided to give ntfs-3g a try. After all, it was a simple matter of grabbing the tarball, then reading the README, then doing the three-step tango of ./configure; make; sudo make install, then calling ntfs-3g /dev/hda1 /media/hda1 -o umask=007 as root. Right? Wrong. I quickly ran into a trio of subproblems: first, I needed fuse (>= 2.5.0); the one Dapper had on its official archives was 2.4.2 . So, naturally, I had to make a quick backport of the fuse source from Edgy (2.5.3), but I at this point I ran into the second problem: for Eggy’s fuse to get busted, I needed the new makedev (2.3.1) as well. Forgetting to do apt-get -f install for the moment, I grabbed Edgy’s makedev and proceeded backporting it, which ran me against the last problem: I also needed the newest sysvinit (2.86.ds1). In short, I needed to do a trio of backports first before being able to build ntfs-3g. My own fuse was almost ready to explode. Fortunately, everything went fine after the backports (thank goodness for my being a Debian package maintainer and MOTU,) so I didn’t break my own fuse after all. Soon after, I was reading and writing stuff to and from /media/hda1 without so much as batting an eyelash. Dad was definitely pleased, since that meant that he no longer had to dread the thought of having to maintain two separate document trees and cause him pain and gnashing of teeth. I was glad too, since I no longer had to dread the thought of having to hack on this today, causing me to disrupt my Summer of Code schedule. But, being the packager that I was, I realized that I could make the world a better(?) place by turning ntfs-3g from a regular Joe source to a real Debian/Ubuntu package. While I was happily waiting for ntfs-3g’s build to complete, I happened to pass by a certain HOWTO on the Web using pre-built fuse and ntfs-3g Ubuntu packages. I grabbed those packages, and took a look at them, and while they were pretty much useful, the ntfs-3g package certainly did not look to pass the gold(?) standards of Debian and Ubuntu: the ntfs-3g package was a single binary package, shipping both a shared library and its headers, coupled with the working binaries. It had outdated FSF addresses too, which my bugging Lintian pointed out to me. With some more extra time to spare on arete, I decided to go ahead and build proper a proper source package for ntfs-3g, producing the three binary packages ntfs-3g (containing ntfs-3g and mount.ntfs-3g,) libntfs-3g0 (depended on by the former package,) and libntfs-3g-dev (containing the include headers.) CDBS and debhelper definitely made this easy pickings, and made my life with ntfs-3g easier. And, I’m going to make everyone else’s life with ntfs-3g easier, by making this package available for nit-picking. I won’t pretend this to be getting into the official Debian and/or Ubuntu archives for the moment, since the upstream authors have explicitly stated that ntfs-3g will be eventually merged into the existing ntfsprogs suite, thereby making my packaging of ntfs-3g obsolete sometime soon; furthermore, the binary packages up there are built against Debian unstable and Ubuntu Edgy, so anyone looking for a Dapper solution can read this post first to avoid reinventing the wheel. But if anyone needs a good solution for NTFS read/write right now (or, if somebody else has time to kill in testing ntfs-3g,) then here’s a good one for you. Caveat emptor!  Ok, next up: finishing my SoC work…

Coincidentally with Madduck's account, yesterday night, my institute lost power for about five hours. This by itself surprises me, as at home (only ~300m away) I stayed awake late, and didn't notice this until I got to my office and my desktop had rebooted.
Any damage? So far, only minor things - i.e. the Gaim buddy list... Nevertheless, it might be minor, but there is always _something_. And I don't want to wait until massive fsckup happens. And, since I'm already using ext3 as it is more solid for my root partition, I think I will be switching back to it. Specially at my servers, where I still value more reliability over speed. Julien agrees. And... Well, although I know Ingo knows internals much better than I do, I have to doubt on Julien agrees. And... Well, although I know Ingo knows internals much better than I do, I have to doubt on /blog.windfluechter.net/?q=node/129">/blog.windfluechter.net/?q=node/129">his assertions.

The Dell saga goes into second stage. Despite me having a priority XPS next day on-site warranty it took three days, one click-trough of on-line wizard, two emails and three phone calls to get the collection of my broken laptop going. And now it will only be collected on Monday. Doh! I wonder how much it will actually take from the first problem report until I get my system back into a fully functional state. I was counting on being up and running by the end of the week, but apparently that is not happening.

Some days ago, RedHat claims that Xen is not ready yet for production environment. Now, Novell strikes back and defend their inclusion of Xen in their latest SUSE release. That's so funny, because in fact they don't give any concret argument. RedHat says that it's not mature, and Novell just answers that they've contributed to the code. As a member of the Debian Xen team, I'll arbitrate between us. Xen is nowadays deployed in a lot of solution and in a lot of system architecture. I don't think this is because the Xen technology is mature, but only because it's the solution which fit the best the need of virtualization (and cost rationalisation) that organizations may have. Xen can not pretend to be stable, mature, or whatever you want, because it is still not integrated into the Linux kernel tree, and thus far for a good reason: the API/ABI is not yet stable.
I know that in theory it is, but in fact it's quite wrong and you cannot rely on that specification. Xen works fine but from a developer point of view it is not in a stable and fixed shape. It seems that Linus and others kernel people are not very happy to integrate directly Xen into the mainline kernel, and I can understand them, since this technology is rather new. I don't think Xen will be a suitable solution which can be deployed for years until Linus decide to integrate a virtualization system into the Linux kernel. Furthermore, Xen is still a huge source tarball of mess with a big kernel patch. And even if I really think that Xen will be the adopted solution for everyone, it won't be in its current state. So, I think RedHat is pretty right. Just think about the Xgl/AIGLX stuff, that's quite again the same behavior between this two companies.

Woah, they are really fast, yesterday I included an e-mail address I've never used before on this blog and I've already received SPAM on it. I've changed my address at the page templates by a tr command:

 echo -n abweqsq@@@uqfqvmb.vmb   tr -s @a-z@ @s-za-r@ 

I don't know if it will be useful, but at least it looks a lot more freaky ;).

Lately I have been trying out a number of distributed version control systems (VCS or SCM).

One of my tests was a real problem: I wanted to track the Linux 2.6.16.x kernel tree, apply the Xen patches to it, and pull only specific patches (for the qla2xxx driver) from 2.6.17.x into this local branch. I wanted also to be able to upgrade to 2.6.17.x later (once Xen supports it) and have the version control system properly track which patches I already have.

But before going on, let's establish what it means to be an ideal distributed VCS:

• 1. The fundamental method of collaboration must be a branch. A checkout should mean creating a local branch on which a person can commit and work without having to involve the server. An update from some central server should take the form of a merge from that branch to the local branch.


• 2. Branching should be cheap. It should be easy to create a local branch, the operation to do so should be fast, and it shouldn't take an inordinate amount of space. It should also be as easy as possible to branch from a remote repository.


• 3. Merging between branches is intelligent. It should be easy to merge another branch with your own. The VCS should know which changesets from the other branch are already on yours, and should not attempt to merge changesets that you have already merged previously.


• 4. Inividial changesets should be mergeable without bringing across the whole history. You should be able to bring across the minimum number of changesets necessary to effect a specific change. This corresponds to my test case above. Future merges from the whole branch should, of course, recognize that these changesets are present already.


• 5. Branching preserves full history. A branch should be a first-class copy of a repository, even if the repository is remote. It should contain the full history of the branch it was made from, including diffs for each individual changeset and full commit logs, unless otherwise requested by the user.


• 6. Merging preserves full history. A merge from one branch to another should also preserve full history. Changesets merged to the local branch should retain the individual, distinct diffs and commit logs for each changeset.

There are also some things that we would generally want:

• 7. It is possible to commit, branch, merge, and work with history offline.


• 8. The program is fast enough for general-purpose use.

Evaluation

Let's look at some common VCSs against these criteria. I'll talk about Arch (tla, baz, etc), bzr (bazaar-ng), Darcs, Git, Mercurial (hg), and Subversion (svn) for reference.

1. The fundamental method of collaboration must be a branch
All of the tools pass this test except for svn.

2. Branching should be cheap
Everyone except svn generally does this reasonably well.

The tla interface for Arch had a pretty terrible interface for this, so it took awhile simply due to all the typing involved. That's better these days.

Darcs supports hardlinking of history to other local repositories and will do this automatically by default. Git also supports that, but defaults to not doing it, or you can store a path to look in for changesets that aren't in the current repo. I believe Mercurial also can use hardlinks, though I didn't personally verify that. bzr appears to have some features in this area, but not hardlinks, and the features were too complex (or poorly documented) to learn about quickly.

svn does not support branching across repositories, so doesn't really pass this test. Branches within a repository are not directly supported either, but are conventionally simulated by doing a low-cost copy into a specially-named area in the repository.

3. Merging between branches is intelligent
Arch was one of the early ones to work on this problem. It works reasonably well in most situations, but breaks in spectacular and unintelligble ways in some other situations.

When asked to merge one branch to another, Darcs will simply merge in any patches from the source branch onto the destination which the destination doesn't already have. This goes farther than any of the other systems, which generally store a "head" pointer for each branch that shows how far you've gone. (Arch is closer to darcs here, though ironically bzr is more like the other systems)

Merging between branches in svn is really poor, and has no support for recognizing changesets that have been applied both places, resulting in conflicts in many development models.

4. Inividial changesets should be mergeable without bringing across the whole history
Darcs is really the only one that can do this right. I was really surprised that nobody else could, since it is such a useful and vital feature for me.

Both bzr and git have a cherry-pick mode that simulates this, but really these commands just get a diff from the specific changeset requested, then apply the diff as with patch. So you really get a different changeset committed, which can really complicate your history later -- AND lead to potential conflicts in future merges. bzr works around some of the conflict problems because on a merge, it will silently ignore patches that attempt to perform an operation that has already occured. But that leads to even more confusing results, as the merge of the patch is recorded for a commit that didn't actually merge it. (That could even be a commit that doesn't modify the source.) Sounds like a nightmare for later.

Arch has some support for it, but in my experience, actually using this support tends to get it really confused when you do merges later.

Neither Mercurial nor svn have any support for this at all.

5. Branching preserves full history
git, darcs, and Mercurial get this right. Making a branch from one of these repos will give you full history, including individual diffs and commit logs for each changeset.

Arch and bzr preserve commit logs but not the individual changesets on a new branch. I was particularly surprised at this shortcoming with bzr, but sure enough, a standard bzr merge from a remote branch commited three original changesets into one and did not preserve the individual history on the one commit.

svn doesn't support cross-repo branching at all.

6. Merging preserves full history
Again, darcs, git, and Mercurial get this right (I haven't tested this in Mercurial, so I'm not 100% sure).

Arch and bzr have the same problem of preserving commit logs, but not individual changesets. A merge from one branch to another in Arch or bzr simply commits one big changeset on the target that represents all the changesets pulled in from the source. So you lose the distinctness of each individual changeset. This can result in the uncomfortable situation of being unable to re-create full history without access to dozens of repositories on the 'net.

Subversion has no support for merging across repositories, and its support for merging across simulated local branches isn't all that great, either.

7. It is possible to commit, branch, merge, and work with history offline
Everyone except Subversion does a good job of this.

8. The program is fast enough for general-purpose use
All tools here are probably fast enough for most people's projects. Subversion can be annoying at times because many more svn commands hit the network than those from others.

In my experience, Arch was the slowest. Though it was still fine for most work, it really bogged down with the Linux kernel. bzr was next, somewhere between arch and darcs. bzr commands "felt" sluggish, but I haven't used it enough to really see how it scales.

Darcs is the next. It used to be pretty slow, but has been improving rapidly since 1.0.0 was released. It now scales up to a kernel-sized project very well, and is quite usable and reasonably responsive for such a thing. The two main things that slow it down are very large files (10MB or above) and conflicts during a merge.

Mercurial and git appear to be fastest and pretty similar in performance.

All of these tools perform best with periodic manual (or scheduled cron jobs) intervention -- once a month to once a year, depending on your project's size. Arch users have typically created a new repo each year. Darcs users periodically tag things (if things are tagged as part of normal work, no extra work is needed here) and can create checkpoints to speed checkouts over the net. git and Mercurial also use a form of checkpoints. (not sure about bzr)

Subversion works so differently from the others that it's hard to compare. (For one, a checkout doesn't bring down any history.)

Conclusions
I was surprised by a few things.

First, that only one system actually got #4 (merging individual changesets) right. Second, that if you had to pick losers among VCSs, it seems to be Arch and bzr -- the lack of history in branching and merging is a really big issue, and they don't seem to have any compelling features that git, darcs, or Mercurial lack. #4 was a unique feature to Darcs a few years ago, but I figured it surely would have been cloned by all the other new VCS projects that have popped up since. It seems that people have realized it is important, and have added token workaround support for it, but not real working support.

On the other hand, it was interesting to see how VCS projects have copied from each other. Everyone (except tla) seems to use a command-line syntax similar to CVS. The influence of tla Arch is, of course, plainly visible in baz and bzr, but you can also see pieces of it in all the other projects. I was also interested to see the Darcs notion of patch dependencies was visible (albeit in a more limited fashion) in bzr, git, and Mercurial.

So, I will be staying with Darcs. It seems to really take the idea of distributed VCS and run with it. Nobody else seems to have quite gotten the merging thing right yet -- and if you are going to make it difficult to do anything but merge everything up to point x from someone's branch, I just don't see how your tool is as useful as Darcs. But I am glad to see ideas from different projects percolating across and getting reused -- this is certainly good for the community.

Updates / Corrections
I got an e-mail explaining how to get the individual patch diffs out of bzr. This will work only for "regular", non-cherry-picked merges, and requires some manual effort.

You'll need to run bzr log, and find the patch IDs (these are the long hex numbers on the "merged:" line) of the changeset you're interested in, plus the changeset immediately before it on the same branch (which may not be on the same patch and may not be obvious at all on busy projects.) Then, run bzr diff -r revid:old-revid-string..new-revid-string.

I think this procedure really stinks, though, since it requires people to manually find previous commits from the same branch in the log.

Today I decided to start learning Python. I am sick of Perl. I used to be quite good but now I totally lost my power and it's too hard to reuse code I wrote years ago, since I barely understand it. To begin, I decided to play with Paramiko, a module for using ssh with Python.
Unfortunately, I was unable to simple use from paramiko import * so I was totally disapointed. Fortunately, a python developer working near me helped me to understand why it did not work. And it was actually a bug :-) which is now reported as #382348. I am very amused by falling on a bug with my first line of Python. But be sure I will continue to use it to develop a little tool for my personnal usage. ;-) I know the pitoon! I know the pitoon!

Wouter Verhelst asked why simple games are so slow nowadays.

I think the problems are in the libs. All this modern stuff tries to become more and more modern, and get more and more stuff out of all those new render extensions, direct graphics and hardware accelerations. There simply is no way to decide which way is faster, so libraries have to guess. So it is no suprise things go wrong. And the place they go wrong are of course not the fast computers, but the older stuff, that does not has those nifty accelerations and no fast CPU to cancel it out.

Another disadvantage are all those "portable" libaries. SDL for example needs three connections to the X server before it does anything. Three times etablishing a connection, checking of security cookies, and so on. Its API looks like living with windows, or never intended to be use for anything other than full-screen mode. (You want to find out how large the window is? Why should you be able to when you said the window cannot be resized?)

QT likes to use extensions, too. I don't know if it is its fault or newer X servers, but the newer your installation gets, the slower 2D games using QT can become. (Note the can, if you have the right graphics card, lucky you, if you have the wrong one, bad luck). To be fair QT is not supposed or designed for 2D games. On the other hand I don't know what it is supposed to do other than being a C++ compiler benchmark measured in hours.

GTK was such a promising design. Object orientated (widget classes are one of those very few things were object orientated can be used with more advantages than disadvantages) but still plain C, small and looking like designed for X. To be fair, I do not even know how well it performs, as the ever increasing library cancer drives me away. From the "users should not be able to change their homedir, that would be far too much the Unix way" glib, over all this miriad of differt little libraries, all moving all the time, spewing their headers in so many different directories a compiler invocation folds three time around your terminal.

Well, enough ranted. My next graphical program will use Athena Widgets. I only have to hope all this reanimated X development in the last time will not pull xlib away from under out feets in the future...

The “foiled” terrorist attack looks suspiciously like an attack on the underlying system, rather than an actual attempt to blow planes up - it’s almost laughable that terrorists in this day and age could hope to get explosive devices onto planes in hand luggage. If we decide that the terrorists aren’t stupid, the attack begins to look decidedly different. They’ve succeeded in causing absolute chaos in one of the busiest weekends in the british airline calendar, the effects of which will probably drag on for a few days. If you wanted to be really nasty, they’ve also caused a large number of people to be trapped in one place, and extremely vulnerable to attack. The BBC report says Heathrow Terminal 1 is “jam packed”. I suspect that a terrorist organisation will look at something like this as relatively cheap, too - 18 peons arrested, sure, but we know they can afford the manpower and they’ve once again demonstrated that the air travel infrastructure our society is so reliant on is extremely fragile and vulnerable.

A half an hour ago my brand new Dell XPS M1710 laptop stopped working. It just turned off and would not turn on again. I got my old HP lappie out and went to Dell site for debugging. After several quite nice debugging steps the fault fell into a generic “no idea what it is, but it sure is bad” category and I was told to contact the support, which I did - by email. Let’s see how long it takes to get this thing fixed and how will they respect my Linux partitions if I will need to send it in.
Oh well, that means that I will go to bed early today - yay! (P.S. As one might note, I am very keen to find good thing behind anything. I got into this habit when I was fired from my job last January. It helped me a lot. Repeat after me - every change is for good. It is that simple, you just need to find the good things sometimes. Sometimes it is hard, but the search is rewarding.)

Now thats what I'd call good news (URL from #debian-devel) This infoworld article claims:

AMD is strongly considering open-sourcing at least a functional subset of ATI's graphics drivers

Well, the article has some other facts wrong:

If AMD's graphics cards were the only ones with open device drivers, it might affect a buying decision or two.

Well, you know. There is not only Nvidia. There is Intel. And for both the R200 ATI Radeon series and the Intel video chipsets there are opensource drivers with 3D acceleration. It's not as if AMD/ATI would be the "only ones". Wait. Intel? Isn't that like the main competitor of AMD... AMD should better try to draw even! But yeah, if AMD would do that, Nvidia would have some issues selling their stuff to Linux users. Manufacturers that try to sell desktop linux computers will prefer AMD if it's better supported out of the box (for servers, neither ATI nor Nvidia is relevant, of course). For example Lenovo is reported to (plan to?) sell Thinkpads with SuSE Linux preinstalled (I'd actually prefer if they would sell them with FreeDOS preinstalled at a lower price); but if they preinstall the NVidia drivers (and some other things such as Intel wireless), they might violate the GPL or some of the other licenses, apparently. I don't know, just hearsay.

After some time thinking about it I've moved my blog from PyBloxsom to ikiwiki; I'm still playing with it and the site needs some work, but it seems to work ok and the default look and feel is good enough for me. This post is written using Markdown to give it a try, but I wrote a simple plugin to add (partial) support for rst to be able to keep all my old entries without additional editing. I've sent the file to joeyh and I hope it gets into the upstream code (improved, if possible), as that will remove the need to keep my local changes in sync with the debian package. I have not enabled the ikiwiki.cgi because the machine I'm running it is quite slow and anyway I only need it for comments, and I usually don't have many of them. Instead of enabling comments I've added a footer asking people to send comments to echo -n klgoaca@@@eapafwl.fwl tr -s @a-z@ @i-za-h@ instead. To avoid flooding planet I've used the ikiwiki flood prevention mechanism, previous posts can be reached through the categories and/or using the full Blog index. Update I've been told that there is a Perl library to parse rst. I knew someone was working on it, but have not seen code until now; the package is called Text-Restructured and it is available from the URL http://search.cpan.org/dist/Text-Restructured/. Probably my hack could be replaced by code that uses this module instead of calling python to parse the files... any volunteers?