I can be childish too: PHP must die I’ve been actively migrating services away from PHP for a while now, even at the cost of having to use less mature applications which aren’t as pretty. I’m definitely at the point now where I simply don’t trust it and the applications which (ab)use it. Tonights job is to look for a non-PHP blogging application which can import my wordpress content from. I even wrote 75% of one myself once upon a time, but I lacked the time to finish it off. Sure there are good PHP coders out there, I’m just sick of the rest. Somebody should write a intepretted templating system similar to PHP, but with no bugs. Although maybe thats the problem, giving people the ablity to mix presentation inline with code was a fundamentally bad idea to start with? Since it led to non-programmers producing things that were broken. I do keep meaning to look at Rails, but I’m usually turned off by the problems of mixing Debian packages with the rubyforge gems - I like to keep things from one source. (e.g. 99% of my perl modules are Debian packages, not CPAN packages.)

The delay of Debian Etch caught some bad press this week. Some articles compare Debian to Ubuntu (which tries hard to have fixed-time releases), and some bloggers are amused by the fact that the next Debian release was delayed “again”. There are some important points though:

• Etch wasn’t really scheduled to be released on Dec 4th. This target date was mainly used to determine other dates in the release process, like the freeze dates.
• Ubuntu Dapper was delayed as well, for 6 weeks. Ubuntu Edgy wasn’t delayed, but I don’t think anybody can seriously compare Ubuntu Edgy’s quality with the upcoming Debian etch’s quality: edgy was more like a technology preview.

Now, the question is: how good is Debian Etch compared to Ubuntu Dapper ? It’s difficult to compare distributions: there aren’t a lot of good metrics for this. Of course, one could compare the number of packages that fail to build from source (it’s a good indicator of something seriously wrong in a package). But a lot of work has been done on etch about this, so it wouldn’t really be fair for Ubuntu. A good alternative is debcheck. debcheck checks that packages can be installed (i.e that their dependancies can be satisfied). It does so by analyzing the content of the Packages files. I compared the results of debcheck on etch as of today (I re-processed it, but the same results are available from qa.d.o), and of debcheck on Dapper (not including dapper-updates - I wanted to compare quality at release date). Included sections were main for etch, and main, restricted and universe for dapper (I didn’t want to consider non-free packages, since their quality tend to be lower). Results: 4 packages have unsatisfiable Depends on etch, on i386. 49 have unsatisfiable Recommends. In the main section of Dapper, still on i386, only one package has a problem with its Depends (it was psycopg, because its binary package python2.3-psycopg has a dependancy on python2.3-egenix-mxdatetime). 46 packages in main had unsatisfiable Recommends. This is better than Etch, of course, but Ubuntu/main is much smaller than Debian/main. When restricted and universe are included, the results are much worse. 80 packages have unsatisfiable Depends, and 150 packages have unsatisfiable Recommends. It is worth noting that those numbers are worse than those of Debian unstable as of today (67 packages have unsat Depends, 34 have unsat Recommends). Conclusions (sort of):

• Using the debcheck metric (which is actually quite important, since it translates in uninstallable packages for the users), Debian etch is already of better quality than Ubuntu Dapper when it was released (again, I haven’t checked with dapper-updates included).
• It would be great to integrate such tests into the Ubuntu release process. Fixing bug is good, but such tools help to improve the distribution quality as a whole. I’ll try to work on this for Feisty after the Etch release.

Here’s a quick status update for mbpeventd users; PowerBook users may be interested too ;-) So, here we go:

• DBus support is done
• Graphical clients are available: mbpgtk for a GTK-based application similar to the pbbuttonsd client, wmmbp for a WindowMaker dockapp
• PowerBook support: Yves-Alexis Perez is adding support for the latest PowerBooks with keyboard backlight, and he’s mostly done with it

The GTK client is complete but still needs a bit more work: configuration support, and changing the colors of the progress bar (currently the colors of the current GTK+ 2 theme are used). Yves-Alexis could probably use some help on the PowerBook front, mainly for identifying the appropriate i2c device to use and other things. If you are interested by using mbpeventd on a PowerBook, check out the mbpeventd-ppc branch and give it a try. Plan for upcoming releases:

• DBus support and graphical clients
• PowerBook support and graphical clients improvements
• More PowerBook support (more machines supported)

As we’re adding PowerBook support, we’ll be renaming mbpeventd, so watch out for the new name when we’ll merge PowerBook support in :-) Thanks to:

• Yves-Alexis for the PPC support
• Soeren Sonnenburg for the base of the GTK client

Source code, check it out using svn co :
DBus branch: http://svn.technologeek.org/repos/mbpeventd/branches/mbpeventd-dbus
PPC branch: http://svn.technologeek.org/repos/mbpeventd/branches/mbpeventd-ppc

ls2rss AFAIK amule is missing notification of completed downloads. In addition to that, me and Godog are sharing the same amule instance and it's cool to be notified of what the other downloaded, it's a bit like the for:someone tag on del.icio.us. As an issue of my hack of the day series I hence implemented ls2rss.py. The name is telling: given a directory it generates a corresponding RSS feed. It's written in python, it's meant to be run as a cron job, and takes care of minor details like remembering files that have been deleted since the last invocation and enforcing a threshold to the feed size. I was unable to find anything like that already available on the net (the one available here is not available for download any longer). In case of need, try mine. Download

• ls2rss.py (python script) Requirements are: python-syck, python-pyrss2gen or equivalent non-Debian packages
• [sample YAML configuration file incoming.yaml] used by me to monitor my ~/Incoming/ directory

Many people have recently posted in Planet Debian regarding the use, usability and usefulness of having comments enabled in blogs, of using comments as the right way for following discussions, of dealing with spam, and so on.
I'm sorry I'm not linking to more of them, but I'm too lazy to look them up. This is one of the down-sides of not using comments - Ideally, if I were interested on commenting on a topic, I would just leave the comment on the blog that started it. It goes somewhat against Joey's logic of posting both the comment and the posting itself - Of course, we all want everybody and their dogs to read our comments, don't we? And, given we know that (most of) our target readers regularly follow Planet Debian, we continue ranting on our personal blogs (as I'm doing now). Besides, that will rank our page higher. We all want Google to love us, right? Of course, following discussions on a bunch of blogs is not optimal, as it's easier to miss parts of it (hey, would somebody volunteer on writing threading support for Planet? It'd have to be multidimensional, as postings often refer to different threads... Bah :) ). Besides, many of us are syndicated on different planets (and many people read our blogs as individuals as well), so many of my postings start with a stupid amount of background information so the martians understand the terrans. But still, here I am, writing a post that provides nothing but a braindump, serves no purpose, and links to your posting. So there, the world is not ideal. QED.
As always, MJR rants against captchas (and yes, thank you, you have commented on my blog that most captchas are trivially crackable by automated means). They do reduce spam, but they are REALLY not a strong barrier against it. I have thought of some ideas, or thought about implementations for other ideas I've read here and there, but I'm too lazy to implement them on my blogging software. I could switch, but I happen to like Jaws. I would like to contribute to making it better, but have had a permanent lack of time for a long time already :-/ I do get swamped by spam comments, and every now and then mass-delete whatever looks like spam (hundreds to thousands of comments, for crap's sake!), but anyway... It's not too important for me. I like having comments on my entries, but sometimes a long time must pass until I even read them (I read my own blog syndicated via the Planets, on a RSS reader).
BTW, Lucas: I used to have trackbacks enabled. The amount of spam, and the control I have over spam in my blog, makes me favor comments against trackbacks. My trackbacks used to be so wildly abused that it almost made me cry. I hope it is not your case :)

In part 1, I described the problem of software installation on Linux; in part 2, I’ll describe the solution we came up with at the recent LSB Packaging Summit. After reading through the comments to part 1, let me first point out that our goal is to create a vibrant third party software ecosystem around Linux—you know, like the one Microsoft has built around Windows. No, it’s not about imitating Microsoft. It’s about being competitive. A platform is only as good as the applications that run on it. Bottom line: Many third parties have built their businesses around proprietary software, and we can’t just ignore them. And “ecosystem” implies decentralized, which I argued in part 1 was a key tenet of open source development anyway, i.e., this should be playing to one of our core strengths. So, if your “solution” is to tell ISVs (independent software vendors) to give us their source code so the distributions can include it because that’s just how we do things, you can safely skip the rest of the post below. You’re simply not going to agree that any of this is a problem. Ok. Assuming our goal is to create a vibrant third party software ecosystem (and everyone still reading agrees that’s a good goal, right?), we have the following challenges. First of all, the distribution vendors are hugely invested in their existing package systems, and for the most part, those package systems work extremely well. As I said in part 1, “if [an application] is in your distro of choice, you re only an apt-get or a yum install away from running it.” (I’m saying it again here because some of the commenters apparently didn’t see that. The tricky bit is “in your distro of choice”, which by definition is not the case with third party software.) Furthermore, a variety of highly sophisticated systems management solutions are built above those package systems, such as Red Hat Network and Novell ZENworks. This is a pretty important consideration, because these days, the “software management problem” largely involves managing software across the entire infrastructure, not just a single system. What problem then? This: ISVs have thus far been reluctant to use the native package systems. Why? THEY’RE hugely invested in “package systems” for other platforms, and every Linux specific thing they have to support costs money. In a world where decisions are ruled by cost vs. benefit, this is a pretty important consideration too. How do ISVs handle this today? For the most part, they ignore the package systems on Linux and do their own thing. Trouble is, while doing their own thing gives ISVs the flexibility to work cross platform, it ultimately makes their products integrate poorly in the broader systems management context because the package systems know nothing about them. What is needed is a way to bridge the gap between what the distros provide and what the ISVs want. But how? First off, we have to understand what ISVs want. The answer is simple: ISVs want to treat Linux as a single platform, which means they want to offer a single package for Linux, much as they do for Windows. So, if one commenter is right that “[t]he problem is that people (including software distributors) believe there s such [a] thing as ‘Linux’ as a target platform” and that “[i]f you re distributing software for ‘Linux’ then it won t be simple to install it, ever”, well, then Linux is destined to suffer the fate of UNIX. I’m not ready to give up so easily. Several commenters suggested that what we need is a brand new package system. That’s a non-starter—for one thing, the distros aren’t going to be too keen on replacing something they’re hugely invested in, and if ISVs aren’t going for RPM today, why would they go for something different tomorrow? No, to find a way forward, we need an evolutionary step from where we are today. From there, perhaps we can do more, but even the first steps can be quite valuable in their own right. To help find those first steps, we put some of the leading minds in Linux packaging in the same room (including the maintainers of RPM at Red Hat and Novell and the authors/maintainers of APT, yum, alien, and klik) along with ISVs large and small, server and desktop. The discussion pretty quickly converged on constructing a single API that could be implemented across the various package systems, because APIs make for nice evolutionary steps and can, done right, mask underlying implementation differences. Question is, what do ISVs need in such an API? Limiting the scope is key here, because providing an API that spans all the functionality of, say, RPM and dpkg is overwhelming to the point of being unworkable, not to mention more work to implement, which in turn makes it less likely to get into the distros so that ISVs can count on it being there, the whole point of this exercise in the first place. Fortunately, the ISVs don’t really need much. At the most basic level, an installer just needs to be able to query the system to see if it’s LSB compliant, and if it is, what version of the LSB it’s compliant with; and it needs to be able to “register” with the package system, so the package system knows about it, including what files it has installed. And that’s really about it. Importantly, because we assume an environment that’s LSB compliant, we don’t have to worry about dependencies, because everything is covered by the single LSB dependency, and dependency management is 95% of the package systems right there. We still need minimal dependency support—components can extend the LSB, and applications can depend on those other components being installed—but we’re talking on the order of a handful of components, not the tens of thousands of components typical package systems have to deal with. We only had a day, so we obviously don’t have a complete solution yet. For one thing, we barely touched on the issue of uninstallation (should we allow applications to register GUI uninstallers?), and the issue of how applications go about changing the system configuration still needs discussion (in a lot of cases, the assumption of LSB compliance means the installer is going to be well behaved, but there’s undoubtedly corner cases to be explored). And it’s going to take time for the API to be implemented and put into widespread enough use that ISVs can depend on it. However, everyone in the room did come to consensus pretty quickly that this was an important problem, and that providing a simple API that provides the minimum necessary functionality was the way to go. Perhaps most exciting, the very people whose support are needed to put the API into widespread use were in that room, and active participants in the discussion too. Everyone is certainly motivated: The distros get more applications, which makes the shared platform more attractive; and ISVs get lower cost, which tilts the cost vs. benefit equation in their favor, making Linux versions more economically attractive and potentially opening new markets. Because this is just a start, the FSG is launching a Packaging workgroup to continue the discussion we started at the Packaging Summit. If you’re interested in this topic, I’d encourage you to join the mailing list and get involved. There’s still plenty to be done. Update: One more thing: In addition to making it easier for ISVs to better support Linux by simply extending their existing installation scripts, the API approach really comes into its own when you imagine it implemented in things like Autopackage and InstallAnywhere. Let the market decide!

Johan Rydberg has recently announced his Free Software (GPL) firmware implementation named GNUFI.

GNUFI is designed to be a firmware compatible with the Unified Extensible Firmware Interface (UEFI) specification. GNUFI is designed so that it can be adopted to different runtime environments; such as a legacy BIOS or U-boot environment, or as a LinuxBIOS payload. At this point there has not been any official release of GNUFI. The version controlled source repository can be accessed using Bazaar:

bzr branch http://gnufi.openbios.org/gnufi.dev

If you're interested in early testing and/or helping with development also checkout the wiki / bug tracker and the mailing list.

For those who've been hiding under a rock for the last few months: dunc-tank is the (controversion) project that was founded by the current DPL, Anthony 'aj' Towns. Controversial, because a lot of people feel that this goes against the spirit of Debian; and that by paying some Debian people and not paying others, we're creating a two-class system that we'd best avoid. And probably a bunch of other arguments, too, but that's not what this blog post is about. Me, I've been staying rather quiet in the whole debate. It's not that I don't have an opinion; rather, I haven't been voicing it, mostly because my thoughts on the matter are rather convoluted, and I'm not sure I can put them in words pretty well. But since the debate seems to be going in circles, and since I think that I might be able to help it out, I'll try anyway. If that doesn't bring the debate any further, well—can't blame me for trying. Do I think that paying people to do work on Debian is necessarily a bad idea? No, not at all. Quite to the contrary; by paying people to work full-time on Debian for a while, we will increase the amount of work that's being put into Debian, which can only be a good thing; and I can only applaud aj for trying to get this done, since it should be obvious to anyone involved that by proposing this, he only had Debian's best interests (i.e., improve our distribution) in mind. The obvious question, however, is who we'll be paying. After all, while I don't think it's necessarily bad to pay people, I do think that with money, you introduce the possibility for corruption; so at the very least, it should be strictly checked what exactly happens with the money that's being spent. Accordingly, the way in which you pay people—your whole set-up and procedures—should have a number of safeguards. Which brings me to my next point. Do I think that dunc-tank, as a project, is a good idea? No, not at all. Quite to the contrary; and I have a number of reasons for that. First, I don't think that deciding by committee who can get paid and who can't is the way to go forward. A committee will always be biased, no matter how diverse its membership. Even if you could find a committee that would not be biased—an impossibility by definition—then there will still be people who will not agree with the committee's decision. Are they right not to agree? Not necessarily. Is it bad to create such controversy if it could be avoided? Sure as hell. Moreover, by creating a project which populated by Debian people and which has the sole purpose of paying Debian people, it's fairly possible to create the impression as if all other ways to get paid to do Debian work would be unsound; that if a developer accepts money for Debian work without going through the committee, he's somehow doing something morally wrong. This would be very bad indeed; I know for a fact that there are cases of people paying Debian Developers to work a few days on a certain package so that a certain bug which impedes their business is fixed, or so that a certain version of a random package which this company is using, is uploaded into the archive. I've done this myself in the past (although I can't disclose more, since the person who paid me requested to remain anonymous); I know of at least two other Debian Developers who've done so as well. So what's the alternative? Not paying people is one, but it would not necessarily be the best. One alternative, which the FreeBSD people have been doing, is just "no organization at all". People who want to get paid just put up a web page with the amount of money they would like to have, and it's up to the community to decide whether their request is valuable enough for it to actually be paid. To some extent, this is also what the Dunc-Tank committee is doing, except that as FreeBSD does it, there is no committee in between. The problem with this approach, however, is that if we all go ahead and ask for money at the same time, it'll not only make us look like a bunch of beggars; it's also very likely that nobody will actually be getting any money, because there's so many "good causes" to choose from that there might not be enough donations to fund them all. Another proposal was one made by Manoj Srivastava, before word got out that dunc-tank would be started (or about at that time). As it was made on the debian-private mailinglist, I can't say much about that; suffice to say that I feel his proposal was overly bureaucratic, and had problems that were similar in nature to the problems I feel exist with dunc-tank. So do I have any answers which might get us a way out of the current status quo? Nope, afraid not. But allow me to make this final observation: In early 2005, a bunch of people decided that Vancouver was a nice place, and travelled there. As it happened, they were all Debian people. What a coincidence. Since they were all there anyway, they decided to talk a bit about Debian, and as a result, came up with some plan for its future. This plan, too, was rather controversial. When I initially read the first few paragraphs, I suddenly fell upon this paragraph which seemed to say that "we suspect we won't be releasing with anything but i386, amd64, and powerpc for etch". Things suddenly turned kinda red from then on. And it wasn't the wine that I hadn't been drinking. I could imagine that what I felt back then is somewhat similar to what some other people felt when they first heard about the suggestion to pay people for Debian work; and this realization is the reason why I haven't been dismissing their arguments or thoughts, much like I've seen other people do. However, I cannot say that I feel the current crisis to have many parallels with the Vancouver one; this is mostly because in the current case, people on both side of the argument seem to be building up walls around themselves, to help them ignore whatever the other side was saying. In contrast, when someone suggested something which had the potential effect of throwing most of the hard work I'd been putting in for Debian during the last five years now down the drain, I went to talk with them—after the heat had cooled down, anyway. Unfortunately for me, the result is exactly the same; for all my effort, I haven't been able to prevent m68k to be kicked out of the release; and to say I'm not happy about this would be an understatement. But at least this way the port has been given a fair chance; if I hadn't been talking to the people on the other side of the argument, I would still be talking about Steve Langasek as if he were the devil himself, and m68k would probably have been kicked out of Debian—along with a bunch of other architectures. At least I got that bit fixed. I guess what I'm saying is that people, rather than farting in eachother's general direction, should be working together in finding a compromise. Sure, that means making concessions, and agreeing to something you'd rather not agree to. But at least this way, the thing you have to agree to isn't as bad as what it could be. And trust me, people will do the stuff you don't want them to do, with or without your agreement. Hell, they've already started. Whoa, long post. I'll stop preaching now.

In the finest tradition it is Christmas-time and my computer is dead. OK slight exaguration. I have two computers I regularly use:

desktop.my.flat

This is my main development machine, which I sit in front of and work at most days.

itchy.my.flat

This has several roles:

• xen
  • So that I can run Sarge for building security updates.
• caching name server
• backup server

(Both of these machines run Sid.) The backup server is the important use for this machine. Every four hours I do a full database dump + rsync of d-a.org, my personal server, and my desktop system.

The backup machine, itchy, is currently down because of a failing hard drive. I’ve ordered a replacement computer (a bit extravogent considering I could have got by with just a new disk drive). This will be my first 64-bit machine, and also my first machine with hardware support for virtualisation. The new machine should arrive on Saturday. Once it does I’ll rotate it in. The new machine will become my desktop. My desktop will become the backup, and the old machine with the failing drive will be donated to my Sister. (Who I was due to give a machine to already. I will need to get a new disk but that will be done shortly.) I think I’ll try sticking with Etch on the new machine, and possibly make the backup machine run it too. I guess I don’t need sid yet… Besides Xen makes new installations easy

People who see those standing to their principles as childish have a strange perception of what being an adult means. Or maybe it's just politics. After all, we've seen this coming: Well, Dunc-tank failed, but this was because of childish people working actively against it.

That sometimes journalists have obvious reading problems, well, isn't a too new thing. One has to deal with that, e.g. by appending more text to the cited blog entry. If someone inside the Debian community fails for the same is way more disappointing for me. I have never stated that "[I] couldn't compensate this" - that is just totally wrong. I think that dunc-tank helped us with release of Etch, but the help could have been greater if some people wouldn't behave as childish as they do. And I also try to look both ways, and not be singled-minded about it. There is another thing I learned as well during the last 12 hours - people don't appreciate if one tries to summarise openly what happened, and look both ways. Is it so wrong to look in both directions, and not only say "that and that were the improvements"? I thought at least within Debian we don't want to fall the usual management mistake of only speaking about how great everything is, but be honest to ourselfs. People starting to rip only half of the words out, citing them out of the context, and inventing new quotes don't help with that.

This morning I received an email from the AMD Developer Center advising me that I need to fill out their NDA if I want access to their development machines.

I have a vague recollection that when AMD64 was first released I was very keep to get access to such hardware and had applied to AMD for access to their machines.

Of course now the second-hand market is full of AMD64 machines and I've got one in my server room so it's not as useful as it once was. I don't even know why AMD would still run a developer center given that everyone who wants AMD64 machines can cheaply buy as many as they want and organizations such as Sourceforge and Debian provide access to such machines for their members.

While I appreciate what AMD is doing, it probably would be best if companies could adopt a standard timeout for electronic correspondence. If someone doesn't follow up for X months then you should assume that they are not interested.

Takatsugu had problems with his maildir and lost a bunch of mail. This reminded me of my little script that keeps my maildirs at a reasonable small size. I let run over my maildirs every night. It removes duplicate mails first and then moves all mails that are older then 30
days and not part of an active thread into a $maildirname.attic maildir.

I invoke it like this on my mail server in my user's crontab

@daily ~/src/pack_maildir.pl --maildir=~/Maildir --dir=. $(find ~/Maildir -maxdepth 1 -mindepth 1 -type d -not -name '*.attic' -not -name 'tmp' -not -name 'new' -not -name 'cur' -not -regex '.*Trash.*' -not -regex '.*Trash.*' -not -name '.SENT' -not -name '.Sent' -not -name '.DRAFTS' -not -name '.Drafts' -not -name '.virus' -not -name '.merkwurdiges' -name '.*' -printf "--dir=\%f ")

and duplicate the maildirs from there to my working machines with offlineimap.

This setup is orthogonal to spam protection, however. Apropos spam: According to my munin spamstats i get a magnitude more spam then ham nowerdays.

[RV Heraclitus SE Asia voyage: blog photos] The past few weeks, we changed our route to visit an uninhabited island (aka Ko Pulau Island) said to be "National Geographic, man" by some Americans we met in Kupang. On the way to Ko Pulau Island we saw a large school of pilot whales and dolphins, a humpback or other whale close to shore, a blue starfish and hot water vents nearby on the same mostly dead reef, a flock of birds feasting on a dense school of fish, a manta ray, a bonfire on the beach shared with the kids of Rote (who we swapped roast banannas and coconuts with), a clean hull and renewed sea-sickness. At Ko Pulau Island, we saw a long white beach made of small bead things instead of sand, with surf at either end and reef in between, a green lagoon with islands being eaten away at the base, a monkey-head rock, pink coral, reef fish, sea urchins, various pieces of flotsam washed up on the beach (flip-flops, a light-bulb, bottles, wood, burnie-beans, nautilus shells, a seabird egg, a dead seabird and other crap), sunset over the ocean with golden cirrus in the sky, turtle nests, tracks and hatchlings scurrying off into the water, Indonesian fishermen in need of water and turtle eggs, tidal pools with the occasional crab, ghost crabs darting towards the water, a pandanus stand, a small cave surrounded by discarded turtle eggshells, spinifex, hermit crabs, scrambling lizards, sunburn and other things. Later in our voyage, we saw a big lone flying fish, land looming mountainous on starboard, TNI, gratis reef fish, water buffalo and threatening rain clouds. The next major stop was a bay on the south side of Sumba, black cliffs to port and an eroded hillside to starboard. There, we enjoyed the excellent snorkeling against the cliffs and off the beach, birds calling from the forest, wasps - shiny blue and otherwise, meeting roaming cows in the forest, forest fungi and other sights. We met some fishermen and drove through the forested slopes toward a nearby city. On the way, we visited an Indonesian village and saw their traditional animist temple, ample baby pigs & dogs, tons of kids trying to get in photos, satellite dishes and graves in front of houses. Unfortunately, I crashed once we reached the hotel, missing eating and night life, but I did enjoy the sights from the windows of the cramped 4WD we were in. We headed for the 9.8 knot passage of Selat Sape, complete with eddies, currents, a barracuda and the steep slopes of a silent volcano. Since there, we saw an increasing number of interesting and curious Indonesian vessels, fish traps, the grey shapes of dolphins swimming in the aqua water under the bow, a floating sandal, a school of mahi-mahi jumping out of the water, a misty night, numerous schools of feeding fish, entangled luminescent trails left by dolphins swimming in the phosphorescent water beneath the bow, flashes of lightning in the distance, our first rain since Cairns, the associated storm, Jack the fisherman (a mast hallucination) and other things. Our next stop was Kalimunjava (north of Java, Indonesia), more than half way to Phuket. We spent a week there, watched lightning, collected rain, visited the local school, dived and snorkelled on the magnificant reef with some really nice university students (hi Lely, Dudu, Jaos and others) from Java who were doing a study on the corals and hiked up the steep slopes of the island. From there we ambled past Borneo, towards Bintan, near Singapore, experiencing the first non-calm seas in ages, dolphins in the storm, floating lines of debris, big barges, container ships and megatankers, a fancy, shiny yacht, fishing vessels with 50,000 lights, Rain Drop and it's egg (child of Rain the gecko), amazing cloudscapes at sunrise, throughout the day and at sunset on the way. Amazingly, we met the 8 (Infinity, the new PCRF vessel) one find day in the South China Sea on their way to Bali. Eddie saw them from 5 miles away and knew almost straight away it was them. Michelle came on board and a lone daytime cumi (squid) swam between us as we parted. Before we arrived at Pulau Bintan (near Singapore), we saw seasnakes and a palm tree floating and lots of wind and rain. We will probably arrive in Thailand by January and I'm thinking of passing thru Sydney on the way home, so let so please mail me if you want to meet up.

I am about 2/3 over with my haul from Edmonton to San Juan, PR (laying over in the beautiful JFK) and am too tired to blog anything much of substance but do check out Furious Season’s impassioned and excellent commentary on the recent NYTimes article (and this one )that reveal how Eli Lily knowingly downplayed the risks of Zyprexa. And if you read the second article, you will find out what Viva Zyprexa means. Here is Eli Lily’s press release, which I have included on the next page as these things tend to vanish… Statement from Eli Lilly and Company: Response to The New York Times Article from December 18, 2006 December 18, 2006 INDIANAPOLIS, Dec 18, 2006 /PRNewswire-FirstCall via COMTEX News Network/ — Eli Lilly and Company (NYSE: LLY), vigorously objects to the characterization of company practices in a New York Times article based upon selective documents illegally leaked by plaintiffs’ lawyers. “At Lilly, we do not engage in off-label promotion - as alleged in The Times article,” said Dr. Steven Paul, Lilly’s executive vice president, science and technology. “Lilly is committed to the highest ethical standards and to promoting our medications only for approved uses. We have clear guidelines and extensive training for our sales representatives to help assure that they provide appropriate promotional information that is within the scope of prescribing information approved by the FDA.” Lilly works to bring Zyprexa to physicians who are confronted with the need to diagnose and treat serious schizophrenia and bipolar disorder wherever they practice. * About half of medical care for serious mental illness takes place in a primary care physician’s office. This is due to the fact a large number of people in the United States have no access to a psychiatrist or do not seek psychiatric care. * Our experience in mental health has taught us that primary care physicians are asking for education on severe mental illnesses, since they see many of these patients in their offices. * We believe that it is absolutely appropriate to discuss Zyprexa and its indicated uses with primary care physicians in the interest of meeting a critical medical need. * It is important that the public understand that physicians can and do prescribe medications outside of their approved indications to meet the needs of their individual patients. “While it is accurate to say that mental illnesses like schizophrenia and bipolar disorder begin early in life — with a higher prevalence during early adolescence and childhood — it is simply untrue to assert that these diseases somehow end — and therefore prescribing for them ends — in young adulthood,” added Paul. “To dismiss the devastating impairment of these disorders throughout a patient’s life is wrong. “Bipolar disorder and schizophrenia are often treated in the offices of primary care physicians. In fact Lilly did research with primary care physicians and found that they were challenged in making the diagnosis of bipolar disorder. Many primary care physicians appreciate the educational outreach Lilly provides in mental illness,” he added. The Times failed to mention that these leaked documents are a tiny fraction of the more than 11 million pages of documents provided by Lilly as part of the litigation process. They do not accurately portray Lilly’s conduct. As part of Lilly’s commitment to patients and healthcare professionals, many high-level Lilly physicians and researchers — along with researchers from outside Lilly — were engaged for a number of years to study the issue of Zyprexa and diabetes. Leaked documents involving these discussions do not represent an accurate view of company strategy or conduct. Lilly deplores the illegal release of select confidential documents. This illegal and selective disclosure of incomplete information will cause unwarranted concern among patients that may cause them to stop taking their medication without consulting a physician. This is the unfortunate result we saw when plaintiffs’ lawyers aggressively advertised about Zyprexa in recent years while searching for clients. Lilly, a leading innovation-driven corporation, is developing a growing portfolio of first-in-class and best-in-class pharmaceutical products by applying the latest research from its own worldwide laboratories and from collaborations with eminent scientific organizations. Headquartered in Indianapolis, Ind., Lilly provides answers — through medicines and information — for some of the world’s most urgent medical needs. Additional information about Lilly is available at www.lilly.com. C-LLY Zyprexa (olanzapine, Lilly) (Logo: http://www.newscom.com/cgi-bin/prnh/20031219/LLYLOGO ) SOURCE Eli Lilly and Company Tarra Ryker, +1-317-276-3787, mobile: +1-317-332-7502, or Marni Lemons,
+1-317-433-8990, mobile: +1-317-532-7826, both of Eli Lilly and Company http://www.prnewswire.com Copyright 2006 PR Newswire. All rights reserved News Provided by COMTEX

If you agree you might understand why I blog about the sign in front of a restaurant I just passed by. Compare "buffet libre" with "all you can eat".

Well, this is first post. I have managed to migrate my blog over to Ikiwiki, including all the historical posts. The reasons for migration was that development on my older blogging mechanism, Blosxom, entered a hiatus, though recently it has been revived on sourceforge. I like the fact that IkiWiki is based on a revision control system, and that I know the author pretty darned well :-). One of my primary requirements for the migration was that I be able to replicate all the functionality of my existing Blog, and this included the look and feel (which I do happen to like, despite wincing I see from some visitors to my pages) of my blog. This meant replicating the page template and CSS from my blog. I immediately ran into problems: for example, my CSS markup for my blogs was based on being able to markup components of the date of the entry (day, day of week, month, etc) and achieve fancy effects; and there was no easy way to use preexisting functionality of IkiWiki to present the information to the page template. Thus was born the varioki plugin; which attempts to provide a means to add variables for use in ikiwiki templates, based on variables set by the user in the ikiwiki configuration file. This is fairly powerful, allowing for uses like:

    varioki =>  
      'motto'    => '"Manoj\'s musings"',
      'toplvl'   => 'sub  return $page eq "index" ',
      'date'     => 'sub   return POSIX::strftime("%d", gmtime((stat(srcfile($pagesources $page )))[9]));  '
      'arrayvar' => '[0, 1, 2, 3]',
      'hashvar'  => ' 1, 1, 2, 2 '
     ,

The next major stumbling block was archive browsing for older postings; Blosxom has a nice calendar plugin that uses a calendar interface to let the user navigate to older blog postings. Since I really liked the way this looks, I set about scratching this itch as well; and now ikiwiki has attained parity vis. a vis. calendar plugins with Blosxom. The calendar plugin, and the archive index pages, led me start thinking about the physical layout of the blog entries on the file system. Since the tagging mechanism used in ikiwiki does not depend on the location in the file system (an improvement over my Blosxom system), I could layout the blog postings in a more logical fashion. I ended up taking Roland Mas' advice and arranging for the blog postings to be created in files like:

 blog/year/month/date/simple_title.mdwn

The archives contain annual and monthly indices, and the calendar front end provides links to recent postings and to recent monthly indices. So, a few additions to the arch hook scripts, and perhaps an script to automatically create the directory structure for new posts, and to automatically create annual and monthly indices as needed, and I'll have a low threshold of effort blogging work flow for blog entries, and I might manage to blog more often than the two blog postings I have had all through the year so far.

That would solve so many problems. LaTeX is still unbeaten in terms of print quality. It's really powerful. Since I've been using it, if started to really despise Writer and Impress. latex-beamer slides look just so much better than any PowerPoint presentation I've ever seen. However, it's far from easy to use. The syntax is a pain, and I don't think it's a feature that you can actuall program in this language. Similar things hold for BibTeX - there are so many things to do wrong there that will go a long way unnoticed. I've recently helped a friend to fix some BibTeX files. It was a pain, there was so much wrong in there... for example URLs. People noticed that they can't just always copy URLs in there, because some characters are special to LaTeX. But instead of using the \url macro, which would also have solved linewrap problem, they started doing the most obscure things (and of course they did not read the FAQ we wrote for them or asked how to do it right), for example adding whitespace to enforce line wraps, replace _ and & with whitespace etc., wrap uppercase chars in - an awful mess. The same thing with the author values. They just wrote "First author, second author" without considering that this might be interpreted according to the common "Last Name, First Name" scheme: e.g. "van Damme, Jean-Claude". (The correct syntax is "First Author and Second Author and Author, Third" - use "and" for separating even when you have more than two authors.) XML is better here. It's rules of escaping are generic and application-independant, and thus you'll have much more tools that know how to do it right, and you only have to learn it once, not for each application. The structuring also comes in handy:

  <authors>
    <author firstname="Foo" lastname="Bar" />
    <author firstname="Gnarf" lastname="Quux" />
  </authors>

is a bit more to write, but it avoids parsing errors. And with good utilies it's not particularly hard to write. Now don't point me to XML-FO. I know about formatting objects, the paper I submitted to the eXtreme Markup Languages conferences was done with FO. It's just that they don't come anywhere close to LaTeX in terms of print quality, the only OpenSource implementation I'm aware of didn't make much progress (but they seem to have released a rewrite in the meantime) and was lacking important features, and MathML has a horrible syntax mess (apart from Apache FOP not having MathML support). XSLT also has an annoying syntax. Too verbose and totally unreadable once you do things that are a bit more complex than the simplest examples. I wish we had something that gives a similar print quality to LaTeX, that uses some XML format (or something similar structured and easy to parse, like Xcerpt data terms, but thats basically equivalent to XML, just a bit more compact; Lisp S-expressions and OEM are other examples) that allows the easy creation of third party utilities and does away with all the black magic involved... Yeah, IMHO it's really time for a rewrite of LaTeX with a modern language design. And a large, unified standard library; plain LaTeX sucks, you can barely use it without extras such as url, hyperref, latex-beamer. [Update: yes, I'm aware of bibtexML, but it's just as bad, you still need hacks such as "the C language" or using "and" to separate multiple authors. I'm also aware of docbook and docbook to latex converters; that definitely is a workaround, but doesn't solve the real problems] (Comments in my blog are intentionally disabled. So if you want to voice your general dislike of anything with XML, abuse your own blog!)

In my first article about testing tuxpaint with xautomation, I mentioned that I wasn’t happy with hardwiring button positions. But before I could proceed, I discovered a bug in xautomation that prevented me from using visgrep to search for the “Yes” button in tuxpaint screenshots. Fortunately, the fix was straightforward enough after reading the libpng man page. At the same time, I also decided to borrow an idea from the example scripts in the xmacro package. Running the test script on the tester’s own display may be fine for developing the script, but it is nice to be able to run it on a virtual display after the kinks are worked out. For one thing, the test doesn’t get in the way of other things when you’re waiting for it to finish. For another, it is much easier to control the test environment. Xvfb is perfect for this. The resulting script requires tuxpaint, Xvfb, xautomation with the above patch applied, xbase-clients and Imagemagick.