I know I have not updated this blog in quite a long time now, but something caught my attention today: canonical-census.

As slashdot.org reports Canonical begins with tracking their (OEM) installations. Now it's obvious that people are uncomfortable with a program running on their system which phones back to their OS vendor, that's why I have had a quick look at what exactly canonical-census does.

Firstly however, I would like to point out that the report on slashdot.org is very clear about which information is being gathered, being "the number of times this system previously sent to Canonical [...], the Ubuntu distributor channel, the product name as acquired by the system's DMI information, and which Ubuntu release is being used". And it's perfectly correct. After getting the canonical-census Debian source package (using dget -u https://launchpad.net/ubuntu/+archive/partner/+files/canonical-census_0.1.dsc) the source package shows, besides the Debian packaging information, two scripts:

• census (written in Python) and
• send-census (a GNU bash script).

3 interesting small things happened in the weekend. Due to the hard work of mostly Florian Reinhard and George Kiagiadakis, Bluedevil is now available. Bluedevil is a new and improved bluetooth handling thing targetted the KDE Workspaces. The Debconf people have uploaded the Qt Debconf frontend that I blogged about a while ago, so now it should be available. Last, but not least, applications now has more accurate data for if they are online or not, by using the ntrack library. This was especially problematic for people having some interfaces defined in /etc/network/interfaces, and other interfaces managed by NetworkManager.
This feature will be committed to upstream KDE whenever Will gets around to do it. As a added bonus, KDEBindings in Debian has seen a release critical bugfix (python plugins, e.g. plasma widgets, related), and the brokenness of Konsole (libkpty) on the kFreeBSD-arches have been tracked down to a libc issue and a patch has been made. All of this is expected to be part of next stable Debian release, codename Squeeze.

A fresh release of RQuantLib is now on CRAN and in Debian. RQuantLib combines (some of) the quantitative analytics of QuantLib with the R statistical computing environment and language. This follows the 0.3.3 release from last week and has again a number of internal changes. All uses of objects from external namespaces are now explicit as I removed the remaining using namespace QuantLib;. This makes things a little more verbose, but should be much clearer to read, especially for those not yet up to speed on whether a given object comes from any one of the Boost, QuantLib or Rcpp namespaces. We also generalized an older three-dimensional plotting function used for option surfaces -- which had already been used in the demo() code -- and improved the code underlying this: arrays of option prices and analytics given two input vectors are now computed at the C++ level for a nice little gain in efficiency. This also illustrates the possible improvements from working with the new Rcpp API that is now used throughout the package, Full changelog details, examples and more details about this package are at my RQuantLib page.

Back in 2009, I did some analysis of the number of developers per country. Apparently, some people at DebConf remember this and asked if I could update this data. So, here we are with the 2010 version, sorted by the ratio of *active* developers per million population for each country.

Act: number of active developers
Dev: total number of developers
A/M: number of active devels per million pop.
D/M: number of devels per million pop.
2009: rank in 2009
2010: rank in 2010
Code	Name		Population	Act	Dev	A/M	D/M	2009	2010
fi	Finland		5359538		21	32	3,92	5,97	1	1
ch	Switzerland	7782900		22	26	2,83	3,34	2	2
nz	New Zealand	4386207		11	15	2,51	3,42	4	3
no	Norway		4895500		11	14	2,25	2,86	5	4
lu	Luxemburg	502202		1	1	1,99	1,99	8	5
se	Sweden		9354462		18	34	1,92	3,63	3	6
de	Germany		81757600	148	212	1,81	2,59	7	7
at	Austria		8356707		14	23	1,68	2,75	6	8
ie	Ireland		6197100		9	12	1,45	1,94	13	9
au	Australia	22413132	32	56	1,43	2,5	9	10
be	Belgium		10827519	14	16	1,29	1,48	10	11
fr	France		65447374	84	112	1,28	1,71	12	12
nl	Netherlands	16607943	20	38	1,2	2,29	11	13
uk	United-Kingdom	62041708	64	102	1,03	1,64	14	14
ca	Canada		34199000	27	56	0,79	1,64	15	15
es	Spain		46030109	34	52	0,74	1,13	16	16
dk	Denmark		5540241		4	8	0,72	1,44	17	17
hr	Croatia		4489409		3	3	0,67	0,67	20	18
lt	Lithuania	3341966		2	2	0,6	0,6	28	19
cz	Czech Rep	10506813	6	6	0,57	0,57	21	20
us	USA		309913000	165	360	0,53	1,16	19	21
it	Italy		60231214	32	46	0,53	0,76	23	22
bg	Bulgaria	7563710		4	4	0,53	0,53	25	23
il	Israel		7602400		4	6	0,53	0,79	24	24
hu	Hungary		10005000	5	11	0,5	1,1	18	25
lv	Latvia		2217969		1	2	0,45	0,9	26	26
uy	Uruguay		3494382		1	2	0,29	0,57	22	27
jp	Japan		127420000	32	45	0,25	0,35	30	28
pl	Poland		38192000	9	13	0,24	0,34	29	29
cr	Costa Rica	4253897		1	1	0,24	0,24	31	30
sk	Slovakia	5379455		1	1	0,19	0,19	32	31
pt	Portugal	11317192	2	4	0,18	0,35	27	32
ar	Argentina	40134425	6	8	0,15	0,2	34	33
tw	Taiwan		23119772	3	3	0,13	0,13	37	34
br	Brazil		192272890	20	21	0,1	0,11	36	35
by	Belarus		9648533		1	1	0,1	0,1	35	36
mg	Madagascar	20653556	2	2	0,1	0,1	44	37
gr	Greece		11306183	1	3	0,09	0,27	33	38
kr	South Korea	48758000	4	6	0,08	0,12	39	39
ec	Ecuador		14790608	1	1	0,07	0,07		40
cl	Chile		17063000	1	2	0,06	0,12	42	41
ru	Russia		141927297	7	8	0,05	0,06	43	42
ro	Romania		22215421	1	2	0,05	0,09	45	43
co	Colombia	45393050	2	3	0,04	0,07	41	44
ve	Venezuela	26814843	1	1	0,04	0,04	40	45
pe	Peru		29461933	1	1	0,03	0,03	46	46
tr	Turkey		72561312	2	2	0,03	0,03	47	47
za	South Africa	49991300	1	8	0,02	0,16	38	48
mx	Mexico		111211789	2	2	0,02	0,02	49	49
th	Thailand	66404688	1	2	0,02	0,03	50	50
eg	Egypt		78737000	1	2	0,01	0,03	51	51
in	India		1184344000	7	7	0,01	0,01	52	52
cn	China		1338612968	6	10	0	0,01	53	53
ua	Ukraine		45888000	0	0	0	0	48	54
								
								
					873	1410	61,91%			

A few interesting facts:

• We now have 62% of active DDs while we had 73% last year. This year's campaign of MIA work has been somehow "successful", apparently
• No earthquake happened in Finland and there hasn't been a huge increase in DD birth in Switzerland, so the first two stay the same. And Luxembourg didn't have a second DD to beat this.
• Sweden lost many active DDs and is no longer close to Switzerland.
• New Zealand made its way in the top 3. I want them to make a special haka for this
• Ireland won 4 places and is now in the top 10. Thanks for their 3 new active DDs
• And France still hasn't kicked Belgium's ass. Maybe will we win when the country splits out?

If you get messages like this:

ACPI Error (psparse-0537): Method parse/execution failed [\_SB_._OSC] (Node ffff8801e8c62b30), AE_AML_BUFFER_LIMIT

then you've fallen foul of one of the less appealing aspects of ACPI. _OSC methods are defined as methods to allow the operating system and the firmware to handshake over their support of optional features. Different _OSC methods apply to different types of hardware. CPU _OSC methods allow the operating system to inform the firmware that it supports ACPI 3.0 throttling states, while PCIe _OSC methods allow the operating system to indicate that it can manage native PCIe hotplug. The firmware can choose whether or not to give up control of these features, and the OS then has to cope.

The problem arises when we get to the _OSC method on the system bus. This wasn't specified until ACPI 4.0, leaving an attractive mechanism for vendors to add OS/firmware integration. To that end, we now have at least three different _SB_._OSC methods in the wild:

1. The ACPI specified _OSC. This exists purely for the OS to tell the firmware what it supports, without the firmware having the opportunity to disagree. As such it passes 8 bytes of data to the method.
2. The Microsoft WHEA _OSC. This exists to allow the firmware and Windows to handshake over whether or not the firmware supports Microsoft's hardware error reporting.
3. HP's PCC _OSC method, designed to allow handshaking between the OS and the firmware in order to determine whether they support OS interaction with the firmware-level CPU scaling

This wouldn't be enough to be a problem in itself. The ACPI spec requires _OSC methods to have GUIDs in order to protect users from exactly this kind of situation - Windows can attempt to enable WHEA on a machine with a spec-compliant _OSC, and the _OSC method will return an immediate failure because the GUID doesn't match. Except that the WHEA and PCC versions of _SB_._OSC pass 12 bytes of data in the third argument, against the ACPI spec version's 8. And many _OSC implementations attempt to access the region between bytes 9 and 12 before checking the GUID, resulting in the AE_AML_BUFFER_LIMIT error.

This is made even more annoying due to the fact that argument 2 contains the number of parameters being passed in argument 3, making it straightforward to avoid this kind of failure. Firmware authors, tbh.

Just noticed about an hour ago on debian-announce: Squeeze entered into freeze tonight. Hurray! What this means in practice is that, unless a new version of something fixes a serious bug, it will not be allowed to trickle down from Sid into Squeeze on time for the actual release. Still, I cannot help but feel sad that it happened just a few days short of upstream releasing the Geode 2.11.9 driver for X.org, because AMD recently committed a lot of resources towards fixing all outstanding issues on this driver and yet one major Linux distribution is about to release without those fixes, unless the Release Manager agrees to let us squeeze 2.11.9 into, well, Squeeze. Doable? Possibly, if enough people calmly ask the Release Manager for it.

The FrOSCon 5 - 21./22. August 2010 booth plans have finalised, I am rather content:

This is especially good, as XTaran will be shared among (at least) Debian, Grml, FreeWRT; same for me plus of course MirBSD; kimnotyze is FreeWRT but may help with MirBSD; benz and gecko2 probably are MirBSD but gecko2 could help with FreeWRT, tokkee was interested in FreeWRT too anyway.

Some days, you just love software.

Thus, let me re terate it for all of you:
(removed from Planet Debian) Well, now that the Debian Release Managers have sent their freezing bits around *shudder* Squeeze is frozen. Well, at least everything I have my hands in has migrated. I m still not persuaded. I also can t decide which looks worse (KDE 4 or Win 7), tending towards KDE 4 (Read on for more controverse/questionable statements.)

The unofficial rc bug tracker currently knows about the following bugs:

In Total:	433
Affecting Squeeze:	314
Squeeze only:	69
Remaining to be fixed in Squeeze:	245

Of these 245 bugs, the following tags are set:

Pending in Squeeze:	18
Patched in Squeeze:	45
Duplicates in Squeeze:	28
Contrib or non-free in Squeeze:	10
Claimed in Squeeze:	2
Delayed in Squeeze:	7
Can fixed in a security Update:	9
Otherwise fixed in Squeeze:	32

Ignoring all the above (multiple tags possible), 145 bugs need to be fixed by Debian Contributers to get Debian 6.0 Squeeze released. However, with the view of the Release Managers, 220 need to be dealt with for the release to happen. Please see my older post for an explanation of the different numbers.

How We Can Be the Silver Lining of the Cloud (Eben Moglen) Eben s talk was on the same topic as his Internet Society talk in February, which I had downloaded and watched some time ago. He challenges the free software community to develop the software to power the freedom box , a small, efficient and inexpensive personal server. Such a system would put users more in control of their online lives, give them better protection for it under the law, and provide a platform for many new federated services. It sounds like a very interesting project, which I d like to write more about. Statistical Machine Learning Analysis of Debian Mailing Lists (Hanna Wallach) Hanna is bringing together her interests in machine learning and free software by using machine learning techniques to analyze of publicly available data from free software communities. In doing so, she hopes to develop tools for studying the patterns of collaboration, innovation and other behavior in these communities. Her methodology uses statistical topic models, which infer the topic of a document based on the occurrence of topical words, to group Debian mailing list posts by topic. Her example analyzed posts from the debian-project and debian-women mailing lists, inferring a set of topics and categorizing all of the posts according to which topic(s) were represented in them. Using this data, she could plot over time the frequency of discussion of each topic, which revealed interesting patterns. The audience quickly zoned in on practical applications for things like flamewar and troll detection. Debian Derivatives BoF (Matt Zimmerman) I organized this discussion session to share perspectives on Debian derivatives, in particular how we can improve cooperation between derivatives and Debian itself. The room was a bit hard to find, so attendance was relatively small, but this turned out to be a plus. With a smaller group, we were able to get acquainted with each other, and everyone participated. Unsurprisingly, there were many more representatives from Ubuntu than other derivatives, and I was concerned that Ubuntu would dominate the discussion. It did, but I tried to draw out perspectives from other derivatives where possible. On the whole, the tone was positive and constructive. This may be due in part to people self-selecting for the BoF, but I think there is a lot of genuine goodwill between Debian and Ubuntu. Stefano Zacchiroli took notes in Gobby during the session, which I expect he will post somewhere public when he has a chance.

My rule to see if a framework is worth of attention I came up with a little rule:

In order to be worth of any attention, a framework must be stable enough that I can charge money to train people to use it.

This probably applies to other kinds of software stacks, libraries, development environments and, well, to most software applications. In the context of python web frameworks, this means that:

• If it changes API all the time it is not worth of attention, because my customers won't get value for their money, as they'd continuously need retraining and rewriting their software.
• If I see lots of DeprecationWarnings it is not worth of attention, because my customers will see them and blame me for teaching them deprecated stuff.
• If fixes for bugs affecting the stable version are only distributed "in a recent git" or "in the next development version", and they are not backported into a new bugfix-only stable release, then it is not worth of attention, because:
  • my customers' business is to develop their own products based on the framework.
  • My customers' business is not to be maintaning in-house stable updates of the framework. Although if the framework's community is nice enough they might end up giving a hand.
• If it requires virtualenv or can only be obtained through easy_install it is not worth of attention, because:
  • my customers are not interested in maintaning custom deployment environments over time.
  • My customers are not interested in tracking each and every single library's upstream development to keep their production system free of bugs.
  • My customers are used to getting software through a proper distribution which also takes care of security updates.
  • I am paid to teach them how to use a framework, not a custom python-only package management system.
  • In my experience, if distributions have trouble keeping packages up to date, upstream is doing something fundamentally wrong.

In light of this rule, I regret to notice that I see very few python web frameworks worth of any attention.

A new release (now at version 0.3.3) of RQuantLib is now on CRAN and in Debian. RQuantLib combines (some of) the quantitative analytics of QuantLib with the R statistical computing environment and language. Many of the changes in this new version are internal. The code was re-written using the new Rcpp API throughout, and the build system was further simplified using the LinkingTo: mechanism. The arithmetic average-price asian option pricer was added. A few other code updates were made as well. Full changelog details, examples and more details about this package are at my RQuantLib page.

It s widely regarded that to solve reliability problems you can just install a cluster. It s quite obvious that if instead of having one system of a particular type you have multiple systems of that type and a cluster configured such that broken systems aren t used then reliability will increase. Also in the case of routine maintenance a cluster configuration can allow one system to be maintained in a serious way (EG being rebooted for a kernel or BIOS upgrade) without interrupting service (apart from a very brief interruption that may be needed for resource failover). But there are some significant obstacles in the path of getting a good cluster going. Buying Suitable Hardware If you only have a single server that is doing something important and you have some budget for doing things properly then you really must do everything possible to keep it going. You need RAID storage with hot-swap disks, hot-swap redundant PSUs, and redundant ethernet cables bonded together. But if you have redundant servers then the requirement for making one server reliable is slightly reduced. Hardware is getting cheaper all the time, a Dell R300 1RU server configured with redundant hot-plug PSUs, two 250G hot-plug SATA disks in a RAID-1 array, 2G of RAM, and a dual-core Xeon Pro E3113 3.0GHz CPU apparently costs just under $2,800AU (when using Google Chrome I couldn t add some necessary jumper cables to the list so I couldn t determine the exact price). So a cluster of two of them would cost about $5,600 just for the servers. But a Dell R200 1RU server with no redundant PSUs, a single 250G SATA disk, 2G of RAM, and a Core 2 Duo E7400 2.8GHz CPU costs only $1,048.99AU. So if a low end server is required then you could buy two R200 servers that have no redundancy built in which cost less than a single server that has hardware RAID and redundant PSUs. Those two servers have different sets of CPU options and probably other differences in the technical specs, but for many applications they will probably both provide more than adequate performance. Using a server that doesn t even have RAID is a bad idea, a minimal RAID configuration is a software RAID-1 array which only requires an extra disk per server. That takes the price of a Dell R200 to $1,203. So it seems that two low-end 1RU servers from Dell that have minimal redundancy features will be cheaper than a single 1RU server that has the full set of features. If you want to serve static content then that s all you need, and a cluster can save you money on hardware! Of course we can debate whether any cluster node should be missing redundant hot-plug PSUs and disks. But that s not an issue I want to address in this post. Also serving static content is the simplest form of cluster, if you have a cluster for running a database server then you will need a dual-attached RAID array which will make things start to get expensive (or software for replicating the data over the network which is difficult to configure and may be expensive), so while a trivial cluster may not cost any extra money a real-world cluster deployment is likely to add significant expense. My observation is that most people who implement clusters tend to have problems getting budget for decent hardware. When you have redundancy via the cluster you can tolerate slightly less expected uptime from the individual servers. While we can debate about whether a cluster member should have redundant PSUs and other expensive features it does seem that using a cheap desktop system as a cluster node is a bad idea. Unfortunately some managers think that a cluster solves the reliability problem and therefore you can just use recycled desktop systems as cluster nodes, this doesn t give a good result. Even if it is agreed that server class hardware is used for all servers so features such as ECC RAM are used you will still have problems if someone decides to use different hardware specs for each of the cluster nodes. Testing a Cluster Testing a non-clustered server or some servers that use a load-balancing device at the front-end isn t that difficult in concept. Sure you have lots of use cases and exception conditions to test, but they are all mostly straight-through tests. With a cluster you need to test node failover at unexpected times. When a node is regarded as having an inconsistent state (which can mean that one service it runs could not be cleanly shutdown when it was due to be migrated) it will need to be rebooted which is sometimes known as a STONITH. A STONITH event usually involves something like IPMI to cut the power or a command such as reboot -nf , this loses cached data and can cause serious problems for any application which doesn t call fsync() as often as it should. It seems likely that the vast majority of sysadmins run programs which don t call fsync() often enough, but the probability of losing data is low and the probability of losing data in a way that you will notice (IE it doesn t get automatically regenerated) is even lower. The low probability of data loss due to race conditions combined with the fact that a server with a UPS and redundant PSUs doesn t unexpectedly halt that often means that problems don t get found easily. But when clusters have problems and start calling STONITH the probability starts increasing. Getting cluster software to work in a correct manner isn t easy. I filed Debian bug #430958 about dpkg (the Debian package manager) not calling fsync() and thus having the potential to leave systems in an inconsistent or unusable state if a STONITH happened at the wrong time. I was inspired to find this problem after finding the same problem with RPM on a SUSE system. The result of applying a patch to call fsync() on every file was bug report #578635 about the performance of doing so, the eventual solution was to call sync() after each package is installed. Next time I do any cluster work on Debian I will have to test whether the sync() code seems to work as desired. Getting software to work in a cluster requires that not only bugs in system software such as dpkg be fixed, but also bugs in 3rd party applications and in-house code. Please someone write a comment claiming that their favorite OS has no such bugs and the commercial and in-house software they use is also bug-free I could do with a cheap laugh. For the most expensive cluster I have ever installed (worth about 4,000,000 UK pounds back when the pound was worth something) I was not allowed to power-cycle the servers. Apparently the servers were too valuable to be rebooted in that way, so if they did happen to have any defective hardware or buggy software that would do something undesirable after a power problem it would become apparent in production rather than being a basic warranty or patching issue before the system went live. I have heard many people argue that if you install a reasonably common OS on a server from a reputable company and run reasonably common server software then the combination would have been tested before and therefore almost no testing is required. I think that some testing is always required (and I always seem to find some bugs when I do such tests), but I seem to be in a minority on this issue as less testing saves money unless of course something breaks. It seems that the need for testing systems before going live is much greater for clusters, but most managers don t allocate budget and other resources for this. Finally there is the issue of testing issues related to custom code and the user experience. What is the correct thing to do with an interactive application when one of the cluster nodes goes down and how would you implement it at the back-end? Running a Cluster Systems don t just sit there without changing, you have new versions of the OS and applications and requirements for configuration changes. This means that the people who run the cluster will ideally have some specialised cluster skills. If you hire sysadmins without regard to cluster skills then you will probably end up not hiring anyone who has any prior experience with the cluster configuration that you use. Learning to run a cluster is not like learning to run yet another typical Unix daemon, it requires some differences in the way things are done. All changes have to be strictly made to all nodes in the cluster, having a cluster fail-over to a node that wasn t upgraded and can t understand the new data is not fun at all! My observation is that the typical experience of having a team of sysadmins who have no prior cluster experience being hired to run a cluster usually involves learning experiences for everyone. It s probably best to assume that every member of the team will break the cluster and cause down-time on at least one occasion! This can be alleviated by only having one or two people ever work on the cluster and having everyone else delegate cluster work to them. Of course if something goes wrong when the cluster experts aren t available then the result is even more downtime than might otherwise be expected. Hiring sysadmins who have prior experience running a cluster with the software that you use is going to be very difficult. It seems that any organisation that is planning a cluster deployment should plan a training program for sysadmins. Have a set of test machines suitable for running a cluster and have every new hire install the cluster software and get it all working correctly. It s expensive to buy extra systems for such testing, but it s much more expensive to have people who lack necessary skills try and run your most important servers! The trend in recent years has been towards sysadmins not being system programmers. This may be a good thing in other areas but it seems that in the case of clustering it is very useful to have a degree of low level knowledge of the system that you can only gain by having some experience doing system coding in C. It s also a good idea to have a test network which has machines in an almost identical configuration to the production servers. Being able to deploy patches to test machines before applying them in production is a really good thing. Conclusion Running a cluster is something that you should either do properly or not at all. If you do it badly then the result can easily be less uptime than a single well-run system. I am not suggesting that people avoid running clusters. You can take this post as a list of suggestions for what to avoid doing if you want a successful cluster deployment.

In the evening today (Tuesday), the Debconf organizers arranged for a screening of the Creative Commons licensed film "Sita Sings the Blues" by Nina Paley. I went to see it as I had missed it when it was first released among tales of trials and tribulation at the hands of copyright meanies. So first let me say yay Free Culture!, boo Intellectual Property! etc. etc. Now we have that out of the way... "Sita Sings the Blues" has two main narrative threads: The breakup of Ninas relationship with her boyfriend and the Ramayana particularly a story from the uttarakanda about how after Shri Rama returned from Lanka, Sita had to undergo the agnipravesha to prove her chastity and even after she passed that test was eventually banished to the forest. I had an adverse reaction to this film. In fact I stayed to the end to be polite but I left afterwards as soon as I could. I had almost a physical feeling of nausea and I was surprised by this. Since then I have been pondering why this is so. It's not that its blasphemous. Shri Rama is not just a "perfect man", he is God (an avatar of Vishnu Bhagavan as is briefly touched upon in the film) for millions of people so, well, yes it is blasphemous but its more Rowan Atkinson style rather than Norwegian Black Metal style blasphemy. One never gets the impression that the author hates Hinduism or Indian culture the opposite in fact. And in fact it is not uncommon in our culture to speak of Sita and Rama in this way. They are not remote authority figures but as familiar to us as our own friends and family and the Ramayana is not just about events that happened long ago it is relevant to our lives right now. Even the "good woman done wrong by big dumb male jerk" narrative is not unknown. (See the Uttararamacharita of Bhavabhuti for instance.) though I would suggest reducing the Ramayana this way is akin to treating the Hitchhikers Guide to the Galaxy as a book about towels. Even the milder criticism that it is not accurate is offbase because although the Sanskrit poem by Maharshi Valmiki is the canonical rendition of the Ramayana, there are other well-known versions. Not just in Sanskrit, the Hindi retelling by Sant Tulsidas called Ramacharitamanasa is more popular than Valmiki. Also speaking as someone who has preached Ramakatha "professionally" I can tell you that even the priests do not stick to the letter of the text. It is encouraged and expected that they will riff on the basic stories adding or removing details according to the needs and taste of the audience. And the device of the three narrators made me smile as this is exactly the kind of discussions that go on after hearing the Ramakatha. (I must say Paley picked a notably illiterate trio though.) One place where this fell flat was when they discussed the alleged discrepancy between Sita living simply in the forest and dropping a trail of jewellery on the way to Lanka. Although I can imagine someone at some point saying, "Do not question these stories" not at this point. Even the most retarded westernized Indian would know that removing ones ornaments is a sign of widowhood. A married woman would only do that in extremis certainly not just merely because she was a hermit. In a few cases some extra details might have helped the story. It was not explained that Ravana does not just have rakshasas in his command but he is one himself. (And he certainly wasn't a good guy until one day he got up and kidnapped Sita.) Shri Ramas brother Lakshamana accompanied the couple into the forest to Lanka and back but he only pops up (for no apparent reason) at the end. But look at me, I'm turning into one of those people who rant about Star Trek continuity errors or complain that the Romans in a gladiator movie have the wrong helmets for that time period etc. One has to cut a storyteller some slack and I entered the screening determined to be charitable. It's also not because I don't really see much connection between the two stories. Getting dumped by someone who simply loses interest in you hardly seems equivalent to being trapped by a moral code that doesn't allow for individuals feelings. Paley could have easily made "Princess Leia Sings the Blues" and it wouldn't have changed the significance much. But in India people make far more tenuous connections between the epics and events in their own life so one can hardly complain about that. Aesthetics are not the problem either. The first version of the Ramayana I ever read was the Amar Chitra Katha comicbook version which partly influenced the visual style of this film. (In fact you briefly see it in one scene when different editions of the Ramayana flash by.) Hindu popular culture is very gaudy. (See Ramanand Sagars '80s Ramayana Hindi TV serial, which was very reverential, insanely popular and tacky beyond belief.) The animation in this film is very good and quite artistic. "So Jaldhar", you might be asking if you've read this far, "what exactly is your problem with this film?" I have read the Valmiki Ramayana in Sanskrit with the commentaries from beginning to end. I've read other Ramayanas in Sanskrit, Gujarati, and English. I have read the comicbook, I've read anti-Ramayana polemics. When you learn Sanskrit in the traditional way the first lesson, in the declension of masculine gendered nouns ending in vowels is rAma.h rAmau rAmA.h ... I am well aware there are different emphases, different interpretations in various versions. Why can't I accept this as just another take on a story that has shown its fluidity over and over again? It's just...wrong on a subrational level. How can I put this? Imagine you are flipping through the TV channels and you see your grandparents amongst Lady Gaga's backup dancers. Or you came home one night to find everything that was on the floor meticulously glued to the ceiling. Over the course of my life (to hear my mother tell it my first exposure to the Ramayana was before I could speak.) I have developed a mental bond with this story a certain idea of how it should be. I think so has Nina Paley. And this is the problem. "Sita Sings the Blues" is Nina Paleys Ramayana not mine.

After coming back from holiday where I made lots of photos and videos, I needed the possibility to import all those from SD cards to my fileserver running Debian unstable. To import the photos I used Digikam on Linux, that was no problem. But for the videos I needed iMovie and/or FinalCut Express on my Mac. I've looked into Kino and Cinelerra, but those Linux apps are awful. The problem was that iMovie is able to directly import from our Panasonic HD camcorder to the network storage. I was always forced to first import the fotoage to the drive in my MacBook Pro and copy it then to the Linux box onto a Samba share. The solution for that problem is to use netatalk/AFP. The Linux box appears as a Mac Xserve then. However, I quickly found some HowTos for configuring netatalk. One HowTo is from Mike Hughes and the other one can be found on disgruntled-dutch.com. If you follow these two HowTos you're quite close to have a working AFP service to interact with your Mac via Bonjour/Avahi. There are mainly two problems when you follow them. First, Mike Hughes has some illegal chars in his sample /etc/avahi/services/afpd.servicefile:

<!DOCTYPE service-group SYSTEM avahi-service.dtd >
<service-group>
<name replace-wildcards= yes >%h</name>

The quotation marks are the problem. Instead of you'll need normal " quotation marks. Or you can use the file on disgruntled-dutch.com. Next problem is the configuration of the shares. On both sites the examples are using cdb as CNID backend:

~/ "Home Directory" cnidscheme:cdb options:usedots,upriv

But this will give the following error:

Aug 3 23:30:29 muaddib afpd[8151]: Can't open volume "/home/ij" CNID backend "cdb"
Aug 3 23:31:26 muaddib afpd[8151]: Cannot find module named [cdb] in registered module list!

The solution can be found on forum.ubuntuusers.de (German): you'll need to change the cdb to dbd. So, the Home Directory share will look like this then:

~/ "Home Directory" cnidscheme:dbd options:usedots,upriv

Quite simple and easy. Now restart your avahi-daemon and netatalk services and have fun! When you want to use a share on your Linux server for TimeMachine backups, you'll need to add a "tm" to the options of your share.

For a while I ve been maintaining my own WordPress packages. I use quite a few plugins that weren t included in Debian, some of them have unclear licenses so they can t go in Debian while the rest would have to go in Volatile at best because they update regularly and often have little or no information in the changelog to describe the reason for the update so we have to assume there is a potential security issue and update it reasonably quickly. As I m maintaining plugin packages it seems most reasonable to keep maintaining my own packages of WordPress itself which I started doing some time ago then the version in Debian became outdated. Now WordPress isn t a convenient package to maintain, the design of it is that a user will upload it to their web space via FTP or whatever, it s not designed to be managed by a packaging system with the option of rolling back upgrades that don t work, tracking dependencies, etc. One example of this is the fact that it comes with a couple of plugins included in the package, of which Akismet is widely used. The Akismet package is periodically updated asynchronously from the updates to the WordPress package with the apparent expectation that you can just FTP the files. Of course I have to build a new WordPress package whenever Akismet is changed. Now there is a new default theme for WordPress called TwentyTen [1]. This theme ships with WordPress and again has updates asynchronously. Just over a week ago my blog prompting me for an update to the theme even though I hadn t consciously installed it I have to update because I don t know whether one of the other users on the same system has chosen it and because having a message about an update being required is annoying. The Themes update page has no option for visiting the web site for the theme and only offered to send it to my server via FTP or SFTP, of course I m not going to give WordPress access to change it s own PHP files (and thus allow a trojan to be installed). So I had to do some Google searching to find the download page for TewntyTen which happens to not be in the first few results from a Google search (even though those pages look like they should have a link to it and thus waste the time of anyone who just wants to download it). After downloading the theme I had to build a new WordPress package containing it I could have split it out into a separate package and have the WordPress package depend on it, but I ve got enough little WordPress packages already. It doesn t seem worth-while to put too much effort into my private repository of WordPress packages that possibly aren t used by anyone other than me. Plugins aren t as bad, the list of plugins gives you a link to the main web page for each plugin which allows you to download it. I wonder what portion of the WordPress user-base install via FTP to a server that they don t understand and what portion of them use servers that are maintained properly with a packaging system, my guess is that with the possible exception of WordPress.com most bloggers are running on packaged code. It seems to me that optimising for Debian and CentOS is the smart thing to do for anyone who is developing a web service nowadays. That includes files managed by the packaging system, an option to downgrade (as well as upgrade) the database format (which changes with almost every release), and an option for upgrading the database from the command-line (so it can be done once for dozens or hundreds of users). deb http://www.coker.com.au lenny wordpress I have a repository of WordPress packages that anyone can use with the above APT sources.list line. There is no reason why they shouldn t work with Testing or Unstable (the packaging process mostly involves copying PHP files to the correct locations) but I only test them on Lenny.

• [1] http://wordpress.org/extend/themes/twentyten

The problem: Splitting patches As a Debian maintainer, I often work with patches (files listing changes to text files), for example when tracking the modification I make to some software before I upload the package to Debian. To manage these patches, quilt is a nice tool: It helps you maintain a stack of patches on top of the original code and encourages you to keep your variously modifications separate. One use case is not supported by quilt at all: Splitting patches. One often has a large patch containing several independent changes. This might happen after you fix a few problems in the upstream code and then run dpkg-buildpackage, which will create one patch of your changes and put it in debian/patches. Before, I had to manually edit the patch and write the hunks, which are the building blocks of patches, into separate file. Where it already works There is no such problem when using a version control system, such as Darcs. Especially Darcs is rightly famous for its user-friendly interface and powerful hunk-selection features. You can even split a single hunk (which could be a change to one line) into two separate steps! Have a look at the HunkEditor page on the Darcs wiki to see how that works.
Let s steal a feature Well, it is not stealing if it is Free Software... Darcs has these nice capabilities and provides them in the context of version control systems, while we need them in the context of patch files. But Darcs is providing an API to its code, so shoudn t it be possible to create a program that uses the Darcs code to split patch files? As a matter of fact, it is possible: You can see that program in action on this 3min Ogg Theora-Video or directly here if your browser supports HTML5: Nice, can I use it? The code is a working proof of concept. What you see works. You do not see how it handles patches that create or delete files, patches that do not apply cleanly or are already applied or any kind of error handling. That does not work yet. If you still want to try it, you can grab the code from the Darcs repository at http://darcs.nomeata.de/ipatch, but you need to build the latest development state of the Darcs library first. I think ipatch could become a very useful and powerful tool with applications in areas where nobody would think of using Darcs. I definitely want some integration into quilt, replacing the splitted patch in the series by the replacing patches automatically. Maybe even a git plugin could be created? But I don t think I can push this project far enough on my own. So this is an invitation to join me and make ipatch a great tool. This invitation goes especially to the Darcs developers: Please have a look how the code uses the Darcs API and help to improve the collaboration here. I think we can use the darcs-users mailing list until there is need for a dedicated mailing list.

Thanks to Val ssio you can enjoy all this modern web stuff for DC10 http://debianart.org/live/

Thanks to Valessio Brito you can also participate on many sessions by simply opening http://debianart.org/live/ in your browser. You ll see a stream, the schedule, identi.ca and twitter posts and can join the irc channels used to comment / discussion during the sessions. You ll either need a HTML5 compliant Web Browser or java.

For those of us, who can't attend this years Debian Conference might be interesting, that thanks to valesio you can also participate via http://debianart.org/live/. You need either a HTML5 capable browser or Java. Also many thanks to the video team for the very nice streams!

Linux 2.6.35 has been a fairly interesting release from an ASoC point of view, with several notable framework enhancements:

• Support for keeping audio paths through the CODEC up during system suspend, primarily intended for use with devices where the Linux system is one of several independent systems running on the device and the other systems (like the cellular modem in a phone) can maintain useful audio paths even when the Linux system is inactive.
• Enhancements to the jack detection infrastructure, including the addition of notifiers on jack status changes (allowing better integration of physical jack detection with electronic methods) and snd_soc_dapm_force_enable_pin() (which allows DAPM managed supplies such as microphone biases to be forced on). For example, jack status change notifications can be used to enable microphone detection via bias current sense only when a microphone is physically present.
• Support for knot and continuous PCM rates in the core.
• SMDK6410 5.1 audio support, TI SDP4030 audio support, and basic support for playback on the 1133-EV1 PMIC module for Freescale i.MX31ADS systems (currently limited by the support for the SSI interface on the i.MX31).
• Support for DaVinci integrated voice CODECs, Philips UDA1345 CODEC, SuperH FSI2 interfaces, TI OMAP4, TWL6040 CODECs, WM9090 audio subsystem.