After several other Debian developers convinced me that a ShortURL service, which is under control of a Debian Developer would be useful for them, I've spent some time to write the necessary code for it. And if it will be used regulary, I'll ask DSA if they want to host it on a proper machine. So I'm happy to announce the public beta test of deb.li (also available under go.debian.net)! Please note that neither the content of the pages nor the CSS is finished... As this should not become just another random, spammer-attracting ShortURL service, I will not provide a web based form to add new URLs. Instead new URLs have to be added via a simple JSON-RPC based interface. Other ways to add new URLs will be added on request (or by sending patches ;)), at least an email-gateway similar to db.debian.org is planned. The small piece of documentation which exists so far is available at wiki.debian.org/deb.li And if you want to give it a try now, log into alioth.debian.org and have a look into

/var/lib/gforge/chroot/home/users/bzed/godebian-client

- the usage is documented in the README file and should be pretty straight forward. I hope it will be useful - comments, bugreports and patches are welcome!

• for i386:
  • iceweasel
  • xulrunner
  • libmozjs
• for amd64:
  • iceweasel
  • xulrunner
  • libmozjs

As of writing, xulrunner 1.9.2.3 has been uploaded to experimental, but as ftp-master is currently offline, and as it will also need to go through NEW, it won t be available immediately. Which is why, once more, I make them available for you:

• for i386:
  • xulrunner
  • libmozjs
• for amd64:
  • xulrunner
  • libmozjs

Iceweasel should follow in a few hours.

Two months ago, I explained how cosmetic carbon copy could allow you to list recipients in a message who never receive a copy. Today, thanks to John Stumpo's writing talent and Wes Filardo's IETF-NG, an Internet-Draft informational document has been published. IETF didn't like it enough to accept it as an April 1 RFC. (I do actually hope that one day someone will submit a modified version to IETF as a rest-of-the-year RFC.) Slashdot took note! In first visible comment, an Anonymous Coward writes:

Although it is an April Fool's...this would actually be useful.

Other highlights from the Slashdot discussion:

• An Anonymous Coward writes about an existing implementation.
• quantumplacet actually corrects me on my recollection of the standard.
• Delusion_ complains of April Fool's Day, "I hate today."

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.

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.

Raphael Hertzog:

Imagine a DD contacts you, she wants to setup an infrastructure to finance Debian related projects (i.e. paying people to enable them to work on the projects that they'd like to do for Debian) but she wants to avoid the main mistakes made during Dunc-Tank; in her project: - everybody can propose projects to be financed - the projects to be financed are selected by the Debian developers and by the donors - eligible projects can only concern new developements and not recurring tasks

I am imagining that this contact took place in public. I see very few legitimate and good reasons to approach the DPL privately, and as DPL I would encourage people to to work toward transparency unless there were very good reasons to do otherwise. I would begin by telling her about the beauty of Debian as a gift economy community, and point out how great it is that I do not need to pay people to respond to my bug reports, apply my patches, release new versions, or develop any code not funded by corporate sponsors. I would recount my recent experience with a different free software community, where there was much talk of the motivational power of money, and how best to link PayPal to bug tracking systems and write a boilerplate email response template suggesting a donation of $5,000 to help facilitate the development of any feature requests. I would confess my suspicion that if this trend continues, any goodness in that community will be driven elsewhere, and the gift economy, which I believe to be a very important basis for free software, will be severely undermined. When I have completed my feeble attempt at political persuasion, if she is still firm and stubborn in her desire to proceed (and when monetary greed is involved, I expect this kind of stubbornness), I would suggest the following points:

• Keep it as far away from Debian as possible: if these projects can be accomplished upstream or externally, it is better for Debian if done that way.
• Ensure that the people saying that the work is necessary are not the same as the people who are the only ones with access to do the work and thus the only people getting paid, because when those decisions are arbitrary it reeks of corruption.
• There should be as little subjectivity as possible. It should be utterly clear when someone has completed the work and earned the monetary prize. There should be no discretion on the part of persons with privileged positions in Debian, especially if friendships or other personal relationships are involved.

Then I would ask her once again not to do anything like this. Dmitrijs Ledkovs:

Please finish "In ten years I'd like Debian...."

In ten years I'd like Debian to still be my favorite operating system. In ten years I'd like Debian to be egalitarian and cooperative. In ten years I'd like Debian to be completely free software, without a non-free section.

In just under a month, Belgium will face Estonia in a Fed Cup World Group Playoff tie. The winning team will participate in the world group next year, which, in theory, opens the possibility of winning. So this is an important encounter. When team captain Sabine Appelmans announced the Belgian selection, it was described by the Belgian press as the 'dream team' Clijsters, Henin, Wickmayer and Flipkens, aka the four best Belgian female Tennis professionals. That, combined with the possibility of a World Group promotion, seems to excite much of the country, to the extent that 10000 tickets have been sold in no time. Yes, I'll be there too. But one man seems unhappy. Marc Wickmayer, father of Yanina, will say to everyone who wants to hear it, that 'Appelmans needs to choose'; that he's 'tired of the hypocrisy', and so on. His arguments: Clijsters and Henin have not been part of the Fed Cup selection in two years, and his daughter should not be the fourth wheel on the wagon after having been much of the reason why Belgium is playing these playoffs. Sigh. Let's check some facts, shall we?

• There are four singles rubbers. There are four players. Appelmans does not have to let any player play more than one singles rubber.
• Wickmayer is currently still the highest-ranked Belgian tennis pro, at number 14. Clijsters (17) and Henin (33) may have been ranked 1st before their respective comebacks, they are not now; and both still seem to be not entirely in their rhythm yet especially so Henin. Appelmans would be stupid to bet the entire encounter on them.
• Last but not least, let's not forget that the opposition may not be easy. Kaia Kanepi, Estonia's top player, may be ranked 100 now; less than a year ago, however, she was at her career-high of 18. Due to several injuries, a viral ilness, and some bad luck, she has not won much anymore since last may, but she may be a tough nut to crack.

Curiously, Yanina herself does not share her father's opinion. She's been quoted several times as being excited to have Clijstes and Henin on the team, since 'the team is much better with them'. Indeed. Her relationship with her father, is often described as being 'very close'; apparently that doesn't mean they are of the same opinion on everything. Maybe it is time for the two of them to have a little chat on the whole Fed Cup thing, before this gets out of hand. I'd hate for Appelmans to have to make the wrong choices to appease people...

While the package is not ready yet for experimental, mostly because there are pending changes in the 3.5 branch, Mozilla released a security update today. So, here are the packages you need to be safe security-wise with Iceweasel 3.6. Please note only xulrunner packages have been updated, as the security fix lies in the xulrunner code.

• for i386:
  • xulrunner
  • libmozjs
• for amd64:
  • xulrunner
  • libmozjs

A known regression of this version is that the icons in the search box on the top right don t show up.
Update: This regression actually doesn t exist.

The following is an invitation to the Latvian Ubuntu Bug Jam (in Latvian) sent for a bit of a wider circulation to catch people that monitor Planet Debian, but not Planet Ubuntu.lv. 27. mart LU Linux centr notiks divi pas kumi vien Ubuntu Global Bug Jam Latvijas da a un installfests. Global Bug Jam ir pas kums, kur piedal ties ir aicin ti interesenti, speci listi, studenti, lai mekl tu k das Ubuntu Lucid Lynx test anas versij . Cilv ki, kas grib uzzin t par Ubuntu Linux, vai kuri grib atrisin t k du konkr tu probl mu ar Ubuntu Linux tiek aicin ti n kt uz pas kuma otro da u no pulksten 14:00 l dz 16:00. Pas kuma b s kafija un bulci as ar Accenture atbalstu. Ubuntu Global Bug Jam ir glob ls pas kums, kura m r is ir iepaz stin t programm t jus un tulkot jus ar r kiem, kas tiek lietoti, lai labotu probl mas Ubuntu oper t jsist m un ar izlabot p c iesp jas liel ku skaitu probl mu s laik . Izstr d t ji, kas grib labot Ubuntu probl mas vai iem c ties k labot Ubuntu probl mas, tiek aicin ti ierasties 12:00 un palikt l dz 16:00. Installfest pas kuma sada tiek aicin ti visi eso ie Ubuntu lietotaji, kuriem ir k das konkr tas probl mas un ar cilv ki, kas tikai v l interes jas par Ubuntu Linux. Ja jums ir konkr ta probl ma ar Ubuntu Linux ir ieteicams atnest uz pas kumu savu datoru, kur o probl mu var atk rtot, lai pas kum eso ie programm t ji var tu noteikt s probl mas iemeslu un pal dz tu no nov rst. Installfests s ksies 14:00 un turpin sies l dz 16:00. Ubuntu ir bezmaksas, uz Linux balst ta pilna apjoma oper t jsist ma jebkuram person lajam datoram, serverim un portat vajai iek rtai. T s standarta komplekt iek autas visas nepiecie am s programmas, lai str d tu ar tekstiem, att liem, elektronisko pastu un Internetu, k ar j s varat instal t papildus programmat ru da diem nol kiem. Pasaul to obr d jau lieto vair k k 8 miljoni cilv ku, un to leg li bez maksas var lietot gan m j s, gan komerci l s un nekomerci l s organiz cij s. LU Linux Centrs ir izveidots Latvijas Universit tes Datorikas fakult t . Linux Centra darb bas m r i ir: populariz t atv rt pirmkoda (Open Source) programmat ras, tai skait , Linux oper t jsist mas un citu atv rto tehnolo iju iesp jas un priek roc bas; piedal ties LU studiju proces un stenot lieti o IKT p t jumu projektus, tajos izmantojot un att stot atv rt s tehnolo ijas; sekm t APP pieejam bu Latvij un pasaul .

Well I suppose its a bit heretical running something such as VMware, but its an important piece of software at my workplace, it also allows me to run some important VMKs or modules. But at first it just wouldn't compile.

And then I found this wonderful blog about Installing VMware on Ubuntu and it worked wonderfully. The author patched the code and it all installed nicely.

The next problem was one of the services would not start. Port 8308 would refuse to work and when I went to the management screen and said Service Unavailable. I tracked this down to the Java program dying at socket binding time.

The absolute first thing you should check if you are having TCP/IP problems with Java is the sysctl path net.ipv6.bindv6only which you can check with
sysctl net.ipv6.bindv6only.

If it is 1, it might mean bad Java code network problems. And in fact this time it was the problem, changing it to 0 and the Java daemon started and stayed running and all was good.

Incidently if you use the Cisco ASA firewall Java client and it dies, use this trick for it too. On Debian systems, edit the file /etc/sysctl.d/bindv6only and set that option to 0. I don't think its the fault of the key, but bad Java code (but is there anything but bad Java code?)

I've made a quick release of dh-make, now up to 0.52. Besides a minor dh_make.1 manual page fix this release will put the right value in the debian/source/format file. 0.51 will make it a native source package no matter what flags you use.

If you get weird lintian errors about native source formats and version numbers wrong on your brand-new Debian package you just made, you might of been bitten by this bug.

That leaves a few bugs left, there are two I need help with:

• Bug 328692 - If you have a plan ASCII name like me, then your name looks fine in the dh-make generated man pages. This bug requires converting names that aren't plain ASCII (e.g. that use UTF-8) into something groff understands. Someone suggested decomposed unicode but unicode and groff are pretty much a black art to me, let alone combining them.
• Bug 533117 - This one is all about making dh-make make your python packages. You'll need to understand the new debhelper v7 rules files. Again, python is not something I use so the bug is stuck here.
  

Related articles by Zemanta

• UTF-8: Bits, Bytes, and Benefits (research.swtch.com)

After a long time of testing and just plain other non-software writing stuff, I'm happy to announce Gjay 0.3.0 is released. This is my first release of Chuck Groom's code and hopefully it will work for you too.

The Debian packages will be out shortly after some building and testing. If you have a 64-bit computer it now works with 64 bits fine (ie on my amd64).

It still needs some work, I'd like it to interact with more than audacious as the sound player. Also if you know how to in one of the sound libraries stream wav, ogg or mp3 files correctly I'd like to hear from you. Currently gjay just uses the same old fork to mpg321 method, but idealy I'd like it to use the libraries directly.

Following up my post about using google-code-prettify to syntax highlight code on Blogger, I want to share what I did to tune it for a dark theme.

Big warning: I'm completely ignorant of any web development, html/css/js are kinda arab (no offense intended) for me, so I'm quite sure there are more elegant solutions to this, but at least it works, and seems to have broken nothing :)

So, the default CSS has some bad values for tokens colors, in particular for the keywords and tags (that are in dark blue) and for the plain text (that is in black, so completely hidden).

What I did was to simply override those values, using this table as reference; so now the code to add to Blogger "Minima Black" template (the one I'm using) is:

<link href='http://google-code-prettify.googlecode.com/svn/trunk/src/prettify.css'
    rel='stylesheet' type='text/css'/>
<style type='text/css'>
.pln   color: #C0C0C0;  
.kwd   color: #4169E1;  
.tag   color: #4169E1;  
</style>
<script src='http://google-code-prettify.googlecode.com/svn/trunk/src/prettify.js'
     type='text/javascript'>  </script>

Work on Iceweasel 3.6 is approaching an end, but there are still issues with it and with 3.5 that I want to tackle before officially pushing to experimental. In the meanwhile, you can already try a preview package:

• for i386:
  • iceweasel
  • xulrunner
  • libmozjs
• for amd64:
  • iceweasel
  • xulrunner
  • libmozjs

The amd64 binary has the JIT compiler enabled by default (contrary to upstream default, and I guess most if not all other distros), so if you have issues with it, you ll need to disable javascript.options.jit.content from about:config. It passes the testsuite, so I expect it to be fairly stable.

Recently I was flirting with the idea of creating an online game, but I got distracted by wondering how to make the back-end more flexible. To communicate the state of the game to N connected clients I figured I needed some kind of server which would accept "join"/"quit" requests and then make changes available. To that end I came up with the idea that a client would make requests via HTTP such as:

http://example.com/server/game/chess/join

This would regard the originating client as part of a new chess game, for example, and return a UID identifying the "game channel".

http://example.com/server/changes/1-2-3-4

This will retrieve a list of all events which had occurred in the game which had not already been sent. (Here 1-2-3-4 is obviously the UID previously allocated.)

http://example.com/server/submit/1-2-3-4/move

This would submit the move "move" to the server.

After mulling this over for a while it seemed like a great reusable solution, I'd make an initial "join" request, then repeated polling with the allocated UID would allow game moves to be observed. All using JSON over HTTP as the transport. It was only this morning that I realised I'd have saved a lot of time if I'd just proxied requests to a private IRC server, as the functionality is essentially the same. Still I'm sure this pattern of "join"/"poll"/"quit" could be useful for a lot of dynamic websites, even in the non-gaming world. So although the idea was mostly shelved it was an interesting thing to have experimented with. D'oh. ObFilm: Conan The Barbarian

The ABC overhauled DIG Jazz (now I think it's just called "ABC Jazz") and upgraded from the oh-so 2008 XML playlist to a much more web-cool JSON one. Hence Version 3 (source) of the applet. Now with improved HTML escaping and different colors. Check out The Dilworths while you're there!

As I mentioned, I headed to Pittsburgh last week to give some talks at CMU and find out something about what they're doing there. Despite the dire weather that had closed the airport the day before, I had no trouble getting into town and was soon safely in a hotel room with a heater that seemed oddly enthusiastic about blasting cold air at me for ten seconds every fifteen minutes. Unfortunately, it seems that life wasn't as easy for everyone - ten minutes after I arrived, I got a phone call telling me that the city had asked CMU to cancel classes the next day.

This turned out to be much less of a problem than I'd expected - whether because of their enthusiasm to learn about ACPI or because they simply hadn't noticed the alert telling them about the cancellation, a decent body of students turned up the next morning. After a brief chat with Mark Stehlik, the assistant dean for undergraduate education, I headed off to the lecture hall. The fact that I can now just plug my laptop into a VGA cable and have my desktop automatically extend itself continues to amaze me, as does OpenOffice's seemingly unerring ability to get confused about which screen should have my content and which should be showing me the next slide. Nevertheless, facts were imparted and knowledge dropped on those assembled. I'm even reasonably sure that the contents were factually accurate, which is a shame because the most attractive part of teaching always struck me as being able to lie to students who will then happily regurgitate whatever you tell them because in case it turns up on the exam. Perhaps this is why I'm safer out of academia.

Lunch offered an opportunity to visit the Red Hat sponsored lab, which was pleasingly located somewhere other than a basement. The guy on the right of the picture is Greg Kesden, the director of undergraduate laboratories in CS there - it was wonderful to get an opportunity to see the machines getting used, and students seemed genuinely appreciative of the facility.

After lunch I spent a while talking to Satya about the Internet Suspend and Resume project. This is an impressive combination of virtualisation and migration, using a Fedora-based live image to bring up an OS on arbitrary hardware before downloading a machine image and launching it. The majority of the data is pulled in on demand, meaning that initial performance can be slow but ensuring that data is only downloaded if it's needed. When the user is finished, the delta between the original image and the new one can be pushed back to the server while remaining cached on the local machine in case the image is used again.

It's an interesting approach, combining the flexibility of thin clients with the advantages of having actually useful computing power at the local end. There's a few functional awkwardnesses, such as some VMs being unhappy if images are migrated between machines with different CPU features, and it obviously benefits from having significant bandwidth. But the idea of being able to combine the convenience of a floating session with the knowledge that you can still keep copies of your data on you is an attractive one, and I'd love a future where I can move my session between my laptop and a desktop.

After that there was some time to talk to Bill Scherlis and Philip Lehman about the software engineering courses that CMU run. Part of the minor in software engineering includes a course requirement to make a meaningful contribution to an existing software project, from design through to submission and upstream acceptance. I had the opportunity to talk to a couple of the students about this and the differences they found between working with the Mozilla and Chrome communities, which I'll try to write up at some point.

Finally I gave a presentation on Fedora and some of the issues that we face in providing a useful OS when patents and recalcitrant hardware vendors do their best to thwart us. Despite the ice outside and the significantly-below-freezing temperatures, enough people turned up that sorties had to be sent out to find extra chairs. It was great to see how interested people were in learning about what we do, although it's probably the case that the free pizza did help encourage people.

After that it was an early trip back to the airport, where I found that my plane was delayed and the only "restaurant" still open was McDonalds. Even so, I left with the feeling that it had been an interesting and educational visit. Many thanks to David Eckhardt, who runs the OS course I presented to and who looked after me all day - thanks too to Joshua Wise who picked me up when David was running late due to the ground being covered with blocks of ice.

If you re using KDE and upgraded to Thunderbird 3 lately you might have the problem that links in emails don t open in a browser anymore. For my case that happened even without a user visible error message. If that sounds familiar for you, check the error console (Tools/Error-Console). If there is an error like:

Error: uncaught exception: [Exception... "Component returned failure
code: 0x80004005 (NS_ERROR_FAILURE)
[nsIExternalProtocolService.loadUrl]   nsresult:  0 80004005
(NS_ERROR_FAILURE)   location:  JS frame ::
chrome://communicator/content/contentAreaClick.js :: openLinkExternally
:: line 188   data: no]

Then Thunderbird just (silently) fails to launch the browser. Guido pointed me to gconftool. gconftool -R / grep url-handlers told me that some components of gnome still had Firefox configured as http-handler (which is strange since it was rebranded to iceweasel ages ago). Resetting them solved the problem for me. The sad part of the story: x-www-browser, sensible-browser and KDE s http handler where all correctly configured and pointed to iceweasel. All applications behaved correctly only Icedove used a (for me) hidden setting pointing to firefox.

The recent development of the situation in China or Iran reminds me of the importance AND fragility of the freedom of speech on the Net. As the influence by the Net on the general public grows, attempts by governments to control and tame the Net will be aggravated, in a more sophisticated, crowd-pleasing way (for example, by claiming a need for Internet Driver's Licenses). How can we deal with this? Freenet can be a key to solve this problem. After almost 10 years of continuous development, it seems that it finally became an usable product(I don't say it's perfect -- there are still a lot of things to be done, especially around its UI). Freenet has its own dark side and I don't expect that it will become the standard way of the communication over the Net, but we always need the last resort to enjoy our everyday life. Unfortunately, most of Freenet-related information on the Net, especially about the installation method on GNU/Linux, are severely outdated. Freenet is a Free Software(GPL'd), and Debian did have a .deb package for Freenet long long ago, but it's basically gone and defunct. Since the pace of current development is quite fast and sometimes the backward compatibility is broken, it's not really a good idea to ITP and upload Freenet to the main Debian archive for now. Thus, I cooked up up-to-date .deb packages of the modern Freenet and publish them by myself on people.debian.org. I tried to follow the Debian packaging convention as much as possible, so at least they can be installed & uninstalled cleanly ;-) Also, Build-Deps are carefully set, so you may rebuild it without much hassle if you need. Add the following to your /etc/apt/sources.list:

deb http://people.debian.org/~mhatta/debian/freenet ./
deb-src http://people.debian.org/~mhatta/debian/freenet ./

Then run "apt-get update" and install "fred" package. This is basically all you need(you might also want jSite or FMS). Then take a look at /usr/share/doc/fred/README.Debian. You might need to copy seednodes.fref into /var/lib/fred if you want to use Freenet's Opennet mode for the first time. After that, access http://localhost:8888 and follow the instructions. Recommended readings on the modern Freenet:

• The Wikipedia entry for Freenet is surprisingly rich and informative(and not so obsoleted).
• The dark side of the internet, a recent featured story on Freenet from The Guardian. As the title indicates, it inclines to emphasisize the negative side of Freenet, but it's a good read anyway.
• The Gurdian writes about Freenet, a quite well-balanced response to The Gurdian article by Ian Clarke, the originator of Freenet.

Enjoy.

Tag this post with del.icio.us!