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).

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.

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.

Hey! virtualbox 1.5.0 is now available in the debian archive. Several bugs, which were reported during the first week in which virtualbox was in the repro, are fixed now with this upload. But the main reason I wrote this blog entry: I would like to thank everybody who helped to find quickly a working solution to the issue concerning team maintanance... see debian-devel@l.d.o for details. This was one of the very rare situtations were a starting flamewar on -devel was stopped by discussion between the two parties in order to find a working compromise. This should happen more often

On his blog, Matt Kohut (an engineer from Lenovo) opened a poll about Linux on Thinkpads laptop. He posted yesterday about Linux on laptops and was surprised about the number of answer he had, so now he asks people what distribution would they prefer on their Thinkpad if Lenovo would start supporting a Linux distribution. So I thought Thinkpad owners in planet readers may want to express their opinion on the post.

* 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 came across John Wang's posting titled Database Abstraction - code vs infrastructure. In it, he talks about the problems many people face when migrating applications tied to a specific RDBMS to another one. He recommends:

One solution of modern programming is to move database abstraction from the code to the infrastructure using a ORM (Object-Relational Mapper) or Data Mapper. A ORM and Data Mapper abstracts the database for you so you no longer have to do tie db abstraction to each app. Not only does it let you code once for multiple databases it lets your users migrate their data from one database to another. This blog runs Typo which is based on Ruby on Rails and ActiveRecord. I've been contemplating migrating Typo from MySQL to PostgreSQL and I've been told that it would be as simple as exporting the data with YAML, updating the database.yml file and importing the data.

Umh... Thing is, you often want to use your DB as way more than a data store - At least, when using Postgres, I do. There are many things that can be done inside the DB (such as guarding the programmer against his own mistakes by keeping sanity checks which often go beyond just referential integrity. Constraints and triggers. Oh, and of course, user-defined functions and views. Of course, most times you can go by without using several of such tools - but when they would come in handy, you can sorely miss them.
On the other hand, John mentions (right after the previous paragraph):

ActiveRecord is a data mapper and isn't as flexible as a full blown ORM but it gets the job done for the most part. For a full-blown ORM, I think of Perl's DBIx::Class which provides a full OO interface to the RDBMS allowing you to code just once for multiple DBs without limiting you when you want to use some esoteric database-specific SQL

Currently, I'm among the many that have jumped on the Rails bandwagon - And so far, I really like it. But yes, ActiveRecord -although great for some tasks- is way under what I'd like for many actions I've got used to making.
I might be seen as a backwards guy for this, but until before I started with Rails, I prefered not to use full ORMs (not that I tried too hard anyway - Probably starting a project with DBIx::Class would be all it takes for me to become a convert, from what I've read), but to do the SQL myself - Only, of course, keeping well in mind that I should separate front-end from back-end (or using other jargon to say the same, separating cleanly what should be in a Controller and what should be in a Model - Of course, no one in their right mind would put SQL on a template or a View!). It's not so hard as many people seem to think, although mixing syntaxes for two different languages (and even more if you, as I do, like to keep your code under 80 columns) is sometimes dirt-ugly. Still, on to my last bit of rant:

There are PHP frameworks out there like Symfony and Cake but do any of them have stand-alone ORMs? If so, could Drupal move to something like that and solve their maintainership problems once and for all? Drupal is part of the Go PHP5 effort so there should be no issue using PHP 5 OO. Something to think about for the Drupal folks if a PHP ORM is available

Umh... Even if there are some great ORMs in PHP... Choosing an ORM is something you do when you start a project. I doubt the Drupal people can now just decide to move over to using a ORM, as they potentially have hundreds or thousands of points where they have DB interaction. And although for most of them moving over to an ORM should even be automatizable, every ORM has some very special features which make it damn hard to craft several kinds of query.

On your clients you have to modify /etc/snmp/snmpd.conf:

#com2sec paranoid default public
com2sec readonly default public
exec .1.3.6.1.4.1.2021.8.3 aptupdate /usr/local/bin/nagios-check-apt-updates Get the check script to the client:

# wget –no-check-certificate \
https://kosh.ganneff.de/ganneffutils/nagios/nagios-check-apt-updates \
-O /usr/local/bin/nagios-check-apt-updates
# chmod +x /usr/local/bin/nagios-check-apt-updates Allow the snmp user to make use of apt-get:

# echo “snmp ALL=(ALL) NOPASSWD: /usr/bin/apt-get update” >> /etc/sudoers
# echo “snmp ALL=(ALL) NOPASSWD: /usr/bin/apt-get –simulate upgrade” >> /etc/sudoers Restart the snmpd:

# /etc/init.d/snmpd restart
Restarting network management services: snmpd. On the nagios monitoring system you have to run something like this:

# /usr/lib/nagios/plugins/check_snmp -H <client> -t30 \
-C public -o .1.3.6.1.4.1.2021.8.3.101.1 \
-r “No updates available”
SNMP CRITICAL - *”Security updates (1): libkrb53; “* iso.3.6.1.4.1.2021.8.3.101.1=”Security updates (1): libkrb53; ” After upgrading the client you should get:

# /usr/lib/nagios/plugins/check_snmp -H <client> -t30 \
-C public -o .1.3.6.1.4.1.2021.8.3.101.1 \
-r “No updates available”
SNMP OK - “No updates available” iso.3.6.1.4.1.2021.8.3.101.1=”No updates available” Debian, opensource, planet

I did upload a updated version of eGroupware to my pool. You can grab it from http://ftp.cyconet.org/debian/archive/bpo/egroupware/1.4.001.dfsg-2.1~bpo40+1/ or via:

deb ftp://ftp.cyconet.org/debian etch-backports main non-free contrib For installing the rules analog backports.org applies. Have fun! backports, bpo, Debian, opensource, planet

Anyone who has done an operating systems 101 course is familiar with the standard hierarchical page-table structure. This is essentially a radix-tree where bits of the virtual address are taken as indexes into an array of pointers, each pointing to the next level down or, at the leaves, to a physical entry. One potential issue with this style of page-table is with a very large, very sparse address space (such as in a single address-space operating system) there will be many intermediate steps with possibly only a single translation at the end (i.e. lots of single pages scattered all around your address-space). Thus we can add a bit-field guard to each of the entries in the page table (Liedtke, 1994) to help indicate only those paths through the tree which are valid (similar to a Patricia tree). Translation first proceeds as usual; the top bits are used as an index into the top level table. However, each entry now contains extra information about further valid addresses. The guard is masked against the next bits in the virtual address; if it matches (e.g. in our example is 0x2) the next step can proceed directly to the leaf node, bypassing the middle look-up. The entry can be marked as either final (i.e. pointing to a leaf node) or intermediate, in which case the process continues with the next level (which also has its own guard, and so forth). Any entry that does not match the guard is known to be false, and therefore a fault can be raised. To examine this further, consider that we know that each page in our 24-bit address space above is 4KiB, thanks to the 2¹² = 4KiB offset. Therefore each of the 16 possible values of the top four bits selects 1MiB of the 2²⁴ = 16MiB address space; e.g. 0x0 selects the first megabyte, 0x1 the second and so forth. The second 4 bits selects a 64KiB region of this 1MiB, and the last 4 bits selects a 4KiB region of this 64KiB region. This scheme could work quite well if we were using only 16 pages each separated by 1MiB. Each of these pages would only require an entry in the top level with an appropriate guard which could then be marked as final and point directly to a physical frame. Once things become less sparse however, we need to start filling in middle levels. If you have 2 pages within a 16MiB region, you need at least one extra bit of address to tell them apart. If you have 3 or 4 pages, you need at least 2 bits to tell them apart, and so forth. It would therefore be beneficial to have variable level sizes to dynamically adapt and create the most efficient lookup possible given the address space layout of a process. For example, if you knew your process was only going map pages 0x123 (100100011) and 0x124 (100100100) a good option would be to make your top-level only two entries (i.e. check the top bit) with a guard on the entry at index 0x1 of 00100. You then need a second level with 8 pointers to differentiate the remaining 3 bits (each of these would be final and hence point directly to a physical page). The more pages you start mapping, the less bits you can discard with the guard. If you follow this through to a guard of 0 bits you end up with a linear page-table. It has been shown (Elphinstone, 1999) that fixed level sizes with 16 entries tends to work well. For a 32-bit address-space with 4KiB pages (e.g. 12 bits offset) this leaves 20 bits to be mapped by the page-tables; with each level mapping 2⁴ bits this means a 5 level tree. The guard values provide enough path-compression that the table is not constantly walked. The disadvantage is that it may "over-allocate" meaning more space is dedicated to page-tables than strictly required. Deciding where and when to split levels, what size indexes to put at each level and updating all the guard values dynamically to make the smallest, most efficient page-table would create a variable-radix page-table (Szmajda and Heiser, 2003). In summary, a guarded page-table is more useful the more sparse your address space is. A variable-radix guarded page-table is complex, but could offer advantages for implementing variable page-size support and thus having positive effects on TLB coverage.

Perhaps this conversation is a sign that we've been in the country for awhile:

"Terah, if you ever drive the pickup..."

"Why would I ever do that?"

"I don't know, but if you ever do, I just want you to know something. The reason there's a towel connecting the brake pedal to the steering wheel..."

At this point I had to wait for her laughter to die down.

"As I was saying, the reason there's a towel connecting the brake pedal to the steering wheel is that, unless you park facing uphill, the brake lights stay on all the time and will drain the battery."

More laughter followed.

I didn't even have the chance to tell her to remove the towel before she starts the truck. Oh well, guess she'll figure it out.

On the other hand, perhaps this is a sign that we haven't been in the country long enough:

Today as I went to lunch, I saw a long, narrow, light gray line across the door on my car. I was pretty annoyed that somebody would have pulled keys or something across it to do that. But as I got closer, I realized it was just a spider web. Terah and I park our cars a few feet apart, and every week or so there will be a spider web connecting the two of them when we go out in the morning.