ELKI: Environment for DeveLoping KDD-Applications Supported by Index-Structureshas been a major part of my research the last one and a half year. In a few words, it's a Java environment for research on data mining algorithms.In reality, it's a huge piece of software, providing various data types, parsers, distance functions (including specialized distance functions for color histograms or time series; 20+ total), index structures and tons of algorithms (with a focus on clustering, correlation clustering, subspace clustering and outlier detection methods; 40+ total). And providing a way to plug all these together in just about any way you can imagine. In fact, some algorithms are implemented just by plugging together other algorithms and distance functions.The 0.3 release adds more than a dozen outlier detection algorithms (the total is somewhere like 16, with some extra ones I didn't get around to clean up for the release branch yet) and a whole set of visualizations and a new convenience GUI for easier parameterization.It's all on the ELKI homepage.If you know what WEKA is, then ELKI is probably also interesting for you. But currently, we do not have much classification in ELKI. If you are into classification, you'll be better of with WEKA. ELKI is aiming to be to Knowledge Discovery in Databases (you know, the unsupervised thing) to what WEKA is to the Machine Learning (you know, the supervised thing) world.If you don't know all these terms, you'll probably need to browse through some literature to get familiar with the concepts and some of the algorithms. ELKI is not (yet?) an application that will just work on whatever data you want to throw at it. RapidMiner is another established application that can help you there better.As for application in commercial use, note that ELKI is designed in a way to be extensible (to help us in research) and clean (to help in teaching; I constantly have some students use ELKI as base for their projects), and it also is a moving target. The next release will likely feature a completely new database layer, to allow us to add our latest index structure research and support online algorithms. Performance and the ability to scale to arbitrary sizes of data is not of high priority to us.So for commercial applications, you might want to implement it on your own, connect it to your favourite DBMS and optimize it how you need it yourself. (When we need to scale, we'll just run it on a 128 GB system, that will take us far enough). Plus, you'll have to talk to us about a license.But: if you are interested in unsupervised data mining, such as clustering and outlier detection, then ELKI might offer you are large library to base your research on, without having to start from scratch with everything.

My main home workstation (previously named katherina, after a distant ancestor) was originally bought a few years ago probably 2002 or 2003. Since then, it s had its motherboard upgraded twice, new hard disks, and then even was moved to a completely new machine back in January. Throughout all of that, it s still running the original sid that I put on it when it was new, dist-upgraded since then, copied to new disks via tar and netcat, but never reinstalled. So it s probably been less than my average of 10 years on a given Debian install. But it s time. For one thing, despite the fact that I was one of the people that helped start Debian s amd64 port (then known as the pure64 effort), I ve been running i386 on my 64-bit workstation. For another, I want to switch from XFS to ext4. And finally, it has not escaped my notice that my laptop running Gnome with xmonad feels a lot faster than the far more powerful desktop running KDE4 with xmonad, plus Gnome integrates better with xmonad. And there are some nice gnome bits installed by default that my KDE system doesn t have, and 400 packages installed on my system that are no longer in any archive. I could, of course, clean that stuff up but all this adds up to enough of an excuse to start from scratch. I continue to be very impressed with the quality of squeeze. This will be a very nice release when it comes out.

The Trade Union Congress s chief executive recently came out in the crazy position of sharing a platform with the British Phonographic Industry (and why are they still relevant? What is the market share of phonographs now?) and supporting the much-hated Digital Britain guilty-without-trial three strikes disconnect measures. Yes, you read that right: the TUC s chief exec wants digital economy workers to be arbitrarily disconnectable in response to allegations of file-sharing by large competitors. If I m being charitable, I think he was duped. That stupid article was in response to yet another set of filesharing-will-fankle-us scare figures which carefully only included the creative industries most impacted by piracy (see second paragraph of introduction). See pages 12 and 14 of the full report to note that businesses that don t depend on profit from copyright licensing were not even included! So, these are not the creative industries. They are the KEA and WIPO definitions of copyright industries. Of course they are hurt by copyright infringement and have little to lose from over-zealous copyright laws, but they are not the creative industries. I contacted the TUC to basically ask why they were so against digital economy workers in this way. I received an anonymous answer from TUC Information Services that was almost helpful:

The current policy of the TUC on this issue was decided at our annual congress last autumn. and directing me to Composite Motions 18 and 19 (PDF) and the verbatim report of the conference (PDF) pp. 107-9

Composite Motion 18 seems largely innocent. In fact, its call for social inclusion, a Universal Service Obligation and digital inclusion could be seen as an instruction to oppose non-judicial three-strikes, because allowing so-called Kangkaroo courts run by private-sector transnationals to decide who may use the internet is basically incompatible with inclusion and universal service. The NUJ-supported Composite Motion 19 is the dangerous one and I m alarmed that the claims around piracy are completely without evidence or justification in the verbatim report of the conference. Were references supplied, or does the TUC adopt positions based solely on reference-free argument? How does the TUC reconcile contradictory motions for inclusion and universal service and for exclusion through private courts? Their answer?

The TUC does not, as a rule, enter into correspondence with individual union members [...]

Oh great(!) You are in a maze of twisted union organisations and none of the ones which are screwing things up are accountable to you. Thankfully, I have happier Digital Britain news from another source which I should write about soon.

Last month I spent two days in Belgium, after I got invited to the MySQL distro meeting. It was a non-public meeting with some people from Sun Microsystems and MySQL maintainers from different Linux distributions. It took place directly after FOSDEM (which I unfortunately could not attend due to personal reasons) at the Sun Microsystems Belgium office in Brussels. It was great to meet with Mathias Gug from the Ubuntu Server team in person. He had some really good ideas on how we could reduce the differences between MySQL in Debian and Ubuntu in the future. As a consequence, Debian will soon switch from Subversion to Bazaar for maintenance of most MySQL packages.

However, we were not only talking about the MySQL Server itself, but also about MySQL Cluster, MySQL Proxy, the MySQL Connectors and the MySQL GUI Tools. Giuseppe Maxia has a more detailed blog entry about the event, including the whole list of participants and some pictures. I fully agree with him: The meeting was a success, we also had a lot of fun, and we should do that more often!

Thanks a lot to Sun Microsystems for sponsoring, and of course to Lenz Grimmer for organizing the event.

It looks like being separate organisation in GSoC definitely brings more attention than last years where we were under MySQL. Hopefully this will allow us to choose really enthusiastic students who will do their work properly and without much kicking. So if you are interested in participation in GSoC 2010 with phpMyAdmin, please take care filling up the proposal and showing us some previous contributions (see student checklist for more hints) in order to be selected. The dark side of this is enormous increase of mails on our devel mailing list and combined with my illness last week and vacation few days before, it makes constant volume of 50 unread mails there for me :-).

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/

Hello As the author of Config::Model, I ve often pondered whether my project was mature enough to be released as 1.0. After all, every time I seriously use it, I find new bugs or need to make it easier to use or even add some new features. So I thought that my software was not good enough for V1.0. Then again, all other software have the same issues: fix bugs, improve usage and follow user requirements. Then, I ve realized that wondering about software quality is not the right question. Sure, you need a decent quality level for 1.0. But the more important is not there. The most important is the compatibility pledge. Do I pledge to keep backward compatibility so people can rely on me and my software? Will I do my utmost to preserve the work done by others ? In fact, that s what I ve been doing for several months now, all the changes I ve made are backward compatible (even if warnings are issued) and people have a smooth migration path. So, yesterday, I ve released Config::Model V1.001. Ta-da !

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/

Here's another quick update on the status of FusionForge. We released version 4.8.3. Nothing earth-shattering, but a collection of bugfixes that had accumulated on the 4.8 branch. If you're running a patched version, you might want to merge. We also published the second release candidate for 5.0. It's not final yet (there have been a few commits on that branch since then), but we're running out of known bugs. We're currently down to zero open bugs targeting 5.0, so the actual release is probably going to happen in a matter of days. 5.0rc2 is currently available in Debian experimental for those who want to test it, and the final 5.0 will be uploaded to unstable, and hopefully migrate to Squeeze in due time. Stay tuned

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.

Steve Langasek:

As a developer, how do you embody the spirit and culture that has made Debian a great operating system? If elected DPL, how will you inspire the same in others?

I do not believe that there is any one single spirit or culture that has made Debian great, never any truly united community. With contributors from various places around the globe, we have a melting pot of different cultural viewpoints. Furthermore we have people doing things for a variety of reasons, some more selfish than others. The interplay between these differences has led to tension, and it has also led to greatness. I am certain that some of the great things in Debian have come to pass borne out of anger and hatred. We have had shifts in cultural norms over the years. When I joined the project, it was considered highly controversial to use the word fuck . Many community members would scream at anyone who did that, rudely sending private emails to admonish them. Eventually, enough anti-censorship people joined that the political tide turned, and many of the people offended by the use of the word fuck quietly faded away. We effectively disenfranchised them. Now the pendulum may be swinging in the other direction, and if it does, we can expect the same sorts of tensions and the same sorts of attrition. Perhaps this is part of the natural cycle of things, perhaps not. So if I list what I do or what I try to do, I do not believe it adequately answers the question. I think that Debian is superior for technical excellence and cohesive policy, so I try to do my part to meet those standards. I think that Debian is great for being a good Free Software Citizen, so I try to forward relevant bugs and patches upstream. I think that Debian is great for not being fully beholden to corporations, other financial interests, or dictatorial personalities, so I try not to encourage that sort of thing. I think that Debian is greater because of a few team efforts, so when someone tries to set up a worthwhile endeavor, I feel some compulsion to join in or at least be supportive. I think that Debian is greater because of some commitment to transparency, so I try not to do anything important behind closed doors, and even when I assume that something is transparent enough because it has been discussed only in public channels, and someone yells at me for hypocrisy, I try to increase the distribution of that information to a level that people feel is appropriate. As DPL I would try to set a good example by not being a hypocrite about any of the things I think are important to Debian, and would try to inspire an atmosphere of more teamwork, cooperation, and empowerment. I think that this could be revitalizing. Alexander Reichle-Schmehl:

Suppose that you would not run for DPL: Who would you vote and why?

I am not sure of how I will be voting. Each of the candidates had said things that I like, and each of the candidates has said things that I dislike very much. I am choosing not to get into specifics here, because I do not consider it appropriate or ethical to try to affect other people's votes in that manner.

I happen to notice a quite high CPU load average on my Core2 quad core. The load average was about 0.5 or even up to 0.8 when running the KDE4 desktop. Funny enough my old Pentium4 the load average with KDE 3.5 (lenny) is near to 0.0. Both hosts are used a "home server" and gateway running some processes like Squid and Apache. "Ok", I thought, "when I stop KDE, load average will be back to normal". So I stopped kdm. But the quad core still has an higher CPU load average than the Pentium4:

On the Quad Core:


On the Pentium4:


I would have expected the opposite: a higher CPU usage on the Pentium4 and a lower one on the Quad Core2... The Quad is a Q9550S and supposed to be more power efficient than the Pentium4, but I doubt that the Q9550S can save more energy with an higher CPU load. The reason for the high CPU load is still mysterious...

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.

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

Bernd Zeimetz:

From the other candidates I'd like to know their opinion and plans (if there are any) about license/copyright requirements in Debian.

I believe that intellectual property laws are wrong and should be abolished, so I am not particularly in favor of giving copyrights any more respect than necessary. However, I do not think that Debian is the place to undermine copyright, and that we should attempt to maintain standards which not only protect people from legal liability, but are also in the best interests of our developers and users. I do not know what level of nitpicking best serves our developers and users. A GR seems like an interesting way of determining at part of that. Anthony Towns:

What's your estimate of the current number of Debian users?

I do not have one. While I do acknowledge that the number of users does affect us in terms of potential contributor base, and scaling issues (including bug reporting), I do not think that the exact number is important at all to what we do. Also I would hope that whichever DPL is elected chooses to focus on practical matters rather than academic exercises. Kurt Roeckx:

I think that one of issues we have is that there is alot of work to be done by some teams, some of them even regularaly mail that they need more members, but they seem to have a hard time keeping the numbers up, burning the other team members out. What are your ideas to make sure those teams keep running?

• Diffusion of power throughout the rest of the project
• Delegation of people who do not seek to be core team members if they have the time, are willing, and would make good additions.

Note that I do not think it appropriate either for core teams to choose their own members or to reserve the privilege of demanding that a new person be able to work with them in a certain way. An ideal team member should be able to work with anyone. If the existing delegates are unable to work with new people, perhaps they are not ideal team members. Charles Plessy:

During the discussions that started after the GR, I suggested that the GR proposer should have more control about the options put to the vote. In particular, it would be useful if he can refuse an option that would disequilibrate the voting system. That would make him responsible for the success of the GR: discarding a popular option is taking the risk that the whole GR is refused and the option is accepted as a separate GR, which is the kind of public failure that I expect that people will avoid.

I do not think GR proposers should have any special control over general resolutions beyond what is Constitutionally granted at present. In fact, I would prefer if people did not try to propose multiple options or strategically craft ballots for any purpose. To me, the only honest method is to propose the outcome one genuinely wants to win, and let our strange and special brand of parliamentary procedure take care of the rest. As for the supermajority issue, I am not a huge fan of political word games. Debian distributes non-free software. We have a non-free section within our normal infrastructure, and while it is segregated and does not receive quite the same love that main does, it is still very much part of what we work on and distribute from our official infrastructure. So there is no amount of word lawyering, cognitive dissonance, or NM indoctrination that can make me believe that it is an honest statement to say that non-free is not part of Debian. Likewise I do not believe in redefining success or the meanings of Foundation Documents. I do not think that we should allow ourselves to pass any kind of magical resolution that contravenes the DFSG or Social Contract without actually modifying them. That seems utterly absurd to me, and I have seen what has become of the United States government.

Hi Planet, (cc-by-2.0 aigarius) I know it s kind of far fetched, but I would need a bottle of DebConf9 wine shipped to California before Wednesday 31st, March. Because of the urgency, the bottle needs to already be in the US and will need to be shipped by FedEx Overnight or equivalent. I will of course reimburse you all costs, including to get you a replacement bottle if needed. This is a gift to someone who has been a great friend of Debian for the past few years and has helped us a lot. Drop by IRC (ArthurLiu, OFTC) or mail me and I will give you more information about what this is about.

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.