Seeing these church bells in L beck wasn t easy for me. They melted and fell to the ground after an air raid in 1942, and have been left exactly as they fell.
I wasn t alive in 1942, and even my parents hadn t yet been born. My grandfather was relocated by the American government because he refused to fight in the military for religious reasons.
And yet, I still felt a sense of embarrassment, being an American standing there in Germany next to those bells. My country* did things like this. Why? Even if there s a war on, and whatever the other side may be doing, do we really have to bomb all their churches?
Then, we went to the Dom (cathedral). It has a small gallery of photos of the destruction in 1942, and how it took 40 years to restore (though some original works are simply irreplaceable.)
I had just been walking through the beautiful Dom, and then saw pictures like that. It was very sad. I imagined the people in 1942, seeing the smoking remains of so many buildings that had been important to the town for centuries. Places where, no doubt, some of them worshiped, and their parents and grandparents had too. I imagined my sadness if a country bombed one of the churches that my ancestors helped start or build. I felt ashamed of what the democracy in which I live (and its allies) did to the Dom, to Marienkirche, and to the other churches and civilians there.
Then, a few days ago, Wikileaks posted a video from an American helicopter in which our soldiers begged Come on, let us shoot! at people, most or all of which were completely unarmed. They killed a bunch of people. Then a van came to try to get the wounded to the hospital. Then the soldiers in helicopter killed those people, and wounded some children. Even if they thought their lives were in danger, I d expect to hear some quiet sadness at what they thought was a regrettable need to use force. Instead, you d hear them cheering whenever they killed someone, as if they had just won a round on some video game. They killed civilians, and considered it a fun experience and a mission accomplished. There was no sadness for knocking a man to the ground, leaving him writhing. Just jokes. There was no more care for human life here than there was 60 years ago.
It saddens me that every year we celebrate our military on independence day celebrating its ability to kill, not its ability to feed. I wish that we could rather celebrate the times Americans have saved lives, whether in Berlin or in Port-au-Prince, or helped to topple dictatorships. Military power shouldn t be our first choice so often.
L beck wasn t attacked for any strategic purpose; the British did it to destroy the morale of the enemy civil population , as the Americans did in Dresden or the Germans in London. In other words, those bells fell to the ground for no reason other than that they were German. People lost their lives for the same reason in Germany and in London. The British had no reason to believe that those civilians meant them any harm, that they were anything but caught between two strong powers. And the same held true in Iraq.
When we went to Berlin, we walked through the replica of Checkpoint Charlie, with the big sign announcing that you are leaving the American sector. There is little positive to be said about the Cold War, but there is something the British and American military did of which I am not the least ashamed: the Berlin Airlift. Although I didn t see it, I feel a sense of the USA having been a force for good when I read about the Berlin Airlift Monument at Tempelhof, which has the names of the 70 British and American men that lost their lives in the airlift (due to accidents), above the inscription They gave their lives for the freedom of Berlin. That s the spirit I wish we d see more often in the world today: people giving their lives not just for their own security, but for strangers in need on a different continent.
We Americans have been, compared to many countries in Europe, relatively sheltered from the ravages of war in our own midst. I wish that more of us would have the opportunity to gaze at fallen church bells, to wonder through a magnificent old church and then to see photos of it on fire, or to see a monument to our soldiers in a far away land. Perhaps then we could better learn from history, and see firsthand that some of our most positive contributions to the world have come in the form of coal and candy bars instead of incendiary devices.
A small post script
Many historic buildings or locations we saw in Germany had plaques on their exterior with a brief history, often in German and in English. I was interested to note that some (though not all) of these plaques had language such as destroyed by fire in 1942 , with no mention that the cause of the fire was a bombing. I was even more interested to note that same sort of description at several sites in Prague Castle, mentioning that the original building was lost in the fire of 1142. It was only on the third or fourth building in the Castle that we learned that the fire of 1142 was caused by a military siege of Prague Castle.
* I know it was the British at L beck, but the Americans did similar things elsewhere.
I also acknowledge that, at a macro level at least, the Berlin Airlift wasn t purely an altruistic act, as there were geopolitical factors in play. But I am speaking of the actions of the airmen here, who took on considerable risk to help others.
Sorry, the only response here is "Don't Do That Then"
Tesco Car Insurance (and most
likely their other financial products) operate a commercial email system which
is populated by anyone who submits their address to them as part of searching
for a car insurance quote.
That's not particularly unusual. Each mail that Tesco sends includes
unsubscribe instructions - standard industry practise. However Tesco's
instructions do not work. I have followed them at least three times since
January this year to no avail. Despite this I have continued to receive
unsolicitied commercial email (spam) from Tesco.
Tesco do not answer mail to their postmaster or abuse addresses, and do not
accept mail for those local parts at many of their domains (they use more than
one domain for their business: tescofinance.com, tesco.com, tescocompare.com,
contact.tescocompare.com, tescoinsurance.com).
I would advise that nobody ever submit their details to a Tesco-affiliated
company for these reasons. I have given up and blacklisted them on the mail
servers which I control.
Based on the unrelated experiences of a friend of mine, I would have strong
reservations regarding the quality of the services they offer, too - in
particular their home insurance products.
Don t expect to get a glass of tap water at a restaurant or caf ; it s an unusual request that probably won t be understood or honoured. Lonely Planet GermanyNow, before I go on, I want to clarify that this post is NOT a complaint of what I saw in Germany and Prague; it s just a description of how it was surprising to these American eyes, and perhaps also a description of how the American approach such a mundane topic might be surprising to people from elsewhere. (Update: I want to clarify that I only visited 3 cities in Germany plus Prague. I don t want anybody to assume that I m making generalizations about the entire continent here, despite my title; I think the comments reflected that I didn t make this point clear enough. I lack data to draw much of any generalization at all; this is more of reporting on my experiences than anything else.) Utilitarian Water I noticed that the vast majority of toilets I saw in Germany and Prague are of the extremely water-saving variety, with an option for a small or a large flush. These toilets exist in the USA, but are still rather uncommon here. I was glad to see this attitude of conserving water. I was a bit surprised when I took a shower at our hotel in Berlin. Although that hotel was extremely environmentally-conscious in every other way including the toilets, light switches with RFID sensors and timers, etc the shower head was the most wasteful of water I had seen in quite a few years. I felt rather guilty of using so much water for a shower. But our hotel in Prague took shower heads to the next level. The shower head there was this huge square monstrosity, about a foot long on each side. I have never seen a shower head that big. It had a voracious appetite for water, too. Although it could be pointed in any direction, doing so was useless because, even at full blast, it was clearly getting not nearly enough water to propel the spray forward. It seems that this shower head needed special water-guzzling plumbing. But even without it, I felt even more guilty for showering in Prague. I suspect that I used more water for the two showers I took there than I would have over an entire week at home. I also very much suspect that this shower head would be illegal in the USA due to its water consumption. (I should note as an aside that the shower heads I saw in private homes were no different than American ones.) One thing I didn t see was lawn sprinklers. This may have been because there is less open grass in the places we visited, or perhaps because spring hadn t yet really hit. In any case, I wonder if our American habit of pumping water from deep beneath the ground, only to shoot it up in the air and spray it back on the ground again might appear a bit odd to others. Drinking Water In Restaurants We did a lot of walking in Europe, and sometimes we d have walked awhile to get to a restaurant. I really prefer water when I m thirsty, and ordered water with my meal at restaurants a few times. I stopped doing that, though. The presentation varied, but usually it went along these lines: they brought a glass bottle to the table, it cost EUR2 EUR5, and generally contained almost as much glass as water. The most impressive display of water was at a Berlin restaurant. I wanted some water, and so did Terah. So the waitress suggested we could share an EUR 4.90 bottle (0.75L). Sounds good, I guess although it s less water than you d get in a typical American bottle for one person, it seemed a lot by typical German restaurant standards. A few minutes later, our water arrived. It required the waitress to use a full tray to deliver our water and its, well, water accessories. First she carefully placed a frosted plastic water holder, precisely centered on the table between the two of us. Into this, she carefully placed the water bottle. It was, of course, made of glass, and also tall taller than most wine bottles, though containing less actual liquid. I am not yet sure of the purpose of the holder; it certainly wasn t to keep the water cold, as it was served warm. Perhaps they feared the bottle s impressive height acting as a sail and getting knocked over by a gentle breeze. In any case, next came our water glasses, which appeared to be exactly like wine glasses, but bore the logo of the company that bottled the water etched in the glass. After that, she picked the water bottle back up out of the holder, carefully opened it (it was just a regular twist-off lid), and then poured water into each of our glasses. She was careful not to have even a drop run down the side of the bottle, and filled each glass precisely 2/3 full. The glasses were, of course, positioned carefully on the table, and the bottle of water returned to its place of honor within the water bottle holder. This process consumed most of the small quantity of actual water in the bottle. I do believe that is the most elaborate presentation of a small amount of good ole H2O I have ever witnessed. It was made with the kind of care I would expect to be shown to someone that had just bought a $100 bottle of wine, not a EUR5 bottle of water. We had walked a mile (1.6 km) to get to that restaurant, and I was indeed a bit thirsty. I wasn t sure I wanted to drink all of my tiny quantity of water presented so elaborately all at once, so I had a sip of the beer I had the good sense to order along with the water. The beer, incidentally, cost roughly the same per liter as the water and was simply plonked down on the table with a complete lack of fanfare. Sadly, beer is not really very good for quenching thirst, due to its diuretic effects over time. Another surprise came at a restaurant in Prague. It appeared to have the typical prices for water, so I ordered a local Czech orange soda to drink. It, like the water, was served in a smallish glass bottle. In any case, I ordered a traditional Czech goulash to be served in a bread bowl, while Terah ordered some ribs. The waiter took our orders and menus, and returned a minute later bearing a bowl full of water and a lemon slice. This he put next to me, and announced, wash for you. My reaction was: Hmmm. This is different. (Which is why we went to Europe, after all!) What is this for? Did he think my hands looked dirty and needed to be washed before eating? Or did he think I would get them dirty while eating, and somehow fail to use my napkin? It turned out that the use of it became clear. I ate the goulash using the supplied spoon, but the bread bowl it was served in was of course edible too. It turns out it is pretty much impossible to eat a bread bowl that had contained a stew without getting your hands dirty, and the wash turned out to be quite practical and useful. It was free to wash my hands in, but I m sure would have cost EUR5 had I wanted to drink it. Drinking Water American Restaurants Some of you reading this may never have experienced water in an American restaurant, so allow me to explain. In a typical American restaurant, water is free and comes with unlimited refills. Americans generally think of water as healthy (and our doctors and government medical experts urge us to drink plenty of it), and water in a restaurant is a good way to save money while dining. It would generally be considered questionable service if your glass of water at a restaurant got less than half full, and really quite bad service if it sat empty for more than a minute or two. A waiter at an American restaurant will typically go around with a pitcher of ice water. If your large water glass isn t completely full, the waiter will pick it up and step a few steps back from the table before filling it from the pitcher. The waiter will then dump water and ice from the pitcher into it, usually overflowing the top such that some water and ice spills on the floor (so now you see the point of stepping back from the table). The glass will then be returned to your table, wet sides and all. It will be completely full, so you have to be careful not to spill when you take your first sip. The fancier or more expensive American restaurants will offer a version of this, though without the spilling on the floor part. Usually at one of these restaurants, you ll automatically get water set out for you when you arrive. This is free, and if you order another beverage, you ll still keep your water. (Though at any restaurant, it would be quite acceptable to order water along with your other beverage.) Needless to say, this water is coming from a faucet, not some glass bottle, but I m fine with that. A few American restaurants have bottled water on the menu, but I can t recall ever seeing somebody with one in a restaurant. Drinking Fountains Drinking fountains are common in the United States. They provide free tap water to anyone. You can find them near almost any public restroom, whether indoors or outdoors. You can also find them in virtually every park, along some walkways or bicycle routes, in airports and train stations, and even in museums. They re so common that I rarely even think about being able to find water in a city if I m thirsty. Often you ll find them installed in groups of two or three, with one at a lower height so as to be usable by children or adults in wheelchairs, and another at a regular height. Many indoor ones even contain integrated chillers to make the water cold (which, sadly, probably more than negate the environmental benefits of water fountains.) I saw exactly two drinking fountains in Europe, and I can say I got a drink at 100% of the drinking fountains I saw there. One was in the Hamburg airport, but notably it was at the place where you wait to have them check your passport. So you can use a drinking fountain in Hamburg, but apparently you must do so before you have officially entered Germany. The other one was in the Prague airport. It was in an out-of-the-way corner, on the lowest level, by the gates for the people that are flying out on the small planes. Which we were. Above it was a placard bearing a icon indicating that this was, in fact, a drinking fountain and how to use it. I was surprised at the need for the icon at first, but less so after I observed a man walk by, glance at the fountain, and wash his hands in it (rather than do so at a sink in the restroom 5 feet away). As a result, we were sometimes a bit thirsty in Germany. By the time we got to Leipzig, we realized what was going on and bought a Coke bottle which we could refill from the tap water in restrooms as we went along. (This we kept until it was confiscated at a museum in Prague). I didn t see many Germans carrying around bottles of water, but it was still cold, so it s possible they were but were in a coat or bag. I was left with the somewhat unwarranted conclusion that some Germans must be either always slightly dehydrated, carrying around hidden bottles of water, or paying EUR2 for a small plastic bottle of water all the time. In the USA, we do have bottled water. Among people that care about such things, there are certain people that drink only from bottled water as much as possible, and then there are other people that view bottled water as exceptionally expensive and an environmental catastrophe and avoid it as much as possible. I m part of that latter group. I ve noticed that statistics show that Germans consume more bottled water per capita than Americans do, which is not really a surprise given what I observed. Conclusions Part of the reason I wanted to go to Europe was to experience different approaches to things, and we surely did. I didn t expect it to lead to a blog post about something as mundane as water, but here it has. I ve got to say I like the overall attitude of water conservation in Germany, which seems to have gone further than it has in the USA. I also like the system of water fountains we have in the USA, which also helps the environment by reducing demand for plastic water bottles. The wash for me in Prague was just great. One of those moments where I was completely surprised (and in a good way) by something. (I m just glad the waiter spoke a bit of English, because I wouldn t have figured it out at all otherwise.) In the end, part of the fun of traveling is learning about these differences. So next time, we ll just plan on finding a bottle to carry around at the start of our trip, and then thirst won t be a problem. Perhaps I ll even try washing my hands in a drinking fountain.
I m currently trying to convince (and hopefully succeeding) Daniel Burrows to co-mentor a Qt frontend for aptitude.
But for that a student is needed. http://wiki.debian.org/SummerOfCode2010/Aptitude-Qt for first draft of project.
http://wiki.debian.org/gsoc for information about GSoC and debianries kernel: [168074.392016] Northbridge Error, node 0, core: -1 ries kernel: [168074.392186] K8 ECC error.This was first noticed somewhere at the beginning of January. A DSA member then used the usual HP tools to check whats up, none of it reported an error. There wasn t much of an option left besides waiting what happens in the future. No support would do anything here. Until March we did not have any trouble. But at the 14th of March this changed, as the HP tools now found a serious error, reporting Status: DIMM is degraded for the third DIMM module. A support ticket was opened at this point and a replacement DIMM got sent out. Unfortunately the well known Mr. Murphy did look at this issue and so the wrong thing was sent out to the wrong place. Countdown continued and 10 days later the host decided to randomly lockup. And as HP servers have an Automatic Server Reset function in such cases, the whole machine rebooted. Not only once. Guess how much a filesystem likes such things when the machine is active. And for added fun a second DIMM got reported as broken, we now had DIMM #3 and #4 gone off. A certain ping-pong with HP support later we asked the local admins to take out the broken DIMMs and then also to change the order in which the remaining DIMMs are arranged. Unfortunately this did not help, the errors stayed. At this time we already turned off the services running on the machine and it mostly waited in the HP Insight Diagnostics test from HPs SmartStart CD. (And it always locked itself at 97% here). The support asked us to try another round of work on the machine, which our DSA team and the local admins did. But as it already was the 30th of March and nothing helped, our DSA got a little more direct in asking for a working solution. Like replacing the board and sending a technician to look and fix the machine. This was scheduled for the 1st of April, but turned out to not work as hoped. For some reason the technician was not able to find the board that was sent as replacement (no fault of our local admins!), so nothing happened the 1st of April except us getting a little upset. DSA communicated this to HP support, asking for escalation and finally getting this fixed. Our local admins could at last greet a HP technician on the 2nd of April then and he even had the replacement board with him, so he did his work there. He also confirmed that the two DIMMs mentioned above are faulty. For some reason he did not replace them, but left them outside of the machine. He also left the place without telling the Brown CS staff, so it wasn t the best performance he made. Fortunately the machine was in a working state again, only missing 2 of its DIMMs, 4Gb RAM. This has to be replaced by HP in the next days. When the Brown CS staff found out the technician left without notice they enabled our DSA to access the ilo of the machine again, so they could get the machine back up. Of course the first run was the HP SmartStart stuff again, running a full test. It reported no error, pheeew. There had been a few more steps in getting the settings of the ilo correct again and running a full filesystem check on it, but somewhere in the night the machine was back up and ready for us FTPMasters and Release team to get the services back. As the machine was back up in the middle of the night where I was sleeping, I did start my work somewhere this morning. At 10:25 CEST this started with a md5sum check of all files we have in our pool/ structure, ie. the Debian archive. We had 655k files to check, so it naturally took a while. Luckily we only found 32 broken files. Even better a set of them is already fixed, the rest of them is easily fixable with a set of binnmus the buildd people helpfully schedule, so not too much work involved in fixing this issue. Could have been worse. (Actually, when the first reboots happened, before the long downtime, we also had some broken logfiles, unreadable changes files and such things. But those I already fixed back then). More or less in parallel to the md5sum check we also started the queue daemons again, to let our upload queues from the other hosts forward their files to the central queue on ftp-master, tested the triggers to the new buildd peoples machine and the release team did a britney run. This took the first 5 hours (and a bit) of the process. As a second step, and we are still in this, we started the processing of the incoming queue. Turned out we have to process 10gigabytes of new uploads, in a total of 1285 uploads. This process is still running at the time I write this blog post, having processed about 1100 uploads. A good 9 til 10 hours run, but this was expected. I actually thought it will take even longer. When this is done I will go and have a manual dinstall run. That is, I will run every action a dinstall is usually doing by hand. And verify each step. Usually dinstall takes some 2 hours, manually it can take a bit more. Somewhere during this run a mirror push will also be done, a fairly huge one this time, with all those updates. When this all works I will turn on FTPMaster cronjobs after this dinstall, or at latest tomorrow morning, as usual, and service is back as usual. As far as I know the release team plans to turn on their cronjobs tomorrow morning too, so this will all be nice then. Apropos release: Please note what I wrote in my latest d-d-a mail:
As a sidenote from me: If you have a package that might be involved in whatever transition to testing, or simply might get involved, it could really help if you wait a day or two with the next upload, so the release team can sort through all before you give them new trouble. If in doubt, try mailing debian-release@lists.debian.org and ask. :)So, thats it, enough annoyance with all those status bits here and there. I go leave you alone now. :)
In my last post, about GRUB2 theming, there were a few people who were unhappy at the perceived difficulty of creating GRUB2 themes, largely based on the lack of documentation. And to be honest, those people are right if the documentation were complete & correct when I started, then I wouldn t have ended up bumping into all the bugs I did. So, to help on that front and to help kick-start GRUB2 theming in general, I m announcing Larval. More GRUB2 themes means more awesome-looking systems in the wild. Hopefully the GRUB2 upstream will embrace it as a project to help raise the profile and potential of GRUB2.
It didn t take me long to realise the most obvious way to develop such an editor: GRUB2 s canvas-based layout system has an awful lot in common with XAML, so the obvious choice was to develop using Silverlight (or, more specifically, Gtk.Moonlight). Larval s internal theme format is XAML files, which are then exported to (and imported from) GRUB2 s simple text based files.
The biggest piece of work, to be honest, is the Managed implementation of a PF2 font reader/writer, so you can design a theme using the regular TrueType fonts of your choice, then have them automatically ported to PF2 format as required.
I look forward to plenty of community input on Larval, once it reaches a point where I m sufficiently pleased with my (Ms-PL licensed) code to share it with the world. Until then, you ll have to make do with the above screenshot!
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.
Our main problem is that we don't have the source code to either the kernel
they use (2.6.24.2 with patches from Samsung and others), or the u-boot
bootloader.
SSH was available without password for the user account and various basic
errors allowed us to root the system relatively quickly. Brute force cracked
the root password a few days later.
The only information we did have was from the provided desktop system (which
is really quite good and certainly looks very polished, but in the end still
way too limited), what's on the flash memory and the contents ofa "firmware
upgrade" image they provided.
Having that firmware upgrade image proved very important as it gave us a good
idea how to boot the system from SD card and made it possible to locate the
kernel, u-boot bootloader and other files in flash memory.
Googling for some boot messages we found two kernel source trees (for a
different device: SmartQ) that looked promising as a basis.
After some disassembly work by Luke Kenneth Casson Leighton on the kernel
to get LCD timings and correct GPIO data we managed to get a basic working
kernel: LCD, USB (and thus keyboard and touchpad), and wired networking.
Although there are still loads of things that need improving/fixing, that gave
me enough to work with to try to get Debian Installer going.
The main limitations for running D-I are that we cannot change the bootloader
configuration and that their boot procedure does not use an initrd. But we did
work out how to boot a custom kernel from an external SD card by making
creative use of their "firmware upgrade" procedure.
Essentially I needed to find a way to run D-I by only booting a kernel.
Piggy-backing an initrd onto a kernel is possible (using the 'bootpImage'
target from the upstream kernel build system), but then the size of kernel
plus initrd is limited to 4 MB and that is really too limited for a
decent D-I initrd (especially if you want full i18n support).
I ended up creating a micro-initrd (only 66 kB!) which only function is
to mount the external SD card, load the real D-I root initramfs (which now
no longer has any real size limitation) and then run init in that.
After adding some relatively minor customizations for this netbook (such as
installing the kernel from a custom repository on alioth), the installer was
up and running.
As the framebuffer worked without problem for the newt frontend, I next wondered
if it would be possible to also get the graphical installer working. This should
be easier for non-x86 systems after the recent switch from DirectFB to X.Org as
backend for the graphical installer. And the image below shows it was.
I had to create an /etc/xorg.conf to get the USB keyboard and touchpad working
(apparently auto-detection does not quite work for less standard hardware), but
that was basically it.
So now all we have to do is get all the remaining kernel issues sorted out...
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?
ACOSS, the Atlantic Canada Open Source Showcase, interviewed me this month. I talked about the Debian Eee PC project.
Next.