I've been pondering this subject for a while, and I think I'm finally ready to write about it.
Tcl was, for many years, my go-to language of choice. It's still near and dear to me in many ways, and I even worked on a portion of a book about it ( http://journal.dedasys.com/2009/09/15/tcl-and-the-tk-toolkit-2nd-edition ). However, examining what "went wrong" is quite interesting, if one attempts, as much as possible, a dispassionate, analytical approach that aims to gain knowledge, rather than assign blame or paper over real defects with a rose-colored vision of things. It has made me consider, and learn, about a variety of aspects of the software industry, such as economics and marketing, that I had not previously been interested in. Indeed, my thesis is that Tcl and Tk's problems primarily stem from economic and marketing (human) factors, rather than any serious defects with the technology itself. Before we go further, I want to say that Tcl is not "dying". It is still a very widely used language, with a lot of code in production, and, importantly, a healthy, diverse, and highly talented core team that is dedicated to maintaining and improving the code. That said, since its "heyday" in the late 90ies, it has not ... "thrived", I guess we can say. I would also like to state that "hindsight is 20-20" - it's easy to criticize after the fact, and not nearly so easy to do the right thing in the right moment. This was one reason why I was reticent to write this article. Let me repeat that I am writing it not out of malice or frustration (I went through a "frustrated" phase, but that's in the past), but because at this point I think it's a genuinely interesting "case history" of a the rise and gentle decline of a widely used software system, and that there is a lot to be learned. At the height of its popularity, Tcl was up there with Perl, which was the scripting language in those days. Perl, Tcl, and Python were often mentioned together. Ruby existed, but was virtually unknown outside of Japan. PHP was on the rise, but still hadn't really come into its own. Lua hadn't really carved out a niche for itself yet, either. Tcl is no longer one of the popular languages, these days, so to say it hasn't had problems is to bury one's head in the sand: it has fallen in terms of popularity. To examine what went wrong, we should probably start off with what went right:

• Tk. This was probably the biggest draw. Easy, cross platform GUI's were, and are, a huge reason for the interest in Tcl. Tk is actually a separate bit of code, but since many of the widgets are scripted in Tcl, the two are joined at the hip. Still, though, Tk is compelling enough that it's utilized as the default GUI library for half a dozen other languages.
• A simple, powerful language. Tcl is easy to understand and get started with. It borrows from many languages, but is not an esoteric creation from the CS department that is inaccessible to average programmers.
• Easily embeddable/extendable. Remember that Tcl was created in the late 80ies, when computers were orders of magnitude less powerful than today. This meant that fewer tasks could be accomplished via scripting languages, but a scripting language that let you write routines in C, or, conversely, let the main C program execute bits of script code from time to time was a very sensible idea. Tcl still has one of the best, and most extensive C API's in the game.
• An event loop. Lately, systems like Python's "twisted", and node.js have made event-driven programming popular again, but Tcl has had it for years.
• BSD license. This meant that you could integrate Tcl in your proprietary code without worrying about the GPL or any other legal issues.

These features led to Tcl being widely used, from Cisco routers to advanced television graphics generation programs to the AOLserver web server, which was busy serving out large quantities of dynamic web pages when many of us were still fiddling around with comparatively slow and clunky CGI programs in Perl. Note also that there have been a lot of cool things to have gone into Tcl in the mean time. It has a lot of impressive features; many more than most people realize, and has had a lot of them for a while. Check out http://www.tcl.tk to learn more about the "good stuff". But that's not the point of this article... There was a healthy, active community of developers producing lots of interesting add-ons for the language, and working on the language itself. This culminated in its adoption by Sun Microsystems, which hired the language's creator, Dr. John Ousterhout, and a team of people, who added a lot of great features to the language. Quoting from Ousterhout's history of Tcl page:

The additional resources provided by Sun allowed us to make major improvements to Tcl and Tk. Scott Stanton and Ray Johnson ported Tcl and Tk to Windows and the Macintosh, so that Tcl became an outstanding cross-platform development environment; Windows quickly came to be the most common platform. Jacob Levy and Scott Stanton overhauled the I/O system and added socket support, so that Tcl could easily be used for a variety of network applications. Brian Lewis built a bytecode compiler for Tcl scripts, which provided speedups of as much as a factor of 10x. Jacob Levy implemented Safe-Tcl, a powerful security model that allows untrusted scripts to be evaluated safely. Jacob Levy and Laurent Demailly built a Tcl plugin, so that Tcl scripts can be evaluated in a Web browser, and we created Jacl and TclBlend, which allow Tcl and Java to work closely together. We added many other smaller improvements, such as dynamic loading, namespaces, time and date support, binary I/O, additional file manipulation commands, and an improved font mechanism. Unfortunately, after several years, Sun decided that they wanted to promote one and only one language. And that language was Java. So Ousterhout and many people from his team decamped to a startup that Ousterhout founded, called Scriptics, where the Tcl and Tk innovations continued:

In 1998, Scriptics made several patch releases for Tcl 8.0 to fix bugs and add small new features, such as a better support for the [incr Tcl] extension. In April 1999, Scriptics made its first major open source release, Tcl/Tk 8.1. This release added Unicode support (for internationalization), thread safety (for multi-threaded server applications), and an all-new regular expression package by Henry Spencer that included many new features as well as Unicode support.
However, as many a company based around open source was to find later, it's a tough space to be in. Scriptics changed its name to Ajuba, and was eventually sold (at a healthy profit, apparently, making it a relative dot com success story, all in all) to Interwoven, for the "B2B" technology that Ajuba had developed. Interwoven was not interested in Tcl, particularly, so, to create a system for the ongoing development and governance of the language, the "Tcl Core Team" was created. This was something of a blow to Tcl, but certainly not fatal: Perl, Python, Ruby, PHP, Lua have all had some paid corporate support, but it has by no means been constant, or included large teams. At the same time in the late 90ies, open source was really starting to take off in general. Programmers were making all kinds of progress, and had begun to make Linux into what is today the world's most widely used server platform, and laying the groundwork for the KDE and Gnome desktops. While these may still not be widely used, they are for the most part very polished systems, and leaps and bounds better than what passed for the 'Unix desktop' experience in the 90ies. One of the key bits of work that was added to Tk was to make it look pretty good on Microsoft Windows systems. This was in an time when the "enterprisey" folks were turning away from Unix in the form of AIX, Solaris, HPUX, et al. and taking up NT as the platform of choice, so it was in some ways sensible to make Tk work well there, and in any case as a cross platform GUI toolkit, it ought to work well there in any case. And, on the Unix side, Tk emulated the expensive, professional Motif look and feel that serious Unix programmers used. What could go wrong? As Gnome and KDE continued to mature, though, what would become one of Tk's major (in my opinion) marketing blunders took root. I have it on good authority, from someone who was there in the office, that the Scriptics guys working on Tcl and Tk viewed Gnome and KDE (and the Gtk and Qt toolkits) as not really worth their while. To be fair, since Tk has always been under a liberal BSD style license, the Qt toolkit has always been "off limits". Still, though, the attitude was that Tk was a standalone system, and since it ran on pretty much any Unix system, it didn't need to bother with Gnome or KDE. Gradually, though, as more and more people used Gnome and KDE exclusively on Linux, the Tk look and feel began to look more and more antiquated, a relic from the 1990ies when Motif (which has since pretty much disappeared) was king. Tk applications started to really stand out by not looking at all like the rest of the operating system. And, while Linux may not be responsible for a vast portion of the world's desktops, it is widely used by developers, who were turned off by the increasingly creaky look of the Tk applications they saw. Tk is and was actually a fairly flexible system, and it would have been possible to tweak the look and feel to make it look a bit better on Linux, without even doing any major work. Maybe not perfect, but certainly better looking. Nothing happened, though. Another problem was that Tk and Tcl made it so easy to create GUIs that anyone could, and did, despite, in many cases, a complete lack of design skills. You can't particularly blame the tools for how they're used, but there was certainly a cultural problem: if you read most of the early Tcl and Tk books, and even many of the modern ones, there are hundreds of pages dedicated to exactly how to use Tk, but few to none explaining even basic user interface concepts, or even admonitions to the user to seek out that knowledge prior to attempting a serious GUI program. The end result is that a lot of Tk programs, besides just looking "old fashioned" had fairly poor user interfaces because they were made by programmers who did not have a UI/design culture. Contrast that with Gnome and KDE, which have made a point of focusing on how to make a good GUI for their systems, complete with guidelines about how applications should behave. It may have taken them some time to get things right, but they have done a lot to try and instill a culture of creating high quality, well-integrated GUI's that are consistent with the system where they run. Lately, there has been a lot of work to update the Tk look and feel, and it has finally started to bear fruit. However, in terms of marketing, the damage has already been done: the image of "old, crufty Tk" has been firmly planted in countless developers' minds, and no amount of facts are going to displace it in the near future. Another problem Tcl faced, as it grew, was the tug-of-war between those wishing to see it small, light, and easy to distribute embedded within some other program, and those wishing it to become a "full-fledged" programming language, with lots of tools for solving every day programs. Unfortunately, that tug of war seems to have left it somewhere in the middle. Lua is probably more popular these days as an embedded language, because it is very small, and very fast, and doesn't have as much "baggage" as Tcl. Meaning, of course, that it doesn't do as much as Tcl either, but for a system where one merely wishes to embed a scripting language, without much 'extra stuff', Tcl's extra functionality is perhaps a burden rather than a bonus. On the other hand, while Perl was happily chugging along with their CPAN system for distributing code, giving users easy access to a huge array of add-on functionality, and Python was building up a "batteries included" distribution, that included a lot of very useful software straight out of the box. Tcl, on the other hand, chose to keep the core distribution smallish, and only lately has got some semblance of a packaging and distribution system, that is, however, run by ActiveState, and is (at least according to a cursory glance at the Tcl'ers wiki), not even fully open source. The lack of a good distribution mechanism, and, in the meantime, eschewing a larger, batteries-included main distribution left Tcl users with a language that, out of the box, did significantly less than the competition. Technically, a Python style "big" distribution would not have been all that difficult, so once again, I think this is a marketing problem: a failure of the Tcl Core Team to observe the "market", assess what users needed, and act on it in a timely manner. Somewhat related to the large Tcl vs small Tcl issue was one particular extension, or extensions to the language that was noticeably absent: a system for writing "object oriented" code. Tcl, at heart, will never be an OO language through and through, like Ruby or Smalltalk, but that doesn't mean that an OO system for it is not a useful way of organizing larger Tcl systems. Indeed, Tcl's syntax is flexible enough that it's possible to write an OO system in Tcl itself, or, optimizing for speed, utilizing the extensive C API in order to create new commands. Over the years, a number of such systems have arisen, the most well-known being "Incr Tcl" (a play on the incr command, which is akin to += 1 in languages like C). However, none of these extensions was ever included with the standard Tcl distribution or somehow "blessed" as the official OO system for Tcl. This meant that a newcomer to Tcl wishing to organize their code according to OO principles had to pick a system to use from several competing options. And of course, newcomers are the least able to judge a complex feature like that in a language, making it a doubly stressful choice. Furthermore, even experienced Tcl programmers who wanted to share their code could not utilize an OO system if they wanted their code to work with just standard Tcl. Also, if their code had a dependancy on some OO system, it would require the user to download not only the extension in question, but the OO system it was built on, which, naturally, might conflict with whatever OO system the user had already selected! As of Tcl 8.6, thanks to the work of Donal Fellows, Tcl is finally integrating the building blocks of an OO system in the core itself, but this effort is probably something like 10 years too late. Some other more or less minor things that have taken too long to get integrated in the Tcl or Tk distributions include the PNG format (still not there in a production release of Tcl), a readline-based command line (Tkcon is nice, but not a replacement for simply being able to type "tclsh" and get a nice, functional shell like Python, Ruby and most other languages have. This could easily lead to a bad first experience for someone trying out Tcl). Tcl also took too long to integrate a first-class hash type (accessed with the 'dict' command), which only appeared in 8.5. Its "arrays" aren't bad, but don't quite have the full power of a hash table as dict implements them. Once again, the code to do these things was/is out there, it has just been a matter of integrating it into Tcl and Tk, which has been a slow process. One actual technical problem that Tcl faces is the concept that all values must be representable as a string. This is more or less ok for things like lists, hash tables or numbers, but is problematic when the user wishes to represent a value that simply isn't a string. A basic example is a file handle, which at the C API level is a FILE*. How does Tcl get around this? It keeps an internal hash table with a Tcl-script accessible string, such as "file5" that points to a FILE * value that is used internally by file commands. This works pretty well, but there is a big "but": since you can compose a string like "file5" at any time, that must be able to access the actual file pointer, you can't do any sort of "garbage collection" to determine when to clean things up automatically. Other languages have explicit references to resources, so the program "knows" when a resource is no longer referenced by the rest of the program, and can clean it up. Therefore, the programmer must explicity free any resources referenced this way. This explanation is simplifying things somewhat, but it is something I view as a technical problem with Tcl. If you've been following along, you've noticed a lot of "these days" and "recently". That's because Tcl is still very actively developed, with a lot of new ideas going into it. However, if you look at the release dates, it seems that after Ajuba was sold off, and Ousterhout pretty much abandoned an active role in the language for good, placing it in the hands of the Tcl Core Team, there was a lull in the momentum, with Tcl 8.5 taking 5 years to be released. This is actually, in my opinion, an interesting phenomenon in languages: you risk hitting some kind of local maximum when your language is popular enough to have a lot of users who will be angry if things are changed or accidentally broken in the course of big upheavals. So you have to slow down, go carefully, and not rock the boat too much. On the other hand, there is an opportunity cost in that newer languages with less to lose can race ahead of you, adding all kinds of cool and handy new things, or simply fix and remove "broken" features. Erlang is another system that has, in my opinion, suffered from this problem to some degree, but this article is long enough already! Once again, though, not really a technical issue, but a problem with how the code was managed (and not an easy one to solve, at that). A Tcl failure that I was personally involved with was the web infrastructure. What went on to become Apache Rivet was one of the first open source Apache/Tcl projects, and was actually quite a nice system: it was significantly faster than PHP, and of course made use of Tcl, which at the time had a large library of existing code, and could be easily repurposed for projects outside the web (or the other way around: non-web code could be brought in to a web-based project). One thing I ought to have done differently with the Apache Rivet project was listen to the wise advice of Damon Courtney, my "partner in crime" on the project, who wanted to see Apache Rivet have a fairly "fat" distribution with lots of useful goodies. Rails and Django, these days, have shown that that's a sensible approach, rather than relying on lots of little extensions that the user has to go around and collect. The code was out there, I should have helped make Rivet do more "out of the box". A problem that is and it isn't: the syntax. Tcl's syntax is amazingly flexible. Since everything is a command, you can write new commands in Tcl itself - and that goes for control structures, too! For instance, Tcl has a "while" command, but no "do ... while". It's very easy to implement that in Tcl itself. You simply can't do that in most "everyday" languages. However, this comes at something of a "cost". The syntax, for your average programmer who doesn't want to go too far out of their comfort zone, is perhaps a little bit further afield from the C family of languages than they would prefer. Still though, a "human" problem, rather than a technical one. Perhaps, sadly, the message is that you'd better not "scare" people when introducing a new language, by showing people something that doesn't look at least a little bit familiar. Conclusions? First and foremost, that, gradually, Tcl and Tk continue to be improved. However, if one visits developer forums, there are also a lot of negatives associated with the Tcl and Tk "brands", and I am not sure if it will be possible to rectify that. So what can we learn from the rise and subsequent "stagnation" of Tcl?

• Success in the first place came from doing one particular thing very well, and making it a lot easier than other existing systems at the time. That's a good strategy.
• Not staying up to date can be deadly. Of course it can be tricky to know what's a genuine trend, and what's just a fad, in this industry, and picking the right things to stay up to date with can be tricky. That said, there are a number of areas where Tcl and Tk failed to follow what became very clear directions until way too late.
• Do your best not to get trapped between existing users who don't want to rock the boat, and don't lose your agility and ability to iterate with the system you're developing. Long delays between releases can be deadly.
• Don't lose touch with your "roots". In this case, the open source community that is a "breeding ground" for new developers and projects. Tcl and Tk became passe in that environment, which has led to its lack of adoption for new projects not only in the world of open source, but in businesses as well.
• Don't isolate yourself: Tcl and Tk stopped appearing at a lot of the open source conferences and events and in magazines/books/articles online, either because with no figurehead/leader to invite there was less interest in speakers and authors, or because the rest of the Tcl Core Team wasn't particularly engaged, or for whatever other reason. This created something of a negative feedback loop where Tcl and Tk were things associated with the past, rather than something currently talked about and discussed.

Russ Albery has described why he doesn t support comments on his blog [1]. I respect his opinion and I m not going to try and convince him to do otherwise. But I think it s worth describing why I want comments on my blog and feel that they are worth having for many (possibly most) other blogs. Types of Blog The first thing to consider is the type of post on the blog. Some blogs are not well suited to comments. I have considered turning off comments on my documents blog [2] because it gets a small number of readers and is designed as reference material rather than something you might add to a public Planet feed or read every week as it has a small number of posts that are updated. So conversations in the blog comments are unlikely to happen. One thing that has made me keep comments open on my documents blog is the fact that I am using blog posts as the main reference pages for some of my projects and some people are using the comments facility for bug reports. I may make this the main bug reporting facility I will delete the comments when I release a version of the software with the bugs fixed. One particular corner case is a blog which has comments as a large part of it s purpose. Some blogs have a regular open thread where anyone can comment about any topic, blogs which do such things have the owners act more like editors than writers. One example of this is the Making Light blog by Teresa and Patrick Nielsen Hayden [3] who are both professional editors. The next issue is the content of the post. If I was to create a separate blog for authoritative posts about SE Linux then there wouldn t be much point in allowing comments, there are very few people who could correct me when I make a mistake and they would probably be just as happy to use email. When I write about issues where there is no provably correct answer (such as in this post) the input of random people on the net is more useful. Another content issue is that of posts of a personal nature. Some people allow comments on most blog posts apart from when they announce some personal matter. I question the wisdom of blogging about any topic for which you would find comments intolerable, but if you are going to do so then turning off comments makes sense. Finally there is the scale of the blog. If you don t get enough readers to have a discussion in the comments then there is less benefit in having the facility turned on the ratio of effort required to deal with spam to the benefit in comments isn t good enough. In his FAQ about commenting [4] Russ claims that controlling spam can take a tremendous amount of time or involve weird hoop-jumping required for commenters . I have found the Block Spam by Math [5] Wordpress plugin to be very effective in dealing with the spam, so for this blog it s a clear benefit to allow comments. Since using that plugin my spam problem has decreased enough that I now allow comments on posts which are less than 1 year old previously comments were closed after 90 days. The plugin is a little annoying but I changed the code to give an error message that describes the situation and prevents a comment from being lost so the readers don t seem too unhappy. The Purpose of Comments Russ considers the purpose of comments to be meaningfully addressed to the original post author or show intent to participate in a discussion . That s a reasonable opinion, but I believe that in most cases it s best if comments are not addressed to the author of the post and are instead directed towards the general readers. I believe that participating in a discussion and helping random people who arrive as the result of a Google search are the main reasons for commenting. For my blog an average post will get viewed about 500 times a year and the popular posts get viewed more than 200 times per month, so when over the course of a year more than 1000 people read the comments on a post (which is probably common for one of my posts) then 99.9% of readers are not me and commentators might want to direct their comments accordingly. Of course a comment can be addressed at the blog author so the unknown audience can enjoy watching the discussion. For some of my technical posts I don t have time to respond to all comments. If I have developed a solution to a technical problem that is good enough I may not feel inclined to invest some extra work in developing an ideal solution. So when a reader suggests a better option I sometimes don t test that out and therefore can t respond to the comment. But the comment is still valuable to the 1000+ other people who read the comment section. So a commentator should not assume that I will always entirely read a comment on a technical matter. Comment threads can end up being a little like mailing lists. I don t think that general discussions really work well in comment threads and don t aim for such things. But if a conversation starts then I think you might as well continue as long as it s generally interesting. Generally for most blogs I think that providing background information, supporting evidence, and occasionally evidence of errors is a major part of the purpose of blog comments. But entertainment is always welcome. I would be happy to see some poems in the comments section of technical posts, sometimes a Limerick or haiku could really help make a technical point. Political blog posts can be a difficult area. Generally the people who feel inclined to write political blog posts or comment on them are not going to be convinced to entirely change course, but as there are many people who can t seem to understand this fact a significant portion of the comments on political blog posts consist of different ways of saying you re wrong . The solution to this is to moderate the comments aggressively, too many political blogs have comments sections that are all heat and no light. I m happy for people to go off on tangents when commenting on my political posts or to suggest a compromise between my position and their preferred option. But my tolerance of comments that simply disagree is quite small. Generally I think that blogs which directly advocate a certain political position should have the comments moderated accordingly, people will read a site in the expectation of certain content and I believe that the comments should also meet that expectation to some degree. Comments on political posts can provide insights into different points of view and help discover compromise positions if moderated well. How to provide Feedback Russ advocates commenting to the blog author via email it is now the only option he accepts. My observation is that the number of people who are prepared to comment via email (which generally involves giving away their identity) is vastly smaller than those who use Blog comment facilities. This means that you will miss some good comments. One of the most valuable commentators on my blog uses the name Anonymous and has not felt inclined to ever identify themself to me, I wouldn t want to miss the input of that person and some of the other people who have useful things to say but who don t want to identify themself. I have previously written about how not all opinions are equal and anonymous comments are given a lower weight [6]. That post inspired at least one blogger to configure their blog to refuse anonymous comments, it was not my intent to inspire such reactions (although they are logical actions based on a different opinion of the facts I presented). I believe that someone who is anonymous can gain authority by repeatedly producing quality work. Another option is for people to write their own blog posts referencing the post in question. I don t believe that my core reader base desires short posts so I won t write a blog post unless I have something significant to say. I expect that many other people believe that the majority of their blog comments would not meet the level of quality that their readers expect from their posts (posts are expected to be more detailed and better researched than comments). As an aside forcing people to comment via blog posts will tend to increase your Technorati rating. :-# A final option is for people to use services such as Twitter to provide short comments on posts. While Twitter is well designed for publishing short notes the problem with this is that it s a different medium. There are many people who like reading and discussing blog posts but who don t like Twitter and thus using a different service excludes them from the conversation. For my blog I prefer comments for short responses and blog posts for the longer ones. If you write a blog post that references one of my posts then please enter a comment to inform me and the readers of my blog. Email is not preferred but anyone who wants to send me some is welcome to do so. If this post inspires you to change your blog comment policy then please let me know. I would like to know whether I inspire people to allow or deny blog comments.

• [1] http://www.eyrie.org/~eagle/journal/2010-03/008.html
• [2] http://doc.coker.com.au/
• [3] http://nielsenhayden.com/makinglight/
• [4] http://www.eyrie.org/~eagle/faqs/comments.html
• [5] http://wordpress.org/extend/plugins/block-spam-by-math/
• [6] http://etbe.coker.com.au/2008/09/13/not-all-opinions-are-equal/

ACOSS, the Atlantic Canada Open Source Showcase, interviewed me this month. I talked about the Debian Eee PC project.

The Claim I have seen it claimed that renting a virtual server can be cheaper than paying for electricity on a server you own. So I m going to analyse this with electricity costs from Melbourne, Australia and the costs of running virtual servers in the US and Europe as these are the options available to me. The Costs According to my last bill I m paying 18.25 cents per kWh that s a domestic rate for electricity use and businesses pay different rates. For this post I m interested in SOHO and hobbyist use so business rates aren t relevant. I ll assume that a year has 365.25 days as I really doubt that people will change their server arrangements to save some money on a leap year. A device that draws 1W of power if left on for 365.25 days will take 365.25*24/1000 = 8.766kWh which will cost 8.766*0.1825 = $1.5997950. I ll round that off to $1.60 per Watt-year. I ve documented the power use of some systems that I own [1]. I ll use the idle power use because most small servers spend so much time idling that the time that they spend doing something useful doesn t affect the average power use. I think it s safe to assume that someone who really wants to save money on a small server isn t going to buy a new system so I ll look at the older and cheaper systems. The lowest power use there is a Cobalt Qube, a 450MHz AMD K6 is really small, but at 20W when idling means a cost of only $32 per annum. My Thinkpad T41p is a powerful little system, a 1.7GHz Pentium-M with 1.5G of RAM, a 100G IDE disk and a Gig-E port should be quite useful as a server which now that the screen is broken is a good use for it. That Thinkpad drew 23W at idle with the screen on last time I tested it which means an annual cost of $36.80 or something a little less if I leave the screen turned off. A 1.8GHz Celeron with 3 IDE disks drew 58W when idling (but with the disks still spinning), let s assume for the sake of discussion that a well configured system of that era would take 60W on average and cost $96 per annum. So my cost for electricity would vary from as little as $36.80 to as much as $96 per year depending on the specs of the system I choose. That s not considering the possibility of doing something crazy like ripping the IDE disk out of an old Thinkpad and using some spare USB flash devices for storage I ve been given enough USB flash devices to run a RAID array if I was really enthusiastic. For virtual server hosting the cheapest I could find was Xen Europe charges E5 for a virtual server with 128M of RAM, 10G of storage and 1TB of data transfer [2], that is $AU7.38. The next best was Quantact who charges $US15 for a virtual server with 256M of RAM [3], that is $AU16.41. Really for my own use if I was paying I might choose Linode [4] or Slicehost [5], they both charge $US20 ($AU21.89) for their cheapest virtual server which has 360M or 256M of RAM respectively. I ve done a lot of things with Linode and Slicehost and had some good experiences, Xen Europe got some good reviews last time I checked but I haven t used them. The Conclusion When comparing a Xen Europe virtual server at $88.56 per annum it might be slightly cheaper than running my old Celeron system but would be more expensive than buying electricity for my old Thinkpad. If I needed more than 128M of RAM (which seems likely) then the next cheapest option is a 256M XenEurope server for $14.76 per month which is $177.12 per annum which makes my old computers look very appealing. If I needed more than a Gig of RAM then my old Thinkpad would be a clear winner, also if I needed good disk IO capacity (something that always seems poor in virtual servers) then a local server would win. Virtual servers win when serious data transfer is needed. Even if you aren t based in a country like Australia where data transfer quotas are small (see my previous post about why Internet access in Australia sucks [6]) you will probably find that any home Internet connection you can reasonably afford doesn t allow the fast transfer of large quantities of data that you would desire from a server. So I conclude that apart from strange and unusual corner cases it is cheaper in terms of ongoing expenses to run a small server in your own home than to rent a virtual server. If you have to purchase a system to run as a server (let s say $200 for something cheap) and assume hardware depreciation expenses (maybe another $200 every two years) then you might be able to save money. But this also seems like a corner case as the vast majority of people who have the skills to run such servers also have plenty of old hardware, they replace their main desktop systems periodically and often receive gifts of old hardware. One final fact that is worth considering is that if your time has a monetary value and if you aren t going to learn anything useful by running your own local server then using a managed virtual server such as those provided by Linode (who have a really good management console) then you will probably save enough time to make it worth the expense.

• [1] http://doc.coker.com.au/environment/computer-power-use/
• [2] http://www.xeneurope.co.uk/packages
• [3] https://www.quantact.com/signup.cgi
• [4] http://www.linode.com/
• [5] https://manage.slicehost.com/customers/new
• [6] http://etbe.coker.com.au/2010/01/18/why-internet-access-in-australia-sucks/

Note: this post written on March 20-21 and posted after our return.
(two women looking into the crypt at St. George s Basilica) We ve had a good couple of days in Prague. The city definitely feels more, well, foreign than Germany and that is perhaps accentuated by the fact that I don t know any Czech at all, while I know some basic German. It s been slow going at times, and surprisingly easy at others. Despite my lack of knowledge of Czech, I d say communicating here has been roughly as easy as in Germany. That is perhaps partially due to the fact that, of the places where we ve needed to communicate, we are either making simple requests (buying bread at a bakery) or the people we re talking to know some basic English. (Or, in one case, a guard at a museum at the Prague Castle complex used German to ask me to check a bag at the coat check, mildly surprising me and confusing Terah when I started to comply with instructions she didn t understand, and didn t know how I did.) The very first time we had a situation where it was a bit difficult to communicate, in the bakery, I got into my difficult to communicate mode and accidentally slipped in a couple of German words. Oops. Terah was laughing at me later, and commented that the store owner might have also been laughing at me or perhaps at his employee that also accidentally slipped into basic German mode. On Friday, we visited Vy ehrad Castle, the one that nobody that visits Prague seems to know about. That is perhaps because the palace/castle part of the complex has been mostly destroyed (but we did know that before going there.) It is in a nice, quiet, and beautiful park, and has the beautiful and old Basilica of Saints Peter and Paul, as well as a large ornate cemetery. Then we visited two iconic Prague places: V clavsk n m st (Wenceslas Square) and Starom stsk n m st (Old Town Square). Both were beautiful. And, unfortunately, also packed with tourists and made-in-China plastic trinket shops. There I got my first clue that large tour groups tend to have a detrimental effect on any free site in Prague. They come in, the guides yell, they clog up things, and also generally miss the sites of true interest because buying tickets to them makes the price of the tour uncompetitive. On Saturday, we took the tram out to Pra sk hrad (Prague Castle) the one that everybody knows about. We got there at about 8:15, and although the grounds are open, most of the buildings weren t open until 9. As a result, we had 45 minutes almost to ourselves in the nearly-empty castle complex. We could walk around on the giant squares, take some photos, and generally enjoy a crisp and quiet morning. At 9, it was still pretty empty and we went into the ticket offices to buy our tickets. By the time we got out a few minutes later, it was packed mostly due to the arrival of innumerable tour groups from all over Europe and, apparently, Japan. We went to the Star kr lovsk pal c (Old Royal Palace) first, since I knew from their website that it would close at noon due to a visit from Prince Charles. That was a beautiful building, and it s amazing to read about the features of it that are centuries old or even almost a thousand years old. The Vladislavsk s l (Vladislav Hall) and chapel particularly caught my eye. Underneath the palace is a museum, including some 1000-year-old jewelry and flooring, and some clothing that is several hundred years old recoverd from burial plots.
(Vladislav Hall) Next, we went to the iconic (and free) Katedr la svat ho V ta (St. Vitus Cathedral). Our audioguides fortunately allowed us to bypass the long line, and we could step inside at a side door. That was one of many times in Europe I stepped inside a building, and suddenly came to a stop with a wow . That building is every bit as much impressive as it is made out to be, even crowded as it was. We also went to Bazilika Sv. Ji (St. George s Basilica), which one of the guides described as ancient . It was another wow moment, and it felt like the oldest church we were in yet. I think it probably was, actually; last rebuilt in 1142. For lunch, we asked for a recommendation from our hotel. They suggested one place, which we walked to. It was a nice easy walk down some Prague side streets, but the restaurant and all the others along our walk were closed on Saturday. We eventually made our way back to the hotel and asked for a new recommendation, which was successful this time. Terah ordered some ribs, while I ordered a more traditional Czech goulash, which happened to be served in a bread bowl. A minute later, the waiter brought Terah a fork and knife. And he brought me a bowl of water with a slice of lemon, and announced wash for you. That was a surprise, and a bit puzzling one at that. Turns out that eating bread that had stew served in it is indeed a bit messy, and having some water to clean up with is indeed helpful. We met up with Anna from Leipzig and one of her Czech friends for dinner Saturday night. We found a nice local Czech place. I had ham with sauerkraut in a folded potato cake. It was excellent, and the total bill for Terah and me came to 235 Kc or about $12.50. We had a nice walk back to the hotel in the crisp, dark evening. Sunday morning we had breakfast at our hotel the only time we ate a meal at a hotel this whole trip then got on the tram, the metro, and the bus to the airport. Total cost for that trip for two: 52 Kc, or about $2.75. Far cheaper than a taxi. One weird thing happened to us in Prague. We were riding the tram towards downtown, and as we would be on it for several stops, Terah was sitting. I was standing as there wasn t an available seat for me. Terah and I were both looking out windows, until Terah was startled because her arm was wet. She looked around and it turned out a middle-aged woman had spit on her, and was glaring at her. We never did figure out why. About all we can think of is maybe someone else, such as a very old person, had gotten aboard but Terah hadn t noticed and therefore didn t offer to give up her seat. That was probably the only real rude gesture towards us on the entire trip. We ran the story by Anna s friend (the native Czech) and she was as surprised and baffled as we were. As I wrap this up, we re sitting at our gate in Prague waiting for our flight to Munich. In this airport, in an out of the way corner on the very lowest floor, I spotted only the second drinking fountain I ve seen in Europe this entire time and also perhaps the continent s most expensive cup of coffee. After we get to Munich, it s a flight to Chicago, another to Indianapolis, and finally a drive home Monday.

I ve been eagerly looking forward to the release of Xero Personal which has been heavily promoted by Xero and BNZ (as MoneyMap) for the last few months. Unfortunately my first impressions of the product today are extremely underwhelming. Xero Personal is definitely not worth anywhere close to $5/month for me at this point in time and I m unlikely to even keep using the free trial. To set the context for that statement, Xero Business set the bar high. I first used the original version of Xero while it was still in beta and even then it was clear that it was an application that took accounting to a new level and would provide an order of magnitude improvement in how I maintained the accounts for our business. That promise held true once we started paying for it, even though the cost of Xero is more than 10% of our annual expenses, the time and hassle it saves makes it a worthwhile investment. By contrast today s release of Xero Personal offers nothing new above existing personal finance websites or desktop packages and would take me extra time to use as it fails to handle many of the basic transactions that a normal household will encounter. The way Xero Personal works is by having you manually upload your bank statements (the automatic import functionality that is so useful in the business version of Xero has been restricted to BNZ MoneyMap customers only). For each transaction you are asked to provide two pieces of information. The first is a category which serves as a basic form of account to track expenses and income. For each category you can set a spending or saving goal which Xero will help you track progress towards. The second is a name to identify the other party in the transaction. Xero Personal comes pre-loaded with some fairly generic categories. Annoyingly you re restricted to no more than 8 additional custom categories and the names associated with each transaction are are simple strings you can t link a transaction to another account or entity. To represent a transfer you need two separate transactions, one in each account, which you assign to the special category Transfer so that Xero knows to essentially ignore it. Nothing links the transactions together or ensures that the values balance. In addition to the basic categorisation functionality the application also attempts to track your assets and liabilities (bank accounts and credit cards show up automatically) so that it can compute your net worth. Unfortunately as soon as you try and use this you hit the problem that there is no way to link transactions from your accounts back to your assets and liabilities. This means unless you regularly and manually update your assets and liabilities the net worth calculation only takes into account changes in your cash position and becomes blatantly incorrect. As an example, take the common case of a household with a weekly mortgage (or other loan) repayment. You want the weekly payment to decrease the balance of your current account, increase the balance of your interest expense category and decrease the value of your mortgage liability. Your net worth should decrease by the value of the interest expense only, as the decrease in the value your mortgage liability offsets the remainder of the decrease in the value of your current account. Xero Personal doesn t come close to being able to handle this example today. The ability to split payments to different categories has also been left out (even though it s present in Xero Business and therefore presumably in the underlying engine) so your only option is to categorise the entire payment as a mortgage or housing expense, decreasing your net worth by the full value of the payment. Even if you could split the payment between two categories, one for the interest and one for the principal the inability to link the category for the principal to the liability account means the net worth calculation will still be incorrect. Maybe I m being to hard on this newly released product? It is a SaaS application after all and Xero has an excellent history of releasing regular updates to the business version of Xero. The reason I m so surprised and disappointed by this initial release is that it essentially lacks any double-entry accounting support many of the missing features are core functionality that is already implemented in the accounting platform that supports the business version. Assuming that Xero Personal is built on the same platform (and that would be the obvious choice wouldn t it?) the fact that Xero Personal has been released and is being heavily promoted without these features (compared to the initial version of Xero Business which was fully functional and obviously awesome even in beta) suggests to me that it s a conscious decision to significantly limit the scope and usefulness of the application rather than simply a limit on what could be implemented before the initial release. I sincerely hope that I m wrong and that the coming months bring significant improvements to the functionality of Xero Personal, but until it can support common transactions like mortgage repayments correctly I won t be using it or recommending it to anyone.

Hector Oron:

Secondly, I was wondering how Debian could make it easier for people to contribute than other (derivatives and non-derivatives) distributions. I came up with a really nice draft howto[1] which I would like to bring up to your attention, so the basic question would be what do you think you could do to make contributions paths easier (take in account not all teams, groups follow such community guidelines)

Human beings are not computers, so I find that applying HOWTOs to them to be misguided at best. As for enforcing a set of arbitrary community guidelines, I would not do that. Frank Lin PIAT:

planet.d.o has became one of the most visible media for Debian, if not the most visible one. Do you think it is a good thing?

I consider it neutral. If people start thinking of blogs or microblogging as important though, I think we might have a problem. I am in favor of our informal policy to never post anything important on blogs unless it is merely a copy of something communicated properly on an official channel. This includes anything that would go into our packages. Consequently I do not think it a valuable goal to respect copyright law by enforcing DFSG-free licenses on blogs, whether they are aggregated or not. Kumar Appaiah:

One of the questions which I've not yet seen exactly in the discussions is on the transparency in the maintenance of non-core but "important" packages, such as python, wherein the maintenance of the package and policy (till a short while ago) has been, poor at best, and we've had near zero communication from the maintainer(s) for over a year. This has led some parts of the "community" (Debian Python, in this case) to knock the doors of the tech-ctte[1] (recommended reading, unless you have done so already).

I think that is a failure of the entire community that the situation has even come to this point. In other analogous situations, the package would have been hijacked by now and the situation resolved. I think it would be appropriate for the DPL either to step in and mediate situations like this before they get anywhere near the tech-ctte, or to delegate someone to do the same. I think it would be equally appropriate for the people involved to resolve this themselves. Of course all of this should be open.

subj. don t mix just upgraded a simple Ubuntu 9.10 to Ubuntu 10.04 and it failed to boot. After careful examination, it looks that something replaced the munt line of my NTFS partition in the /etc/fstab and claimed that it is a VFAT partition and mountall that is run during boot gets very, very confused if presented with such dillema, so mach in fact that it hangs and stops the whole boot sequence. The workaround is to boot from a livecd/usb and comment out all NTFS and VFAT lines in /etc/fstab. If that still does not help replace the large UUIDs with device names back. Still have not reported the bug as there look to be several regression in NTFS support, the upgrader corrupting the fstab file and mountall incorrectly handling a case of an unmountable file system. P.S. Also my Firefox would not start that was solved by removing the sessionstore* files in my profile.

I have been at Amazon.com for a very short while (I have only gotten one paycheck from them so far), but long enough for first impressions to have settled. Dress is casual, Parking is limited. Cafeteria food is merely OK, and is not free. There is a very flat structure at Amazon. The front line work is done by one-or-two pizza teams size measure by the number of large pizzas that can feed the team. Individual experiences with the company largely depend on what team you happen to end up with. I think I lucked out here. I get to work on interesting and challenging problems, at scales I had not experienced before. There is an ownership culture. Every one including developers get to own what they produce. You are responsible for our product down to carrying pagers in rotation with others on your team, so that there is someone on call in case your product has a bug. RC (or customer impacting) bugs result in a conference call being invoked within 10-15 minutes, and all kinds of people and departments being folded in until the issue is resolved. Unlike others, I find the operations burden refreshing (I come from working as a federal government contractor). On call pages are often opportunities to learn thing, and I like the investigation of the current burning issue du jour. I also like the fact that I get to be my own support staff for the most part, though I have not yet installed Debian anywhere here. While it seems corny, customer obsession is a concept that pervades the company. I find ti refreshing. The mantra that it s all about the customer experience is actually true and enforced. Whenever a tie needs to be broken on how something should work the answer to this question is usually sufficient to break it. Most other places the management was responsible for, and worried about budgets for the department this does not seem to be the case for lower to middle management here. We don t get infinite resources, but work is planned based on user experience, customer needs, and technical requirements, not following the drum beat of bean counters. The focus is on the job to be done, not the hours punched in. I can choose to work from home if I wish, modulo meetings (which one could dial in to, at a pinch). But then, I have a 5 mile, 12 minute commute. I have, to my surprise, started coming in to work at 7:30 in the morning (I used to rarely get out of bed before 9:30 before), and I plan on getting a bike and seeing if I can ride my bike to work this summer. All in all, I like it here.

For me, this is the year of the conference, mostly because I am helping to organize Debconf10, which so far has been quite fun, though I know that as we approach August, the planning will become more all encompassing. It is also the case that my piece on the hacker conference has finally been published by Anthropological Quarterly (and thanks to those who help be hunt some of the mistakes and typos). If you have university access you can get it via the traditional (and closed) routes but you can find a copy via my department web page or here. For those that did not catch my last post about this piece, it is a rare specimen for academia: a feel good piece or so I think and so I have been told. If you have been to Debconf before and liked it, it is a good piece for reminiscing. If you have not been and are thinking of going, I would also recommend it (and btw the deadline for the end of registration is fast approaching. Now that I am organizing the event, I know the experience of the conference will feel, look, and be quite different from what I have portrayed in the article. So maybe at the end of August, when I am worn, torn, and deflated from months of hard work, I will write a piece poking fun at my feel-good description, a nice counter-weight to what is admittedly a bit of a romantic piece.

RCBW - #25 Last (long) week has finally passed: first in Geneve visiting Gismo, then in Sierre/Crans-Montana to present a paper at SAC 2010, then back in Paris for half a day before a day in Bruxelles for the 2nd year Mancoosi project review. (And of course campaigning has always been going on ...) All went fine and I can finally relax a bit for a week-end back "home" (i.e. Paris). Regarding RCBW, it looks like that in the past 2 months I've stabilized around 3 issues per month, which makes me happy nevertheless. Without any further ado, here are this weekissue's squashes:

• Debian bug #570727 - xmldiff - fix tree comparison (on i386), patch by Daiki Ueno
• Debian bug #574640 - turbogears2 - ensure compatibility with new routes, patch by Piotr O arowski
• Debian bug #574083 - wwwoffle - add missing dep on net-tools, needed by init.d script
• Debian bug #555036 - bash-completion-lib - RM/RoQA/ROM (see Debian bug #575260)
• Debian bug #574228 - mediamate - request RM/RoQA (see Debian bug #575508)
• Debian bug #574025 - mathgl - switch to octave3.2 (bonus: QA upload w/ proper orphaning)
• Debian bug #482790 - elserv - fix emacs deps wrt current emacsen flavours (malus: fought with cdbs' DEB_AUTO_UPDATE_DEBIAN_CONTROL)

Random points:

• Up and downs in the "RCBW community": gregoa rock's (as usual) whereas Lucas is subverting the rules! (bad Lucas, bad).
• Some of the side comments by Gregor made me realize that I have probably chosen the wrong tagline/acronym for RCBW, as the point is not really keeping a sustained average (or feel bad about not keeping it), but rather doing that "constantly" in some available Debian time slots, as well as trying having others do the same.
• Clint has commented on BSPs also mentioning RCBW. (I mention en passant that I've never claimed RCBW to be innovative, as my kudos show; my memory is short though, I'll be happy to integrate the list with pointers to similar initiative more far in the past.) The idea of newbie/teaching-oriented BSPs is just wonderful, it only needs some motivated people to (continue) organizing them.

Diagnostic Changes for Autism Spectrum Disorders Currently Asperger Syndrome (AS) is one of a group of conditions that are grouped into the category Autism Spectrum Disorders (ASD). The American Psychiatric Association plans to merge Asperger s Disorder into Autism Spectrum Disorder [1] in version 5 of their Diagnostic and Statistical Manual (DSM). Apparently a primary reason for the change is the difficulty in assessing people into the various categories (AS, Autism, and PDD-NOS) and some variation in diagnosis between regions. Professor Simon Baron-Cohen (a leading researcher on Autism and Asperger Syndrome) wrote an insightful article about this for the New York Times [2]. He suggests that while genetic research about the causes of Autism Spectrum Disorders (ASDs) is in progress there should be no change. If it turns out that AS and Autism have the same genetic cause then that would be good evidence to combine them into a single diagnostic category. If however they turn out to have different genetic causes then they would need different categories and he suggests that changes should be delayed until this issue is resolved. Simon also raises the issue of the status of people who have already been diagnosed, this is one of the social issues relating to a change in diagnostic criteria. Social Issues related to Diagnosis Unlike some disorders listed in the DSM, many (possibly most) people with AS really care about such things. I think that a common reaction to being diagnosed with Aspergers is to make the study of ASDs a Special Interest , which therefore makes it impossible to ignore what the psychologists are doing in this regard. The biggest problem with changing the diagnostic criteria in this regard is that AS has a good reputation. Some people even think that it s generally a good thing and seem to imagine that every child who is diagnosed with it will end up working for Google! This means that parents will be less likely to reject a diagnosis and therefore will be more likely to try and create a good environment for their child and seek appropriate therapies (such as social skills training and occupational therapy). I expect that a child who is diagnosed as Autistic but who doesn t obviously conform to the worst stereotypes will likely have their parents reject the diagnosis which will lead to a bad result for everyone concerned. The contrary view in this issue is that people who are on the spectrum but who insist that they aren t Autistic are prejudiced and they should embrace the Autism Spectrum label as a measure of solidarity [3], while that s a reasonable point it s not going to happen in the short term. Also there is the issue of adult diagnosis of AS, there are lots of adults who could benefit from being diagnosed and obstacles to such diagnosis (such as associating it with a label that is not well accepted such as Autism) are not going to do any good for anyone. Is Asperger Syndrome really that similar to Autism? Roy Richard Grinker (Professor of Anthropology) wrote a positive article for the New York Times about the diagnostic changes [4]. He seems to think that because in some cases it is difficult to distinguish the difference between Autism and AS they should be in a single diagnostic criteria. Based on that logic you could say that no-one should be diagnosed with an ASD because there is never a clear dividing line between the Neuro-Typical and those who are on the spectrum! Some people are clearly on the spectrum, some clearly aren t, and some are near the border. Roy cites his daughter and Temple Grandin as examples of Autistic people who have greater ability to relate to animals than someone who is Neuro-Typical (NT). I don t have any particular skills in terms of relating to animals. Animals have smaller brains than humans and have thoughts that are less complex and more related to short-term issues, this makes them easier to predict in some situations. I do have significantly better skills in figuring out how to operate machines than most NTs, and this doesn t appear to be uncommon among Aspies. I ve read some of the material that Temple Grandin has written and watched the video of her TED talk, and I get a strong impression that she isn t like me. Even the Aspies who are the least successful in terms of their career (IE quite unlike Temple Grandin) often seem to be like me, I can understand the way they think and recognise that the problems they face are similar to mine but merely more severe. It seems to me that there are significant personality differences between people who have an affinity for animals and those who have an affinity for machines, maths, and engineering. I wouldn t be surprised if it was discovered that Autism and AS had different genetic causes, and this might mean that someone could have both sets of genes. It is obvious that the dividing line between Autism and AS is not that clear. It also seems that part of the diagnosis as implemented by psychologists may be based on the ability to act like an NT and succeed by objective criteria IE earn a good salary in the case of adults. One thing that Roy does get right is that he notes that among people diagnosed with AS and Autism there are both high and low functioning individuals. One thing that Roy gets wrong is the implication that Autistic people can become Aspies. An adult who is assessed without background information on their childhood may get a different diagnosis. If someone was reassessed as an adult with the full facts about their childhood available then (barring DSM changes) the same diagnosis should be returned. Conclusion It appears that this DSM change is going through regardless of the opinion of the people who are affected. While there is a logical basis for giving more weight to researchers than to the research subjects (who are bound to be more biased) it seems that there are some things you can t properly understand unless you live them. When a good portion of the research subjects feel compelled to share their experiences with anyone who will listen it is disappointing that so few of the researchers appear to be listening.

• [1] http://www.dsm5.org/ProposedRevisions/Pages/proposedrevision.aspx?rid=97
• [2] http://www.nytimes.com/2009/11/10/opinion/10baron-cohen.html
• [3] http://chaoticidealism.livejournal.com/76484.html
• [4] http://www.nytimes.com/2010/02/10/opinion/10grinker.html

Note: this post written on March 19 for posting after we return. We arrived at Leipzig surprisingly about 5 minutes late on Wednesday morning. My friend Brad was at the Leipzig Hauptbahnhof (central stration) to meet us. As we walked through the city with him, he commented that I hadn t yet tried Currywurst, and there was a stand selling them with different levels of spiciness. I tried one and liked it; Terah was afraid to touch them. After a light lunch with Brad and Anna, we went back into town and saw the V lkerschlachtdenkmal (Monument to the Battle of the Nations). We were warned that it was weird and ugly. And when we arrived, I noticed that it was enormous. And, well, somewhat ugly. And, yes, weird. After that, we walked through the old trade fair grounds. Leipzig has a long history as a trade center, and after they built the new trade fair grounds, the old ones were reused for other things except for the old Soviet building, which is now both gaudy and abandoned. We picked up Fritzi, who is a very cute 4 years old, from preschool and returned to their house for supper. After that, Brad and I went back into town, intending to hear a reading at the old city pool. When we realized it was a different day, we walked around the city center for awhile and then had a beer at a yes combination cafe/laundromat. Thursday was our day to explore the city. Brad showed us a couple of buildings in the university, including the library, then dropped us off at St. Thomaskirche. That s the church where J. S. Bach was music director for many years, and was buried. Like so many, it was impressive in its height and history. Next we went to the Stasi museum. The Stasi were the feared and powerful East German secret police during the Communist times. The museum itself was housed in the former Stasi headquarters for Leipzig and was involved with the history of the overthrow of the Communists. The museum covered a lot of the history of the Stasi, including its frantic last days during the 1989 revolution. The level of spying on people was incredible and sophisticated, and they tried to destroy records as the overthrow of the government was imminent. One of the offices in the inner part of the building was left untouched from the Communist years, right down to the typewriter and coffee machine. After that, we went to the Altes Rathaus (old city hall or townhouse, built in 1556) to do a bit of shopping. Terah was wanting some souvenirs, and I had spotted a shop I thought she might like when walking through the city with Brad the night before. We had already bought some souvenirs at the Schloss Charlottenburg museum store in Berlin (some East German-style crosswalk fridge magnets, and a decorative egg), but wanted something a bit nicer for us and were on the lookout for gifts for others too. We wound up buying a wood carved church scene with a woven wheat tree for us, and another item for others. The shopkeeper spoke no English, and my German vocabulary is small, but we managed to communicate the question of whether or not she could wrap it up in a box for our trip home and she could, and did. Excellent. (I didn t know how to ask about box, but knew how to say that we were Americans, and with a fair bit of gesturing all around, managed to get the idea across.) Then we went in the Altes Rathaus itself, which was both a museum and an interesting cultural experience. We bought our tickets at the booth downstairs, then went upstairs to the entrance. We asked for the English audio guide, which is very common at museums in Germany. (They are small digital audio players that contain recorded information; each room or display has a number you can key in to hear about it in your own language.) We got it, and were told in incredible detail how to use it, even though they are quite easy to figure out and we had used them before. The museum employee told us where the audio tour starts, and in what order it usually goes, which was an effort for her given her limited English. But we all understood and went on our way. It wasn t even 5 minutes later when she had left her desk and came over to us. She was slightly alarmed at two things: one that we didn t have the volume at full blast (which was loud enough for the entire room to hear), and secondly that we weren t looking at the exhibits in the proper order. Never mind that it s easy enough to pull up the audio information about any room just by keying in the number posted in it, I guess. Anyhow, we sort of inwardly shrugged, let her turn the volume up to potentially disturbing the other visitors level, and went through the museum in the order she wanted us to. (Note that this wasn t a museum where there is a one-way flow of traffic or something; you walk into one exhibit, back to the main hall, and then pick your next one.) So we went through the rest of the museum with our English audioguide blaring throughout the large, echoing, wood rooms, feeling a bit rude to the other visitors (maybe 5 of them while we were there) due to its volume. Anyhow, the Altes Rathaus was beautiful and interesting, covering mainly the pre-industrial history of Leipzig. We learned about some of the guilds, the city treasury (vault), and where the town council/parliament met along with rich merchants. There were about as many museum guards as visitors there, and one or two of them sort of followed us around, pointing out the large and completely obvious signs with audio guide numbers in the rooms for us. They are serious about their audio guides in Leipzig. I m glad we went, and I m glad we had the experience we did, too. Terah told me later that she felt reprimanded about the audio guide and visiting order. My take on it was a bit different: the museum is impressive and interesting, but obviously not visited by tourists as much as museums in other cities, or even touristy sites like Thomaskirche in Leipzig. I think they they noticed two people, obviously very foreign (speaking only a little German, and with an American accent) with an interest in their city s history, and took pride in making sure we got the most of our visit and learned as much as possible about something they care about. Here is the main hall of the Altes Rathaus. We met up with Brad in a cafe near St. Thomaskirche for coffee and cake, then it was on to St. Nikolaikirche (the Church of St. Nicholas), the other large church in town. We stepped out of a passageway to face the large building, and walked in. The interior was decorated in pastels, and was also beautiful and historic. I can t get enough of that sort of building, I think. This building was especially important because it was the site of organizing for the Monday evening protests against the Communist government in 1989. People met at the church, sang a few hymns (to qualify it as a religious service, perhaps), then organized their protest for the evening. Sometimes they would wind through city streets and put flowers at the Stasi headquarters steps, and once the citizens actually overtook the Stasi headquarters. After awhile we grabbed a bit more for lunch: a pretzel for Terah and a Currywurst for me. (This one wasn t spicy and wasn t all that good.) Then we went to the GDR museum, which was large and interesting, but unfortunately for us, completely in German with no English guide available. That evening, we went to a Bach concert at the Leipzig Gewandhaus, celebrating Bach s 325th birthday. That was fun, and a neat experience with such good music in a very nice venue. The program included Bach s Suite for Orchestra no. 1 in C Major (BWV 1066), Concerto for Violin no. 2 in E major (BWV 1042), Ich habe genug (BWV 82), and Suite for Orchestra no. 4 in D major (BWV 1069). Sir Roger Norrington was conducting, and was rather fun and atypical to watch. He had the audience chuckling a few times with his minimalist conducting or perhaps his flamboyant gestures. Anyhow, the music was excellent and the tickets included free passage on the public transit system 3 hours before and after the concert a nice touch. Due to our schedule, we didn t spend much time with Fritzi, but we did get to play with her a bit. She likes to pretend to be a shopkeeper, and had her store all ready to lay out. We would ask her for some items, which she d put in a basket for us, and then of course there would be a child s twist: we d get our items, and she d pay us for them too. Terah and I brought some books for Fritzi. The particularly enjoyed Goodnight Moon because inside it is an picture of The Runaway Bunny, which she already had. Fritzi chose one of her books to give to Jacob it was a German book (Maulwurf) based on a Czech cartoon mole. That was nice of her, and Jacob really liked it (I ll write about that later). We had a good time in Leipzig, and I was getting fairly good at navigating downtown and with the trams and then, of course, it was time to move on. So Friday morning we caught our 7:50 train from the Leipzig Hauptbahnhof. We took the ICE train to Dresden, then walked a few feet to get onto the EC to Prague. That was a bit of a funny experience. The ICE trains are all sleek, modern, meticulously maintained, and the passengers tend to be very quiet. Talking is barely above a whisper, and people seem alarmed if their cell phone rings, even outside the quiet car. The EC passenger car appears to have been built, or last renovated, in the 1970s, and may have been Hungarian. The seats and curtains are old and faded; some of the seat backs have rips in the vinyl headrests. People were talking or eating loudly, in a very different setting than on the ICE train. As we rode along, we were on the right side the river Elbe for many miles. The scenery was beautiful, with small houses in the river valley, and the occasional house up in the hillside. At one point (a bit before we passed through K nigstein on the way to the Bad Schandau stop), we spotted what looked like an old walled city up on the hill. I figured out later that it was Festung K nigstein (K nigstein Fortress). Update: I forgot to mention a couple of things about Leipzig. One was our walk through a forest yes, a forest in the city. That was a nifty, quiet, and pleasant surprise. Secondly was seeing all the DDR apartment blocks, where the apartments evidently were quite literally blocks. It is interesting to see the Communist architecture.

Gerfried Fuchs:

I have a question to the candidates: History has shown that DPLs more or less disappear not too long after their period or at least reduce their visible efforts immensly. I wonder where you see the reasons for this trend, what your impression is about it and wether you try to follow that trend or what you will try to do to not have this happen to you, too.

I think that some DPLs are overwhelmed by the amount of requests they receive, and more importantly, are overwhelmed by the feeling of futility from perceiving that it is impossible to fix the things that they had intended to fix. So, unless there are other factors I would need to adapt to, I would try to discourage the number of private requests, and to not lose hope and faith in Debian. I imagine that delegation could be very useful in both these areas. Gunnar Wolf:

What would be different if there was no leader? Where would the project lose more? Would it gain in some aspect?

The DPL is theoretically one of the most important checks against the power of delegates. The absence of a DPL would thus increase any power imbalance in the the project, and likely to make the fighting between core teams even more political and harmful. Communities and teams are destabilized by egos because people stop paying attention to their healthy shared goals and the people around them and instead focus on their own individual success. So if the project were to achieve some kind of anarchic utopia where this is not an issue, I could imagine that the DPL would be the last remaining ego threat, and removing that role would make things better. However, we are nowhere near that now, and I think the DPL can do more good on this front. Yavor Doganov:

What do you think the project should do (with or without or regardless of your help as potential DPL) to preserve this goodness (maximum supported architectures) for as long as possible? Do you think it is "goodness" or you're in the "good riddance" camp?

I definitely think that one of our strengths is being available on a large number of architectures, and beyond that, providing nearly identical experiences on each of those platforms. I am saddened when porters or package maintainers make decisions to stray from the norm on a particular architecture, because I truly enjoy the consistency. I have run Debian on i386, sparc, hppa, powerpc, amd64, and in the few cases where something was different, I found it irksome. However, there is definitely a point where the cost in maintaining a release architecture far exceeds the benefit, and at that time I think we must regretfully bid it farewell. So you are right that porters are a precious resource, and as DPL I would try to reduce their attrition. Speaking as a former porter, I found the unresponsiveness and uncooperativeness of certain buildd maintainers (especially when not porters themselves) to be extremely demotivating. I would try to find a way mitigate porters being demotivated in such a way.

Marc Haber:

Do you see the diminishing care for our Core infrastructure as a problem? Do you have any idea how do sensibilize our new blood for the fact that "new packages" doesn't help Debian if our Core stuff is diminishing? I know that this is not exactly within the power of the DPL, but do you think that you, as DPL, can help speeding up Core development again?

Note: "core infrastructure" here refers to dpkg and apt. I am seeing numerous projects across the free software world struggle with a lack of contributors, and wonder why they cannot get anyone to help them. In most cases, I think there are hints about why people might feel disenfranchised by a particular development process, and in most cases, I think the people in charge are mostly unwilling to change the way that they have been doing things for years and years just to accommodate potential contributors. I think this is particularly true of projects where there is a dictatorship or a single gatekeeper for all VCS repository commits. Frequently these things seem to work themselves out after a long time. Old people leave, new people come in. Sometimes it is peaceful, sometimes it is violent. Rarely does it result in structural improvements. I do not know why there is lack of manpower on dpkg and apt right now. I know I tried to make a change to dpkg a few months ago and was unable to do so, partly due to the codebase and partly due to important information existing only in Guillem's mind. In the end, I had to just wait for Guillem to do it, which he helpfully did, and now we have libdpkg-dev in experimental, with one reverse build-dep. Had I been able to make the change myself, it is unclear whether I would have made any other contributions; that was the only itch I needed scratched, and I have plenty of other things to work on. So even though I found it near-impossible to contribute to dpkg in this way, I don't think that I'm excluded. So as DPL I would first try to determine why there might not be enough contributors to dpkg and apt, or why the existing contributors are not performing up to your standards. This could be an instance where I would solicit private communication from people who might have potentially-valuable information that they do not wish to communicate in public for fear of hurting someone's feelings. This does not mean that I would try to resolve these issues behind the scenes, because I consider that to be a dangerous and potentially-harmful tactic. Given a reasonable theory about why the problem exists, I would then proceed to encourage the resolution of that problem. I also think that some package maintenance teams may share some issues with some core teams and even the project at large, and addressing the more general problems could lead to relief in many areas. Specifically I would name problems related to ego and teamwork, which is a theme on which I plan to elaborate later.

Russ Allbery:

Do you have any thoughts about how to resolve release issues with less hurt and negative impact to the project all around?

I sure do. There has been a trend over many years to conflate the release management role with many other things: QA work, buildd work, ftpmaster-like work (I mean britney here), and in some cases I would even say DPL work. If we relegate release management to a strictly managerial role, I am certain that much of the stress, tension, and burnout will be mitigated. This means putting more access into the hands of many people, which is a good thing anyway. A release manager's job should be to say when a release is ready, what should and should not be in that release, and potentially some coordination with other developers, who are almost their equals. There will still be social conflict when the spirit of teamwork and cooperation is overcome by other factors, but I can conceive of a point where even that would not happen. Raphael Hertzog:

What do you think of this and would you be ready to withdraw a delegation for a delegate that behaved badly towards another DD (even outside of his delegated role), that has been warned once by you and that did it again later on? Do you think we can draft a code of conduct for Debian and do you think you can ensure that it would be respected by delegates?

I do not think that any long-term delegations should exist. I think that if they do, we have a structural problem which should be addressed in another way. Therefore I do not think it should be a big deal to withdraw a delegation for any legitimate reason, and if we are trying to force people to behave better (by a definition I agree with), then it seems reasonable to withdraw a delegation for bad behavior. Of course I would include ignoring people and having secret meetings in Vancouver as bad behavior, so that is perhaps not what you are getting at. I am not particularly in love with any formal codes of conduct, but I do think it is reasonable to hold DPL delegates or anyone who holds privileged positions of power to a much higher standard of behavior than the standard DD. With power should come responsibility, and all that. Presumably I would not delegate anyone who would place self and ego ahead of the well-being of the project, and presumably if there were a formal code of conduct or set of guidelines for delegates, those principles would align.

Dmitrijs Ledkovs:

Sometimes technical Debian discussions (mailing lists, bug reports, blog posts, etc.) become personal flame-wars. Do you think current frequency/amount of heated discussions is acceptable for the Debian project? What would you do to reduce those?

I do think that the current frequency/amount of heated discussion, as I perceive it, is acceptable for the project. I think that it is acceptable because it demonstrates that we have problems, and we should not be trying to hide problems. A code of conduct, or CoC, is something that treats symptoms but not causes. As DPL I would encourage the identification and resolution of the root causes. Why are people so angry? Why is there lack of respect? Why are people not asking these questions? In any healthy, functional organization, there are shared goals. Shared goals, obviously, contribute to a feeling of unity of purpose, and perhaps a vague and general direction to follow. Another thing is the spirit of cooperation and teamwork, and perhaps this is most important. Such spirit does not flourish when there are power inequalities or hierarchical structures. Such spirit does not flourish when you say that it is reasonable to make someone ask for permission to do things that anyone should be able to do. Such spirit does not flourish when things like ego and greed get in the way. Anyone can claim to be a team player, but it is rare that I actually encounter one. Paul Wise:

Which project and external Debian-related communications media do you follow? and contribute to? As well as a general list I'm interested in specific lists (for eg #debian, #debian-devel, debian-devel@l.d.o, debian-project@l.d.o, the Hardware forum on forums.d.n etc). How do you see those two lists changing if you become DPL? Which of these communications media do you feel is important for the DPL to read?

I am subscribed to over 50 Debian mailing lists. I do not follow them all. I am currently on #debian-glibc, #debian-devel, #debian-women, #spi, #alioth, #debian.de, #debian-devel.de, #debian-devel-fr, #debian-release, #debian-kernel, #debian-private, #debian-dak, #debian-devel-changes, #debian-ftp, #debian-buildd, #debian-games, #debian-dpkg, and #debian-bugs. I do not follow them all. I joined #debian-admin after a misunderstanding which led me to believe that it had become open and transparent, and was kicked out after about a week. I do not read any web forums, as I find them to be unbearable. As for external media, I occasionally read LWN. The only specific change I would anticipate after becoming DPL is the addition of leader@debian.org. I feel that it is important for the DPL to have a grasp of what is going on in the project, but I would not cite anything other than debian-devel-announce@lists.debian.org to be required reading. As for tones and perceptions on these various communications channels, I cannot say that external perception is entirely unimportant. However, if Debian is made the best it can be, I think external perception will become positive or not matter very much. So unless there are specific public relations needs arising out of a particular incident, I imagine that I would prefer to focus on improving Debian rather than improving Debian's external image.

The following article was contributed by John Cass. Note that John's instructions will also work on other NAS machines running Debian, such as QNAP devices. I had a problem upgrading my Debian kernel to 2.6.32 on the D-Link DNS-323. The upgrade looked like it worked but on reboot I had a hung machine. I tried taking the disk out, putting it in my main machine and remaking the links in /boot to the previous kernel and initrd.img but it turns out that on the DNS-323 both kernel and initrd are actually stored in flash memory (the /boot disk files are where they are built and a useful archive but are not used during the boot process). So I was stuck, and had to make a serial cable in order to find out what was going on. The instructions here and here were very useful and the CA-42 clone cost me 4 GBP on eBay and arrived within a couple of days. A delicate bit of soldering (and installing ckermit on my main machine) and I had a serial connection - I could finally see what was was happening. The upshot was, during the boot process the DNS-323 failed to mount my root partition. This was because the partition was formatted ext3 and the initrd.img had not included the ext3 module. It probably did this because I had deliberately forced mounting it as ext2 in the /etc/fstab (in an attempt to limit the write access to the disk, I want it to stay in standby for a long time but that's another post). (Remark by Martin: this is a known issue with initramfs-tools.) Anyway, having seen this, Martin was able to guide me to getting it fixed:

• First of all, I issued modprobe ext2 to get the ext2 module loaded (luckily this was included in initrd.img).
• Then you can mount the root partition on /root: mount -t ext2 /dev/sda2 /root - it will complain a bit but will work fine.
• Then run /scripts/init-bottom/udev - this moves /dev to within the new root directory.
• chroot /root /bin/sh - shift the root around so we are working from the proper root disk
• mount -t proc none /proc - mount the proc tree
• mount -t sys none /sys - and the sys tree
• nano /etc/fstab - edit this to change ext2 back to ext3 for the root partition
• mount -t ext2 /dev/sda1 /boot - mount the boot partition if it's a different device (mine is)
• Edit /etc/initramfs-tools/modules and add both ext2 and ext3 - this will force their inclusion in the updated initrd.img
• run update-initramfs -u to regenerate the kernel and initrd.img - this will rebuild the files in /boot and it will use flash-kernel to put them into the flash memory
• umount /proc /sys /dev /boot - unmount filesystems
• exit - leave the chroot
• umount /root - unmount the root partition
• reboot

And it should all be working!

Note: This post was written in March 14-15 and posted after our return. When I think about L beck, the first thing that strikes me is the feeling of history underfoot. It struck me most when we set foot inside the Marienkirche. I had never quite felt a wave of a feeling of stepping back in time like that before. The stones on the floor were uneven and imperfect. L beck has had a wet and snowy winter, so the city had spread sand everywhere: sidewalks and roads. Walking into any grand church, I could hear the sound of sand under the shoes of everyone nearby, and feel it under my own shoes. I think I will long associate with L beck the feeling of walking into a grand old church, looking up at the top of the old building at seemingly impossible heights, while feeling the grit of sand and uneven stone beneath my feet. Marienkirche isn t perfect, like some American churches I ve been in, such as the Basilica of Notre Dame. It doesn t have a lot of gold, either, and both of these attributes are wonderful. Look at a column of bricks, and you can see that each brick isn t exactly like its neighbor, and the entire column isn t perfectly straight. Lots of things in L beck are so old that they aren t perfectly straight, and it made me think that our American notion of always having to fix such things might be somewhat off sometimes. Look up, and you see the frescos from the 1300s, revealed after many years after the building was struck by an allied bombing raid in 1942. This heavily damaged the building and knocked down plaster from the walls and ceiling, revealing the old artwork. Many parts of Marienkirche were lost as a result of the bombing, which perhaps adds to its slightly sparse and ancient feel. The church bells were sadly melted and crashed to the ground due to the bombing, and have been left exactly where they fell as a memorial. Look down, and you see the uneven floor, and the concrete slabs above where important people were buried under the floor an attribute common to many of the churches we visited. It was common to see dates of graves from the 1600s and 1700s, though in some places it would go as far back as the 900s. The main part of the church has no heating or cooling, and visiting it on a day just a bit above freezing adds to the feeling of, well, old. Marienkirche has to be my favorite sight in L beck. Walking around the city, I get a similar feel. Many streets and sidewalks are made of stone. The streets that weren t damaged in the war have rows of beautiful old facades. Walk down many streets, and every so often I d see a little tunnel ( just wide enough for a coffin ) that goes under the street-facing houses to a nice little inner courtyard. These are open to the public, but tend to be very quiet and somewhat private. In the courtyard are smaller houses, which would have originally been used by the less wealthy. We also saw the L beck Dom (cathedral), which had a small museum about the destruction due to the Royal Air Force bombing in 1942. It was very sad to see the photo of the Dom in ruins, still smoking, even now. I can only imagine what it must have felt like to residents of L beck to wake up to see many of their priceless centuries-old landmarks and places of worship so horribly destroyed and all of this for little strategic purpose really focused on the morale of the enemy civil population . It s sad that the allies would do such a short-sighted and terrible thing. Europeans have long had to live with the legacy of war upon war, while we Americans have rarely had to see the consequences of war up close. I think it would be good for more of us to visit these sites and come up face to face with what a bomb can do, and then perhaps we will be more judicious with them in the future. Shifting gears now to where we stayed: Andreas & Sigrid, with whom we stayed, have a beautiful 500-year-old house, with lots of original wood beams exposed, and some very old paintings on the walls and ceilings. Nearby were excellent bakeries and a chocolate shop. Terah and I visited it today and bought some very good chocolate. And this brings me to the second thing I ll remember: Andreas & Sigrid s children, Lukas and Rahel. Now, Terah knows no German, I know only a little bit, and the children know no English. So it was a bit slow getting to know each other to start out, but we managed to work around the communication barrier and had a great time. Terah played board games with Rahel, while with me, she kept inventing games to play: hiding somewhere, saying Hallo! , and laughing at how many unsuccessful attempts I might make to find her. I showed Lukas the camera on my Droid, which he used a lot, though a racing game on Terah s iPod Touch was more exciting. They both enjoyed looking at videos of American trains a bit, but especially pictures of our house and yard with Jacob and Oliver. They tried to teach me the German words for things, and also made futile attempts to correct my pronunciation! When we were leaving today, Rahel came over and gave me a kiss on the hand, then the same to Terah s hand, then a little kiss on one of our suitcases. It was touching and sweet. This was one of those experiences no guidebook prepared me for, and no tour bus would have provided. It is something neat to make friends with children despite the large language barrier. On to the rest of the visit We had arrived a little late into Hamburg. After getting our bags and some Euros at an ATM, the next step was to find the bus to L beck. No signs for it were evident, so I found an information desk. The person at the desk was carrying on a conversation in German with the person ahead of me in line. I figured an information desk person in a busy airport would speak English, and was all ready to ask Sprechen Sie Englisch? , but when I walked up, he got a polite smile, and said, Good morning! How can I help? Guess I m obvious. He directed me to the bus, gave me a brochure about it, and told me what time it would leave. Terah and I found the spot to wait, and for a moment I stepped inside the airport terminal. Terah won t let me forget that someone came up to her and asked a question in German, whereas I was spoken to in English. Anyhow, we found the bus, managed to communicate with the driver that doesn t speak English, and sat next to the friendly person that was talking to Terah. He turned out to be a violin player from Munich, and we had a great conversation for the next hour he asking questions about the USA, us asking questions about Germany and Munich. At one point, he commented, You two are so open minded and you re also Americans! He sounded surprised. We exchanged email addresses at the train station. Andreas found us there, and we walked through the city to his house, with him pointing out the sights along the way. L beck is a beautiful city, and though it was damaged in World War II, much of the really old parts still remain. The famous Holstentor Gate has a museum inside, which was fascinating to visit. On Sunday, we went to church with the family we were staying with, Andreas helpfully translating for us. There I met a British Python programmer, which was fun. His wife is a social worker, which was fun for Terah. Monday it was time to get on the train to Berlin. We again walked through a cold and rainy city to the Hauptbahnhof, ready to head to Berlin. There we got on a train to Hamburg, then an ICE train to Berlin. Despite having just a few minutes for a connection in Hamburg, it all went perfectly smoothly. The train left Leipzig about 10 seconds late the clock inside turned over to the minute, then the doors closed and we were off. Impressive. Note: the rest of my photos from L beck are available on Flickr.

The federated authentication bar BOF will be held tonight at 9 PM US Pacific time in the Manhattan room at the IETF 77 meeting.. Here is information for participation. Reading List

• Use case/briefing paper
• EAP GSS-API Mechanism draft
• RADIUS SAML attributes draft
• sstc-saml-binding-aaa-draft-00
• sstc-saml-eapgss-sso-draft-00
• Feasibility analysis of the approach
• Brief overview

Remote Participation

• Join our audio stream during the session
• Join our jabber chat room at moonshot@conference.jabber.postel.org

Join our mailing list