Nick Andrew News

In From Win32 to Cocoa: a Windows user's conversion to Mac OS X—Part II, Peter Bright writes:

So Windows is just a disaster to write programs for. It's miserable. [...]

The code isn't just inconsistent and ugly on the outside; it's that way on the inside, too. There's a lot of software for Windows, a lot of business-critical software, that's not maintained any more. And that software is usually buggy. It passes bad parameters to API calls, uses memory that it has released, assumes that files live in particular hardcoded locations, all sorts of things that it shouldn't do. If the OS changes underneath—to prohibit the reuse of freed memory, to more aggressively validate parameters, to stick more closely to the documentation without making extra assumptions or causing special side-effects—then these programs break.

So Windows has all sorts of bits of code which are there to provide compatibility with these broken applications. It's hard for MS to maintain and fix this code, because it means the code no longer does what it's documented to do; it does that plus some other stuff. It's hard to test, because there's no knowing exactly what broken things programs are going to try to do. And it makes things more expensive; Microsoft has all sorts of special behaviours it needs to preserve. This means that not only can it not make the API better—it can't even easily make the API's implementation better. It's all too fragile.

It's nice to see confirmation of this from an experienced Windows programmer. Since I don't program for Windows at all, my opinions are based on what I see and read about Windows, rather than coal face development experience. The take-home message from this article is that mediocrity rules the Windows development ecosystem; although there are no doubt many developers who write high quality Windows applications, there are also many who do not, and Microsoft supports the latter to the detriment of the former.

I've become a recent convert to distributed SCM systems, particularly Mercurial and Git.

Use of a distributed SCM is a much more sensible way to release open source software than the traditional tarfile, or even having a public CVS or SVN repository. In particular:

• It makes it easy for users of the software to feed back their local changes, which encourages more participation and development of the code
• It helps users maintain their own local changes in an SCM
• It helps users upgrade to newer releases (without wiping out their local changes, for instance).

Having a public CVS or SVN repository solves only the problem of giving users quick access to the latest version of the software. CVS and SVN don't help with feedback or maintenance of local changes. They can help with upgrades - but it's of little practical benefit when local changes can't be committed into the repository.

I was in the process of converting my CVS repositories to SVN (it takes a long time) when I discovered the virtues of Distributed SCMs. I'm using both Git and Mercurial. Git is perhaps more powerful but Mercurial is more user-friendly. So I have halted all conversion to SVN and I'll be converting remaining repositories to Mercurial. I'll be converting most of my SVN repositories over to Mercurial too. Ultimately the only code/data remaining in SVN will be that which I particularly need to be centralised (it might end up being none at all).

I have started to put some repositories of my public source code online already. The full list is available at: http://www.nick-andrew.net/hg and individual repositories which are currently online are:

Here's a patch which I believe solves the recent linux local root problems, for the latest stable OpenVZ kernel (2.6.18-028stab053).

To run linux guests I can highly recommend OpenVZ. It's a container system - you run only the host kernel which is modified to implement isolation between containers and each other, and the host. Processes in the containers run as processes on the host, with a container-specific root directory.

The upshot of all this is that overhead is almost zero; each guest runs at almost native speed. There are various other benefits too, such as:

• The guest root filesystem is a directory on the host, so the host has full visibility to the guest files. It isn't necessary to preallocate space to each guest, so there's no wasted space and each guest can grow dynamically.
• Resource utilisation limits are enforced and can be modified on the fly.
• Guests can be minimal because they don't have to support hardware. A typical guest, before installing additional software, may be running only these processes: init, syslogd, sshd and cron. 4 processes - and you don't even need cron.
• Networking is very easy to get going (unlike user-mode-linux).
• Using templates, you can have a new guest installed and running in under 2 minutes.

There are some caveats though:

• The host kernel is modified in many places. The latest stable patch is over 4M.
• Not every linux kernel version is supported. The latest stable, supported patch is against 2.6.18 or you can use a development level patch against 2.6.22
• You can see all the guest processes on the host; it can be tricky to know which guest a given process is running on.
• Some kernel functions are restricted, such as kernel-space NFS server (use the userspace one instead).

Overall OpenVZ is very stable and functional. I haven't had any kernel crashes related to OpenVZ. I would like them to support newer kernels - specifically 2.6.23 and above, since there are features in 2.6.23 that I want to use. But the patch is quite extensive and so I can't really blame them for picking a version and sticking with it for a long time. OpenVZ patch developers have contributed many security and stability fixes back to Linus. One day, much of OpenVZ will be integrated into the mainline kernel. Already 2.6.24 supports PID namespaces (in which process IDs are unique to each guest, not the host) and further OpenVZ functionality will move into the mainline kernel over time.

Importing my bank account history today from a CSV file exported by the bank's website, as I do every month, and the import failed. The reason was that the bank changed the dates on several transactions made from December 2007 to as early as April 2006. The dates were changed from 17th or 16th to 15th in each case.

What is it about banks that they can arbitrarily change transaction dates, even 12+ months after the transaction occurs? This could have been legally problematic for me, say if I had to transfer money by a certain date (and did that) and sometime later the bank's "official" record of the transaction has changed.

What has happened is that my financial records now no longer agree with those of the bank, for no good reason, and I have to adjust mine accordingly, or else there will forever be a discrepancy.

Firmware for the LifeView TV Walker Twin (DVB-T USB digital TV receiver) can be found here at dvb-usb-tvwalkert.fw. Copy the file (without renaming it) into /usr/lib/hotplug/firmware/. This is needed to make the device work in linux.

I'm working on a driver and it will be merged into the linux-dvb project repository in a few days.

AA 85 6A 1B A8 14 AB 99 FF DE BA 6A EF BE 1C 04

It seems that the software raid1 superblock version 1.0 is not fully supported by linux. I created two raid1 arrays, one with a version 0.90 superblock and the other with version 1.0. During kernel boot, the md autoconfiguration found the 0.90 superblock array, but said it could not find a superblock for the other array.

Furthermore, LILO refuses to install onto a raid1 array with a version 1.0 superblock. As soon as I converted it to version 0.90, LILO worked fine.

Lastly, the manpage for pivot_root(2) fails to note that the system call cannot be used to move away an initramfs. I dug into the kernel source code and it's clearly noted in a comment above the function definition.

09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0

It took me just one hour to write a tiny web template tool in perl which is now driving this website. The news items are now included using the following tag:

This instantiates the 'News' module and runs it with the supplied arguments.

The key to getting it going so quickly was that it processes the same SHTML files which I used to use to give the site a consistent layout. It parses the '#include' directives and runs itself recursively on the specified filename. Thus, I was able to move the site to the templating CGI script without changing any of the content files. I then added the tag parser to instantiate modules from a "Plugins" directory, and wrote a News module to read a sequence of news items from individual files in a directory. Finally I split the single news.html file into one file per news item.