I read The Iliad recently; see my review of it here. This article isn t about The Iliad, but about Shmoop s coverage of it. I have never been a person who puts much stock on study guides before, and my own prejudice is that they have probably earned their reputation as useful for little more than a tool to help students pass exams without reading the material. However, I felt rather unequal to reading The Iliad; after all, it has been many years since I had been exposed to Greek mythology, and even then it was very brief. I had remembered from Amazon s blog that they are offering some of the classics with a Shmoop study guide built in. I figured the $2.39 would be worth it. But I m not sure it was. The resulting ebook has two sections: the main text, and the Shmoop overview. The overview contains essentially the information available for free on their site. This information is pretty good. It has some overviews of the entire book, plus summaries of each chapter. They helpfully provide the backstory in the chapter summaries, so I know why certain gods are on the side of the Trojans and the others on the side of the Achaeans. It helped me figure out the point to some of the actions described on the text. These are linked to at the beginning of each book (chapter) of the Iliad, which was a bit inconvenient because I prefer to read them after reading the main text. Nevertheless, it wasn t a big problem. The summaries were written colloquially, sometimes too much so. I grinned as the less grabbin , more stabbin summary of the Achaeans being told to salvage armor from the dead later and keep fighting now. I cringed as no way Jose , and rolled my eyes as it described how one of the heroes got owned . That would have been less clear than the original for many. I would probably have given the Shmoop edition 4 or 5 stars on Amazon were it not for numerous boneheaded mistakes they made. The commentary uses one translation (Lattimore), while the included text uses a different one (Butler). That s bad enough, but it gets worse: Lattimore uses the Greek names for the gods and heroes, while Butler uses the Roman ones. So you can be reading through the text, learning about Jove, Ulysses, Juno, and Mars. But the commentary refers instead to Zeus, Odysseus, Hera, and Ares. Now, some might have memorized the Greek and Roman names for everyone, but then such people probably aren t wanting a study guide. I finally had to print out a page to help me understand the study guide. That is terrible, and completely inexcusable. They should have used the same translation for the text as the commentary, or at least have provided parenthetical notes throughout the commentary. Next, they really did a poor job of the main text itself. They have apparently grabbed the Butler ASCII text from Project Gutenberg, and cut and pasted it into some editor. I say this because each line renders as a paragraph; that is, the text doesn t reflow to fit the screen as every single other book does. Worse, it s too wide for the Kindle. So you get one line full width, the next only half as wide as the display (some of the first having wrapped), then the next full width again, on down. Butler is a prose, not a poetic, translation, so this is pointless. Moreover, the line endings are exactly where they are at Project Gutenberg. So, what we have here is that somebody at Shmoop cut and pasted from their own website and Project Gutenberg, and nobody bothered to check if the resulting product was crap. At least with the new Kindle firmware you can read in landscape mode to prevent most of the lines from wrapping. Still, I m very annoyed at this. There are other flaws. They highlighted some passages in the text. Clicking on them goes to some commentary about it. OK, fine. But why are some passages highlighted in the text, and some mentioned in the chapter summary? There seemed no rhyme or reason. The highlighted passages commentary was iffy in quality. Sometimes it was useful, and sometimes it asked a question of the sort I might expect in a jr. high English question When has pride helped you in your life? or some such. Worse, not all of the highlights linked to the correct place, and they also suffered from the Greek/Roman name issue. In all, Shmoop has helped me understand The Iliad and place it in context. But they need to spend a lot more effort on copyediting. Even a couple of hours of someone actually looking at their Kindle product on an actual Kindle would have immediately shown these problems. They could have made a far better product with a few hours more effort.

I have been pondering the idea behind this article for a while, and finally had a bit of time to implement it. The basic idea is this: certain platforms have higher costs in terms of memory per concurrent connection. Those translate into increased costs in dollar terms.
Nota Bene: Having run LangPop.com for some time, I'm used to people getting hot and bothered about this or that aspect of statistics that are rough in nature, so I'm going to try and address those issues from the start, with more detail below.

• Constructive criticism is welcome. I expect to utilize it to revisit these results and improve them. Frothing at the mouth is not welcome.
• There is something of a "comparing apples and oranges" problem inherent in doing these sorts of comparisons. As an example, Rails gives you a huge amount of functionality "out of the box", whereas Mochiweb does much less. More on that below.
• I am not familiar with all of these systems: meaning that I may not have configured them as I should have. Helpful suggestions are, of course, welcome. Links to source code are provided below.
• You can likely handle many more 'users' than concurrent connections, which means multiple browsers connecting to the site at the same time.
• Programmer costs are probably higher than anything else, so more productive platforms can save a great deal of money, which more than makes up for the cost of extra memory. There's a reason that most people, outside of Google and Yahoo and sites like that, don't use much C for their web applications. Indeed, I use Rails myself, even though it uses a lot of memory and isn't terribly fast: I'd rather get sites out there, see how they do, and then worry about optimizing them (which is of course quite possible in Rails).

Methodology All tests were run like so: my new laptop with two cores and four gigs of memory was used as a server, and my older laptop was used to run the ab (Apache Benchmark) program - they're connected via ethernet. I built up to successive levels of concurrency, running first 1 concurrent connection, 2, 10, and so on and so forth. The "server" computer is running Ubuntu 9.10, "karmic". Platforms The platforms I tested:

• Apache 2.2, running the worker MPM, serving static files.
• Nginx 0.7.62, serving static files.
• Mochiweb from svn (revision 125), serving static files.
• Jetty 6.1.20-2, serving static files.
• Rails 2.3.5, serving up a simple template with the current date and time.
• PHP 5.2.10.dfsg.1-2ubuntu6.3, serving up a single php file that prints the current date and time.
• Django 1.1.1-1ubuntu1, serving up a template with the date and time.
• Mochiweb, serving a simple template (erltl) with the date and time.
• Jetty, serving a simple .war file containing a JSP file, with, as clever observers will have surmised, the date and time.

As stated above, it's pretty obvious that using Rails or Django for something so simple is overkill: Better Tests for the Future I would like to run similar tests with a more realistic application, but I simply don't have the time or expertise to sit down and write a blog, say, for all of the above platforms. If I can find a few volunteers, I'd be happy to discuss some rough ideas about what those tests ought to look like. Some ideas:

• They should test the application framework with a realistic, real world type of example.
• The data store should figure as little as possible - I want to concentrate on testing the application platform for the time being, rather than Postgres vs Sqlite vs Redis. Sqlite would probably be a good choice to utilize for the data store.
• Since this first test is so minimalistic, I think a second one ought to be fairly inclusive, making use of a fair amount of what the larger systems like Rails, Django and PHP offer.
• I'd also be interested in seeing other languages/platforms.
• The Holy Grail would be to script all these tests so that they're very easy to run repeatably.

Results With that out of the way, I do think the results are meaningful, and reflect something of what I've seen on various platforms in the real world. First of all, here we look at the total "VSZ" (as ps puts it) or Virtual Size of the process(es) in memory. Much of this might be shared, between libraries, and "copy on write" where applicable. The results are impressive: Rails, followed by Django and PHP eats up a lot of memory for each new concurrent connection. Rails, which I know fairly well, most likely suffers from several problems: 1) it includes a lot of code. That's actually a good thing if you're building a reasonably sized app that makes use of all it has to offer. 2) Its garbage collector doesn't play well with "copy on write". Which is what "Enterprise Ruby" aims to fix. Django and PHP are also fairly large, capable platforms when compared to something small and light like mochiweb. That said, excuses aside, Erlang and Mochiweb are very impressive in how little additional memory they utilize when additional concurrent connections are thrown at them. I was also impressed with Jetty. I don't have a lot of experience with Java on the web (I work more with J2ME for mobile phones), so I expected something a bit more "bloated", which is the reputation Java has. As we'll see below, Jetty does take up a lot of initial memory, but subsequent concurrent connections appear to not take up much. Of course, this is also likely another 'apples and oranges' comparison and it would be good to utilize a complete Java framework, rather than just a tiny web app with one JSP file. So what's this mean in real world terms of dollars and cents? As your Rails application gets more popular, you're going to have to invest relatively more money to make it scale, in terms of memory. For this comparison, I utilized the bytes/dollar that I'm getting for my Linode, which works out to 18,889,040.85 ($79.95 for 1440 MB a month). As we can see, to have a similar amount of concurrent users is essentially free for Mochiweb, whereas with Rails, it has a significant cost. This information is particularly relevant when deciding how to monetize a site: with Erlang and Jetty it would appear that scaling up to lots of users is relatively cheap, so even a small amount of revenue per user per month is going to be a profit, whereas with Rails, scaling up to huge numbers of users is going to be more expensive, so revenue streams such as advertising may not be as viable. It's worth noting that 37 signals, the company that created Rails, is a vocal supporter of charging money for products. There's another interesting statistic that I wanted to include as well. The previous graph shows the average cost per additional concurrent user, but this one shows how much the platform costs (using when there is just one user, so it acts as a sort of baseline: As we can see, Jetty is particularly expensive from this point of view. The default settings (on Ubuntu) seem to indicate that, for instance, the basic $20 a month Linode package would not be sufficient to run Jetty, plus a database, plus other software. I think that the Apache Worker number is off a bit, and may reflect settings made to handle a large number of connections, or perhaps a different MPM would make sense. Source Code / Spreadsheet The spreadsheet I put together is here: http://spreadsheets.google.com/ccc?key=0An76R90VwaRodElEYjVYQXpFRmtreGV3MEtsaWYzbXc&hl=en And the source code (admittedly not terribly well organized) is here: http://github.com/davidw/marginalmemory/

Lenovo have announced their innovative new U1 Hybrid laptop [1]. It consists of a tablet-style device with a resistive touch-screen that runs Linux on a 1GHz ARM processor which attaches to a base computer that has a keyboard and a Core2 processor running Windows 7. They apparently have some special software to synchronise web browsing on both computers so you can maintain your web sessions when you detach the computers. How they manage to use the power of the Core2 CPU for javascript and flash intensive web sites while allowing the active browser sessions to migrate to a different OS must be a neat technical trick. Revision3 have a youtube review of the U1 which shows what it can do in terms of the hardware interface [2] Running two computers requires having two batteries, motherboards, etc which means more weight or means less battery life for the weight, whichever way you think of it the user is losing because of this choice. The idea of having two computers in one is one of these cool technical ideas which just won t provide a benefit for the users. The best thing for the users would be to have a single light-weight computer that provides an adequate amount of performance. A 1GHz ARM processor should give good performance when running Linux for most tasks (web browsing, office applications, and most games). So it seems that a good tablet with some USB ports and a matching USB keyboard would be a better option. Maybe you could have a spare battery integrated with the keyboard as most times when you want a full sized keyboard weight isn t such a big problem. The problem with MS-Windows in regard to such machines is that performance is poor and processors other than i386 and AMD64 have never really been supported (sure you can buy MS-Windows-based PDAs that have ARM and PPC CPUs, but the application support for them is minimal). These problems will never be solved. MS wants to compel users to continually upgrade their software, this requires always adding new features (bloat) while an older or less featureful OS is often a better option for lesser hardware. Vendors of proprietary applications will never support the range of CPU architectures that a free software distribution such as Debian or NetBSD supports (not that NetBSD is an ideal tablet OS but it does demonstrate what can be done if you want a portable OS). These inherent flaws in the proprietary software environment lead to some unusual hardware being designed to work around them such as the Lenovo U1. I don t have any reason to believe that the Lenovo is a bad machine, it sounds like a reasonable work-around for some of the problems that MS-Windows has forced on the industry. But I believe that it would be a much better machine if it was lighter, had a better battery life, and had a choice of keyboards all of which would have been achieved if it was designed as an ARM-only tablet machine that you can connect to an external keyboard. They could even have used a multi-core ARM CPU. But the market for such systems apparently isn t large enough for Lenovo (or anyone else) to ship ARM laptops for serious use. There have been a couple of netbooks released recently with CPUs that don t support the i386 or AMD64 instruction set, but they were aimed at web browsing use not general purpose computing. Almost everything that I do on computers could be done at least as well with a CPU that doesn t run an Intel-based instruction set, the only exception is virtualisation which doesn t seem to be well supported on architectures other than AMD64 nowadays.

• [1] http://lenovoblogs.com/insidethebox/?p=366
• [2] http://www.youtube.com/watch?v=-5DYuVN6nuY

Five years ago I spent an hour wandering around a large department store looking to buy a kettle & a set of bathroom scales. Much to the amusement of the woman I was shopping with I spent a very long time trying to find the cheapest available set of scales. (We're talking at least 20 minutes, due to the nature of the store and the crowds.) Once I'd selected the cheapest possible set of bathroom scales we walked over to the kitchen section of the store. I glanced over all the available kettles and picked up the one that looked the nicest (in terms of size, shape, and handle design) with no regard for the price at all. Why? A set of bathroom scales I use maybe twice a year. A kettle I use in excess of ten times a day. Something you use that often should be right. Even if over time you take it for granted and forget about it. (FWIW the scales were 6.50 and the kettle cost me 39.95 - John Lewis 15/03/2005 - I kept the reciept!) I'll haggle and quibble over prices for a lot of things, trying to ensure that I don't pay too much. But there are items which are worth paying for (and I don't just mean that "expensive == good" idea some people seem to have). On that basis I'll think nothing of paying 150 for a pair of shoes for example, even though I'll go out of my way to save 5- 10 on a DVD player. Because shoes are important, used very very often, and DVD players just aren't. (ObReference: I have one pair of shoes. I have five pairs of boots. I might pretend I don't but I also have a pair of sandals. Sshhh it'll be our little secret. ;) Anyway today my kettle broke. I had to buy a new one at short notice. I did so and the replacement is obviously more advanced. It boils quickly and quietly which is technically an advangtage but in practise is actually a drawback. Generally speaking I'll fill the kettle, turn it on, then wander away. I'll only return to the kitchen to make my delicous beverage when I hear the "click" signaling that the kettle's job is done. This new one? From outside the kitchen I cannot hear it at all... In conclusion: Technology and progress is all around us. Sometimes a technical step forward "being quiet" is a bad thing. In other news I'm fighting with IPv6 & a head cold. Both suck. ObTitle: Alias

I want to use the Ext4 filesystem on Xen DomUs. The reason for this is that the problem of fsck times on ext4 (as described in my previous post about Ext4 [1]) is compounded if you have multiple DomUs running fsck at the same time. One issue that makes this difficult is the fact that it is very important to be able to mount a DomU filesystem in the Dom0 and it is extremely useful to be able to fsck a DomU filesystem from a Dom0 (for example when you want to resize the root filesystem of the DomU). I have Dom0 systems running CentOS5, RHEL5, and Debian/Lenny, and I have DomU systems running CentOS5, RHEL4, Debian/Lenny, and Debian/Unstable. So to get Ext4 support on all my Xen servers I need it for Debian/Lenny and RHEL4 (Debian/Unstable has full support for Ext4 and RHEL5 and CentOS5 have been updated to support it [2]). The Debian kernel team apparently don t plan to add kernel support for Ext4 in Lenny (they generally don t do such things) and even backports.debian.org doesn t have a version of e2fsprogs that supports ext4. So getting Lenny going with Ext4 requires a non-default kernel and a back-port of the utilities. In the past I ve used CentOS and RHEL kernels to run Debian systems and that has worked reasonably well. I wouldn t recommend doing so for a Dom0 or a non-virtual install, but for a DomU it works reasonably well and it s not too difficult to recover from problems. So I have decided to upgrade most of my Lenny virtual machines to a CentOS 5 kernel. When installing a CentOS 5 kernel to replace a Debian/Lenny kernel you have to use console=tty0 as a kernel parameter instead of xencons=tty , you have to use /dev/xvc0 as the name of the terminal for running a getty (IE xvc0 is a parameter to getty) and you have to edit /etc/rc.local (or some other init script) to run killall -9 nash-hotplug as a nash process from the Red Hat initrd goes into an infinite loop. Of course upgrading a CentOS kernel on a Debian system is a little more inconvenient (I upgrade a CentOS DomU and then copy the kernel modules to the Debian DomUs and the vmlinuz and initrd to the Dom0). The inconvenience of this can be an issue in an environment where multiple people are involved in running the systems, if a sysadmin who lacks skills or confidence takes over they may be afraid to upgrade the kernel to solve security issues. Also apt-get dist-upgrade won t show that a CentOS kernel can be updated, so a little more management effort is required in tracking which machines need to be upgraded. deb http://www.coker.com.au lenny misc To backport the e2fsprogs package I first needed to backport util-linux, debhelper, libtool, xz-utils, base-files, and dpkg. This is the most significant and invasive back-port I ve done. The above apt repository has all the packages for AMD64 and i386 architectures. For a Debian system after the right kernel is installed and e2fsprogs (and it s dependencies) are upgraded the command tune2fs -O flex_bg,uninit_bg /dev/xvda can be used to enable the ext4 filesystem. At the next reboot the system will prompt for the root password and allow you to manually run e2fsck -y /dev/xvda to do the real work of transitioning the filesystem (unlike Red Hat based distributions which do this automatically). So the state of my Debian systems running this is that the DomUs run the CentOS kernel and my backported utilities while the Dom0 just runs the backported utilities with the Lenny kernel. Thus the Debian Dom0 can t mount filesystems from the DomUs which makes things very difficult when there is a problem that needs to be fixed in a DomU, I have to either mount the filesystem from another DomU or boot with init=/bin/bash .

• [1] http://etbe.coker.com.au/2009/12/01/transition-ext4/
• [2] http://etbe.coker.com.au/2010/01/05/ext4-and-rhel5-centos5/

A new littler release (now at 0.1.3) just went out of the door this evening. littler provides r (pronounced littler), a shebang / scripting / quick eval / pipelining front-end to the the R language and system. This version adds a few minor behind-the-scenes improvements:

• interactive() now evaluates to false as you'd expect in a non-interactive scripting front-end. To restore the previous behaviour, new switches -i or --interactive have been added.
• Some of the 'cleanup' functionality described in Section 8.1.2 on 'Setting R callbacks' from the R Extension manual have been adopted.
• Example scripts install.r and update.r received an update based on lessons learned from the R 2.10.0 roll-out and package rebuilding.
• A few build issues were improved, a minor manual page formatting bug was fixed.

As usual, our code is available via our svn archive or from tarballs off my littler page and the local directory here. A fresh package is in Debian's incoming queue and will hit mirrors shortly.

5 years ago I founded my own company Freexian SARL with the goal to make a living out of my free software experience. I marketed the company as being specialized on the Debian distribution in the hope to combine my Debian work and my professional work. Given that Freexian is still alive I think I met the first goal. My free software experience allowed me to complete many projects: a large number of development projects for embedded devices running a custom Linux distribution (usually built with debian udebs), the development of a Debian derivative (SLIS) and some recurring tasks of remote system administration. However, even if I use Debian daily for all my work, very few of the projects that I complete for customers have direct results in terms of improvements for Debian (except some bugreports and some related fixes). And even when I m able to contribute something back to Debian, it s usually not in areas that I care about. My focus within Debian is on the technical and organizational infrastructure of the project: as a dpkg/dpkg-dev maintainer I try to improve the packaging infrastructure, as a QA member I maintain the Package Tracking System to ease collaboration, as an Alioth admin I ensure all DD can host VCS repositories for their Debian related projects, as a developers-reference co-maintainer I try to share good packaging practices, etc. Given this bias, it s difficult to find customer projects that would let me contribute in those areas. Thus I think I need to try another approach: the simplest solution would be to find sponsors for some of my own Debian-related projects (if you have something else to suggest, please leave a comment either in the blog or by mail). That said finding sponsors looks like a difficult task in itself. While I can imagine (for example) a company using Debian on embedded devices that would like to sponsor the rewrite of update-alternatives in C in order to get rid of the perl dependency in the dpkg package (if you know such a company, get in touch with me!), I don t see who would have an interest in sponsoring the time that I need to contribute new sections to the developers-reference manual. But who knows maybe I should just try and publicly solicit sponsorship for some of the projects that I care about. In any case, suggestions and comments are welcome! Partagez cet article / Share This

The MirBSD Midi-ISO (bi-arch manifold boot) and NetInstall for both i386 and sparc have been upgraded to the 20091226 snapshot (sorry for the delay). A separate news announcement will be done when a full ISO (MirBSD + MirGRML) is done. Other than that, I have fixed a couple of things all over the place, jupp for example. The planned release of mksh R39b is still not done though, as I m only human as well, and too much hacking isn t something one can do without relaxing some in between. On the Debian front, my RCBD #1 was continued, here s #1 results:

• Carry over from day #1
• bug #552791 acorn-fdisk Copyright file does not contain verbatim copy of the license or a pointer to one
• bug #562647 gidentd Does not work with ipv4 after recent change in netbase
• bug #558812 dietlibc incorrect license in debian/copyright
• bug #531937 autossh FTBFS on mipsel due to missing -fPIC
• New ones
• bug #563522 acorn-fdisk cleanup patches
• bug #563525 gidentd cleanup patches

Explanations: I did go overboard during the first patching session, but I suppose this is what the NM learning period is for too. The autossh maintainer said thanks and will probably integrate my patches, so I don t need to NMU. I could close the dietlibc bug. The other two didn t look as good, I had to separate the fix for the RC bug (and other required fixes, such as ftp-master rejects there were none though) and my other fixes; I submit the former as NMU diffs again and pointed Zack to the .dsc files, and opened the aforementioned two new bugs with the rest of the diffs, so the proper maintainers can take and apply them. There s questioning if gidentd should be removed (see the PR for more); the acorn-fdisk upstream (arm-fdisk it s called there) is not actively developing but will receive patches; the autossh maintainer said thanks but I didn t yet hear back from upstream. The binutils as intel_mode bug was fixed upstream and in experimental for my case, but I had to reopen things because the variant documented in binutils-current still doesn t work, so others (who use the new, more intel-like, syntax) don t run into it. Luk sent me a request to do more mipsel-FTBFS-due-to-toolchain-bugs workarounds. Will do (but can t promise to do so before the upcoming BSP. Robert Millan incorporated something like manifold-boot into GRUB 2, after I described it to him (the debian-bsd@ people are currently sorting out some heisenbugs with it, though). Now there s three variants (but then, this helps spotting bugs that don t appear in all implementations). sendmail 8.13.4 is out, I wonder when OgreBSD will upgrade I could do it myself again, but this time it s not that urgent. Still waiting for the TLS extension, though

Two weeks after the Rcpp 0.7.0 release, Romain and I are happy to announce release 0.7.1 of Rcpp. It is currently in the incoming section of CRAN and has been accepted into Debian. Mirrors will catch up over the next few days, in the meantime the local page is available for download too. A lot has changed under the hood since 0.7.0, and this is the first release that really reflects many of Romain's additions. Some of the changes are

• A new base class Rcpp::RObject that replaces RcppSexp (which is still provided for compatibility); it provides basic R object handling and other new classes derive from it.
• Rcpp::RObject has real simple wrappers for object creation and a SEXP operator for transfer back to R that make simple interfaces even easier.
• New classes Rcpp::Evaluator and Rcpp::Environment for expression evaluation and R environment access, respectively.
• A new class Rcpp::XPtr for external pointer access and management.
• Enhanced exception handling: exception can be trapped at the R even outside of try/catch blocks, see Romain's blog post for more.
• Namespace support with the addition of a Rcpp namespace; we will be incremental in phasing this in keeping compatibility with the old interface
• Unit test for most all of the above via use of the RUnit package, and several new examples.
• Inline support has been removed and replaced with a Depends: on inline (>= 0.3.4) as our patch is now part of the current inline package as mentioned <here.

As before, fuller details are in the ChangeLog on the Rcpp page.

In Egypt s sandy silence, all alone,
Stands a gigantic Leg, which far off throws
The only shadow that the Desert knows:
I am great OZYMANDIAS, saith the stone,
The King of Kings; this mighty City shows
The wonders of my hand. The City s gone,
Nought but the Leg remaining to disclose
The site of this forgotten Babylon. We wonder, and some Hunter may express
Wonder like ours, when thro the wilderness
Where London stood, holding the Wolf in chace,
He meets some fragments huge, and stops to guess
What powerful but unrecorded race
Once dwelt in that annihilated place. Horace Smith

Many of us that can afford an Internet connection still qualify as exceedingly rich compared to, for example, many poor people in Africa. On a scale of centuries, the ancient centers of civilization and wealth tend to collapse. Even Rome, with over a million inhabitants in its day of ancient prominence, shrank to only 20,000 over the course of history. Some other ancient cities no longer dot our maps. It helps us, perhaps, to have some perspective. Those magnificent working monuments to wealth in New York, London, or Tokyo probably won t be there 1000 years from now. What will?

With the help of a couple of friends, we ve put a 4.5T RAID-5 machine on our network and I m trying to figure out how to share the storage with the rest of the hosts. In the past, I have used NFS and CIFS/Samba to provide access to remote hosts. This has generally worked okay so long as the server stays online. I don t know if the results are going to be much different, but I am now trying a different approach. I plan to run an iSCSI server, and I ve already configured AoE (ATA over Ethernet). I ve exported a block device on the network segment and mounted it on a remote host. This was pretty easy to configure. There is a bit of documentation on the internet already, but I ll give another quick overview. I gave the storage server the unoriginal name san0 . This host is running debian lenny. I am testing the configuration from my debian sid development host, which has the similarly unoriginal name dev0 . So, think server when you see san0 and client when you see dev0 . I assume that you ve already got an LVM volume group set up. Mine is called vg0 . Correct the following examples to account for any differences. You can use disk partitions instead of LVM logical volumes.

---

Create a logical volume to be exported: cjac@san0:~$ sudo lvcreate /dev/vg0 -n e0.1 -L 5G Load the AoE kernel module: cjac@san0:~$ sudo modprobe aoe Install the package containing the vblade block device export server: cjac@san0:~$ sudo apt-get install vblade Export the block device. Note that the ethernet bridge on which I export the device is called loc : cjac@san0:~$ sudo vbladed 0 1 loc /dev/vg0/e0.1 Install the AoE discovery tools on the client: cjac@dev0:~$ sudo apt-get install aoetools Load the AoE kernel module: cjac@dev0:~$ sudo modprobe aoe Probe for exported AoE devices: cjac@dev0:~$ sudo aoe-discover Verify that our exported device was discovered: cjac@dev0:~$ test -e /dev/etherd/e0.1 && echo "yep"
yep

---

You can now treat /dev/etherd/e0.1 as you would any other block device. You can format it directly, or partition it and format a partition, use it as a device in your software RAID array, use it as swap space (ha), or something completely different. Now to figure out this iSCSI stuff

Christian writes about the nightmare of using the proper name for people in an international context. I ll add that even in the same country/culture, you can have a hard time, because of another factor: the generational context. People don t necessarily address other people from their generation the same way as they would address people from different generations. And these rules may also vary when people age. Even people from the same generation can have different ways to address people. All in all, naming someone is complicated everywhere, though it is more complicated in international context. I ll also add that there are at least two persons involved in a conversation, and that while it is nice that the sender tries to make an effort to address a person the proper way, the recipient should also not take it bad when someone from far away uses the wrong name, and don t make a fuss about it. That s called tolerance. To give an example that is not about names, but about such tolerance, President Obama recently made a visit to the Japanese Emperor, and bowed before him. If you are living in the US, you probably heard about that, because the media there made a fuss about the US president bowing. It so appears that by japanese standards, he indeed did bow too deeply. But the japanese didn t care much. He s not japanese, he doesn t have the cultural background, and therefore can be wrong. At least he tried. What actually made news in Japan is the US news making a fuss about it.

Forgetting that the product named Internet Explorer is from a certain Redmond company, and thus has to promote other products and services of the same company, I typed in a search term straight into the address bar in an IE6 window.
I ended up on the search results page for what I typed on Bing, and noticed a link at the top right which read Gebruik Bing om beslissingen te nemen ( Make Bing your decision engine ).


Curious about what a decision engine could do for me, I followed that link. The decisions weren't all that exciting I could add Bing as a search engine, but actually it already was the default one; and I could set Bing as my homepage not something that Microsoft already aimed for before, with live.com, and something which other search engines do as well if they have a chance.

What struck me however, was the example bing.com screenshot used on the page using a graphic of a puffin. Which, while not being some species of, could remotely pass for some sort of penguin.
Would it really be coincidence that they'd use this image of all possibilities, or is this a wicked taste of humor from someone within Microsoft?

On the train to my parents' house for Christmas I finished up a wild run through the book Coders at Work. The book isn't even mine, but I'd been borrowing it very often, sometimes to the chagrin of its owner, because I could barely put it down. The book is a collection of interviews with 15 great programmers of our time, starting with Jamie Zawinsky and ending with Donald Knuth. It's written in an interview style each interview starts with a brief introduction to the person being interviewed, summarizing what the person is known for and what he or she has accomplished and a few of the highlights of the interview, and then a transcript of the interview follows, with the author/editor, Peter Siebel, will saying something or asking a question, and the interviewee responding. I was skeptical about this format at first because I feel like it can be an easy way out of good editing and make the reader have to do the work of the editor, but on finishing I think that Siebel uses the format to his advantage in this case. For one, the speech format allows the reader to really form a picture of how the person being interviewed speaks and would act in a conversation. Jamie is somewhat bitter and pretty informal. Brad Fitzpatrick is flippant and energetic, his speech littered with profanity and colloquialisms. Others seem more stately and verbose Joe Armstrong's responses can go on for a page or more. In this way, not only do readers learn something about what these greats have learned about programming, but we also feel a bit more like we've met or know them, and can connect to them more as people. I always have this problem where I want to read computer books, but often computer books seem inextricably tied to the computer, so there's this dynamic of reading a bit and then wanting to get on a machine and try something out, write some code, play around especially with books focused on a specific language. Coders at Work retains some of this computer-book dynamic in that I constantly encountered things that I want to investigate or play around with more: Erlang, OCaml, various papers and essays, Knuth's literate programs, and books such as Higher Order Perl and others. Siebel makes a point to ask each person what her short-list of books and papers programmers should read are, so this book is a great source of pointers to other reading material. Unlike a more specific book, however, keeping a list in a notebook was enough to settle the mind to read away-from-a-computer for chapters at a time. It's obvious that despite the interview format, Siebel has done some serious editing. None of the prose is boring to read, and I can't imagine that the text is a straight transcript of how the interviews went. He also has arranged the interviews in an order such that different interviews play off each other. In Branden Eich's interview, for example, he disparages the book Design Patterns:

I never bought the Gamma book. Some people at Netscape did, some of Jamie Zawinski's and my nemeses from another acquisition, they waved it around like the Bible and they were kind of insufferable because they weren't the best programmers.

In the next chapter, Joshua Bloch names it as a book he thinks programmers should read:

Another one, which I have slightly mixed feelings about but I still think everyone should read, is Design Patterns. It gives us a common vocabulary. There are a lot of good ideas in there.

Similar plays, such as Ken Thompson and Fran Allen disagreeing on the badness of C, happen in later chapters, tieing together the different chapters and illustrating how even really good programmers disagree on the Right Thing all the time. Clearly the craft of programming is no settled thing. Besides the general structure of the book being well thought-out, the material is generally thought-provoking and interesting. One thing that stood out to me was Joshua Bloch describing what he called the "empathy gene", which is what a programmer has to have if he's going to be able to design good APIs and programming languages he has to be able to put himself in the shoes of the person who will be using the language or API. This is one thing that differentiates how different programmers can be good at different things. Another thing that stood out to me is that many of those interviewed stated that they don't use much in the way of modern tools and IDEs Joshua Bloch and Simon Peyton-Jones both touch on this, just to name a couple examples, even though some say that they think using these tools would make them more productive, especially when it comes to refactoring. This is a testament to the power of inertia sometimes there is just no chance to be unproductive now in order to be more productive later. Or perhaps just a sign that a programmable text-editor can stand on the same level as a heavier tool in terms of productivity in the right hands. I could go on with examples, but the conclusion here is that I thoroughly enjoyed Coders at Work, and I think it is a book that is well-worth the time spent reading the entire thing.

I recently tried to improve my way to interact with people by mail, in my free software work. Particularly, my intent is to be "better" in using other people names and specific politeness rules. As many of my readers may guess, being involved in internationalization means interacting with people of different cultures. And, when it comes at names, this is just a nightmare..:-) Most so-called "westerners" (western of what, by the way?) are used to the common tradition we share to use people's "first" name....at first...followed by what is most often the "family" name (the one we usually get from our parents). As a consequence, it is fairly easy for me to guess that, interacting with someone named "Barack Obama", I can use "Dear Barack" if I'm in position to use his first name and "Mr Obama" if I need to show some respect distance whatever. Also, as most "western" names are quite familiar in my ears (international culture, blah blah), I can easily guess what is a first name and what is a family name (though, here, "Barack" is probably not the best example). Gender may become a little bit trickier in several cases, but, thankfully, in English, "Dear" does not change with gender (but the third person does whic sometimes leads to problems). The problem arises when interacting with many other culturally different people such as my friends in Japan, China, India, Africa, etc. Here, dammit, the habits might vary a lot and things get harder. Should I call my friend "Kenshi Muto" as "Dear Kenshi", "Kenshi-san", "Muto-san" or whatever? From my readings, I see that most Japanese people do put their family name at first. So, I should then call him "Dear Muto" if I'm very close to him (oh, maybe it's 'her', by the way, who knows?)...or maybe "Kenshi-sensei" because he (oh...or she) is a respected figure in the Japanese FLOSS community...or whatever. Damn! Thankfully, I know Kenshi for years, we're good friends and I know that he's using the "western" way to write his name. I also know he's a man : after 5 or 6 Debconfs, you know everything about people! But, of course, it becomes harder when it comes at people I never had contacts before.....and I don't want to appear as impolite, or silly so, then we jump into my daily "nightmare". Using Wikipedia for hints about Chinese, Indian (the many ones) or even Icelandic or Indigenous peoples of the Americas helps a lot, still. I can only encourage my various friends in free software to do the same. We probably all deeply appreciate when someone shows some knowledge of our culture or at least tries to do his her best to understand our culture. That is probably also part of the mutual enrichment we get in our free software activities. As a tribute for this, I now write my own name as "Christian PERRIER" in my email headers, so that people have a slightly better clue that "Perrier" is my family name and that someone who wants to be familiar with me should call me "Dear Christian". I can probably ncourage my friends all around the world to do the same. For once, using capitals is not about 'shouting' but more about helping other people to figure things out. Next blog writing about the interesting challenge we all face in free software meetings and conferences: shake hands, kiss, hug or just wave? :-)

Holy crap! I don't know how I made it, but my mailing-list spam review page is EMPTY!! It was a long way, started on 2009-04-05, but at least the biggest part is done (now there are only the new reports, much much less than the whole backlog).

Again, I'd like to invite anyone to contribute to have (an ideal) lists.d.o spam free:

• any non-DD can report spam messages clicking on the button on the message page on lists.d.o
• any DD can start here and then contribute reviewing the received reports.

I know it seems boring at first (and indeed it is), but we are many people, and anyonw contributes a little, it will be much faster and less-annoying. For example: why not review some message while waiting for your next package to be built? Or while you wait for the dist-upgrade to end? Or in any other situation where you got some minutes of spare time to dedicate to such an easy task?

Some links to those interested:

• Listarchive spam review main page
  
• wiki page
• spam review stats

Have fun!

Oleg has updated the inline package to version 0.3.4 which is now on CRAN. It is includes my patch for both Rcpp support as well as extended header / library options for PKG_CPPFLAGS, PKG_CXXFLAGS, and PKG_LIBS which I had mentioned recently here and here. There is also a brand-new and shiny R-Forge project for it. A new release of Rcpp will probably follow in due course as we can now depend on this new inline version; Romain has also put nice new code in around exceptions and we may add some more on external pointers. Good times ...

According to the man page, there are three ways to exclude files from being tracked by git.

Shared list of files to ignore The most well-known way of preventing files from being part of a git branch is to add such files in .gitignore. (This is analogous to CVS' .cvsignore files.)

Here's an example:

*.generated.html
/config.php

The above ignore list will prevent automatically generated HTML files from being committed by mistake to the repository. Because this is useful to all developers on the project, .gitignore is a good place for this.

The next line prevents the local configuration file from being tracked by git, something else that all developers will want to have.

One thing to note here is the use of a leading slash character with config.php. This is to specifically match the config file in the same directory as the .gitignore file (in this case, the root directory of the repository) but no other. Without this slash, the following files would also be ignored by git:

/app/config.php
/plugins/address/config.php
/module/config.php

Local list (specific to one project)For those custom files that you don't want version controlled but that others probably don't have or don't want to automatically ignore, git provides a second facility: .git/info/exclude

It works the same way as .gitignore but be aware that this list is only stored locally and only applies to the repository in which it lives.

(I can't think of a good example for when you'd want to use this one because I don't really use it. Feel free to leave a comment if you do use it though, I'm curious to know what others do with it.)

Local list (common to all projects)Should you wish to automatically ignore file patterns in all of your projects, you will need to use the third gitignore method: core.excludesfile

Put this line in your ~/.gitconfig:

[core]
excludesfile = /home/username/.gitexcludes

(you need to put the absolute path to your home directory, ~/ will not work here unless you use git 1.6.6 or later)

and then put the patterns to ignore in ~/.gitexcludes. For example, this will ignore the automatic backups made by emacs when you save a file:

*~

This is the ideal place to put anything that is generated by your development tools and that doesn't need to appear in your project repositories.

The following snippet allows readline-style tab completion backed onto Django models. I am using this in management commands in preference to specifying primary keys as arguments. Example usage: Pressing <tab> at this >>> prompt will complete from the name field of the MyModel model just like a regular shell would. We call readline.set_completer_delims as our items may contain word delimeters - otherwise readline would attempt a seperate completion of (eg) "Bar" if one of our items was "Foo Bar".

A friend of mine is interested in trying out the Automatic Rule Based Time-Tracker arbtt which I programmed. Unfortunately, he is using Windows and up to now, arbtt only worked on Linux. But as I wanted to check out Haskell s cross-platform abilities for a while, this was a good opportunity to do so. I don t have Windows installed myself (and did not plan to do so), so I did all this under WINE, the Windows compatibility layer, which works very well: It takes only a few minutes to install the Haskell Platform for Windows and then I was able to run wine ghc --make and cabal install. I played around with some simple programs and was surprised by these timings:

$ rm *.o *.hi; ghc --make fourfours.hs ; time ./fourfours > /dev/null
[1 of 1] Compiling Main             ( fourfours.hs, fourfours.o )
Linking fourfours ...
real	0m1.909s
user	0m1.692s
sys	0m0.208s
$ rm *.o *.hi; wine ghc --make fourfours.hs ; time wine ./fourfours.exe > /dev/null
[1 of 1] Compiling Main             ( fourfours.hs, fourfours.o )
Linking fourfours.exe ...
real	0m1.631s
user	0m1.376s
sys	0m0.092s

So it is faster to run a compiled Haskell program on top of a compatibility layer than directly on Linux! The world is in order again, though, if optimization is enabled:

$ rm *.o *.hi; ghc -O --make fourfours.hs ; time ./fourfours > /dev/null
[1 of 1] Compiling Main             ( fourfours.hs, fourfours.o )
Linking fourfours ...
real	0m0.981s
user	0m0.876s
sys	0m0.108s
$ rm *.o *.hi; wine ghc -O --make fourfours.hs ; time wine ./fourfours.exe > /dev/null
[1 of 1] Compiling Main             ( fourfours.hs, fourfours.o )
Linking fourfours.exe ...
real	0m1.270s
user	0m1.036s
sys	0m0.072s

Funny. Anyways, I wanted to port arbtt. The only platform-dependent part is the capture module that gathers the list of open Windows. The Win32 package that comes with the Haskell Platform did not cover all the functions needed to do so, but creating additional function bindings is really easy with Haskell, as can be seen in the Graphics.Win32.Window.Extra module. I also replaced the locking code that prevents two instances of arbtt-capture to run at the same time by equivalent code using Windows mutexes (module System.Win32.Mutex). With these small changes and some CPP conditionals to make the code compile for either platform, the porting was done! Even accessing the files in ~/.arbtt works correctly on Windows, where it will look in the Application Data folder, without changing the code, thanks to System.Directory.getAppUserDataDirectory. But Windows users won t like compiling software on their own. They won t even like installing software by copying various files to certain directories. Therefore, I also had to create a Windows Installer. I picked Inno Setup, because it s Free Software and seems to be simpler than NSIS. The installer puts the compiled .exe files, the example categorize.cfg and the HTML documentation in the right spot, adds icons to the Start Menu ( Edit categorize.cfg , which fires up wordpad, a link to the documentation and the uninstaller), puts arbtt-capture in the Autorun folder, puts the path to arbtt-stats in the PATH variable and starts arbtt-capture at the end (the last three points being optional). Of course it undoes all this when removing the program again. I integrated the call to the Inno Setup installer into the usual ./Setup build process of Haskell packages. Some more details of how to create the Windows installer are mentioned in the README file. Now all this does not magically add a graphical user interface to arbtt, so users will still have to work with arbtt-stats on the command line even on Windows. If this is not a problem for you then you can fetch the latest installer from the arbtt homepage. And if you happen to become a serious user of arbtt on Windows and want to help maintaining the Windows port, I ll gladly share some responsibilities. I m very satisfied with the process and the result and I m happy to know that I can offer some of my programs also to Windows users in the future.It is also a big plus for Haskell with Python, shipping a program for Windows users is likely more difficult. The next step will be providing gtk-based graphical Haskell applications for Windows, including a nice installer that ideally includes all dependencies (gtk etc.).