Search Results: "cas"

18 April 2006

Josselin Mouette: That's how the X strike force fixes bugs

"It's kind of cute that you just attempt to handwave this away as having 'no justification', but please spend your time on other, more productive, pursuits."

I bow before thy knowledge, great and mighty Daniel.

For those who don't follow the X drama, the X.org upgrades can now fail joyfully, depending on your system. You might ask yourself, "what have I done to break my system so much that X cannot be upgraded?", and the answer might be... "nothing!". The upgrade will fail if there are remaining files in /usr/X11R6/bin after APT has upgraded all packages using this location.

Here are the contents of this directory on my system before the upgrade:
  /usr/X11R6/bin/x9407
  /usr/X11R6/bin/#startx#
  /usr/X11R6/bin/startx.dpkg-dist
The first one is a broken application installed by "make install". I guess this is far from an isolated case, especially when there is software built using imake around. The two other ones were obviously left by previous upgrades of X itself. Yes, this means the upgrade can fail just like that, without any real reason whatsoever.

It took several years to move /usr/doc to /usr/share/doc, but we only need a week to move /usr/X11R6/bin to /usr/bin, don't we?

Philipp Kern: Back on Planet Debian

I have readded me to Planet Debian's feedlist. Hopefully there are no dupes submitted to the feed again. Please notify me by mail in the case that my old articles reappear, thanks.

17 April 2006

Martin F. Krafft: "What goes up must come down"

After three days of intensive city soaking, it was little surprise that Saturday and Sunday nights brought cats and dogs down from the sky, almost as if St. Peter up there also wanted to play along at the Songkhran festival, but came late. Preceeded by strong winds, the rain on Saturday caused everyone to hurredly pack up their booths, leaving the wonderful markets deserted that night. Fortunately, Sunday's rain wasn't so strong, and the famous Sunday night market in Chiang Mai did take place after all -- when the first showers had settled, almost all merchants came back out onto the road and the shopping could continue. I witnessed a funny moment on the market in the afternoon: the speakers, which are installed on almost all lamp post and sometimes blast horrid music onto the streets, started playing the national anthem. In response, everyone stood up and still for its duration, almost as if time had been frozen. When the last chord stroke, the the people continued at what they were doing and the familiar buzz was quickly restored. We spent yesterday in cooking school, the same one I had been to a year before: the "Thai Chocolate Cookery Centre", which I can recommend to anyone. I chose this place again because I did not want to run the risk of ending up at one of the tourist ripoff places, but next time I shall try a different one; apparently there's a cooking school outside the city on a farm, where yuo get to harvest all herbs and fruits yourself prior to the cooking, instead of the market tour commonly done in the beginning of the day. On our way home, stuffed after 8 dishes of Thai food spread throughout the whole day, we stoped by our guesthouse from last year: the "Chiang Mai Garden Guesthouse", to say hello to the owner, Pissamorn. I was happy to find her remembering me, and all the more happy when she honestly advised us not to try "just any bamboo rafting" -- I had been spoiled by the trek she organised for us last year, which involved a morning of bamboo rafting down a river from the middle of the jungle, which you cannot reach by car. I have no problem believing her that the other travel agencies which organise rafting trips dump you just somewhere along a road on slower rivers with a far less beautiful scenery. Unfortunately, neither time nor the heat really allow us to go on the three day trip through the jungle, so we postponed the rafting to our next trip. Nevertheless, I feel very good about having Pissamorn as a reliable contact in Chiang Mai, for future trips, and in case of any problems! She also referred us to a Thai silk factory and told the owner to treat us with respect, so today (Monday), we let them pick us up and placed an order for a bunch of comfy trousers, and some silk button-down shirts; Aline got herself a nice blouse and a wonderful dress. We now have two and a half days left in Chiang Mai and have no real plans. A 1-2 day trip to Pai still seems like an option, but it's supposed to be unbearably hot up there. We'll see. A keep having recurring thoughts about my dream to move to Southeast Asia (Hanoi, to be exact) to start a computer school, and even though there are no concrete plans yet, I feel like my motivation to finish the Ph.D. rather sooner than later is on a steep incline. I could imagine tearing down my "tents" in Switzerland and to go to Vietnam for half a year or a year of language school, then see whether I manage to meet the right people to allow me to set up an existence. Alongside the computer school, my dream includes visions of a nice and comfy guesthouse where you get what you pay for, concentrating on quality rather than quantity, which by the way is what the Chiang Mai Garden Guesthouse seems to be doing. For me, that's the only way to go about anything if you want success and satisfaction, be it consulting, teaching, or a guesthouse in Asia. Again, thanks for reading along.

Andree Leidenfrost: mindi 1.07 & mondo-2.07 Packages

are available from the Debian unstable repository. It's i386 only atm, but amd64 is hopefully going to follow soon. In fact, I'm writing this from a restored amd64 installation.

The upstream ChangeLog can be seen here: http://www.mondorescue.org/.
.

The main Debian changes are:
  • package reorganisation to adjust for upstream changes
  • fix for #357785
  • fix for #331060
  • fix for broken '-I' and '-E' parameter handling (from SVN r468)
  • fix for verify via NFS not working
  • fixed compiler warnings on i386
There is still a handful of 64 bit related compiler warnings because the code wrongly assumes that pointers are 32 bit and can thus be cast to int that I am not sure about how to best fix:

newt-specific.c: In function 'popup_changelist_from_file': newt-specific.c:1651: warning: cast to pointer from integer of different size mondo-rstr-newt.c: In function 'redraw_filelist': mondo-rstr-newt.c:1007: warning: cast to pointer from integer of different size mondo-rstr-newt.c: In function 'edit_mountlist_entry': mondo-rstr-newt.c:1374: warning: cast from pointer to integer of different size mondo-rstr-newt.c: In function 'redraw_disklist': mondo-rstr-newt.c:2506: warning: cast to pointer from integer of different size mondo-rstr-newt.c: In function 'redraw_mountlist': mondo-rstr-newt.c:2538: warning: cast to pointer from integer of different size mondo-rstr-newt.c: In function 'redraw_unallocpartnslist': mondo-rstr-newt.c:2575: warning: cast to pointer from integer of different size mondo-rstr-newt.c: In function 'redraw_varslist': mondo-rstr-newt.c:2610: warning: cast to pointer from integer of different size

Other than that things have been tested successfully on amd64 with kernel 2.6.16-1-amd64-k8 using NFS as backup media and on i386 with kernel 2.6.16-1-k7-smp using both NFS and DVD as backup media.

With the etch freeze still some time away, I'll try to focus on the following issues in the given order:
  1. get RAID and LVM to work - this is by far the most important task and there are numerous bugs in BTS
  2. improve FHS and other compliance, in particular default the location of the scratch and tmp directories to something sane (cf. #312546) and move the location of floppy and ISO images away from /root and make it configurable (cf. #222065)
  3. fix things so that NTFS restore leaves Windows in a bootable state rather than requiring the workaround using gparted - this may require switching things from fdisk to parted which Bruno doesn't like much...
  4. IA64 support for mondo - depends largely on what happens upstream and probably also on whether I can get my hands on an Itanium box that I can actually reboot and restore...
  5. general clean-up and wishlist stuff
I think I'll be quite happy if 1. and 2. are done before etch freezes (and all new bugs are addressed as well). We'll see.

16 April 2006

Brett Parker: bpgallery.sh v1.0.2 released

Just tagged up the latest version of bpgallery which is my rather light bash script for generating static gallerys, this version fixes a couple of (minor) bugs, removes some duplication of code (to make it easier for me to maintain, and because I'm going to need to extend that part of the code for the next release), and fixes an outstanding part of the todo list (i.e. regenerate thumbnails if the required width changes). It's also added a per gallery config file option, so now putting in a file called .bpgallery.rc with the right variables in it (WIDTH, TITLE, BPGALLERY_THEME), will use that file as the last one to get settings from, overriding previous settings (well, unless they're set readonly, in which case it won't ;). Next release should have some extra themes in the release as a demonstration, medium sized images (and the pages to go with them, and an extension to the themeing for this), next and previous 'buttons' on the autogenerated pages, and should generally just be a nice release! Sometime I'll get round to finishing off writing the documentation for it, but until then, if you're using it and get a problem, mail me (or find me on IRC!).

Wichert Akkerman: Using a seperate Data.fs for the catalog

It has been argued that it makes sense to use a seperate ZODB to store a catalog for Zope sites. So far I have not been able to find any benchmarks that substantiate this claim. Without doing any benchmarks I can think of three reasons why this makes sense: It would be nice if someone can extend this list and do benchmarks proving that this ZODB split indeed helps (or that it does not in which case a lot of us can simplify our setups). Update: alecm mentioned a very good reason: catalog searches, which can wake up a large amount of small objects, should not cause other objects to be pushed out of the cache.

15 April 2006

Wouter Verhelst: OpenBSD sucks!

Last FOSDEM, I snatched one of the free OpenBSD 3.7 CD-ROMs with me. Not that I was planning to switch to OpenBSD or anything; but I have this spare 10G partition on my laptop that I use to play with all the time. There's never anything on that partition that is insanely important; and usually I change it to something else after a few months. It had been containing MacOS for a fair number of months, since there was an issue with my kernel that made changing my screen brightness impossible for some reason; but that has been fixed now. I wouldn't know what the problem was, but switching from my own-built kernel.org kernels to the Debian-precompiled kernel fixed it. Heh. As it happened, this weekend I was looking for something in my backpack, and stumbled upon that OpenBSD installation set again, which I'd completely forgotten about. Since I'd grown tired of MacOS by now, I thought about installing OpenBSD on the play partition. Obviously, their installer is a slight bit more spartanic than the Debian installer. Heck, they're a BSD system. One of the first questions was whether I wanted to use an OpenBSD-specific partition table or an HFS-based one. Since Linux uses the latter, and I didn't want to lose the Linux partition, I chose HFS. Next, it threw me into a partitioner, telling me that I needed to end up with (at least) one partition that had 'OpenBSD' as its type and name. So I made sure to do it that way, which took me a few tries to get it right. After that, I had to create a BSD-style "disklabel". I happen to think those things are pretty crazy, but, well; it's how the BSD systems work. First, I made a 4.3BSD slice for my data (slice a), and next a swap slice (slice b) that was 10% of the size of the partition that I'd created for OpenBSD. Or so I thought. The problem was that none of the above steps used gigabytes, megabytes, or even kilobytes, as its unit; instead, I had to create partitions and slices in blocks. Not that I don't know what a block is, but it's not as easy to spot issues that way. After I'd written the new partitions and slices, and started to format the a slice, suddenly the system decided to show me the size of the thing it was formatting after all. I didn't notice it immediately. But then it dawned on me... It was formatting my entire hard disk. That's right, even though I had clearly and explained that it shouldn't touch anything besides these 10 gigabytes that I set aside for the thing, it still decided to go on and format everything. Aaargh! I quickly switched the thing off, and rebooted it to check the damage. Of course, I didn't reboot it by using the system that I'd just corrupted; that would only make matters worse. However, since the Linux partition is near the end of the disk, it could just as well have been so that there was nothing wrong. Unfortunately, that was not the case; my ext3 partition had been corrupted. Luckily, not entirely; I've been able to rsync most of my data to another system, including the list of packages and most of the files in my home directory. But the OpenBSD disk is sooo toast. No, really.

14 April 2006

Aigars Mahinovs: First week in UK

Again, this article is mostly event description that would mostly interest my relatives, but this part of it still goes to the Planet in case someone out there would be interested in how I am doing here. (477 more words in the post)
Continue reading ...

13 April 2006

Martin F. Krafft: Soaking the city

We spent eight hours today, starting at around 10:00 o'clock, completely soaked with water. I had read about the Thai New Year celebration "Song Khran," but I would not have believed it to be as extreme as it turned out to be. But let me start where I left off: Phitsanulok. Following the recommendation of the director of the lower northern Thailand Tourist Authority (TAT), we spent the evening by the river running through Phitsanulok, where the Thai were celebrating the "food festival" -- it seems to me that the Thai, or Southeast Asian folk have a festival for almost anything to make it around the year... The road along the river was banked with little booths selling just about everything, from edible to handicrafts, with fair booths offering games such as darts, jumping castles, and live bands in between. Strolling around, we had a bite of the most appealing things -- I did stay away from roasted cockroaches, maggots, and other bugs this time, for I had already sampled them in Vietnam and felt no particular need to repeat the experience, although it was not revolting back then at all: it's just a little meat with a lot of crust that you don't want to eat, and the taste isn't particular. An excellent meal of noodles with some sort of sweet-spicy sauce, together with a beer and the company of some young Thai boys ended the evening for us and we returned to our hotel rather soon, with the intention to get up early to finish our errands and make a run for Sukhothai. So with our plane tickets and some fresh cash, we set out for "Sgt. Tawnee's Folklore Museum", a private collection of traditional Thai "things" -- tools, traps, toys, instruments, clothing, ... just about everything... Sgt. Tawnee was a poor soldier who realised that people were forgetting about how their ancestors went about to solve everyday's problems and consequently started collecting anything and everything -- a truly remarkable and beautiful collection! After a so-so Thai massage (see forthcoming blog entry), we quit the city by bus to arrive in Sukhothai about an hour later, where we were met by the pickup van of the guesthouse we had booked, also following the recommendation of the TAT director: we are staying at the Ruean Thai Guesthouse, a place with cozy rooms, a swimming pool, and very friendly staff, for about 10 EUR a night -- the best guesthouse I have been to in three vacations in Southeastasian countries, three thumbs up, I can recommend it to anyone coming to the area! We had just settled and taken a shower when the hotel clerk notified us that the director was waiting downstairs to take us to the "light show". We boarded his van, together with his family and colleagues, and drove about an hour to Srisatchamalai Historical Park, where we arrived just in time to witness an impressive ceremony, part of the New Year celebration: old people were sitting in rows on chairs, and younger folk passed from one to the next, pouring drops of water into their hands as a form of respect to the elderly to help them stay cool in the dreadful heat of the month. Naturally, we lined up and did as the others did -- and found us filmed and greeted by a television crew afterwards for an interview. Not wanting to be a burden to the director and his family, we followed the suggestion to stroll around in the park for about an hour, until we returned to the agreed meeting point. There, we found that mats had been rolled out on the lawn in front of one of the temples, and maybe 200 Thais were sitting and dining. The director invited us to join them, and we enjoyed Thai cuisine until dusk, when everyone got up for the national anthem and the show began. At first, a famous Thai singer (so we were told) performed a couple of folk songs and we learnt that, (to my knowledge) unlike European folk songs, the Thai sing songs telling real events in history. A fashion show of old, traditional Thai clothing followed, and finally, the stage was set for a performance of the history of Sukhothai. People were all over the place, fighting, dancing, or just "ruling" (as the king(s) would do), and a voice recounted the story, which one of the director's daughters translated for Aline, I was busy taking pictures. Fireworks accompanied the scene, along with flying objects consisting of a real flame underneath a balloon made of rice paper. Most flew high and far away, some got stuck in trees and went up in flames. After the show, I had a chance to see some of the costumes and must say that I am deeply impressed, not only by how Thai people used to dress, but also by the love and care the people put into the show to make it as authentic as possible. Interestingly, only one other tourist ("fallang") was at the event, something the tourist director wants to change in the future -- good thing we witnessed the "pure event"... I seem to prefer places not frequented by tourists, and in the Thais seem to be continuously surprised that we are not heading for the beaches in the south following our time in the north. Back at the hotel, we fell into bed, exhausted from the day and the nightswim in the pool. I got up this morning to find my ear clogged with water -- must have been the late swim. The guesthouse owner insisted to take me to a pharmacy to find some eardrops, and I hope this nuisance will go away soon. We rented a motorcycle for the day and headed in direction of the old Sukhothai city, or the Sukhotai History Park, as it is also called. Waiting for our photo chip to be beamed to CD, we made our first encounter with the way young people like to celebrate the New Year (which officially started today): all over the city, people rode around on the back of pickup trucks, emptying buckets of water over other people. We bought ourselves a water gun and plunged in for the fun. It didn't take 30 minutes until we were soaked, but nothing could stop us. The old city is maybe 10 kilometres away, and the drive was the most unforgetable motorcycle ride I'd ever had: all along the sides of the road, people were filling buckets and splashing everything that passed -- being on a motorcycle with merely a water gun, and as "fallang" (foreigners), we were naturally the primary target for just about everyone, so by the time we had reached the city, we had soaked up half an ocean each. We stopped by a group of kids, gave our water gun to the smallest one, bought a new one, and teamed up with them to fight the passing vehicles. Oh what fun! Dripping, we made our way to the park after a while, and strolled around some temples, the market, and many more water fights. Even though the water obscured the heat, we still didn't feel like taking the barrels of water we had collected for a walk and didn't last too long before we were on our way back, destined to stop again with our allies (the kids) to make sure no car and no passenger got by unwashed. The Thai also crumble up chalk, mix it with water, and smear it into each other's face -- you can imagine how we looked like after a few minutes: soggy and chalked. Finally, we made a run for the hotel and got back at about 16:00 o'clock for the first time of feeling "dry" in eight hours. Now, after some time at the pool, we are loathing for dinner but daren't go for the city as we are wearing our last set of clean, dry clothing; I doubt the Thai lay their buckets to rest at seven and call it an evening. Fortunately the hotel offers food too, so we'll likely be boring and stay in. Tomorrow morning is our flight to Chiang Mai for more of the wet fun. I'll keep you posted. Thanks for reading along.

Jeff Bailey: Tagging entries

First - I've switched the feed for http://planet.debian.org/ to RSS instead of atom. Atom doesn't work, and apparently never has despite there being a fair number of registered atom feeds.

Second - I'm likely to start blogging comments about religion. I think most people who know me know that I'm a UU and have been now for about half of my life. So this isn't new - I'd avoided posting religious things in my blog before because the software that I was running at home had no method for trivially separating things based on tags. I moved to LJ a while ago, and I think it has this. The question is what's the best way to keep things posted to planets without those entries? Is there some sort of a thing I can setup that says "make a feed for everything that *isn't* tagged religion?" If you have an idea, let me know. Or perhaps people don't care, in which case don't worry about it. =)

(Why doesn't the LJ spellchecker include obvious things like "RSS", "Blogging", and "href"?)

Christine Spang: Some Things I Learned at MIT s Campus Preview Weekend

12 April 2006

David Welton: Ruby vs Tcl, round 2

Ding ding. (Round 1 - for those who missed it) Kidding aside, remember that I like and respect both of them. Libraries In the first article, I mentioned that Ruby has a lot of momentum, which is a pleasant change from Tcl's relative 'uncoolness' amongst the Web 2.0/O'Reilly/"next big thing" crowd. That said, there are still places where that momentum hasn't taken it. I set about writing some code that I'd wanted to play with that involves sending some email. Something that's very easy in Tcl: http://tcllib.sourceforge.net/doc/smtp.html (towards the end of thepage). Python seems to have a pretty complete email system too, for that matter: http://docs.python.org/lib/module-email.html. So it appears that, based on a sample of one attempted task (how's that for statistics?), that Ruby is still lacking a few things in its standard distribution. Note that this functionality is available elsewhere (TMail, to cite one), but email is ubiquitous enough that it ought to be in the standard library. Command line swiss-army knife While Ruby's OO system gives it a head start when you need to create a larger system with distinct parts, it can still be used as a quick'n'dirty scripting language for quick one-off jobs. From the man page:
% cat /tmp/junk
matz
% ruby -p -i.bak -e  $_.upcase!  /tmp/junk
% cat /tmp/junk
MATZ
Very handy. Tcl's command-based syntax just isn't quite as quick for those sorts of operations, so Ruby wins hands down here. I've suggested that the Tcl folks distribute a second program that takes a lot of the Perl-style command line arguments for this sort of work, but the idea doesn't seem to be of much interest. C API's On another tack completely, one of the things that originally drew me to Tcl was its very, very nice C API. It's documentation is clear, and thorough, and the API itself lets you get involved in pretty much any aspect of the language that you want. This makes sense, because when Tcl was originally created by Dr. Ousterhout in the late '80ies, the idea was to create a scripting language as a C library that would be loaded into other programs. The language has always been faithful to its heritage, and to this day I find it lots of fun to merge Tcl with C code. I have to admit that I don't know the Ruby API all that well, but what I have looked up looks pretty nice. To a certain degree, it's comparing apples and oranges, because Ruby requires you to deal with the very object oriented nature of the language, whereas Tcl is a lot more direct. The Programming Ruby book's coverage of the subject also leads me to believe that Tcl really gives you access to more stuff (interpreters, channels, events, and many other parts of the system). Ruby seems to take an approach that might best be described as letting you write Ruby in C - meaning that you create Ruby objects, use their methods, get their values, and so on, but you're still really dealing with Ruby. This has a certain elegance, but sometimes it's necessary to muck about with things at a lower level. I don't know how it works out in practice, but Ruby has a bit more infrastructure in place for actually building extensions once you've created them. Tcl has "tea", which is a set of m4 macros, but anyone can tell you that the auto tools are not much fun to work with (going to the dentist is more fun) - anything that keeps me away from them is welcome. Garbage collection One of the more interesting aspects of the different approaches to C interoperability is the fact that Tcl uses a simple, robust, straightforward reference counting system to keep track of, and throw away resources that are no longer used. Ruby has a mark and sweep garbage collector, which is probably more sophisticated, but also more complicated, and requires a bit more support from the programmer initially. The benefit is that once things are set up, they require less keeping track of, because you hand off memory management to the computer. From the end user's point of view, Ruby wins here, but if you happen to be writing a C extension, I could see it being more difficult to write and debug to this API, although Tcl has its own warts, one of the worst of which is the fact that Tcl values must be convertible back and forth to strings, so that for things like a file handle that can't really survive the round trip, because it's just a pointer, you use a hash table and some sort of string to hold onto the object:
 "file1" -> int fd1
 "file2" -> int fd2
which makes it impossible to GC these values. I suspect that both approaches have their merits - Ruby's is more elegant, but Tcl's is simple and rugged. Licensing Bouncing back to something completely non-technical, Ruby's licensing is either the GPL, or their own license. If I understand things correctly, you can get around the GPL's "viral nature" by simply renaming things, if you have a need to include Ruby in a proprietary product:
  1. You may distribute the software in object code or executable form, provided that you do at least ONE of the following: a) distribute the executables and library files of the software, together with instructions (in the manual page or equivalent) on where to get the original distribution. b) accompany the distribution with the machine-readable source of the software. c) give non-standard executables non-standard names, with instructions on where to get the original software distribution. d) make other distribution arrangements with the author.
So it seems that you're ok if you just call it something else. However, the license goes on to talk about several other files in the core distribution:
  1. You may modify and include the part of the software into any other software (possibly commercial). But some files in the distribution are not written by the author, so that they are not under this terms. They are gc.c(partly), utils.c(partly), regex.[ch], fnmatch.[ch], glob.c, st.[ch] and some files under the ./missing directory. See each file for the copying condition.
Looking through the LEGAL file in the distribution shows that there are files distributed under other terms. Of course, they're all free software, but some are LGPL, some BSD, and a few others for good measure. Tcl's licensing, on the contrary, requires very little understanding. The language was developed at the University of California, Berkeley, and the license remains BSD. This goes for many of the libraries and extensions as well. If you need to embed a language in your proprietary system, Tcl and its libraries present no problems whatsoever. Of course, I prefer to work with open source code and communities, but that's not possible 100% of the time, so it's always nice to know things are free and clear, should that need arise. Internationalization This is something the Ruby folks know they need to fix, and are working on, so it's not worth dwelling on it much, but it is a proud point for the Tcl community. Tcl has had very nice i18n setup for many years, at this point - since the 8.0 release. It's built into the language, so that everything works with it. You have commands to set encodings of IO channels, and even munge strings. Tcl wins here - no contest. As I continue exploring Ruby, I think I'll find more stuff to compare with Tcl, so we won't ring the final bell just yet.

John Goerzen: Tuttle: Neither Gone Nor Forgotten

So just when I thought the whole Tuttle story had wound down, more starts appearing.

The Register has a new article: Only "freaks" waste their time with Linux in Oklahoma. In it, they posted a video clip from an Oklahoma TV station that called Tuttle "an international laughing stock." Quite a funny little piece. The Register also mentioned that the Tuttle city manager left work when he heard a TV crew would be there to interview him. Favorite quote:

Instead of a website, Taylor discovered an Apache server configuration page that mentioned CentOS. He's an Oklahoma man, and the Apache feather must have proved frightening.


Today's next little piece of fun is this page at the Tuttle Times. Look on the right, under Links. See the link that reads "Example of CentOS test page"? Notice where it points to. Yes, that's right, www.tuttlechamber.org. Click on it, and sure enough, up comes the infamous test page. So the Tuttle Chamber of Commerce apparently is getting ready for round two...

And while we're speaking of the Tuttle Times: they have published a letter to the editor from Johnny Hughes, the CentOS lead developer that was on the other end of those exchanges with Tuttle. I think Johnny wrote an excellent little piece there.

And finally, another funny headline from the Tuttle Times homepage: "Prosecution attorney presents complete case." I am glad to hear that at long last this terrible scourge of incomplete cases has been brought to an end. But beware, this shocking story is not over yet! The next article is "defense raises compelling questions." Another first for Tuttle?

Aigars Mahinovs: Berlin Schoenefeld airport rant rap

Berlin Schoenefeld airport first impressions - chaotic, lots of long walkable corridors and staircases without elevators, outdoor walking stretches, anal security with super extra checks announced on loudspeaker, (luckily) lacky computer system, Huge gaps between connections, terrible tax free zone where CCs are not accepted, no power in sockets, no free wifi, existing wifi doesn't work, mini mirrors in pissoirs, 1 monitor per 200+ meters, usually not visible from sitting places, some monitors do not show all info, impossible to find out where the flight will be until it is open, no healthy food in tax free zone at all, delays are announced in German but do not show up on monitors, no seats near gates. I'll expand this article with more details when I have more time (yeh, like that's going to happen :P).

Lars Wirzenius: Random hacks: doc-get

I often want to save interesting web pages on my own disk, so that I have a copy even off-line, or in case the page goes away. Occasionally a bit of a pack-rat I am, yes. Web browsers can do this, but not in a perfect manner. For example, Epiphany does not save all embedded objects (images), so viewing the saved page can result in images being loaded from the net. Another problem is that I'd like to record the URL of the page that was saved, in case I want to go back some day. And finally, I would like to be able to get an entire multi-page document (say, a manual) in one go. The other day I played around with wget options, and came up with this set:
wget -N -nd -k -p -H -P "$dir" "$url"
This seems to work fairly well so far. I've wrapped it in a little shell script I call doc-get. It doesn't do the multi-page document thing yet, but I'll look at that later. More things that doc-get might do, but that I'm probably too lazy to implement in the near future: updating an already saved document; better heuristics for the name of the directory (currently it's date + MD5 of URL); having a central registry of saved documents, so that you can do "doc-get --update-all" and refresh everything; inventing something to make it easy for publishers of free documents (say, much of the Creative Commons stuff) easily downloadable by doc-get, even if their directory structure is complicated.

Martin F. Krafft: Asian women and western men

Following yesterday's blog entry, a derogatory comment reached me why we would be spending the evening with the sort of girl that would go to hotel with foreign men. This prompted me to write a short note of how I see the position of the women in these countries with respect to this subject. I hope you are aware that this is a delicate topic, of course, and that I write nothing but about my own perception and interpretation. There are two types of women who'll readily engage with foreign men: those receiving money for a night and those looking for more. Nothing needs to be said about the first. As for the second, I can understand their position very well, and if it weren't for assholes coming to this country trying to "score" and exploiting their position, there'd be nothing to be said against it. For the young women in these parts of the world, foreign men are attractive for two reasons: first, they have money, and thus give them the hope and maybe even a chance to live a better life then they are forced to. It is very unlike Western women seeking rich men to buy them lots of jewelry, for the women here it's more a question of existence. On the other hand, the women here seem to prefer Western men, since they are generally perceived to be more gentle and "good". I have been told on numerous occasions now that it is not uncommon for Asian boys to beat their wives when drunk. Unfortunately, the situation seems to be bad enough for the women to forget about the chance that Western men may do the same (and I'd believe more do than we would be willing to admit). So in the end, the girl we met was far from a "prostitute", and having talked to her, it hurts me that she should be perceived as such by some of my readers. I'd much rather spend time with her at a club than most of the superficial girls you'll find in the Western world.A I hope this sets things a little more straight.

11 April 2006

Anthony Towns: Developers and Maintainers

My first blog post after winning the Debian Project Leader election. Scary. Links so far: debian-project, Slashdot, ZDNet Australia. I’m trying to make sure I’ve got something vaguely new to say before replying to press requests, and to also make sure I say anything new on some Debian forum first, and given there’s one I’m replying to tonight, well, you do the maths… So my tentative theory is to put together a list of ten-twelve “interesting projects” to push forward over the course of the year, in theory one a month. The idea is that’ll stop me from letting my time be taken up reacting to things – whether that be problems, questions, the press or what have you – and thus losing control of what I’m doing, and that it’ll also force me to keep moving onto new things regularly, and also to actually “finish” them too so they don’t cause an ongoing distraction. My current list of topics is: maintainers; partners; extended suite support; constitutional stuff; non-free; distributed leadership; localisation/specialisation; livecds; the etch release. Those are just heading to roughly remind me of various s3kr1t pl0ts I’ve thought about in the past, and you shouldn’t read too much into it – you’re welcome to think about them yourself, and get inspired though. And I’m sure I’ll change some of them around over the next few days; but one that won’t include the first one, which is something that I’ve been thinking about for most of the year now. I’ve talked about it privately with a few people over drinks and IRC, and it looks like it’s basically at the point where it seems sensible to everyone, and just needs to be coded up. But enough teasing. There are a few ways to explain the concept, this is the one I prefer. The idea is to do away with the whole concept of “sponsored uploads”, and replace it with a more formal and efficient way of doing the same thing. Sponsorship has a few significant problems: first, it makes it harder to work out who’s actually responsible for an upload when you can’t just rely on the name in the changes file; second, it puts a roadblock in the way of getting bugs fixed in the sponsored package – you don’t only have to have the fix ready, you have to find a sponsor with free time to check your work and upload; and third, it confuses who is responsible for broken packages: the sponsor for not doing sufficient checks, or the packagers for not getting it right in the first place. The obvious way to fix the first problem is to make dak check that the key used to sign the .changes files uploaded actually matches the person listed in the .changes file as doing the uploading. But of course, that alone would kill off sponsorship, and thus make a fairly large number of packages (does anyone know how many?) essentially unmaintained, and also make it harder to prove you know what you’re doing when going through the new-maintainer process. Interestingly, the obvious way to solve the second and third problems is also to do away with sponsorship, but in a different sense – namely by letting the packager upload directly. Of course, that’s unacceptable per se, since we rely on our uploaders to ensure the quality of their packages, so we need some way of differentiating people we can trust to know what they’re doing, from people we can’t trust or who don’t yet know what they’re doing. Of course, there’s not really anything stopping us from doing that; and it’s something that’s been suggested before – it just means that as well as separating some contributors to the project out as “Debian Developers” after passing the new-maintainer process, we need some other level of people who’re trusted to do what sponsored packagers currently do – maintain a single package, after getting vetted by a developer. And basically, that’s what I think we should do; and I’m calling the intermediate level “Debian Maintainers”. The idea is that while a Debian Developer (DD) can do everything we currently can – upload NEW packages, NMU each others packages, hijack packages in extreme cases, and so forth – a Debian Maintainer (DM) can only maintain a specific package, after being authenticated by a DD in three ways: first to ensure they’re a real person via the usual key signing mechanisms, second to ensure they can be trusted to understand what uploading to Debian involves, and third to ensure that they understand what’s involved in maintaining a particular package before being given rights to upload new versions of that package. Hrm. This is getting too long, so I’ll leave commenting on implementation details for later, and close with some of the possible implications on how Debian works. One thing is that it means is that it adds an extra way in which you can contribute to Debian; from just using it, you can move to helping other people in usergroups, to contributing bug reports, to helping fix bug reports, to sending the maintainer patches to upload, to becoming a DM, to becoming a DD. Another thing it means is that the DAM role becomes somewhat more decentralised; suddenly every DD can vet new contributors, though in a far more limited way than the DAM and FD does. Another thing is that the utility of being a DD both rises and drops: if you just want to maintain some package, being a DD instead of a DM is pointless; but on the other hand, this is a new ability DD’s don’t currently have. It’s possible that might have a flow-on effect to new-maintainer, meaning that fewer people bother with it – giving AMs more time – or that the people who do bother with it need to be more thoroughly tested, or tested on different areas – giving AMs less time. Another thing it means is that there’s the possibility of more central control over who can upload than sponsorship allows – rather than only looking at which DD is involved and which package is involved, we’ll have signatures by the person who did the actual packaging directly. And of course if we have their key anyway, we can – if we choose – allow that key to sign votes in elections, with whatever limitations we might choose, such as requiring they be a registered contributor for over six months before voting, or that their votes are advisory only rather than binding, or that they can only vote in some elections, or that their vote is weighted less than a DD’s vote. And, of course, we could try different arrangements out and see what effect they have. This is a big thing, so it needs to be done with a great deal of care. In particular, it seems like the best way to handle DMs will be to do so almost entirely automatically (rather than add extra tasks to keyring-maint or the new-maintainer team eg), which means both that the scripts need to be written with extreme care, and probably also that all the information they work with be completely public so that it’s easily auditable. The current theory is that becoming a DM should work roughly like:
  1. work with some developer, by helping resolve bugs, providing or testing patches, and otherwise demonstrate you’re interested and sensible
  2. ask that DD to send an advocate mail to a bot supporting your desire to be a DM
  3. reply to an automated mail from the bot, indicating you support the social contract, agree with the DMUP and constitution etc
  4. receive an acknoledgement from the bot that your replies are in order, that your key is signed by a DD other than your advocate, and that you’re a registered DM
  5. ask that DD (or another) to upload a new version of the package you want to (co-)maintan with your name and email address added to the Maintainer: or Uploaders: field
  6. maintain the package directly
So that’s the theory. More detailed thoughts on the implementation later, hopefully after I’ve caught up on some sleep. I debated a bit where to send this – since I expect trying to get this idea happening will be my main focus this month, maybe it would be better off on one of the Debian lists; but on the other hand, it’s a bit more half-baked than I’d feel comfortable posting to -devel-announce, and I suspect just posting to -devel would miss some people it shouldn’t. And hey, it’s not hard to forward a url, or just cut and paste the whole thing, right? Discussion (probably on debian-devel) encouraged.

Martin F. Krafft: More luck than brains

It's been a busy three days since I last wrote. The climax (or lowest point) must have been the loss of my wallet with about 800 Bhat of cash (16 EUR) and a credit card inside. I left in on a telephone in a bus station in Khon Kaen during a very stressful moment trying to get to our next destination. Luckily, within ten minutes I noticed the loss and could cancel the credit card, so the damage is minimal (although I should hope that one day it hits me hard because I apparently never learn and leave my things all over the place -- like the camera on the return trip from Zanzibar/Tanzania). Anyway, shortly after the loss, we ended up in a very fortunate situation ("more luck than brains"), but more on that later. Last time I wrote, we were in Khorat, headed for Phimai the same evening. With about four hours to spend, we opted for a massage, and I chose the traditional style with a weighty woman bouncing up and down my body and twisting it into unnatural shapes. Nevertheless, I felt absolutely great afterwards and am looking forward to the next time. The massage took a little longer than expected, and when we finally made it to the laundry place to pick up our load, they had just closed. But nothing is impossible in Asia, and soon we had one person tell another to find the owner in a hairdresser shop, and she happily made an exception and handed over our bag. Feeling very good, we headed for the bus terminal to find the bus leaving 90 minutes later than planned, so we spent the time watching the busy life of Thais departing and arriving before riding for 90 minutes to Phimai, where we had to wake the owners of the guest house despite having called in earlier to let them know of our late arrival. The room was spartan but moderately clean, and we passed a night only disturbed by the continuous sounds obviously made by cockroaches, though none seemed to be in our room itself. Jokingly, I remarked that there is nothing to worry as Thai cockroaches would take off their shoes before crawling onto the bed, but I am yet unsure whether that was reason enough for Aline to finally drift to sleep. Phimai is a tiny town housing a beautifully restored Khmer temple, said to be the best preserved in Thailand. Without a guide, and with the heat picking up to a stifling level already at 9:00 o'clock, we decided to better spend the time in a bus, traveling north to Udon Thani, but first spent a visit to the Phimai national museum, and the "Banyan Tree," a huge assembly of trees with Thais picknicking in its shade. Leaving Phimai with a bus, we had to hop on another in Thalak Ke, about 10 kilometres away from Phimai, but our initial joy of catching an air-conditioned ride for the 4 hour trip to Udon Thani was severly lessened when the bus pulled in and was completely crowded. We stood pressed against each other for the first 90 minutes of the trip, until we reached Khon Kaen, where lots of people got off before lots more got on, but we were able to get seats in between. Having arrived in Udon Thani, the plan was to leave the same day for the Laotian border to catch a boat along the Mekhong river to Chiang Khan, but that seemed impossible without a visa for Laos, which is $30 per person and a little too much for the joy of the journey. A little disappointed, we stayed in a luxurious hotel (10 EUR per night) and strolled around the city at dawn, chatted a while with a Welsh expat about old European men coming to Thailand to find women, and finally headed for the Mandarin restaurant, suggested in the Lonely Planet. The place was sketchy, with a loud television set blasting some Thai soap opera, and the staff really misunderstood the meaning of "appetiser" and "vegetarian", so that I ended up eating a giant plate of "Chinese Hors d'Oeuvre", Aline's spring rolls with shrimp paste, and the Pad Thai I had ordered. They forgot the noodles, and Aline's Tofu portion was too hot, but our tummies stuffed, and we sank into bed early. The night was horrible, I was plagued by stomach aches and the fear of a repeated experience -- the last time I ate Pad Thai along this meridian was in Vientiane, and I came down with food poisoning, and I felt exactly the same way as back then throughout the night and morning. I stayed in bed long but fortunately found that I had just put too much food into my belly (which wasn't used to it, we had been eating sparingly), and walking solved the problem. Weighing our options, we decided on the route of the next two days. Initially, it was to be Loei and the Phu Kradung National Park, but seeing that it was a little too difficult to reach with public transportation, we decided to head back to Khon Kaen, forget about Udon Thani and the lost day, and continue to Nam Nao National Park along the route 12 between Khon Kaen and Phitsanulok, with an optional stop shortly after Lom Sak for some whitewater rafting. It was after being told that all busses were overbooked (remember, Songkrat, the New Year's festival bringing every Thai back to his home, starts this week) and our furious attempts to find a hole to slip through that I left the wallet on the telephone. I noticed the loss on our way to the other bus terminal, but it was too late, and it didn't help that nobody spoke English anymore (basically ever since we left Ayuthaya). As said, the money wasn't a big loss, the credit card immediately cancelled, driver's licence and insurance cards also being no biggie, but the wallet still contained one item of interest: the receipt for the cargo bag with the children's clothing waiting for me in Chiang Mai (hopefully). We had our friendly Tuk Tuk driver took us to the tourist police to file a report, with which we should be able to reclaim the bag even without the receipt -- Aline also fortunately took a picture of the bag. But the tourist police was out for the day and as we came to realise the misery of our situation -- it was about 18:00 o'clock by now and we were looking at losing another day on our journey, a friendly women with very good skills of English walked around the corner and told us to hop on her car. We were so glad to be able to follow someone's command that we didn't even ask where she was taking us, but on the back of the pickup, we learnt from her two students that she was an English teacher taking us to the police headquarters. There, we got the report and again boarded the pickup heading back to the city. We still did not know how to continue from Khon Kaen towards Phitsanulok in the lower north of the country, but the lady offered to negotiate a rental car for us after heading to another police station to help her student with a report against a British man, who had left her in the top-end hotel without paying the bill. Fortunately, she knew the real name and telephone number of the guy, so he'll surely get his share, that bastard. The rented car with driver to Phitsanulok would cost us between 4000 and 5000 Bhat (80 to 100 EUR), which we thought was too expensive, and it was again our lady friend who decided to head for the busses again and try her luck. She got us on a 2nd class bus to Phitsanulok, leaving Khon Kaen at 3:45 in the morning, and with about 7 hours to kill, we took her and her two students for dinner and to a discotheque as a form of thanking her for her help. Her name, by the way, is Jill, and she runs the "Khon Kaen Language Centre", teaching English, Japanese, German, and Spanish to about 20 students, half of whom live in her own house as they come from far away. We talked much with her and her students that night. Dinner was a huge buffet with everything you can imagine, including cow stomach and pig intestines (and yes, I tried them both, though I need not do that again), and grills at the tables for a very cozy atmosphere (if it hadn't been for the live band that was playing just a tat too loud). Jill apparently spends her days helping other people, not only learning languages; people come to her for relationship troubles, legal issues, or other difficulties such as my lost wallet. She does not choose to help people, but feels that as a Thai, she must. This attitude prevails throughout the population (as soon as you leave Bangkok and the tourist centres in the south) and is maybe the most important reason why this country is such a great place to be. After dinner, we ended at a discotheque with another live band, including singers and dancers, and even though it was clearly too loud for my taste, the band was very good, and we had a splendid time getting drunk on Thai beer -- after all, what else was there to do until the bus left. I also found out that Jill runs an Internet cafe and consequently left her with 10 Ubuntu CDs to try out, and give away to her computer-savvy students. It was great to explain to her what "free of charge" means, but very hard to actually get her to accept it. After the discotheque, she took us to her house for showers and a quick meal, and I tried to demonstrate Ubuntu to her, but did not succeed within the small time frame I had available. The reason was that her house uses static IPs, and I could not figure out how to tell the Live CD to use a static IP -- it did not ask me. Anyway, this isn't anything I cannot solve via email once I return to Switzerland. We left the city on time and were looking at 5:30 hours of an uncomfortable, rocky bus ride, but thanks to ample space, it went by quite quickly. We gave up on the plans for the national park and postponed the "experience of nature" until Pai (see below), and also found out that April is not the month to go whitewater rafting in Thailand, so without any stops, we reached Phitsanulok and quickly headed for a hotel to sleep through the midday heat, a little too long unfortunately to still get some errands done, like cashing traveller cheques. I am now sitting in an Internet cafe in Phitsanulok, and we did get most of our to do list done. We'll stay here for one night, enjoying the "food festival" over at the night bazaar, and head for Sukothai tomorrow. Having made the acquaintance of a very helpful employee of the Thai Tourist Authority, we now have the possibility to ride along in his van tomorrow, iff he makes it back from Bangkok in time; otherwise we'll go by bus and meet him there for another festival and a light show in the old city of Sukothai, which is now known as the historical park, which the Lonely Planet describes as "Thailand's most impressive World Heritage site". Also, tomorrow, Songkran starts in Sukothai (a day before the official start), and we have been told that Sukothai is one of the two best places for the event on numerous occasions. The other is Chiang Mai, and we were lucky to get two seats on a plane leaving Sukothai for Chiang Mai on the 14th, so we'll get to spend more or less two days in each of the "party centres" (Songkran ends on the 15th, though some cities just keep on going). I have to say that I am very excited about witnessing this event. All the shops in all the towns keep piling water guns on the streets, and for three days, the camera will be better left in the hotel as the entire city soaks itself in water. I cannot wait to buy one of the biggest guns, make a run for the all the Thais, and then give the gun to a child. While I am talking about plans, I might just as well continue my brain dump. From Chiang Mai, we are currently looking at 2-3 days in Pai, a village north-west from Chiang Mai with beautiful landscapes and many hill tribes within walking distance. I'll be leaving Chiang Mai for Yangon in Myanmar, and am currently faced with four choices as to how to spend my remaining time in that country. Mind me while I share these options with you: The simplest options would have me drop the clothing and gifts off at Julie's guest house; Julie is Swiss or German and frequently organises for clothing and similar items to be sent to refugee camps in Myanmar. Then, I could travel to Myanmar and be free to spend the time in Yangon and Mandalay, showing Linux to people, head out into the countryside, or spend my time in the monastery to which I have been invited. These options all appeal to me, approximately in decreasing order. The last option depends on whether Julie organises a trip to a refugee camp anytime soon, in which case I may be able to go along. I'll keep you posted. That's it for now from me from southeast Asia; we're off for the night bazaar. Thanks again for reading along.

7 April 2006

Wouter Verhelst: DFSG vs GFDL

One of the things that has kept Debian in heated discussion over the last few years is the question whether the GFDL, or the GNU Free Documentation License, is free according to Debian's own DFSG. We've had three votes on the subject, with the final one decisively saying it's conditionally free. Or so I thought. Yesterday, Josselin Mouette proposed another GR on the subject, since he believes there's a conflict between GR 2006 001 and the current text of the DFSG. Sigh. At least he isn't trying to reverse the effect GR 2006 001. But still; no, the GR does not conflict the text of the DFSG. I used to think otherwise, but got swayed by the discussions on -vote that occurred prior to GR 2006 001, especially (strangely) the one that happened as a result of Anton Zinoviev's amendment, which ended up as choice #3 on the ballot. At the the time, I was supportive of the original proposal to throw out all GFDL-licensed documents, even though I disliked doing so (for obvious reasons); but I felt that the arguments about the DRM clause did hold. This was wrong, and it took me an insult to see it. Quoting Anton, myself, and Craig Sanders:
This clause disallows the distribution or storage of copies on DRM-protected media only if a result of that action will be that the reading or further copying of the copies is obstructed or controlled. It is not supposed to refer [to] the use of encryption or file access control on your own copy.
No; however, as written it can be interpreted as such.
only by nutcases with an agenda. normal people (including lawyers and judges) wouldn't have such an insane and insupportable interpretation. that's because normal people rely on facts. and evidence. they don't just make up whatever crap they need to suit their argument.
Craig's way of saying things did not immediately have the intended effect; and had I not grown tired of the discussion, I probably would've missed it. But the fact that I stopped following the discussion gave me some time to think about it, and as such, Craig's argument had a chance to sink in. When I was finally swayed, I failed to attribute it to Craig, however, instead thinking it was an argument by Anton that did it. The point is this: the mere fact that you're able to construct an interpretation of a license which is logically sound and complies with everything, does not mean that it is a sane interpretation. Lawyers and judges, strange people though they might be according to some jokes, are still people; human beings. If you come up with an interpretation that nobody in court came up with on the first reading of a given text, then chances are rather high nobody will follow you. That's what really matters: whether something you claim will hold in court. Not whether something you claim holds up to your own argumentation. And yes, claiming that doing chmod -r, or storing something on an encrypted filesystem is somehow restricting distribution, seems a little far-fetched. After all, when I'm storing something on my own hard disk, or even in the privacy of my home-directory on a large shared fileserver, I'm not engaging in a distribution of any kind.
From WordNet (r) 2.0 (August 2003) [wn]:
  distribution
      n 1: (statistics) an arrangement of values of a variable showing
           their observed or theoretical frequency of occurrence
           [syn:  statistical distribution ]
      2: the spatial property of being scattered about over an area
         or volume [syn:  dispersion ] [ant:  concentration ]
      3: the act of distributing or spreading or apportioning
      4: the commercial activity of transporting and selling goods
         from a producer to a consumer
Definition 3 and 4 seem to require an active action by the originating person; when someone copies a file from your $HOME, you didn't distribute the file to them; they took it from you. In our culture of sharing is good, you should share!, I missed it; but a court would probably see copying without asking for permission more as stealing, rather than distributing. After all that, the arguments about the DRM clause being too broad seemed a bit weak to me; and given that the FSF had already agreed on it being a bug which needed to be fixed, as they had for the other arguments against the GFDL (apart from the Invariant sections, which are not being discussed here), made me decide that the big giant insane problems with the GFDL are not so much of a problem as most people seem to claim.

6 April 2006

David Welton: Language Design - weak types and easy marshalling

Weak/Dynamic typing One of the things I really like about Tcl is how very, very dynamic it is. It's possible to replace just about everything 'on the fly', including control commands like if and while (in Tcl, they're just commands, not special syntax). Like Lisp, Tcl gets a lot of its flexibility from its simplicity, and one of the ways that things are kept simple is via the concept of "Everything Is a String". Some people erroneously recall the early days of Tcl and take this to mean that Tcl represents everything as a string internally, making it very slow for numerical operations. That hasn't been true for something like 8 years - Tcl values are translated into a more appropriate internal representation 'on demand'. However, the concept still gives you lots of flexibility:
set a b
You don't have to quote things - they default to strings - the variable 'a' now contains the value 'b'.
set lst  a b c d e 
No fiddling around with lots of syntax - the above is defined as a string (we could have used "" to group the words), but it gets turned into a list
llength $lst
5
Things are automatically converted into the type you want to work with. Of course, this also makes it really easy to work with code as strings and vice versa:
proc until  cond code   
    while  1   
        uplevel $code
        if   [uplevel [list expr $cond]]     return  
     
 
set i 0
until  $i == 10   
    puts "i is $i"
    incr i
 
and so on and so forth. Ruby (and Python) handles things a bit differently than Tcl does. Even though it's still very dynamic, it is more strongly typed:
"5" + 5 # error
Whereas the same code runs just fine in Tcl - "5" is transformed into a number, because if the programmer is trying to add to it, they must want it to be a number. On the other hand, strong typing can help catch errors, may help make things clearer, and in corner cases, probably helps catch nasty surprises. One of the things that Tcl's system facilitates, at least with simple types (lists, strings, numbers, dicts) is 'marshalling' or 'serializing'. Want to send a hash table down a socket?
 puts $sk $mydict
 # And on the other side:
 gets $localsk mydict
 dict get $mydict key
When you start treating it as a dictionary, it "just turns into one" - or throws an error. Good programmers will check for errors, but that goes for whatever language you use. This often comes in handy for code-creation, as well - it's very easy to build up a string programmatically and then evaluate it, much as you might do with a list in Lisp. It also makes coding short scripts... well, shorter, because you don't have to fiddle around telling the language what you mean, in most cases. Treat it like how you want to use it, and it will work out what you want to do. Hecl Hecl comes into the picture, because I've borrowed a lot of design ideas from Tcl, but the language is still used by only a few people, so we're free to hack on it and change things that we don't like about Tcl. Lately, we've been having an interesting debate on the merits of Tcl style weak typing, vs stronger Ruby-style typing, as well as the string representation you get when you attempt to print a type: http://sourceforge.net/mailarchive/message.php?msg_id=15254941 http://sourceforge.net/mailarchive/message.php?msg_id=15254942 There are certainly some things that could be improved in Tcl's way of dealing with things - one area where it doesn't do so well is in dealing with NULL values - you can't really deal with that in a string, because a blank string is different from no value at all. Wolfgang would like to go towards more Ruby-style values. I'm willing to consider most anything at this stage, because it's interesting, and I like going over the possibilities, in order to make Hecl as useful as possible. "Everything is a string" has its limits in Tcl, in any case, because what ends up happening is that 'complex' types (files, say), are tied, via a hash table, to the C struct that actually implements them, meaning that the string representation is really only a pointer to something else, and isn't "meaningful", as it is with lists or dicts. I think, though, that in this case I'll mostly want to keep types weak/dynamic, as Hecl aims to be a complement, not a replacement for Java, so in many cases, I'd rather see it make nearly the opposite design decision, where it's reasonable. We'll see, though, who knows what 'type' of interesting compromise we might end up with. Of course, I'm always happy to see new people join the discussion.

Next.

Previous.