Due to the comments on my blog post about Divisive Behavior [1] I ve been considering the issue of terms of abuse of minority groups a topic of which racial abuse is only one aspect. It seems that there are many discussions about which terms are offensive and when they are offensive, most of which are very misguided. Solving this problem would be an almost impossible task, but I have some ideas which may help to improve the situation. I would appreciate any pointers to better ideas in comments or in blog posts that are inspired by this one. One common mistake seems to be the idea that there are global objective criteria by which a statement can be proven to not be offensive. In any language that is constantly evolving (IE any language that s not dead) this seems impossible. It is particularly difficult with a language like English which is widely used in different countries and cultures. If a member of a minority group claims that you have just offended them then it seems most reasonable to have the default assumption be that you have said or done something which is actually offensive. In such a situation an immediate apology for the misunderstanding should be well accepted, but a debate about who s cultural standards should be used for determining what is offensive probably won t get a positive reception. It seems extremely difficult (if not impossible) for a member of the majority group to properly understand what members of a minority group experience. So therefore attempts to understand why certain terms are offensive are likely to be doomed to failure. Sometimes if a certain word is used and then a group of people immediately get really angry you just have to accept the fact that it s not a good word to use. One common example of this is words that are associated with violence if someone associates a particular term with a threat of serious injury or death then you won t be able to convince them that it s not a big deal, but there are more subtle things of a similar nature. It s worth trying to understand people and these things can be productively discussed between friends. But a discussion of such things is not viable during the course of a debate. If involved in a debate with someone you really dislike it doesn t seem like a good strategy to start a meta-discussion about whether they should regard one of your statements as being unreasonably offensive (regarding minority group status) as opposed to the level of offense that is acceptable in debate (something like that s the most ridiculous argument I ve ever heard may offend the recipient but is not inherently unreasonable). Words tend to have multiple meanings. Claiming that your intent was significantly different from the way your message was interpreted probably isn t going to work well unless accompanied by an apology. Even I m sorry you were offended (which is not the best apology) will probably do. Finally I m sure that anyone who does Google searches dating back to 2005 (as an arbitrary year that references my previous post) can find examples of me doing things that go against some of these suggestions. I ve learned things since then, it s an ongoing process.

• [1] http://etbe.coker.com.au/2010/02/23/divisive-behavior/

A good friend of mine convinced me to give "The Wire" a try. I've just finished season four of five. This is the best TV programme I have ever seen. I'd have a renewed faith in the TV industry's quality standards were it not for the fact it stands alone, quality-wise. Guardian columnist Charlie brooker says it best:

The Wire's so good, I've lost count of the number of people who've approached or emailed me just to thank ME for convincing THEM to watch it. The Wire's so good, I'm jealous of anyone who hasn't seen it yet, because they get to discover it anew. The Wire's so good, it's come to an end.

That last point is an important one. I'm only ten episodes away from it ending. As much as I'm going to hate reaching the end, I'm glad it will. I'm reasonably confident it will end with the same quality as it began: something which I can't say about Battlestar Galactica, for example. I wish I'd discovered "The Wire" sooner: I think you can learn a lot about relationship politics which can be applied to aspects of your own life. A word of advice to the folks who produce the boxed-set: a second set of Season One episodes would be very useful, as things stand I can only loan it out to one person at a time.

In the past, several of my Puppet modules have been tightly coupled. A perfect example is Apache and Munin. When I install Apache, I want munin graphs set up. As a result my apache class has the following snippet in it:

munin::plugin   "apache_accesses":  
munin::plugin   "apache_processes":  
munin::plugin   "apache_volume":  

This should make sure that these three plugins are installed and that munin-node is restarted to pick them up. The define was implemented like this:

define munin::plugin (
      $enable = true,
      $plugin_name = false,
      )  
   include munin::node
   file   "/etc/munin/plugins/$name":
      ensure => $enable ?  
         true => $plugin_name ?  
            false => "/usr/share/munin/plugins/$name",
            default => "/usr/share/munin/plugins/$plugin_name"
          ,
         default => absent
       ,
      links => manage,
      require => Package["munin-node"],
      notify => Service["munin-node"],
    
 

(Note: this is a slight simplification of the define). As you can see, the define includes munin::node, as it needs the definition of the munin-node service and package. As a result of this, installing Apache drags in munin-node on your server too. It would be much nicer if the apache class only installed the munin plugins if you also install munin on the server. It turns out that is is possible, using virtual resources. Virtual resources allow you to define resources in one place, but not make them happen unless you realise them. Using this, we can make the file resource in the munin::plugin virtual and realise it in our munin::node class. Our new munin::plugin looks like:

define munin::plugin (
      $enable = true,
      $plugin_name = false,
      )  
   # removed "include munin::node"
   # Added @ in front of the resource to declare it as virtual
   @file   "/etc/munin/plugins/$name":
      ensure => $enable ?  
         true => $plugin_name ?  
            false => "/usr/share/munin/plugins/$name",
            default => "/usr/share/munin/plugins/$plugin_name"
          ,
         default => absent
       ,
      links => manage,
      require => Package["munin-node"],
      notify => Service["munin-node"],
      tag => munin-plugin,
    
 

We add the following line to our munin::node class:

File<  tag == munin-plugin  >

The odd syntax in the munin::node class realises all the virtual resources that match the filter, in this case, any that is tagged munin-plugin. We've had to define this tag ourself, as the auto-generated tags don't seem to work. You'll also notice that we've removed the munin::node include from the munin::plugin define, which means that we no longer install munin-node just by using the plugin define. I've used a similar technique for logcheck, so additional rules are not installed unless I've installed logcheck. I'm sure there are several other places where I can use it to reduce such tight coupling between classes.

Update: This wlog entry uses aggressive tone because I somehow needed to vent frustration from using some of the tools. I should probably provide some constructive critics, too... but this is a rant. Be warned. Keysigning is useless. I boot up a suitable live GNU/Linux system, install signing-party, take the trouble that is to set up caff, transfer my secret key from the secure box, sign. I think caff providing the keys in a different order than they're given on the command line sucks and just run caff once per key. I did even start Postwreck. But no, people just don't accept any mail from "EHLO grml" systems, and I still cannot control my reverse DNS despite having a static IPv4 address (and IPv6, which looks to be unused). People also pretend I'm on dial-up. Great! I will no longer participate in any (mass) PGP keysigning but will continue to do so on a per-person basis. Probably sign but one uid, either apply common sense and upload it to t h e keyserver, or mail the entire signed key to one address. By the way, how crazy is it that I need to use the deprecated $CONFIG 'mailer-send' to pass an envelope-from to the mailer? It also suffers from the same delusion as e.g. nmudiff, namely that my Debian box is a fully set up workstation able to send out eMail and configured correctly. At least, it, unlike a number of others, does not assume I use mud (Mutt). grml Oh, and caff does a protocol violation (by always sending out GnuPG/MIME and not offering the standardised Inline OpenPGP), I think people just don't care about such. (There is a notation people can use to signal they want PGP/MIME, Inline PGP which is called "partitioned" or both (and which order of priority) but, alas, despite Inline PGP being the only one useful for the MUAs without integratin, and being more widely spread than that PGP/MIME crap, the followers of the latter do some (FSF-style?) kind of vendor lockin by not speaking anything else. Anyway. I'm all for X.509 except there seems to be no sane CA (Startcom is... trouble, even with Opera; CAcert.org is dying). I'll just buy a certificate (not from Verisign though) for www, and roll my own again (I can do it, I have experience with that actually). On an unrelated side note, still waiting for an OpenSSL patch for that recent TLS extension... ObRant: password policies, be they required characters or any kind of length restrictions, suck. People I will eventually end up with less secure passwords on such systems, because even if some of mine may appear to be derived from some kind of dictionary (what language that is I'd be interested in, though...) they aren't, and I have my schemes. You got to have them with a gazillion of passwords used. And I probably will forget them more often (and sending them via eMail is also not a solution). Unrelated notice: mksh R39c with bug fixes coming RSN. (Updated 24.02. because I was, rightfully, told the language, and the title, were too strong. I also would like to excuse for going so low as to write an ad-hominem attack, which I've since redacted.

This is it! xulrunner now builds and successfully runs the checks and xpcshell-tests on all release architectures, including arm, mips, powerpc and sparc, that were all failing 2 weeks ago. 2 patch pulled from upstream, 5 patches written and sent upstream, and several more as not quite successful attempts. What puzzles me is that e.g. the arm issue in the test suite has been known upstream for a year, yet Firefox was released on maemo (arm) without it being fixed. I mean, it only took me a few hours (if you don t count the time lost waiting for the builds to end), starting with no specific knowledge of arm, and even less of jit compilers. Anyways, this all means work on 1.9.2 can go on.

Past Sins Sam Varghese wrote an article about Matthew Garrett s LCA talk The Linux community: what is it and how to be a part of it [1]. In page 2 Sam quotes Martin Krafft as asking about how Matthew s behavior had changed between 2004 and the present, Sam cites some references for Matthew s actions in 2005 to demonstrate. I think that this raises the issue of how far back it is reasonable to go in search of evidence of past behavior, something that I think is far more important than the specific details of what Matthew said on mailing lists many years ago and whether he now regrets such email. If someone did something that you consider to be wrong yesterday and did the same thing five years ago you might consider it to be evidence of a pattern of behavior. If someone s statements today don t match their actions yesterday then you should consider it to be evidence of hypocrisy. But if someone did something five years ago which doesn t match their current statements then in many situations it seems more reasonable to consider it as evidence that they have changed their mind. Then of course there is the significance of what was done. Flaming some people excessively on some mailing lists is something that can be easily forgiven and forgotten if Google doesn t keep bringing it up. But as a counter-example I don t think that Hans Reiser will be welcome in any part of the Linux community when he gets out of jail. For the development of the Linux community (and society in general) I think it s best to not tie people to their past minor mistakes. While it is nice when someone apologises for their past actions, the practical benefits of someone just quietly improving their behavior are almost identical. A particular corner case in this regard is the actions of young people, anyone who was born after about 1980 will have had great access to electronic media for their entire life and will have left a trail. Most people do a variety of silly things when they were young, the older members of the Linux community were fortunate enough not to have electronic records remaining where Google could find them. Back to Matthew, I think that if he is to be criticised about such things then evidence that is much more recent than 2005 needs to be used. Cultural Differences Sam quotes Matthew as claiming that the Linux community was largely a Western, English-speaking one, those who participated in it necessarily had to adapt to the norms of this group . I don t believe that there is a single Linux community. There are a number of different communities that are formed around free software, which have significant amounts of overlap. I don t believe that there s any reason why a Chinese or Indian Linux mailing list should conform to the same standards as those of an American list. But there will be a trend towards meme propagation through people who are associated with the Linux communities in multiple countries every time you meet Linux people in another country you are helping to reduce the cultural differences in the Linux community. Someone from China or India who joins a LUG in Australia will have to adapt to some of the norms of Australian behavior in the same way as an Australian who migrates to China or India would have to adapt to some local norms. On page 4 of the discussion Matthew disagrees with Sam s interpretation [2], maybe Matthew s opinions on this matter are closer to mine than the way Sam describes them. Is Division Inherently Bad? I believe that the word divisive is overused. The only way to avoid division is to have everyone agree with the majority, but sometimes the minority will be right. Note that I am using the word minority to refer to any group of people who happen to disagree with the majority, among other things that includes people who vote for a political party that isn t one of the two biggest ones. An entirely separate issue is that of the treatment of minority groups , one of the most divisive events in history was the US civil war it s good that slavery is outlawed but unfortunate that a war was required to gain that result. On page 4 of the discussion Matthew says to Sam Your writing is influenced by members of the Linux community, and in turn it influences the Linux community. The tone of it is entirely relevant to the behavioural standards of the community [2]. If a community can be easily divided then the real problem probably isn t the person who triggered a particular division. Also there is the issue that even if you could get a general agreement that certain issues shouldn t be discussed in certain ways then with the wide range of cultural attitudes and ages of participants you have to expect someone to raise the issue you don t want raised. Of course it s impossible to objectively determine whether a division is productive or not, so it doesn t seem at all viable to have any expectations regarding outsiders not being divisive. Sometimes you just have to deal with the fact that the Internet contains people who disagree with you. It seems to me that the most divisive issues we face involve people who mostly agree on contentious issues. If someone entirely disagrees with you then it s easy to ignore them (if you even have a conversation with them), but if they are someone that you communicate with and they are almost right in your opinion then there s the potential for a big argument. Probably the best way to minimise division in the community is to have the first people who get involved in a dispute take a Rogerian approach [3]. Failing that a good approach is to respond by writing an essay. When an issue is made popular by services such as Twitter that give little explanation then everyone rushes to the barricades. It seems to me that the unreliability of some blogging platforms is part of the cause of the problem in this regard. I ve just given up on writing comments on Blogger, I m not going to write a good comment only to have it eaten by blogger. There are lots of blogs that have problems which discourage the population from writing anything other than a one-sentence response. The Good that can come from Disputes On page 5 of the discussion there is a comment from Anirudh the Indian student who was criticised by Sam (which ended up inspiring part of Matthew s talk and leading to more disputes) [4]. Here is the start: I am the person who wrote the ill thought-out post that drew criticism eight months ago. There has been some discussion about that, so I wish to say something.

I am very grateful to Sam Varghese. I say this with utmost sincerity. Read the rest, it s educational. I m sure that there are others who have had similar learning experiences but who don t want to write about them. I m sure that there have been many disputes which would appear to the casual observer to have resulted in no good at all, but which would actually have resulted in people learning things and amending their behavior. The issue of Age Car rental companies generally don t do business with men who are less than 25 years old. Life insurance policies don t offer reasonable rates to males between the ages of about 16 and 25. This is because the insurance companies have good statistical data on the results of the typical actions of people at various ages and know that young men tend to be at a high risk of earning a Darwin Award. The same combination of hormones and life experience that makes a young man a danger on the road will also tend to make him get involved in flame-wars on the net. If we could figure out how to influence teenagers into being less anti-social then it would be a great achievement. The current young people will become older and more sensible soon enough but will be replaced by a larger number of young people who will do the same things. As things stand I don t expect the next cohort of young people to learn from Anirudh.

• [1] http://www.itwire.com/opinion-and-analysis/open-sauce/36850
• [2] http://discuss.itwire.com/viewtopic.php?f=8&t=18319&start=28
• [3] http://en.wikipedia.org/wiki/Rogerian_argument
• [4] http://discuss.itwire.com/viewtopic.php?f=8&t=18319&start=28

Every winter I just get incredibly damp and depressed Well this year, I ve found an ultimate remedy + stress reliever since I m all jumpy around DebConf11 decision coming around this Saturday So to whoever has the same problem during winter take your board/skies (whatever your fix is) and hit the mountains! This weekend I went to Bosnian Olympic mountain Jahorina; couple of days later stress free, depression free and ready for new challenges, in the meantime I ll let pictures talk for themselves
My friend and I
Black and white in colors
Ready to go down the slope
Camera can t display this beauty
Notice how close the clouds are
This image is my current wallpaper
On our way to sky
Road to our cottage
Our little cozy cottage
Board ninja

The t-prot package might need your help: There is a discussion going on with the upstream developer how to proceed with respect to a hopefully helpful change in its behavior. There are several options how to address this, one of them would involve using the Getopt::Long module instead of Getopt::Mixed. Given that the benchmarks of upstream rather speak for sticking with Getopt::Mixed we would like to ask you for help: Please test this version of t-prot (for your safety: detached gpg signature for the version) and compare it to the packaged version 2.15 that I just upload into unstable (it is installable without anything else also into (old)stable or testing). Your feedback on this is truly appreciated, please send it until the start of next week (Monday evening/Tuesday morning) to "t-prot (AT) tolot.escape.de". Much thanks in advance!

Application Indicators: A Case of Canonical Upstream Involvement and its Problems I always thought Canonical could do a bit more to contribute to the GNOME project, so I was happy to see the work on application indicators proposed to GNOME. Application indicators are based on the (originally KDE-driven, I believe) proposed cross-desktop status notifier spec. The idea (as I understand it) is to have a consistent way of interacting with status notifiers and stop the confusing mix of panel applets and systray indicators. This is a very laudable goal as mentioned by Colin Walters:

"First, +5000 that this change is being driven by designers, and +1000 that new useful code is being written. There are definite problems being solved here."

The discussion that followed was very useful, including the comments by Canonical's usability expert Matthew Paul Thomas. Most of the discussion was about the question how this proposal and spec could be best integrated into GTK, the place where most people seemed to agree this belongs (rather than changing all apps to provide this, this should be a service provided by the platform) However, on the same day, Canonical employee Ted Gould proposed libappindicator as an external dependency. The following thread showed a couple of problems, both technical and otherwise:

• It is proposed as an external dependency, not as a part of GTK
• It is unclear how it will integrate with the GNOME3 Shell
• It requires Canonical's notorious copyright assignment
• It is licensed under the LGPLv2.1 or 3 specifically, not any later one

What I personally disliked is the way the Cody Russel and Ted Gould are papering over the above issues in the thread that followed. For examples, about point one, Ted Gould writes in the proposal:

Q: Shouldn't this be in GTK+?
A: Apparently not.

while he himself said on the same day, on the same mailing list: "Yes, I think GTK/glib is a good place" and nobody was against it (and in fact most people seemed to favor including this in GTK). To the question about why libappindicator is not licensed as usual under the LGPL, version 2.1 or later, Canonical employee Cody Russell even replied:

"Because seriously, everything should be this way. None of us should be saying "LGPL 2.1 or later". Ask a lawyer, even one from the FSF, how much sense it makes to license your software that way."

Not everybody has to love the FSF, but proposing code under mandated copyright assignments which a lot of people have opposed and at the same time insinuating that the FSF was not to be trusted on their next revision of the LGPL license seems rather bold to me. Finally, on the topic of copyright assignments, Ted said:

"Like Clutter for example ;) Seriously though, GNOME already is dependent on projects that require contributor agreements."

It is true that there are (or at least were) GNOME applications which require copyright assignments for contributions (evolution used to be an example, but the requirement was lifted), however, none of the platform modules require this to my knowledge (clutter is an external dependency as well). It seems most people in the GNOME community have the opinion that application indicators should be in GTK at least eventually, so having libappindicator as an external dependency with copyright assignments might work for now but will not be future proof. In summary, Most of the issues could be dealt with by reimplementing it for GTK when the time comes for this spec to be included, but this would mean (i) duplication of effort, (ii) possibly porting all applications twice and (iii) probably no upstream contribution by Canonical. Furthermore, I am amazed at how the Canonical people approach the community for something this delicate (their first major code drop, as far as I am aware). To be fair, neither Ted nor Cody posted the above using their company email addresses, but nevertheless the work is sponsored by Canonical, so their posts to desktop-devel-list could be seen as writing with their Canonical hat on. Canonical does not have an outstanding track record on contributing code to GNOME, and at least to me it seems this case is not doing much to improve things, either.

This is getting old news, and others have blogged about them before I did, but here's my summary of the recent activity in and around FusionForge. The early February meeting was a success, and gathered about twenty people on the first day and a dozen or so on the second day (not planned initially). My impression is that there was a healthy mix of FusionForge hackers, FusionForge users, and people from other forge communities (Codendi, NovaForge, and even one representative from nFORGE, from South Korea). I'm not going to repeat all that was said then, especially since the proceedings are online. Beyond the technical points, I'll just advertise PlanetForge again, since everyone present agreed we had lots to share and that this site would be a good and relatively neutral place. If you're into forges, I recommend joining us in that community. On the purely FusionForge front, news are good too. Most of the major pieces we want to see in the next release (which is probably going to be called 5.0) are in place. The last blocker we had was the merge of the rework of the default theme for better accessibility and easier maintenance and customisability (most of the theming now happens in CSS). This merge has been completed this week, and although there are still a few rough edges, it's mostly done. We'll try to fix most of these rough edges soonish, then start a stabilisation branch towards 5.0, so more experimental work can start again on trunk. For the impatient and the curious, there's a list of new features on the fusionforge.org homepage, and the site is now running code from trunk. Of course, we're eager to get testers for that, which is why I prepared snapshot packages. They are currently stuck in NEW on their way to the official Debian experimental repository due to the renaming of the source package and the introduction of plenty of new binary packages, but they can already be obtained from my unofficial repository at people.debian.org. The packages are built for Debian unstable, but they seem to run just fine on Lenny if you grab mediawiki from backports.org (only required for the Mediawiki plugin, of course), and libnusoap-php and php-htmlpurifier from Debian testing (they don't drag any extra dependencies). I'll end this note by reminding people of the announcement I did three months ago: as of this week, Debian Etch is no longer officially supported security-wise, and so neither is GForge 4.5. As far as I know, I was the last person doing that, and my incentives have gone away on the day Etch ceased to be supported, since it was also the day the Adullact forge finally migrated from Etch with GForge 4.5 to Lenny with FusionForge 4.8. If you're still using 4.5, well I think you should be aware of that. That more or less wraps it up for now. The next announcement is likely to be about a release candidate

For quite a while we are receiving TV via Internet. The original reason is that I got at most 2 MBit/s via ADSL due to line noise, but VDSL supports 25 MBit/s on the same line. Of course, you couldn t order the DSL line without also getting a phone flat rate and IPTV. Most of the channels are encrypted and can only be received with the original Media Receiver , which is a proprietary (and Microsoft) solution. But at least, I can watch the public service broadcasts using these playlists for VLC or mplayer.

ISPs fight a raging war over net neutrality because their infrastructure cannot keep up with the increasing demand (or rather supply) of content. Therefore, ISPs want to charge the users premiums if they wish to use certain services on the Net. For instance, since videos are usually large in size, one would have to purchase e.g. the platinum package to be able to access video hosting sites. It would be a serious loss of freedom if they won, and the Internet would never be the same. Let s turn that idea around: since sites that use advertising make money off every visitor, they are really the ones that should pay the ISPs so that they can improve their infrastructure. The same applies to sites that make money off visitors in other ways. At the moment, users pay to access the network (which is like paying a taxi to get to the market), so that they can visit sites where advertisers make money showing ads to the visitor, which might actually let them to pay a manufacturer for a product the end user pays twice, and the advertisers take in money, leeching off the ISPs investing into their infrastructure. I think that the advertiser and not the consumer should pay the ISP to keep the infrastructure afloat improve it even. The manufacturer should then pay the advertisers for displaying the ad, and the user consumes if s/he chooses to and everyone only pays once, for services they want. This will help improve competition among providers, which should always be the goal. If my ISP would start to record the volume of HTTP traffic I produce for each target site, charge the targets appropriately (they could start with a couple at first), and I d get free connectivity in turn, I d be quite happy. The ISP wouldn t have to look at the contents at all for that. I don t yet know what to do if the target sites choose not to pay up. ISPs could block them, or throttle or deprioritise traffic, but either of those might simply lead to an exodus of users, just like premiums would. As usual, this just needs to be done by many ISPs in concert. Are you listening?

In ancient Rome, the Imperial cult was the worship of the Roman emperor as a god. It came to be at roughly the same time as Christianity. In the cult of the emperor, Caesar was revered as a deity. According to Harvey Cox, This was what we might today call a civil religion it had its holidays, processions, and holy sites throughout the empire. Adherence to it was required of all of the emperor s subjects, wherever they lived and whatever other deities they also worshiped. It was the religious and ideological mucilage that held the far-flung empire together. Perhaps you see where this is going. There was a certain group that found the imperial cult, well, repugnant. They felt their own goals bringing their god s peace and justice to the world were incompatible with this sort of devotion to a human institution, and the very institution that had killed their leader at that. Their reaction went like this:

Regarding worship of the emperor, Christians responded with an unequivocal no. They claimed that Jesus Christ was God s kyrios ( anointed one in Greek), but since kyrios was one of the titles attributed to Caesar, they refused to participate in the imperial cult. They were willing to pray for the emperor and for his health, but they stubbornly refused to pray to him or offer ritual tribute. They recognized that one could not be a follower of Jesus while also honoring a rival to the loyalty their faith in him and his Kingdom required; therefore, not even one pinch of incense on the imperial altar. This defiance of the political religion of the empire, which led their critics to brand them subversive, landed many of them in arenas with salivating lions. Harvey Cox in The Future of Faith

Now, you may be wondering, why am I asking if anyone still worships the emperor of a long-extinct empire? I maintain that this practice is still alive and well, just under a different name. I have been interested in some of the debates about American institutions that choose to perform neither the national anthem nor the pledge of allegiance. Many of these institutions are Mennonite, and their reason for not participating in these two particular acts mirrors that of the early Christians refusing to worship Caesar: namely, their goal is to bring about God s peaceful and just kingdom on earth, and no country, no human institution at all, can ever command greater loyalty than that cause. Moreover, the American national anthem is a particularly violent one, celebrating the taking of life right there at the beginning. Not completely compatible with the ethics of a church trying to bring about a more peaceful world, right? It is from that basis that many Mennonites, and our institutions, do not perform the national anthem or say the pledge of allegiance. For myself, when the national anthem is being performed, I will stand out of respect for those around me for whom the moment is important, but I do not sing. I am deeply appreciative that the United States, like many other countries, makes it legal to do this. I am heartened by the fact that I do not risk a confrontation with the lions over my religious stance today. Goshen College, a Mennonite institution, recently decided to go back on a century of history (which goes back farther than the anthem itself, which was only adopted in 1931) and will now be performing the anthem, followed by a prayer, before select sporting events. And by so doing, they fail both to act in accordance with the way of Christ, and to be a patriot. They fail to act for peace and justice by playing an anthem that supports and glorifies war and violence. And they fail to be patriotic. Patriotism and nationalism are different things. It s easy to be nationalistic to get up there and sing a song that everyone wants you to sing. It is far more difficult to be patriotic. Being patriotic in the United States means using the freedoms we have to improve our country. Goshen ought to use its freedom to not observe the national anthem as a way to try to draw a line in the sand against violence, to suggest that our anthem fails to adequately recognize the character of the American people and who we want to be, and to suggest a better alternative. After all, those people who are venerated today as patriots anyone from Martin Luther to Thomas Jefferson to Martin Luther King stood up to their fallible human governments to seek positive change. Instead of a route both religious and patriotic, Goshen College has chosen one that is neither. I am deeply disappointed that 300 phone calls have apparently cowed their leadership. What have we come to when our ancestors braved the lions, and we give up our principles over the fear of bad publicity? Ah, Goshen, perhaps you are thinking that you could spare a few pinches of incense for Caesar after all?

Most times when I blog about WebKitGTK+ it s to talk about new features, and their usage in Epiphany. This time I d like to tell those who care more about our test infrastructure. Like I said in my previous post, testing is something we take very seriously in WebKit land. It would be hard to get such a complex project, with such diversity of platforms moving forward without automated testing. Apple hosts a buildbot master that controls a whole lot of build slaves, for many platforms. Today we added the fourth WebKitGTK+ build slave to the family: 64bits release. This makes up for 4 build slaves in total, 2 release bots sponsored by Collabora, and 2 debug bots sponsored by Igalia. These bots build WebKitGTK+, and then run what we call the layout tests . I use quotes there because the name is a bit misleading. Despite being HTML/JavaScript tests, they cover a whole lot of functionality, and tests for regressions in many areas, including security, crashes, animations, media playing, DOM behaviour, and javascript API behaviour. WebKitGTK+ bots currently run 6397 tests, which represent about half the available tests. Our bots are also, as of today, the first ones to run platform-specific API tests. Almost a year ago we started writing small tests based on glib s GTestSuite, and they have been very valuable in helping us make sure our API expectations aren t breaking (at least unknowingly), and to be able to test things that would be very hard to have Layout Tests for. So, yay! Thanks to everyone involved. Back to layout tests, now: the other half is currently skipped because of one of three main reasons:

• We suck, and the test fails for real, either because we are missing implementation of something it uses (say, JavaScript isolated worlds, which has been recently added), or because our implementation is wrong
• The test is a render dump, and we did not generate results for it yet
• We lack functionality to run the test in our DumpRenderTree implementation

The first one is the worst of all. It means we have broken functionality, or lack web compatibility. The second one is less bad, we can usually trust layout, and rendering to be good because most of the rendering code is shared (thought there are exceptions, of course). Render dumps are a special way of representing the render tree as text, and we need to generate our own results because of differences in things such as font sizes. The third one is also pretty bad - it means we cannot test some features; DumpRenderTree is an application that uses the port s API to run the tests, and provide additional JavaScript API through JavaScriptCore. If you feel like helping WebKitGTK+, choosing a bunch of these (specially non-render-dump) skipped tests to make them pass could likely be a good first step =).

I've been overhauling the way that I am host a number of virtual websites upon my main box. Partly to increase security, and partly for a cleaner separation or roles, ownership, and control. (In general everything on my box is "mine", but some things are "ours"...) After a fair amount of experimentation I decided that I wasn't willing or able to rewrite all my Apache mod_rewrite rules just yet. So my interim plan was to update each existing virtual host:

• Add a dedicated user & group to run it under.
• Launch it via a minimal server listening upon the loopback adapter.
• Have Apache 2.x proxy through to it.
  • Expanding any mod_rewrite rules prior to the proxying.

To make it clear what the users were for I decided that every hosting-user would have an "s-" prefix. So the virtual host "static.steve.org.uk" was initially going to be served by the s-static user. The thttpd configuration file would look like this, and would be located in /etc/thttpd/sites/static.steve.org.uk:

host=127.0.0.1
port=1008
dir=/home/www/static.steve.org.uk/htdocs/
chroot
user=s-static
throttles=/etc/thttpd/throttle.conf
logfile=/home/www/static.steve.org.uk/logs/thttpd.log
pidfile=/home/www/static.steve.org.uk/pid/file

(I wrote a trivial script to stop/start all the sites en mass, and removed the default thttpd init script, logrotation job, and similar things.) How did I decide which port to run this instance under? By taking the UID of the user:

steve@skx:~$ id s-static
uid=1008(s-static) gid=1009(s-static) groups=1009(s-static)

With this in place I could then update the Apache configuration file from serving the site directly to merely proxying to the back-end server:

<VirtualHost *>
    ServerName  static.steve.org.uk
    # Proxy ACL
    <Proxy *>
        Order allow,deny
        Allow from all
    </Proxy>
    # Proxy directives
    ProxyPass          /   http://localhost:1008/
    ProxyPassReverse   /   http://localhost:1008/
    ProxyPreserveHost on
</VirtualHost>

So was that all there is to it? Sadly not. There were a couple of minor issues, some of which were:

cronjobs

I have various cron-jobs in my main steve account which previously updated blog indexes, etc. (I use namazu2 to make my blog searchable.) I had to change the ownership of the existing indexes, the scripts themselves, and move the cronjob to the new s-blog user.

cross-user dependencies

I run a couple of sites which pull in content from other locations. For example a couple of list summaries, and archives. These are generally fed from a ~/.procmail snippet under my primary login. Since my primary login no longer owns the web-tree it is no longer able to update things directly. Instead I had to duplicate a couple of subscriptions and move this work under the UID of the site-owner.

I'm no longer running apache

For a day or two I'd forgotten I was using the apache facility to include snippets in my site; such as links to my wishlist. Since I'm not using Apache in the back-end server-parsed files no longer work. Happily I'm using a simple template-based setup for my main sites, so I updated the template-parser to understand "##include ./path/to/file". For example this source file produces my donation page. The upshot is my "static" site is even more static, which is a good thing.

uploads are harder

Several of my domains host entirely static content which is generated on my main desktop machine, and then uploaded via rsync post-build. I had to add some more accounts and configure SSH keys, then update the uploading routines/Makefiles appropriately. Not a major annoyance, but suddenly my sshd_config file has gone from "PermitUser steve,backup" to including many additional accounts.

The single biggest pain was handling my my mercurial repositories - overhauling that took a bit of creativity to ensure that nothing was broken for existing or new checkouts. I wish that a backport of mercurial-server was trivial because I'd love to be using that. In general though watching the thttpd logs has been sufficient to spot problems. I had to tweak things a little to generate statistics properly, but otherwise all is good. Why thttpd? Well small, lightweight, and the ability to run CGI scripts. Something missing from nginx for example. I'm still aiming to remove apache2 from the front-end - it is mostly just a dumb proxy, but it does perform some ACL operations and expand mod_rewrite rules. I could port those to another engine .. but not today. The most likely candidates are nginx, perlbal, or lighttpd - each of these should be capable of doing simple ACL checks, and performing mod_rewrite-like rules. ObFilm: Mallrats

I opened Slashdot's Looking back from the 1980s at computers in education article because I am quite convinced of the point some of the commenters argued before me, (and it's good to know others think as you do ;-) ) When I got close to computers, learning computing for children basically meant learning programming in a fun way. For years, my hobbies included Logo and BASIC. At age 7 (by 1983), typing TeX and using Emacs at the computer of the institute where my father worked, I started walking the path I took for my professional life. When I taught computing to high school students as my first paid job (which didn't last long, only a semester, as for an untrained 20 year old it is very hard to control a group of kids nearly his age), I tried to teach some basic BASIC programming (which was the best I knew then)... But no, both students and the school wanted me to focus on teaching MS Office applications. It seemed stupid for me 14 years ago, and it still seems stupid for me today. Anyway, on Slashdot, I came across this beautiful way to explain what computer education should mean:

"computing is no longer taught in schools (parents look quizzical), they are simply 'trained' (parents look like they vaguely get it). if this was sex instead of computing that was taught in schools, would you prefer that your kids have sex _education_ or sex _training_? (parents finally get it)".

By the way, if you are interested in reading a bit of paleofuturism, to feel the joy and excitement with which computer-aided education was seen 30 years ago, be sure to get the Classroom Computer News issue for September-October 1980, linked from the Slashdot article (and copied over here for your convenience, of course!)

Attachment	Size
Classroom Computer News vol. 1 no. 1, sep-oct 1980	3.54 MB

Until today you could only use reportbug-ng to query the BTS with simple queries like packagename , bugnumber , tag:patch , etc. But the BTS actually supports composite queries like severity:grave tag:patch which returns bugreports with severity grave and a patch. The underlying Python library python-debianbts also supported this right from the start, but reportbug-ng did not make use of it. Last weekend I finally had the time to fix that and the result is on it s way to unstable. Composite queries provide a very convenient way to find cheap NMU candidates: the query "severity:critical severity:grave severity:serious tag:patch" will return release critical bugs which have a patch. Now you can just go through this list, pick an open bug, test the patch and do what s necessary to release Squeeze in time. Next item on my list is an option to hide closed bugs, maybe next weekend.

Sarah got a call from the contractor on the weekend, saying he wanted to make a start on the kitchen demolition on Wednesday. So we've moved everything from the kitchen into the living room (fridge and stove included), and they started work today. Boy, did they start! It's all gone already. All of the cabinets, and the existing lighting, and the fan. Here's how it looked last night: Unfortunately there's no working lights any more, so I couldn't take photos of how things look tonight. I'll have to try and get some in the morning before the contractor gets here. It's sounding like it's going to take longer than one and a half weeks, so we're going to be eating out for a while (or cooking with the microwave in the living room). Conveniently (depending on how you want to look at it given the temperature there) I have a work trip to New York next week, and Sarah's going to come along for a few days as well, so that'll help kill some time. I think our next immediate need is to decide on what colour to paint the walls. Some light shade of green is a current contender.

Shortly after I wrote my last article about ACTA and the lack of transparency, I was delighted to find out that a report of the recent negotiations in Mexico has been leaked. I find it a bit disconcerting that our politicians, who are theoretically supposed to represent our interests, are writing documents that can leak to the public, when they should have been available to the public from the start. The document and the coverpage are available for direct download. Michael Geist has a first analysis

A brief report from the European Commission authored by Pedro Velasco Martins (an EU negotiator) on the most recent round of ACTA negotiations in Guadalajara, Mexico has leaked, providing new information on the substance of the talks, how countries are addressing the transparency concerns, and plans for future negotiations. (read more )

NP: Dimmer: Degrees of Existence

I'm glad to see that Sam 'When All Else Fails, Call 'Em Racists' Varghese has admitted that he's definitely not a part of the open source community. Which is good, because I'd be pretty upset if he was. (Though his claim to be a professional journalist is no doubt fairly upsetting and phenomenally insulting to actual journalists.)