First day of the Rugby World Cup around here. Here are some of my impressions (for those of you not aware, I'm a rugby fan for ages and this event in my country will definitely affect my work on free software in the next 6 weeks). France-Argentina (12-17): being beaten by Argentina is a surprise only for people who don't know that much about Argentina in rugby. Argentina is currently ranked 6th in the world national team ranking, very close to Ireland (5th) and before England (7th), the last RWC winner. The argentinians played the best rugby they could play against a very hesitating French team. All players know each other very well as 2/3 of the Argentinian team plays...in France. The world's top player (imho), Juan Mart n Hern ndez, lead his team to victory while the french were anything but brilliant. Nothing really harmful, indeed: in rugby, completely screwing a match happens and does not necessarily mean anything for other games. Only drawback, if France qualifies, it becomes more and more likely that the 1/4 final could be France-New Zealand. Ouch... New Zealand-Italia (76-14): I haven't seen that one, therefore missing the first "haka" of that RWC. All Blacks are still the favourites of the RWC and they scored the quickest try as of now. Italy team fought quite well, from what I read, with one of my favourite players (Maurizio Bergamasco) scoring a try. Australia-Japan (91-3): in the past, Japan was closer to the top rugby world teams, particularly because of a long tradition of playing 7-players rugby and therefore being very efficient in rear lanes play. However, rugby changed last years and the power is the key. The japanese team was obviously lacking it...and then they had 14 tries scored against them by a very strict Australian team. England-USA (28-3 as I'm writing this): England is not that impressive but serious, still. The USA team plays well around the scrum and defend pretty well. On the English side, Mike Catt could be one of the stars of that RWC. And, yay, while writing this, USA scored a try against England *and* Lawrence Dallaglio got expelled for 10 minutes. Two occasions for me to be happy..(sorry in advance to my friends in England). Tomorrow, we'll attend South-Africa vs Samoa at Parc des Princes, Paris. That will definitely be a great feast and a nice rugby match. We'll of course put our heart on the Samoan side (I'm afraid I've never been enthusiast with the South African way to play rugby).

After searching for new gallery and investigating lazygal, I finally decided it's time to give it some real world usage. My current album from Japan is being processed by this damn fast tool. It needed a bit of hacking, but as the core was already there and Alexandre Rossi is quite cooperative upstream. I managed to implement almost everything I requested in original post. The only thing I'm still not completely happy with is the theme, but I hope I will improve it over time. From original requirements, I completely dropped links to full size images. There is simply no reason to put here crappy pictures which my only camera I currently have here (built in camera in Nokia 6234) produces. Also once I'll buy new camera (what will be most likely Pentax K10D), I probably won't upload huge 10Mpix images on web server as I don't think it would be good for anything else than wasting my bandwidth.

Just trying to get some data "out-there" on this issue because I'm seeing duplicate bugs being filed and I can't get any response from GnuCash Bugzilla - probably because bug-buddy is busy filing lots more duplicate bugs upstream about a problem that is entirely within Debian.
The latest upgrade of g-wrap is borked and this leads to the g-wrap binary being installed at version 1.9.9-1 when the rest of the g-wrap package is held back due to the transition from libgwrap-runtime0 to libgwrap-runtime2.
This broken transition breaks gnucash. A simple error message if only g-wrap is upgraded, a complete seg fault crash if guile-g-wrap is upgraded too.
So far, we have 3 bugs in Debian:

• 441129 gnucash: fails to start after upgrade of g-wrap 1.9.9


• 441248 gnucash: Do not start anymore after last unstable upgrade


• 441309 gnucash crashes on start

Please don't add any more. The real bug is 441103 in the g-wrap package and the fix is described in my response to 441248 as:

GnuCash is usable if you can revert to the version of g-wrap in

testing. I'm running it now with:

$ cat /etc/apt/preferences 

Package: g-wrap

Pin: version 1.9.6-3.2

Pin-Priority: 1001



Package: guile-g-wrap

Pin: version 1.9.6-3.2

Pin-Priority: 1001



i.e. there isn't anything wrong with gnucash and if g-wrap had

transitioned properly, the g-wrap binary would not have been upgraded

to 1.9.9 on your system until gnucash could use libgwrap-runtime2

instead of libgwrap-runtime0. With the correct dependencies set in

g-wrap, this whole gnucash problem would have been avoided cleanly.

There is a separate RC bug against gnucash because of this transition: gnucash: FTBFS due to g-wrap transition. which does NOT affect the currently installable and usable version of gnucash in sid.

Thanks.

After dealing with Optus phone support [1] in regard to a routine request for a password change I have been thinking about better ways of managing password changes for a large ISP. The first criteria is that the user must have a password that is difficult to brute-force attack at all times. Changing a password to a supposedly temporary value that can be easily guessed (such as “changeme“) is never acceptable. The next criteria is that the help-desk operator should be trusted as little as possible and it would be ideal if they never knew the password. One possibility that occurred to me is that each bill could have a six-digit pseudo-random number printed on it. This number could be used as an alternate password. When a customer calls up because they lost their password they almost always have their last bill (this is why they print the number for phone support on each bill). The help-desk operator could then push a button on a web based form that makes this pseudo-random number be their new password, thus the help-desk operator would not know the new password and the user would also have it printed out clearly which avoids the confusion from having a password read out in a foreign accent. Another possibility is to have the password change infrastructure integrated with the CTI [2] system, then the help-desk operator could push a button and have the computer dictate the password without the help-desk operator being able to listen in. There will always be corner cases where a help-desk operator has to change the password, but if these are rare because the automated system handles most cases then the potential for damage would be limited. Of course it would also be a really good idea to do some statistical tracking of the number of password change requests performed by each operator and investigate those who do significantly more than average. In the past AOL has experienced a variety of security problems related to trojans [3] which probably would have been discovered by such analysis. Another possible option is that customers with mobile phones could have their new password sent to them by SMS. It’s quick, easy, cheap when done in bulk, and is much harder to intercept than most methods that might be used for transferring passwords. References:

1. http://etbe.coker.com.au/2007/09/03/optus-password-changeme/


2. http://en.wikipedia.org/wiki/Computer_telephony_integration


3. http://www.wired.com/techbiz/it/news/2003/02/57753

Share This

As you may have noticed, X.org 7.3 has been released yesterday. This means that the new Xserver 1.4 will land in unstable in the near future. All input and video drivers will have to be rebuilt since the ABI changed. Which xserver-xorg-video-ati version do you want us to rebuild and upload to Sid? The latest upload of xserver-xorg-video-ati (6.6.3) to Sid occurred on October 14th 2006. This release was pretty solid, but it might be too old to deserve another rebuild with a recent Xserver. No new stable release happened in the meantime. Several release candidates arrived in experimental (6.6.19[123]), the latest one was pretty stable too, with better support for some boards. Then, the randr-1.2 branch got merged upstream and a new cycle of release candidates started (6.7.19[12]), but I personally think they are NOT stable enough for Sid (various lockups here). So I think we will upload the current head of the ati-6.7-branch in Sid. It means, 6.6.193 with several fixes. The new RandR-1.2-aware + TV-out-aware driver (6.7.192) would remain in experimental for a little while. If you want to give a try before the big upload of xserver-xorg-core 1.4 and updated drivers, a bunch of them are available on alioth, see this.

Thanks to a patch from Mathieu Geli, live-initramfs as of version 1.99.1-1 supports a boot parameter called fetch. That means, that it is enough to have a bootloader (syslinux, grub, whatever) and a kernel with the initrd image on a medium (cdrom, usb-stick, whatever) to boot a Debian Live system directly from the Internet or the local network without needing to setup a netboot environment (as in PXE). Just type:

	live fetch=http://example.com/my_squashfs.img

at the boot prompt. Whithin the boot process of the live system, the squashfs image will be once downloaded into RAM. After that point, no network access is required anymore. This is also the reason why it was invented initially, it is an alternative to the conventional netboot (PXE with tftp for boot and shared root over a network filesystem such as cifs, nfs or smb) where permanent network access is required, not a replacement. Temporary limitations

• At the moment, the amount of RAM required to run a web booted live session is equal to the size of the squashfs image. Because squashfs compression is quite good, this is not so much of a problem on reasonably modern machines (512MB for a complete Xfce Debian desktop, 758MB for a complete GNOME or KDE Debian desktop system). Nevertheless, improvements to use a local swap partition to store the image are on the way (including caching and updating).
  
  
• Due to a still pending move of the machine where live.debian.net is hosted, there are not yet autobuild squashfs images available. Later, you can just boot with something similar as: live fetch=http://live.debian.net/webboot/etch.

* Sometime back, I came to know this little cool tool for previewing and comparing fonts. Did RFP–>ITP and then I came to know that it has one file gnome-specimen-about.svg under cc-by-sa license (Thanks to Torsten Werner for pointing out!). What to do?? I searched over packages and found that atleast one package is under similar license. So, I went ahead and submitted package (Was it brave step?). It took long time in NEW (due to license issue), but finally it got place. I contacted author (Wouter Bolsterlee) and told about this. A nice discussion followed. Tried Inkscape, no luck. And finally, 0.3.1 is with-out that cc-by-sa license!! You can get upstream tarball here. /me (Debian package will hit soon!)

Hello World I have finally a new Hackergotchi, I can’t do that myself since I’m quite unable to do any graphics work. So my coworker Markus Roth helped me, thank you! I will upload it to the SVN and modify the configfile according as soon as the CVS->SVN migration for planet.debian.org is over. Thanks and Regards,

A fairly common request is to be able to duplicate a Xen instance. For example you might have a DomU for the purpose of running Wordpress and want another DomU to run MediaWiki. The difference in configuration between two DomU’s for running web based services that are written in PHP and talking to a MySQL back-end is quite small, so copying the configuration is easier than a clean install. It is a commonly held opinion that a clean install should be done every time and that Kickstart on Red Hat, FAI on Debian and comparable technologies on other distributions can be used for a quick automatic install. I have not yet got FAI working correctly or got Kickstart working on Xen (it’s on my todo list - I’ll blog about it when it’s done). Regardless of whether it’s a good idea to copy a Xen DomU, there are often situations where clients demand it or when it’s impractically difficult to do a fresh install. I believe that the most sensible way to store block devices with Xen is to use LVM. It is a requirement for a Xen system that you can easily create new block devices while the machine is running and that the size of block devices can be changed with minimal effort. This rules out using Linux partitions and makes it unreasonably difficult to use LUNs on a fiber-channel SAN or partitions on a hardware RAID. LVM allows creating new block devices and changing the size of block devices with minimal effort. Another option would be to use files on a regular filesystem to store the filesystem data for Xen DomU’s, if choosing this option I recommend using XFS [1] filesystem (which delivers good performance with large filesystems and large files). If you use XFS to store the block devices for the DomU that you want to copy then you will need to halt the DomU for the duration of the copy as there is no other way of getting an atomic copy of the filesystem while it’s in use. The way of doing this would be to run the command “xm console foo ; cp /mnt/whatever/foo-root /mnt/whatever/bar-root ; xm create -c foo” where “foo” is the name of the DomU and “/mnt/whatever/foo-root” is the file that is used to store the root device for the DomU (note that multiple cp commands would be needed if there are multiple block devices). The reason for having the two xm commands on the one line is that you initially login to the DomU from the console and type halt and then the xm command will terminate when the DomU is destroyed. This means that there is no delay from the time the domain is destroyed to the time that the copy starts. If you use LVM to store the block device then things are a little easier (and you get no down-time). You simply run the command “lvcreate -s -L 300m -n foo-snap /dev/V0/foo-root” to create a snapshot with the device name /dev/V0/foo-snap which contains a snapshot the of the LV (Logical Volume) /dev/V0/foo-root. The “-L 300m” option means to use 300Meg of storage space for the snapshot - if the writes to /dev/V0/foo-root exceed 300Meg of data then your snapshot breaks. There is no harm in setting the allocated space for the snapshot to be the same as the size of the volume that you are going to copy - it merely means that more disk space is reserved and unavailable for other LVM operations. Note that V0 needs to be replaced by the name of the LVM VG (Volume Group) Once you have created the snapshot you can create a new LV with the command “lvcreate -n new-root -L X /dev/V0” where X is the size of the device (must be at least as big as the device you are copying) and then copy the data across with a command similar to “dd if=/dev/V0/foo-snap of=/dev/V0/new-root bs=1024k“. After the copy is finished you must remove the snapshot with the command “lvremove /dev/V0/foo-snap” (please be very careful when running this command - you really don’t want to remove an LV that has important data). Note that in normal operation lvremove will always give a prompt “Do you really want to remove active logical volume“. If you made the new device bigger then you must perform the operations that are appropriate for your filesystem to extend it’s size to use the new space. There is no need to copy a swap device, it’s easier to just create a new device and run mkswap on it. After copying the data you will need to create the new Xen config (by copying /etc/xen/foo to the new name). Make sure that you edit the Xen config file to use the correct block devices and if you are specifying the MAC address [2] by a “vif” line in the config file make sure that you change them to unique addresses for your LAN segment (reference [2] has information on how to select addresses). Now you must mount the filesystem temporarily to change the IP address (you really don’t want two DomU’s with the same IP address). If your Dom0 has untrusted users or services that are accessed by untrusted users (IE any Internet facing service) then you want to mount the filesystem in question with the options nosuid and nodev so that if the DomU has been cracked it won’t allow cracking of the Dom0. After changing the configuration files to change the IP address(es) of the DomU you can then umount the filesystem and start it with the xm create command. If instead of creating the clone DomU on the same Dom0 you want to put it on a different system you can copy the block devices to files on a regular filesystem on removable media (EG an IDE disk with USB attachment). When copying the block devices you also need to copy the Xen configuration and edit it to reflect the new paths to block devices for the data once it’s copied to the new server, but you won’t necessarily need to change the MAC address if you are copying it to a different LAN segment. References:

1. http://en.wikipedia.org/wiki/XFS


2. http://en.wikipedia.org/wiki/MAC_address

Share This

Some people at DebConf 7 were (like Mario) wondering how many users Debian has. They realised that while we have a distributed mirror network we do have all installed systems use security.debian.org by default and we do have control over that. Since apt will only download files when they have been changed we can make a minimal estimate by looking at the number of downloads of the release files while they remain unchanged. Obviously, this will only be a minimum - for example, some users won’t have network access, some users will use caching proxies or local mirrors - but it’s a start. Unfortunately I can’t actually remember the numbers they came up with but perhaps someone could enlighten us.

As previously mentioned, we are setting up a shared Xen hosting, and I promised to publish detailed setup steps. So here I will, but I warn you: I ll just note down what I m doing, and it might be confusing...
"Xen-Server-Sharing: The Setup" vollst ndig lesen

A significant problem with the old-fashioned media is that as a general rule they don’t cite references for anything. Some of the better TV documentaries and non-fiction books cite references, but this is the exception not the norm. Often documentaries only cite references in DVD extras which are good for the people who like the documentary enough to buy it but not for people who want to rebut it (few people will pay for a resource if they doubt the truth and accuracy of it’s claims). I can understand newspapers not wanting to publish much in the way of background information in the paper version as every extra line of text in an article is a line of advertising that they can’t sell. So they have financial pressure to produce less content, and the number of people like me who want to check the facts and figures used in articles is probably a small portion of the readership. Another issue with newspapers is that they are often considered as primary authoritative sources (by themselves and by the readers). It is often the case that journalists will interview people who have first-hand knowledge of an issue and the resulting article will be authoritative and a primary source in which case all they need to do is to note that they interviewed the subject. However the majority of articles published will be sourced from elsewhere (news agencies [ http://en.wikipedia.org/wiki/News_agency ] such as Reuters are commonly used). Also articles will often be written based on press releases - it is very interesting to read press releases and see how little work is done by some media outlets to convert them to articles, through a well written press release a corporation or interest group can almost write it’s own articles for publication in the old media. One way of partially addressing the problem of citing references in old media would be to create a web site of references, then every article could have a URL that is a permanent link to the references and calculations to support the claims and numbers used. Such a URL could be produced by any blogging software, and a blog would be an ideal way of doing this. For bloggers however it’s much easier to cite references and readers have much higher expectations of links to other sites to support claims and of mathematical calculations shown to indicate how numbers are determined. But there is still room for improvement. Here are some of the most common mistakes that I see in posts by people who are trying to do the right thing:

1. Indirect links. When you refer to a site you want to refer to it directly. In email (which is generally considered a transient medium) a service such as TinyURL [ www.TinyURL.com ] can be used to create short URLs to refer to pages that have long URLs. This is really good for email as there are occasions when people will want to write the address down and type it in to another computer. For blogging you should assume that your reader has access to browse the web (which is the case most of the time). Another possibility is to have the textual description of a link include a reference to the TinyURL service but to have the HREF refer to the real address. Any service on the net may potentially go away at some future time. Any service on the net may have transient outages, and any reader of your blog may have routing problems that make parts of the net unavailable to them. If accessing a reference requires using TinyURL (or a similar service) as well as the target site then there are two potential things that might break and prevent your readers from accessing it.
   One situation where indirect links are acceptable is for the printed version. So you could have a link in the HTML code for readers to click on to get to the reference page directly and a TinuURL link for people who have a printed version and need to type it in.
   Also when linking to a blog it’s worth considering the fact that a track-back won’t work via TinyURL and track-backs may help you get more readers…


2. Links that expire. For example never say “there’s a good article on the front page of X” (where X is a blog or news site). Instead say “here’s a link to a good article which happens to be on the front page now” so that someone who reads your post in a couple of years time can see the article that you reference.
   Another problem is links to transient data. For example if you want to comment on the features of a 2007 model car you should try to avoid linking to the car manufacturer page, next year they will release a new car and delete the old data from their site.
   A potential problem related to this is the Google cache pages which translate PDF to HTML and high-light relevant terms and can make it much easier to extract certain information from web pages. It can provide value to readers to use such links but AFAIK there is no guarantee that they will remain forever. I suggest that if you use them you should also provide the authoritative link so that if the Google link breaks at some future time then the reader will still be able to access the data.


3. Not giving the URLs of links in human readable form. Print-outs of blog pages will lose links and blog reading by email will also generally lose links (although it would be possible to preserve them). This counts for a small part of your readership but there’s no reason not to support their needs by also including links as text (either in the body or at the end of the post). I suggest including the URL in brackets, the most important thing is that no non-URL text touch the ends of the URL (don’t have it in quotes and have the brackets spaced from it). Email clients can generally launch a web browser if the URL is clear. Note that prior to writing this post I have done badly in this regard, while thinking about the best advice for others I realised that my own blogging needed some improvement.
   I am not certain that the practice I am testing in this post of citing URLs inline will work. Let me know what you think via comments, I may change to numbering the citations and providing a list of links in the footer.


4. Non-specific links. For example saying “Russell Coker wrote a good post about the SE Linux” and referring to my main blog URL is not very helpful to your readers as I have written many posts on that topic and plan to write many more (and there is a chance that some of my future posts on that topic may not meet your criteria of being “good”). Saying “here is a link to a good post by Russell Coker, his main blog URL is here” is more useful, it gives both the specific link (indicating which post you were referring to) and the general information (for people who aren’t able to find it themselves, for the case of deleted/renamed posts, and for Google). The ideal form would be “<A HREF=”http://etbe.coker.com.au/whatever”>here is a link to a good post by Russell Coker [ http://etbe.coker.com.au/whatever ]</A>, his main blog URL is <A HREF=”http://etbe.coker.com.au/”> [ http://etbe.coker.com.au ]</A>” (note that this is an example of HTML code as a guide for people who are writing their own HTML, people who use so-called WYSIWYG editors will need to do something different).


5. Links that are likely to expire. As a rule of thumb if a link is not human readable then the chance of it remaining long-term is low. Companies with content management systems are notorious for breaking links.


6. Referencing data that you can’t find. If you use data sourced from a web site and the site owner takes it down then you may be left with no evidence to support your assertions. If data is likely to be removed then you should keep a private copy off-line (online might be an infringement of copyright) for future reference. It won’t let you publish the original data but will at least let you discuss it with readers.


7. Referencing non-public data. The Open Access movement [ http://en.wikipedia.org/wiki/Open_access ] aims to make scholarly material free for unrestricted access. If you cite papers that are not open access then you deny your readers the ability to verify your claims and also encourage the companies that deny access to research papers.
   An insidious problem is with web sites such as the New York Times [ www.nytimes.com ] which need a login and store cookies. As I have logged in to their site at some time in the past I get immediate access to all their articles. But if I reference them in a blog post many readers will be forced to register (some readers will object to this). With the NYT this isn’t such a problem as it’s free to register so anyone who is really interested can do so (with a fake name if they wish). But I still have to keep thinking about the readers for such sites.
   I should probably preview my blog posts from a different account without such cookies.


8. Failing to provide calculations. My current procedure is to include the maths in my post, for example if you have a 32bit data type used to store a number of milliseconds then it can store 2^32/1000 seconds which is 2^32/1000/60/60/24 = 49.7 days, in this example you can determine with little guessing what each of the numbers represent. For more complex calculations an appendix could be used. A common feature of blogs is the ability to have a partial post sent to the RSS feed and the user has the ability to determine where the post gets cut. So you could cut the post before the calculations, the people who want to see them will find it’s only one click away, and the people who are happy to trust you will have a shorter post.


9. Linking with little reason. Having a random word appear highlighted with an underline in a blog post is often not very helpful for a reader. It sometimes works for Wikipedia links where you expect that most readers will know what the word means but you want to link to a reference for the few who don’t (my link for the word Wikipedia is an example). In the case where most readers are expected to know what you are referring to then citing the link fully (with a description of the link and a human-readable form for an email client) is overkill and reduces the readability of the text.
   The blogging style of “see here and here for examples” does not work via email and does not explain why a reader should visit the sites. If you want to include random links in a post then having a section at the footer of related links would probably be best.


10. Linking to a URL as received. Many bloggers paste URLs from Google, email, and RSS feeds into their blog posts. This is a bad idea because it might miss redirection to a different site. If a Google search or an email gives you a URL that is about to go away then it might redirect to a different site. In that case citing the new URL instead of the old one is a service to your readers and will decrease the number of dead-links in your blog over the long-term. Also using services such as www.feedburner.com may cause redirects that you want to avoid when citing a blog post, see my previous post about Feedburner [ http://etbe.coker.com.au/2007/08/20/feedburner-item-link-clicks/ ].

Here are some less common problems in citing posts:

1. Inappropriately citing yourself. Obviously if there is a topic that you frequently blog about then there will be benefit to linking to old posts instead of covering all the background material, and as long as you don’t go overboard there should not be any problems (links to your own blog are assumed to have the same author so there is no need for a disclaimer). If you write authoritative content on a topic that is published elsewhere then you will probably want to blog about it (and your readers will be interested). But you must mention your involvement to avoid giving the impression that you are trying to mislead anyone. This is particularly important if you are part of a group that prepares a document, your name may not end up on the list of authors but you have a duty to your readers to declare this.
   Any document that you helped prepare can not be used by itself as a support of claims that you make in a blog post. You can certainly say “I have previously demonstrated how to solve this problem, see the following reference”. But links with comments such as “here is an example of why X is true” are generally interpreted to be partly to demonstrate the popular support for an idea.


2. Citing secret data. The argument “if you knew what I know then you would agree with me” usually won’t be accepted well. There are of course various levels of secrecy that are appropriate. For example offering career advice without providing details of how much money you have earned (evidence of one aspect of career success) is acceptable as the readers understand the desire for some degree of financial secrecy (and of course in any game a coach doesn’t need to be a good player). Arguing the case for a war based on secret data (as many bloggers did) is not acceptable (IMHO), neither is arguing the case for the use of a technology without explaining the science or maths behind it.


3. Not reading the context of a source. For example I was reading the blog of a well regarded expert in an area of computer science, and he linked to another blog to support one of his claims. I read the blog in question (more than just the post he cited) and found some content that could be considered to be racially offensive and much of the material that I read contained claims that were not adequately supported by facts or logic. I find it difficult to believe that the expert in question (for whom I have a great deal of respect) even casually inspected the site in question. In future I will pay less attention to his posts because of this. I expect a blogger to pay more attention to the quality of their links than I do as a reader of their blog.

While writing this post I realised that my own blogging can be improved in this regard. Many of my older posts don’t adequately cite references. If you believe that any of my future posts fail in this regard then please let me know.

Share This

The short story: we lost the baby. "Cord accident". The long story: Sarah woke me up at about 2:30am on Tuesday morning in a panic because she'd woken up herself at about 2am, and realised that she hadn't felt the baby move since about 8am the previous day. I had a quick feel, but couldn't feel anything like his usual vigorous kicking, and eager to put her mind at rest, called Labor an Delivery at Lucile Packard Children's Hospital to see if we could come in. They said we could, so we jumped in the car and got there at about 3:25am. They hooked up Sarah to a fetal heart monitor, but after anxious minutes, they couldn't pick up anything, so they got out the ultrasound machine. It was pretty obvious from that that there was no movement. We'd lost him. So from about 4am onwards, we, well, tried to come to grips with the fact that we'd lost our baby. That we'd been robbed, 13 days from the finish line, and that we weren't going to be bringing a baby home to all the stuff we had ready for him there. The doctors briefly mulled over whether to have a C-section to deliver Joshua, as was the plan, or induce. Apparently it's psychologically better for the mother if she delivers naturally, since she doesn't have the constant reminder for 6+ weeks while she recovers from the C-section. However, the doctors decided that as nothing had really changed from a delivery point of view, and they wanted to do a C-section for reduced strain on Sarah's heart, they opted for a C-section. They managed to get a free operating room slot in the Stanford ORs, so they transferred Sarah over there, and they started performing the surgery at about 10am. Joshua was delivered sometime around 10:15am. I got to see him and hold him while we were still in the OR. He was perfect. 4 pounds 12 ounces. He didn't look that small. We were wondering if he was going to make 5 pounds or not. Maybe he would have by the 17th. I brought him around to show Sarah while she was still on the table, but it was hard to get him up to a good position that she could see him from, and she was a bit zonked out from all of the drugs. They finished up at about 10:45am, and took her to the recovery room, where they didn't really want me, so one of the nurses from Labor and Delivery took me back to Lucile Packard, to spend some time with Joshua. There she let me hold him for a while, and look at him, and take some photographs. Then she weighed him and measured him, and took some more photographs. The nurse was really compassionate about the whole thing, and it felt like we were there for a good couple of hours, which was good, because apparently Lucile Packard and Stanford don't really inter-operate very well, and whilst physically transferring a patient just involves wheeling them down a corridor, getting all the paperwork sorted out is a completely different story. So while Sarah was only supposed to spend an hour in recovery, she spent three hours there, because they were waiting on paperwork to release her, then waiting on a room to be available, then the right people weren't talking to each other, so they didn't know they didn't know that a room was available from midday. I forget what time we actually got out of recovery. The doctors, being the overcautious bunch of people that they are, wanted to keep Sarah in the Cardiac Surveillance Unit for 24-48 hours so they could check on her vitals post-delivery. They let us out of there late today. We're currently in a general ward. I thought they said it was for gynaecology patients (they didn't think it'd be terribly considerate to stick us in with all the other recovering mothers and their babies), but there's some male patients in here too, so I'm not sure what this ward is. In terms of coming to grips with things, they brought Joshua up to our room for pretty much as long as we wanted yesterday, and Sarah was more with it by then, so she could hold him, and we could take more photographs. It's been really hard. I was awake from when Sarah woke me up in the morning until about 10pm that night. Fortunately I was able to get a cot in the room with Sarah, so I could stay the night there. I'm staying here tonight as well. The obstetrician that delivered Joshua said that his umbilical cord was wrapped around his neck twice and once around his body, and was pretty tight around his neck. They can't say for sure that that's what happened, but it's a good enough explanation for us, and we're not going to have the little guy cut up for an autopsy, which may not tell us anything anyway. So we're taking some small comfort from the fact that we're able to make a healthy looking baby, and that Sarah's heart performed fine throughout the pregnancy and delivery, and that this was just one of those so very unlucky accidents. Apparently babies get their umbilical cords wrapped around their necks all the time, and most of the time it's not a problem. So we know that he didn't have any birth defects, and it wasn't because of something Sarah ate, or because Sarah got sick or anything. It's just plain bad, rotten luck. We'll most probably try again, but the next pregnancy is going to be hell. It'll be like walking on egg shells the entire time. Clearly, your baby isn't out of the water until he's screaming in the delivery room. There's a lot more I want to write, but I also want to get this finished and get some sleep, so here's a brain dump of what's been going through my head for the last 48 hours:

• Dammit!
• Dammit! Dammit! Dammit!
• We only had 13 days to go
• We just had the baby shower on Saturday!
• We just bought the last few things at Babies 'r' Us on Monday. He was probably dead by then.
• We were so ready. We'd gotten everything. We bought a cool jogging stroller! We bought a super-awesome safety table of a high chair.
• I never thought my Tuesday would end up like this when I went to bed on Monday night
• He looked so perfect. We've been robbed. He's been robbed.
• The little bugger was too active for his own good
• We were supposed to be having our Caesarian class the next day
• Should we try again? Can I handle seeing Sarah go through all the pain and suffering of another C-section?
• It's just not fair!
• I wouldn't wish this on anyone
• This sucks
• This just isn't fair
• We'll get through this

We've been very grateful for the near endless stream of visitors, phone calls and SMSes, and flowers. It's helped us not dwell on things, especially given all of our family is so far away. Sarah's Mum, who was going to arrive in 5 weeks, is now arriving on Friday, so that'll be good for Sarah. Sarah will hopefully be discharged on Friday or Saturday. We're planning on cremating Joshua, as it just doesn't seem right to bury him over here and then someday move back to Australia and leave him all alone. Current thinking is we won't have a funeral service. Here's what I emailed to the people we were going to send the birth announcement to:

Hi everyone, It is with heavy hearts, that we have to tell you that rather than announcing Joshua's birth on the 17th of September, we have to say that yesterday, we learned that we lost him, 13 days before he was to be delivered. Sarah woke me yesterday morning at about 2:30am, because she'd woken up at about 2am, and realised that she hadn't felt Joshua moving since about 8am the previous day. She tried a few things to get him moving, but they didn't work, so we hurried into Labor & Delivery at the Lucille Packard Children's hospital. There, they confirmed the worst, no heartbeat. Yesterday morning at about 10am, Sarah had a c-section so the doctors could deliver little Joshua. He was absolutely perfect, weighing in at 4 pounds 12 ounces (2.15 kilograms) and 26.7 centimetres (10.5 inches). Yesterday was a very long day. Sarah is currently recovering in the Cardiac Surveillance Unit (CSU) of Stanford Hospital (her aorta has been absolutely fine, the doctors are just being their usual cautious selves). It's a little bit up in the air as to whether she'll spend the entirety of her recovery in the CSU, or if she'll be transferred back to the Post-Partum area of Lucille Packard after 24 hours. (We hope that she does get transferred back, as the CSU isn't really used to dealing with post-c-section patients, particularly ones that have lost the baby). The obstetrician that delivered Joshua said that his umbilical cord was wrapped around his neck twice, fairly tightly, and once around his body. So whilst we'll never know for sure, it looks like it was a cord accident. That's a good enough explanation for us, so we're not going to have him autopsied. That's about all I can report at the moment. If you'd like to speak to Sarah, you can either call home and I'll try to keep Sarah's extension forwarding to her hospital room, or you can call my cell phone. I've got it on vibrate all of the time, and I'll answer if we're not in the middle of something. If you're calling from Australia, my extension at home will let you connect to my cell phone. If you're local, and would like to visit, we'd love to see you, just call ahead to check where we are. It's going to be hard, but we'll get through this.

Great essay from Paul Graham about why college prestige doesn’t matter. (I wish I had both the time and ability to churn out his volume of high-quality writing.) My favorite parts were the following two footnotes:

…No one ever measures recruiters by the later performance of people they turn down.[2]…

[2] Actually, someone did, once. Mitch Kapor’s wife Freada was in charge of HR at Lotus in the early years. (As he is at pains to point out, they did not become romantically involved till afterward.) At one point they worried Lotus was losing its startup edge and turning into a big company. So as an experiment she sent their recruiters the resumes of the first 40 employees, with identifying details changed. These were the people who had made Lotus into the star it was. Not one got an interview.

…Obviously you can’t prove this in the case of a single individual, but you can tell from aggregate evidence: you can’t, without asking them, distinguish people who went to one school from those who went to another three times as far down the US News list. [3]… [3] The US News list? Surely no one trusts that. Even if the statistics they consider are useful, how do they decide on the relative weights? The reason the US News list is meaningful is precisely because they are so intellectually dishonest in that respect. There is no external source they can use to calibrate the weighting of the statistics they use; if there were, we could just use that instead. What they must do is adjust the weights till the top schools are the usual suspects in about the right order. So in effect what the US News list tells us is what the editors think the top schools are, which is probably not far from the conventional wisdom on the matter. The amusing thing is, because some schools work hard to game the system, the editors will have to keep tweaking their algorithm to get the rankings they want.

As an alum of a fairly prestigious institution, I think I endorse Graham’s conclusions.

Share This

I've been using source control management (SCM) systems going back to the the very limited RCS back in the early 1990's. Over the years, I've migrated my SCM to take advantage of improved functionality. Recently, I migrated from subversion to git. While I keep my home directory in SCM (initially CVS, then SVN, now GIT) and that directory is replicated across Linux, Windows, and Mac OS X systems, a big reason for changing from svn to git is to give people more access to my open-source projects. Periodically, I'd have my CVS and SVN repositories available on a public web server. But, that typically required some effort of mine to mirror a public copy from my private repository. Using a distributed SCM like git, there is no additional effort needed to make a public copy of my respository. But, a bigger win over just making a public respository available is allow users to have their own local respository. While I appreciate the patches (bug fixes and improvments) users email to me, there are some cases where I feel the patch has limited value and don't incorporate it into my upstream respository. With a distributed SCM, users can maintain their own local patches while being able to merge changes that I make to the project's canonical repository. Though, I do hope users to continue to send patches that would be useful to a project's user base. As an added benefit, git has much improvement mechanisms for users to do so. For my private use, the distributed repository system is not a big win. However, git has much improved branching over subversion which will help when I want to make a local branch for experimental changes. To convert from my single private respository to a useful public git repository, I've separated my open-source projects into discrete git repositories. The histories of the git repositories on some projects go back to 2002. Unfortunately, I was not able to migrate my tags from subversion to git because git-svnimport got confused about the odd tagging/commits from the cvs2svn tool I used when I migrated from CVS to SVN. If checking out a particular old version is important, one can refer to the dates in the project's debian/changelog file to find the commit matching that release. At some point, I may write an automatic tool to retag the version numbers on the projects. The public git repositories can be browsed at http://git.b9.com/gitweb. I'm modifing my Lisp web site creation tool so it will automatically add the git repository to each project's website. For now, the typical URI to clone a git repository would in the form of git://git.b9.com/<project>.git. I expect users of my projects will find the new, much deeper access to my open-source projects empowering. The set of commands to clone the current set of open-source repositories are:
git clone git://git.b9.com/cl-base64.git
git clone git://git.b9.com/cl-modlisp.git
git clone git://git.b9.com/cl-photo.git
git clone git://git.b9.com/cl-readline.git
git clone git://git.b9.com/cl-rss.git
git clone git://git.b9.com/clsql.git
git clone git://git.b9.com/cluck.git
git clone git://git.b9.com/ctsim.git
git clone git://git.b9.com/getopt.git
git clone git://git.b9.com/hyperobject.git
git clone git://git.b9.com/irc-logger.git
git clone git://git.b9.com/kmrcl.git
git clone git://git.b9.com/lml.git
git clone git://git.b9.com/lml2.git
git clone git://git.b9.com/md5.git
git clone git://git.b9.com/pipes.git
git clone git://git.b9.com/postoffice.git
git clone git://git.b9.com/ptester.git
git clone git://git.b9.com/pubmed.git
git clone git://git.b9.com/puri.git
git clone git://git.b9.com/reversi.git
git clone git://git.b9.com/rlc.git
git clone git://git.b9.com/rt.git
git clone git://git.b9.com/uffi.git
git clone git://git.b9.com/umlisp.git
git clone git://git.b9.com/umlisp-orf.git
git clone git://git.b9.com/vcs-tree.git
git clone git://git.b9.com/wdq2wav.git
git clone git://git.b9.com/wol.git
git clone git://git.b9.com/xlunit.git
git clone git://git.b9.com/xmlutils.git
git clone git://git.b9.com/xptest.git

I've been using source control management (SCM) systems going back to the the very limited RCS back in the early 1990's. Over the years, I've migrated my SCM to take advantage of improved functionality. Recently, I migrated from subversion to git. While I keep my home directory in SCM (initially CVS, then SVN, now GIT) and that directory is replicated across Linux, Windows, and Mac OS X systems, a big reason for changing from svn to git is to give people more access to my open-source projects. Periodically, I'd have my CVS and SVN repositories available on a public web server. But, that typically required some effort of mine to mirror a public copy from my private repository. Using a distributed SCM like git, there is no additional effort needed to make a public copy of my respository. But, a bigger win over just making a public respository available is allow users to have their own local respository. While I appreciate the patches (bug fixes and improvments) users email to me, there are some cases where I feel the patch has limited value and don't incorporate it into my upstream respository. With a distributed SCM, users can maintain their own local patches while being able to merge changes that I make to the project's canonical repository. Though, I do hope users to continue to send patches that would be useful to a project's user base. As an added benefit, git has much improvement mechanisms for users to do so. For my private use, the distributed repository system is not a big win. However, git has much improved branching over subversion which will help when I want to make a local branch for experimental changes. To convert from my single private respository to a useful public git repository, I've separated my open-source projects into discrete git repositories. The histories of the git repositories on some projects go back to 2002. Unfortunately, I was not able to migrate my tags from subversion to git because git-svnimport got confused about the odd tagging/commits from the cvs2svn tool I used when I migrated from CVS to SVN. If checking out a particular old version is important, one can refer to the dates in the project's debian/changelog file to find the commit matching that release. At some point, I may write an automatic tool to retag the version numbers on the projects. The public git repositories can be browsed at http://git.b9.com/gitweb. I'm modifing my Lisp web site creation tool so it will automatically add the git repository to each project's website. For now, the typical URI to clone a git repository would in the form of git://git.b9.com/<project>.git. I expect users of my projects will find the new, much deeper access to my open-source projects empowering. The set of commands to clone the current set of open-source repositories are:
git clone git://git.b9.com/cl-base64.git
git clone git://git.b9.com/cl-modlisp.git
git clone git://git.b9.com/cl-photo.git
git clone git://git.b9.com/cl-readline.git
git clone git://git.b9.com/cl-rss.git
git clone git://git.b9.com/clsql.git
git clone git://git.b9.com/cluck.git
git clone git://git.b9.com/ctsim.git
git clone git://git.b9.com/getopt.git
git clone git://git.b9.com/hyperobject.git
git clone git://git.b9.com/irc-logger.git
git clone git://git.b9.com/kmrcl.git
git clone git://git.b9.com/lml.git
git clone git://git.b9.com/lml2.git
git clone git://git.b9.com/md5.git
git clone git://git.b9.com/pipes.git
git clone git://git.b9.com/postoffice.git
git clone git://git.b9.com/ptester.git
git clone git://git.b9.com/pubmed.git
git clone git://git.b9.com/puri.git
git clone git://git.b9.com/reversi.git
git clone git://git.b9.com/rlc.git
git clone git://git.b9.com/rt.git
git clone git://git.b9.com/uffi.git
git clone git://git.b9.com/umlisp.git
git clone git://git.b9.com/umlisp-orf.git
git clone git://git.b9.com/vcs-tree.git
git clone git://git.b9.com/wdq2wav.git
git clone git://git.b9.com/wol.git
git clone git://git.b9.com/xlunit.git
git clone git://git.b9.com/xmlutils.git
git clone git://git.b9.com/xptest.git

Jim Grisanzio: “What I find interesting is that Matt uses the phrase ‘we’re getting Solaris versus Linux’ to point to an article titled ‘OpenSolaris will challenge Linux says Sun’ which is actually an abridged article from the more aptly titled ‘Sun: Coders key to Solaris’ rise’ published last week. I blogged about that original article because I loved the quote in there about the OpenSolaris Community. But the version that has people all worked up today is missing eight paragraphs of text from the original. Why? Read both of them and you’ll see the clear difference in tone. And why all the wild headline changes, too? Even if you read the version Matt points to you’d be hard pressed to find anything in the article to substantiate the headline. I mean, really, this is silly. Sun’s Ian Murdock and Marc Hamilton were talking about how the OpenSolaris community is growing, how the technology is improving, and some of the plans we are kicking around to improve things. That’s pretty much it. So, where’s the war here?”

I have written a new music player to fulfill my needs, and I’ve dubbed it Minirok. It is written in Python, uses KDE libraries, and GStreamer as a backend. It is also heavily modelled after Amarok, with the look and feel being pretty much identical, but with a reduced set of features. The main deal is that there is no collection built from tags: only a tree view of the filesystem, which I sorely missed in Amarok. Because of this, most probably only folk whose collection is already structured as a tree at the filesystem level will find it enjoyable. Version 0.6 was released yesterday, and is already in Debian. Check out the screenshots, and feel free to provide feedback. P.S.: I am aware that minirok means miniskirt in Dutch.