So i'm a couple hours late for Ada Lovelace Day (in my time zone at least), but i wanted to mention Leslie Pack Kaelbling, an excellent technologist who has also had a significant impact on my life. Her extremely short biography says (in full):

Leslie Pack Kaelbling is Professor of Computer Science and Engineering at the Computer Science and Artificial Intelligence Laboratory (CSAIL) at the Massachusetts Institute of Technology. Her research focuses on decision-making under uncertainty, learning, and sensing with applications to robotics.

She is also the founder and co-editor-in-chief of the Journal of Machine Learning Research, an active open-access academic collection which encourages the development of open source software for the field of machine learning. Cool stuff! lpk was my professor when i was an undergraduate (before she went to MIT), and she opened my mind to a lot of great ideas about artificial intelligence, machine learning, robotics, and computation in general. Beyond the specifics that she taught, though, she also demonstrated what it means to be a spirited and engaged academic, both in research and in teaching. I think i first read Stanslaw Lem in one of her robotics classes (it was one of the stories from The Cyberiad), where she encouraged us to think not just about the technical possibilities of machinery, but also about the social possibilities. And it wasn't just theorizing: I also had the chance to do significant work with robotics hardware (both real and emulated) in a lab under her friendly and open supervision. She developed a new introductory series of two classes for the school's Computer Science department, which i was unfortunately too late to take. They're designed to reach students who were discouraged by the traditional programming-heavy approach, and focus instead on the issues of theory, abstraction, and collaboration, with programming taking a subordinate place to understanding the nature of computation itself. Later in my scholastic career, I had the privilege of helping her out as a teaching assistant, working with her on various robotics projects, advising a handful of younger students with her, and having her advise my final-year project, where i tested and evaluated variants of the boosting machine-learning algorithm. Throughout all of this, and despite my typical collegiate distractions, Leslie helped me understand technical details and nuance about the possibilities that we have with these incredible machines, and how they might be made to interact with the real world with all of its contradictory input and uncertainty. So here's to Leslie Pack Kaelbling: thank you for all your amazing contributions to our field, and for the things you taught me and the opportunities you shared!Tags: adalovelaceday09

Today is Ada Lovelace day, a project to celebrate the women involved in technology and make it easier to give examples of female role models in the industry. I've had the opportunity to meet many women working on Linux over the past few years, and if there's one thing that's tended to overshadow the achievements and dedication to their work it's the sheer amount of effort they've had to go to in order to gain equal recognition. And that made me realise that in many ways, the woman who's had the greatest impact on my career is Hanna Wallach[1]. About ten years ago she spent a ridiculous amount of effort teaching me that it didn't matter how much I professed to be entirely free of sexism if I then proceeded to do things that implicitly excluded women from being involved in computing communities. I've gone to some amount of effort to repay that (contains profanity and a man with a raccoon tail covering his crotch), but I'm very aware of how different my life might have been if Hanna hadn't gone to the trouble of ensuring that I knew not to be a dick.

I think the Linux community has become more welcoming since then, and Hanna and people like her have been instrumental in helping that happen. However, we still have people being driven away by the behaviour of others or arguments that technical contributions are more important than social behaviour, and while that's true we need role models for social change just as much as we need role models for technical achievement. Thanks, Hanna[2]. The Linux world's a better place because of you.

[1] And while she's a role model of mine for social reasons, she's also got a PhD in machine learning, was British computer science student of the year in 2001 and came top of her MSc class at Edinburgh. So there.

[2] "Thanna"

Identi.ca is one of the contestants in the Internet March Mayhem e-Tournament. We're up against LinkedIn in the first round. Help us out by clicking the "Identi.ca" link in the lower left-hand part of the tree. tags identi.ca marchmayhem voteforus

Ada Lovelace Day FAIL Updated. I signed up for the Ada Lovelace Day pledge a few months ago, so I wrote a churlish, short, and ill-tempered blog post on the subject. (Since redacted.) Among other things, I said, "I dislike the canonization of Ada Lovelace as a patron saint of women in computing. [...] Hundreds of thousands if not millions of women have written more code that mattered more for people's real lives than anything Ada Lovelace did. [...] Maybe instead of honoring Ada Lovelace, we need to honor these other women instead." But on re-reading the pledge, I realized that I totally missed the point of Ada Lovelace Day, and that this is exactly what people are supposed to do. Oops. See #ald09 for some nice posts about women in computing. Oh, and to pick a woman in technology I admire: Eve Maler, one of the co-creators of XML. I met her when she was chairing the SAML committee, and she led that group of competitive egos through some very difficult security and protocol design issues with great intelligence and diplomacy. tags: women technology adalovelace adalovelaceday AdaLovelaceDay09

Today, among all the other things I accomplished, I converted the rest of the system templates for the eyrie.org systems to Git and tweaked my personal configuration management system to make better use of Git's features to push data around. I was feeling on a productive roll, so I also wrote up the system I use. This system has a long history. The first commit in the underlying repository for my personal workstation is dated September of 1998, and the underlying system was already in use at Stanford before I started working here more than 15 years ago. It survived several major OS changes and several significant reorganizations and only recently has been replaced for day-to-day server management by Puppet. We still use bundle to do some of the initial system configuration inside FAI before the system is put together enough to run Puppet. Puppet is overkill for a few personal systems, so the system I'm using is based on our previous revision of our server template system, with some modifications to not depend on AFS and to make remote deployment of changes easier and simpler. It's not as fancy as some of the new ideas for managing all of /etc in a VCS, but it's been reliable and capable enough for me that the core of the system remains unchanged after ten years.

Steven Levitt gave an interesting talk for TED about the economics of a crack-dealing gang [1]. He makes some interesting comparisons with the way that corporations work. Top 10 strangest terrorism patents [2]. Items 1 and 4 have been implemented many years ago, item 5 was probably implemented by the CIA decades ago (they did many similar things), item 7 will probably kill a significant portion of the passengers (bummer if it goes off accidentally), item 8 has the same problem but will only target nervous people (calm terrorists can do what they want), and the creator of item 9 doesn’t seem to have much idea about how much energy is contained by high explosive. Supporters of Barack Obama are adopting Hussein as their middle-name to support him and oppose some of the unreasonable claims from extremists [3]. I’m not planning to call myself Russell Hussein Coker. Chris Samuel summarises the latest CSIRO report about droughts caused by climate change [4]. He notes that most simulations are based on lower levels of CO2 than we are expecting… Interesting article in the Guardian about car use in the US [5]. It suggests that soon suburbs will be slums occupied by the poor an unemployed and inner city areas will experience a revival. Recently I’ve been putting the papers I’ve presented at conferences online on my documents blog (see this link for the “papers” category) [6]. The papers are almost unchanged from when I published them, I fixed up some broken URLs and made some notes on relevant things that have happened since publication but made no essential changes to the text. Linux.com article about Bonnie++ [7]. It’s well written and covers most of the features quite well. An unfortunate omission is the fact that if you want to run Bonnie++ from the root account you can specify “-u user” on the command-line to run the test as a different user, or you can use “-u root” if you REALLY want to run it as root. A Linux.com article with the source code for a Perl script to create charts from Bonnie++ results [8]. I had always planned that other people would write programs like this, I’m glad to see someone finally publish the source to one!

• [1] http://www.ted.com/index.php/talks/view/id/29


• [2] http://www.neatorama.com/2008/06/27/top-10-strangest-anti-terrorism-patents/


• [3] http://www.nytimes.com/2008/06/29/us/politics/29hussein.html


• [4] http://www.csamuel.org/2008/07/06/csiro-bom-report-drought-exceptional-circumstances-not


• [5] http://www.guardian.co.uk/environment/2008/jul/06/travelandtransport.usa?gusrc=rss&feed=networkfront


• [6] http://doc.coker.com.au/category/papers/


• [7] http://www.linux.com/feature/139742


• [8] http://www.linux.com/feature/139743

Share This

Ten years ago, most of us wouldn't have dreamt we'd be managing terabits of storage, tens of megabits of bandwidth, arrays of network-distributed services. The height of a programmer's worry would likely be choice of UI toolkit or finding the right way to indent code, and the height of consumer concern deciding which room to put the new computer in. Now the problems associated with managing large networks are becoming real for everyone, right down to the consumer level. Stupendously large amounts of computing resource are available at an instant. Your household probably has more than a terabyte of storage already. Issues such as single sign-on are going to hit home over the next year, as networked computing and entertainment devices profilerate. Features such as Apple's Time Machine will be increasingly vital — software that makes traditionally gnarly sysadmin tasks consumer-friendly. The rebranding of .Mac into "Mobile Me" is also a step in this direction. The impact on developers As software developers, we also have to cope with the effects of this resource-richness. For small sums of money we can get access to large computing clusters, geographically redundant hosting services. Our programs have left the desktop and found their new home on the web. System administration issues loom large upon us, security concerns lurk auspiciously in the corners of our minds. Although the cost of infrastructure has dropped radically, other costs remain high and are going to stay that way. System administrators are not only grumpy, they demand high wages. Commercial software license fees spiral out of control: traditional per-CPU licensing models make little sense when you can quickly bring up tens of machines. The cost in power is already troubling large companies, and there's no reason to suspect the problems won't ripple down. Help is at hand from a variety of technologies. If they don't yet make massive resource management trivial, they at least make it possible. Some of these also inhabit the weird territory of being both the source of a problem and a solution at the same time: virtualization, for example. Distributed revision control systems Distributed revision control is a technology whose time has finally come in popular circles, thanks in part to Linus Torvald's Git system. DRCS has several important impacts on today's developer:

• Branching and, importantly, merging become much cheaper, allowing agile and flexible iterations of development.
• Loosely connected and geographically diverse development becomes much easier. Even within a single organization it is not uncommon to find teams spanning countries, time zones. Complex multi-site VPN setups aren't necessary when a few SSH keys can do the job.
• Revision control becomes packaging on the cheap. Like it or not, the mere tagging of a source tree has now become a valid option for releasing software.

All these trends lower the barrier to entry, increase collaboration and agility of development. You can the value of this as more software tools become free. Selling such tools is rapidly becoming a thing of the past, the advantages of sharing enable the developers at the sharp end to get their jobs done quicker. However, such increased agility and, well, messiness leave other problems to solve, which the next two technologies address. Virtualization Hardware-as-a-service, infrastructure-as-a-service, call it what you will. The ability to create what we used to call entire machines, pick them up and move them around the network is revolutionary, and it's something that will have a real impact on regular developers. The benefits are at several levels.

• Agile infrastructure — a ready supply of new machines makes it a lot easier and cheaper to test different scenarios, architectures, and to separate concerns. If things go wrong, throw away the image and start over. It's all about cutting the administration load.
• A packaging solution — the new macroeconomics of software distribution mean that distributing entire machine images which communicate exclusively via the network is now a feasible way to distribute your software. We must adjust to the notion of distributing appliances, not code. We may mourn the lost crafts of creating RPMs or installers, but let's face it, it's now a waste of time.
• New business models — your application can now be delivered as a black-box appliance, circumventing compatibility issues, or as a service, with virtualization part of the solution to scaling.

Configuration management Computing is a zero-sum game, and despite our increased ability to create and distribute software, problems still exist. We just pushed them to the next level. In good part, this next level is the problem of configuration management. We now have networks and clusters of (virtual) machines, software so agile we need six decimal places to describe its revision levels, and network and authentication paths that are starting to tangle. How do we manage that? One thing developers crave is repeatability. That's why we love our makefiles, autoconf, Ant, rake and so on. It's the one time even the most imperative-minded programmer writes declarative code. We like to say "let the world be like this." Our new sprawling world lacks this feature, and the best of our old toolkits — .debs, RPMs — address things only at the level of packages in a single environment. So developers must look to the world of operations, a territory we probably thought we needn't enter. In this world the new "make" is called Puppet. You write recipes to describe how things ought to be, and Puppet will make it so. I've been spending some time digging into Puppet, and feel excited by the confidence it's giving me. Now my applications exceed single source trees, and single machines, it gives me the means to tie the whole together. This article was going to be solely about Puppet, but that will have to wait now for another time. It's likely you'll have played with virtual machines and distributed revision control, but have you tried Puppet yet? Give it a spin, and let your mind wander over the benefits for your organization and development approaches. Conclusions
For developers and users alike, our world is changing. Hardware, connectivity and increasingly software is becoming cheap or free. The solidity of the old things we put value on — real things you can touch like disks — is eroding. What really matters is our data, our creations, and their communication. If they don't quite yet exist in a universal "cloud" yet, they're certainly getting frisky. As vendors provide solutions for consumers to manage their new domestic infrastructure, developers must look to network-aware toolkits and operations techniques to manage and get the best from their emergent infrastructures. Also on this topic:

• In search of agile infrastructure for web applications (June 2006)
  

Join the conversation about this post

In a perfect world, when we design some aspect of our infrastructure, we'd get it right the first time, and would never have to change our design once it had been deployed. Back in this world, however, we regularly have to change things as we expand our infrastructure. Sometimes we made a mistake originally, other times new requirements pop up. In either case we will end up doing things differently in the future than how it was done in the past. The danger here is that if you only create your new machines or services differently, you've got effectively two separate and different systems to maintain. This may not sound like much, until it happens again... and again... and again... and then suddenly you've got 18 different ways of setting up backups, depending on how long ago you set it up and (if you're really unlucky) who did it and what the phase of the moon was at the time. If you've been here before, you probably remember the pain of having some disaster happen and needing to fix it NOW NOW NOW, only to wade into the setup and realise that it's been done in a way that (you thought) died out six months ago -- and so you don't really remember how it works, and yeah, the documentation's been updated so many times since then that it doesn't mention the old way of doing things, and here comes your boss to ask how long it's going to be until it's all working again... If you haven't had this experience (yet?), you'll have to trust me when I say that it's no fun to hit an older, out-of-date system. It's especially painful because the most common reason you change things is because the old way sucked. So you turn up at a critical moment to fix something in a poorly documented and sub-optimally configured system. Fun, fun, funnity fun. There are only two ways to avoid this problem: never change the way you do anything, or else plan your changes so that retrofitting is part of the plan every time you're modifying an existing service. Assuming that never changing anything isn't an option, you need to plan to retrofit. When you're putting together the design for your system change (you do design your changes, right?) you need to audit what's out there, determine what's needed to bring it all up to date, and put together a plan to make that happen. It's like documentation and testing -- if you don't make an explicit effort to make it happen, it'll never get done. That sounds like a lot of work, and it is. Luckily, if you're already working in a well-maintained infrastructure you should only really have one existing config to upgrade, which shouldn't be too painful. However, if you've got a lot of machines to change there's no way around the fact that they've all got to be changed, and that can take time. If you accept that you don't want configuration skew, you can start to think about how to engineer your systems and processes to make it less of a hassle to keep everything up to date. Putting some extra thought into how you set things up in the first place so that it's easier to update is at the heart of this. Automating deployment is an easy way to take some of the pain away from rolling out new configs, but there's also plenty of smaller decisions that help with updating configs: putting everything in revision control, making extensive use of templating and pulling out common config fragments, and making sure that you've got good notes and records of what has been done where. The more you automate your deployment and maintenance, the less pain you feel when you need to retrofit. With something like Puppet, you can eliminate a lot of the pain because you're describing what you want done for all the relevant machines, and then the machines themselves work out what needs to be done to bring themselves up to date. With an advanced automation system in place, you can say "I want all my mail servers to have setting X turned on" and off they go and set the option. Or you might want to have some of your mail servers to have a different config setting, triggered based on a config setting or class of machine. Of course, you might not already have that config setting or class defined, so you'll need to add it. Don't forget to retrofit that new config setting or class to your existing machines. That might involve finding the config for all the existing machines and modifying them. Yep, no matter how much automation you've got you can't get away from the need to retrofit, but given the choice between editing a bunch of config files on my local machine (with all the power of my text editor to back me up) or logging into dozens of machines all over the globe to edit their configs and restart services (with all the risks of making a mistake) I know which one I'd choose...

XQuery 1.0 and XSLT 2.0: news and how to use them in Debian (long post about the second generation of the XSL family and how to use the related languages in Debian)

• XPath 2.0, XQuery, et al.
• the above stuff .. in Debian
• links

---

The 2nd generation of the XSL family At the beginning of 2007, W3C released a family of interrelated specification: XPath 2.0, XSLT 2.0, XQuery (1.0). The 3 specifications are based on the very same underlying data model which (finally!) supports typed values and exploits them to some extent, for example permitting some form of static type checking in XPath and XQuery. Types usually come from XML Schema, with both built-in and user-defined types supported. A brief overview of the 3 specifications and what they change in the state of the art follows. XPath 2.0 XPath 2.0 basically consists in XPath 1.0 + 3 new macro features. The first one is a revamp of those language features which are dealing with types, in order to better integrate them with the new typed data model. XPath now has operators to check whether a value belongs to a given type (so yes, type information are kept at run time), and to cast them from one type to another. The basic new type constructor is now the sequence, which replaces the old node-set solving many annoying issues, such as the impossibility of having a node ordering other than document order. The second feature is the improvement of standard library of functions which was ridiculously small in XPath 1.0; it is much better now. Additionally, 2nd generation languages (XSLT 2.0 and XQuery) now support the ability to define functions which will then be visible to inner (XPath) expressions, pushing yet forward the possibilities of plain old XPath. Functions can now also declare types in their signatures (for their arguments and return value) and untyped arguments will be automatically casted to them upon invocation. Hence, even if you are not using an implementation which assigns types to your XML trees, once you "enter" the typed world calling a typed function (almost all standard library functions are decently typed) you will be able to stay there avoiding annoying casts everywhere. Finally XPath 2.0 has turned into a powerful purely functional language and is now powered by constructs like conditionals, for-each loops, existential/universal quantifiers, and existentially-quantified comparison operators for sequences. Here is a complex expression to hwet your appetite (or scare you away ...), comments come as (: smiley faces :)

for $book in /bookshelf//books
return
  if ((every $author in $book/authors/author
       satisfies $author/nativeLang eq "it_IT")
      and $book/lang eq "it_IT")
  then $book
  else ()
(: think about the trouble of writing this in XSLT/XPath 1.0 ... :)

XSLT 2.0 XSLT 2.0 is what I would call a "bug fix release" of XSLT 1.0 + the routinary reworking of the language to deal with typed values, which is not sensibly different than what has been done for XPath 2.0. The fixed "bugs" are several, starting from the annoying issue of result tree fragments. They are basically tree snippets that in XSLT 1.0 you were able to generate for future use. Unfortunately they were not thaaat reusable, given that you were not even able to navigate them with XPath operators! Now the specification is much more clear and distinguishes final result trees from ordinary variables, which can now contain sequences of (navigable) tree nodes. Another important "bug" fixed is the new ability to output multiple documents with a single XSLT stylesheet: it marks the end of stupid extra post processing to be added in pipeline to a XSLT processor. Other minor "bugs" fixed are a limited amount of backtracking capabilities among imported templates, regular expression support directly in the language, and powerful grouping constructs on the lines of SQL's GROUP BY (but much more powerful). Here is a template snippet exploiting the latter feature:

<xsl:for-each-group select="*" group-starting-with="h1">
  <div>
    <xsl:apply-templates select="current-group()" />
  </div>
<xsl:for-each-group>

XQuery XQuery is the end of the chains imposed by XML-based syntaxes. Why the heck one has to use an XML syntax (as in the above snippet) only because she is manipulating XML tress is one of the mysteries of XML technologies which have always been floating around in my head. XQuery is the (supposedly) SQL equivalent for databases of XML documents, but is actually much more than that. I depict it in my head as the XML manipulation language with a syntax I can finally stand. Technically it is XPath 2.0 (say 80% of the whole language) + some extra ingredients (say 20%); so remember that every XPath 2.0 expression is also a XQuery expression. The main extra ingredient is the so called FLWOR expression (to be read: "flower expression", which in addition to the "smiley faces" used for comments gives a "back to 1968"-flavour to the language .... erm FLWOR/flower/flavour, no pun intended). A FLWOR expression is very similar to SQL's SELECT-FROM-WHERE: it lets you generate a tuple stream by iterating on sequences (F: for clauses), binding expression values to names (L: let clauses), filter out tuples which do not satisfy a required condition (W: where clause), order the survived tuples (O: order by clause), and finally return a sequence built using the residual tuple stream (R: return clause). The other interesting extra ingredient is the ability to build the XML snippets you want to manipulate. Within XQuery you do that using plain XML syntax (the only place where a sane-minded programmer actually wants to see it!) which also supports a classical interpolation mechanism to embed expressions which will be evaluated inside XML snippets, and also the other way around. A canonical XQuery example is:

for $t in doc("books.xml")//title,
    $e in doc("reviews.xml")//entry
where $t = $e/title
return <review>  $t, $e/remarks  </review>
(: braces denote the escaping context where XQuery expressions will
   be evaluated inside snippets; plain XML syntax is used for the
   other way around :)

But remember: XQuery for XML is much more than SQL for RDBMS, thanks to the implicit templating mechanism implemented by interpolation, and thanks to several language features fostering modularity (user-defined functions, library modules, XPath 2.0 standard library, ...) you can basically do with it any kind of XML manipulation you can imagine. I don't think I will ever write myself any other single line of XML output in DOM or XSLT ...

---

Cool, how can I use it in Debian? ... if only this stuff were decently supported in the open source world. Last time I checked, the author of most parts of the GNOME toolchain for dealing with XML (libxml2, libxslt, ...) was not intentioned to implement XSLT 2.0, not even mentioning XQuery. This comes as no surprise, the whole GNOME XML toolkit is written in C, and XSLT 2.0 / XQuery have reached a level of complexity and formal specification which usually entails a higher level approach. So on the GNOME side we are stuck. The other open source implementations of XSLT 2.0 / XQuery I'm aware of are Saxon and Galax. Saxon is an XSLT 2.0 and XQuery implementation written in Java, which is unfortunate per se. Additionally, it is also unfortunate that it is only partially open source. Indeed, Saxon is split into SaxonB (for "basic") which is open source under the Mozilla Public License and SaxonSA which is commercial. While SaxonSA is a fully conformant, XML Schema-aware processor, with support for static typing, SaxonB is a basic-conformant processor with no type-aware features and actually much less optimized than SaxonSA. This is annoying. (Much more annoying is the fact that SaxonSA's author is the only editor of the XSLT 2.0 specification and that instead of his mail address the specification includes an URL pointing to the website selling SaxonSA ...) Galax is an open source (IBM CPL / Lucent license) OCaml implementation of XQuery which is not fully conformant to the specification (though it gets quite close) which is type-aware and implements static typing. The only XQuery / XSLT 2.0 implementation available in Debian at the time of writing is SaxonB. The binary package is libsaxonb-java, kudos to Michael Koch and the Debian Java Maintainers for having packaged it (and to have stood some annoying pings of mine bug #408842). To execute XQuery code you just have to aptitude install libsaxonb-java, prepare a query.xq file containing your query, and then execute something like:

CLASSPATH=/usr/share/java/saxonb.jar \
java net.sf.saxon.Query query.xq

note that the information in README.Debian are still referring to old Saxon versions, see bug #465894 which proposes a more up to date README.Debian. Similarly, to perform a XSLT 2.0 transformation you have to do something like:

CLASSPATH=/usr/share/java/saxonb.jar \
java net.sf.saxon.Transform -ext:off -s:input.xml -xsl:style.xsl -o:output.xml

Do not remove the -ext:off flag when processing untrusted stylesheets!, see bug #465885 for the reason. I've written some handier (1-liner) shell script helpers which remove the need of invoking java manually. They are attached to bug #465894 and I've proposed their addition to the saxonb package. Using them the above invocations become:

saxonb-xquery query.xq
saxonb-xslt -ext:off -s:input.xml -xsl:style.xsl -o:output.xml

Galax in Debian ... well, since long time I've been planning to package it (the ITP has been filed some months ago: bug #447984) and the authors sent me a newer version than what is available online to gather feedback before the long overdue final release. Unfortunately I've been lagging behind in finishing the packaging (which is tricky due to the need of binding libraries to several different languages: OCaml is native, but there is also Java for example). Hopefully this post will give me some renewed motivation for finishing the work ...

---

References

• Debian package w3-recs, ships the whole list of W3C Recommendations for offline consultation; it includes all the specifications we have discussed in this post
• Saxon: home page of Saxon, a XSLT 2.0 / XQuery processor written in Java
• Galax: home page of Galax, a XQuery processor written in OCaml
• Debian package libsaxonb-java, ships SaxonB as a Debian package

---

Acknowledgements Thanks to godog for his helpful comments.

---

Update: the helpers I've proposed have been accepted into the official package, I've also made available their manpages. Also the pending changes to README.Debian has been accepted. Kudos again to Michael Koch for his quick feedback on my patches!

We really haven't stopped since we lost Joshua. It's helped us kill time until Sarah's surgery, which is now in two days time. It's hard to believe it's rolled around so quickly, really. We've got about four hours of pre-op stuff tomorrow, from 9am, which sounds like it entails blood tests and a chest x-ray, as well as general Q&A. The surgery is scheduled at 7:30am the next day. It's good that it's early in the day. We found a good page that describes what they're going to be doing (a modified David's Reimplantation Procedure)). I'll be able to write something more competent about proceedings tomorrow after the pre-op stuff I expect.

Nice to see the British Computer Society finally run Linus to ground after 7 years, so that they could pin the Ada Lovelace Medal on him, but I reckon he looked even more pleased when he got a new T-Shirt:

Eurosport are broadcasting the Vuelta a Burgos at 19 east until Saturday. This can be an interesting race for seeing how well the ProTour teams are recovering from the Tour de France, ready for the Vuelta a Espa a. Barloworld's TdF revelation Juan Mauricio Soler has a 17-second lead into tomorrow's individual time trial. The 69th Volta a Portugal finished yesterday with an ~50-minute individual time trial that saw the lead change hands and Xavier Tondo of LA/MSS take the General Classification by a little under a minute. RTP's coverage was strangely subdued. It seemed like they only had cameras around the finish line, not on motorbikes following the riders. The bad weather may have caused that, though. Meanwhile, the Deutschland-Tour 2007 is broadcast to Europe until Saturday on ARD at 19 east and 13 east. Gerald Ciolek of T-Mobile won his second stage in a row today, while CSC's ever-popular Jens Voigt remains in yellow. Individual time trial there too tomorrow. ARD's coverage has been very swish so far this year. Widescreen with informative graphics, although the commentary is still a bit subdued for my taste. Overall, it's a shame there's not more airtime given to it.

After my comments about the TV audience figures, Ismael Valladolid Torres commented:

"Audience in Spain will keep on raising while Contador keeps playing such a big race!"

I hope that's still the case after the recent revelations. The evidence suggests that Vinokourov had someone else's blood [tdfblog] and Cofidis's Moreni was using something like a nutsack patch [tdfblog] while Rabobank have fired race leader Rasmussen for telling them he was in Mexico when he was in Italty [tdfblog] so it looks like this year's race is still really unpredictable as the dopes are caught and kicked out. Maybe my hopes for a Valverde (now 6th, 10:18 back) win still stand a chance... (My "serious" prediction, Kl den, left with Vino.)

Peter Brown replied:

"Thanks for the message. Here are some comments on the issues you raise:

"> - On the Radio New Internationalist show "Up in Smoke", during an interview with Peter Brown of FSF (about 43 minutes in), I was surprised to hear the following revelation that FSF uses Skype and the failure to challenge the claim that Skype is free software:"

The FSF doesn't use Skype. I would appreciate if you would clarify that on your blog post. The interviewer used Skype to telephone me on an FSF telephone. I agree that from what I said, it would be easy to infer that FSF uses Skype, but it doesn't. The interview lasted about an hour and we covered a lot of ground. Also, in this exchange I didn't clarify for the listener that when the interviewer remarked that "Skype was free", they meant as in price, but not as in freedom.

"> - I was disappointed not to find much on the FSF web site about the need for free VoIP software, building on GNU oSIP and other free software, instead of Skype's proprietary software, which has contained spyware and worms already. Will you be adding such information soon? What is the official FSF view of Skype and similar proprietary VoIP systems?"

Skype is proprietary and we don't use it. In that section of the interview we were discussing telecoms monopoly and net neutrality, and I lost the focus on the free software issue - my bad. As far as adding an article about VOIP on fsf.org I think that's a great idea. Unfortunately, I don't think we can cover that immediately, as we have some campaigns we have other campaign activities to focus on. We would be glad to take a contribution though, if you would like to write such an article - we might also want to think about using such an article as a basis for a campaign.

"> - Nevertheless, well done for covering DRM, net neutrality and the privacy problems of Google, Yahoo! and Microsoft in a relatively short interview."

Thanks. I actually used to work at the New Internationalist in Oxford, and they are a great coop. I have been working with them now for a couple of years, tying to encourage them to cover free software related issues for their audience. Have you seen the article Bruce Byfield (Newsforge) wrote that I got placed in the November issue of the magazine? all the best peter"

Thanks for the reply! To my shame, I'd completely forgotten that Skype can also call ordinary telephones and the interview didn't remind me. I guess that might be because my main awareness of Skype is when it's a problem, when someone gives a skype: address instead of a sip: one or a real phone number. However, I'm not sure a called person would usually say that they were being called over Skype, rather than being telephoned. FSF people are smarties, though, so can hear the artefacts, or maybe the interviewer had mentioned it beforehand. Anyone else want to summarise the benefits of free software VoIP compared to Skype systems? I won't get time before next month. kris commented:

"There's openwengo, it has more features than skype (i.e. video), is encrypted, open and free. Enjoy."

I keep meaning to try openwengo, but each time I look at it, I fail to find the source tarball for the latest release. It also seems to be Qt-only, which I also try to avoid installing (as it'd be a fourth set of desktop widgets). At the moment, I'm using linphone from the command-line. I sometimes consider replacing it with a stand-alone telephone adapter. I wonder: are any running free software? (2007-07-27: 7 comments)

I just sent this: Dear FSF, On the Radio New Internationalist show "Up in Smoke", during an interview with Peter Brown of FSF (about 43 minutes in), I was surprised to hear the following revelation that FSF uses Skype and the failure to challenge the claim that Skype is free software:

"Peter Brown: ... This interview today is being transmitted through Skype. We're talking through Skype. Now, that obviously is a direct threat to the entrenched telecoms and they would like to restrict that, to lower the quality of the voice connection and they want to do that with lots of other types of transmission. Rachel Maher: And can they do that? Because Skype of course is free and there's a really direct benefit for organisations like ours, which is a non-profit organisation using Skype technology. Will they be able to do that? Peter Brown: Yes, so what they can do is easily identify types of information being passed, so what they can typically do is downgrade the service that you're using, so that - for instance, voice communication - those packets of data can be slowed down, effectively making voice communciation more difficult. Now this can only really be achieved if they're able to manipulate legislation. Unfortunately, they have a long history of being very successful at this. I mentioned earlier on that Digital Restrictions Management are a threat to our freedoms because it's allowing them to erect gateways and to control what it is that we can view and do with our computers. ..."

I was disappointed not to find much on the FSF web site about the need for free VoIP software, building on GNU oSIP and other free software, instead of Skype's proprietary software, which has contained spyware and worms already. Will you be adding such information soon? What is the official FSF view of Skype and similar proprietary VoIP systems? Nevertheless, well done for covering DRM, net neutrality and the privacy problems of Google, Yahoo! and Microsoft in a relatively short interview. Regards, MJR

For a long time I've been vexed by the gender bias of computing towards men. It's clear that computing has multiple issues, ranging from its perception to the nature of its society. As organizer of computing conferences, I care about ensuring that participation is meritocratic and inclusive.
As various debates have taken place over blogs in the past on women in computing, I have stayed silent. Not because I don't care, but because I really didn't know what to say. I try to understand, but at the end of the day I'm a man, I tend to misunderstand important points, and I suspect my contributions would come across as at best naïve, and more likely, patronising. So many conversations between men and women on this topic end up in mutual uncomprehension. Better to stay silent than be a fool.
This is why I'm very grateful for Jeni Tennison's analysis of women in computing. It is the most helpful blog post I have read recently on the topic. Perhaps it's because Jeni's British, and we share some of the same cultural assumptions and constraints. But more importantly, it's because her article builds bridges to my experience and understanding.
An argument of femininity Rather than simply appealing to tribes of men and women, Jeni places the discussion in terms of feminine and masculine traits. Like many men, I identify with certain attitudes and preferences more closely allied to my feminine side. By not excluding me, her wording helped me view the points she unfolded in terms that my own experience, however poor, could identify with. I've often found contemporary computing communities to be suffocatingly macho. There's a strong pressure to succeed in terms of attention from the chattering bloggers, privileged inner circles and the capacity for vicious excoriation of those who fall from grace.As I grew up through school and university, I held these sorts of social forms in contempt, as well as occasionally suffering at their hands. Yet now, bafflingly, I find myself under the impression I need to belong and compete in these spheres.Self-efficacy One of Jeni's central points is concern about one's own self-efficacy. This was the real revelation to me. I tend to assume most capable people I meet are aware of their own capability. Jeni turned this on its head for me when she wrote

... look at how Ruby on Rails is marketed. A big play is made of how easy it is. But if a language or framework is easy then people with low self-efficacy can’t win: if they manage to do something with it then they haven’t really achieved very much because anyone can do it; if they don’t manage to do something with it then they’re complete idiots. I’m not saying that we should advertise languages or frameworks as being hard, because obviously that can put people off as well, but a recognition of the barriers that people might face may, in a strange way, make them more approachable.

As Jeni brings her article to a close, it's with some shock and shame that I get the punchline loud and clear: "this isn't about you."It's about empathy, inclusivity and selflessness. Human qualities that are unrestricted to either gender.

Puppet the system-administration tool, similar to CFengine is very nice. What is less-nice is the lack of decent examples. The wiki has lots of "recipes", however these give no real explaination of how to install them. I know that I need manifests/site.pp which will control which nodes get which actions applied to them, but beyond that I'm a little lost! I'm hoping to replicate my cfengine setup. Most of it is pretty simple "append line to file if missing", and copying files from the central server. (The latter I've got working nicely.) Hopefully somebody will now point me at a good tutorial that doesn't stop once it is installed (like this one.)

The GNOME project announced a GNOME Mobile & Embedded Initiative today. Here's a screenshot of the browser on my laptop of the web page: What's wrong with the above picture? The browser window is around 700 pixels wide, which about as wide as you'd get on, say, an N800 Internet tablet gadget. Significant parts of the web page are unreadable. I have to go to about a thousand pixels wide to get the whole page be visible. This is no way to design pages for a mobile environment. Other than that, it's obviously good. Not worth the hype, not worth keeping secret for months before the big revelation, but a good thing nevertheless.

I plan on announcing the GUADEC 2007 Call for Papers in the next day or so, so I want everyone to put their thinking caps on and consider giving a talk this summer. There are several topics I'd like to see a good set of talks on:

• 10x10. How are we doing on the 10x10 plan: this includes feedback from people who have done large deployments, to people working on making GNOME work in the enterprise, and people putting GNOME in embedded devices.
• Integration. GNOME needs tighter integration within itself, be this showing presence in relevant applications, integrating chat/voip into the desktop, and tighter integration between applications. Do you have a cool application that makes GNOME easier to use, or something that integrates applications, documents, and people into a cohesive whole?
• Future. Lots of new code is being written, do you have anything interesting? A replacement for gnome-vfs, progress on Project Ridley, a new implementation of something fundamental like the panel?

Recently, I was doing a conversion of CFEngine configs to Puppet manifests. I noticed this line being set in sshd_config:

 AllowGroups foo bar baz xyzzy

And then somewhere else, the www-data user had been added to the baz group, so that the webserver could write to some files owned by the baz user (on a group-per-user system, naturally). Ordinarily, you wouldn't connect these two things (the changes most likely having been made months apart), and it was only that I was examining all of the changes made to the system in this manifest at once that I connected the two things at all. There are a couple of ramifications here:

• This likely makes a lot more things readable/writable by the webserver than was anticipated.
• Suddenly, despite all of the admirable paranoia shown by the initial use of the AllowGroups config, we've just inadvertantly given the user that our webserver runs as SSH access to the server.

I don't know whether the problem is excessive complexity and hence the risk of unintended consequences, or if problems like this can be avoided with sufficient careful thought, but I do know one thing: making all of your system changes through a system like Puppet doesn't just make your systems more reproducible, it also makes them more auditable. Bonus!