Search Results: "ema"

13 April 2006

Wouter Verhelst: X.Org 7

If you're using Debian unstable on powerpc and haven't done your update today yet, might I suggest you hold off on that for a few days?
apr 13 09:14:28 <Yoe>	xorg 7 also seriuosly messed up fonts
apr 13 09:14:48 <Yoe>	"display" from imagemagick doesn't work anymore, and neither does rxvt-unicode
apr 13 09:15:02 <Yoe>	so how am I supposed to do *anything* useful, now? ;)
apr 13 09:15:04 <simonrvn>	i've been using 7 from experimental, so i had to change my fontpath in xorg.conf
apr 13 09:15:10 <simonrvn>	was
apr 13 09:15:19 <Yoe>	oh?
apr 13 09:15:36 <simonrvn>	/usr/share/fonts/X11
apr 13 09:15:39 <Yoe>	is that documented somewhere?
apr 13 09:15:42 <Yoe>	ah
apr 13 09:15:55 <simonrvn>	might be, not sure
apr 13 09:16:16 <Yoe>	hmm
apr 13 09:16:16 <simonrvn>	though don't remove the old ones, add those, since some of the packages still use the old path
apr 13 09:16:26 <Yoe>	well, not here, aparently
apr 13 09:16:36 <Yoe>	my FontPaths all point to /usr/lib/X11/fonts/misc,
apr 13 09:16:37 <simonrvn>	if it is, either BTS or one of the READMEs
apr 13 09:16:44 <Yoe>	s/misc//
apr 13 09:17:06 <Yoe>	and /usr/lib/X11/fonts is a symlink to '../../share/fonts/X11'
apr 13 09:17:11 <Yoe>	which does not exist.
apr 13 09:17:27 <ejka>	Yoe: dpkg -l xfonts-base
apr 13 09:17:41 <Yoe>	that's installed
apr 13 09:17:53 <Yoe>	... but still the 6.9.0 version
apr 13 09:17:53 <ejka>	Yoe: version
apr 13 09:18:04 <simonrvn>	l /usr/share/fonts/X11/75dpi: -rw-r--r-- 1 root root 4.1K 2006-04-11 00:32 charB08.pcf.gz ....
apr 13 09:18:41 <Yoe>	ah
apr 13 09:18:51 <Yoe>	xfonts-base depends on xfonts-utils, which isn't available (yet)
apr 13 09:18:59 <Yoe>	so I s'ppose I'll need to wait another day
apr 13 09:19:02 <Yoe>	(powerpc here)
apr 13 09:20:25 <ejka>	Yoe: for now you can add fontpaths /usr/X11R6/lib/X11/fonts/ misc,... 
apr 13 09:20:49 <simonrvn>	xfonts-utils *just came in to ppc today (sid)
apr 13 09:20:55 <simonrvn>	*just*
apr 13 09:21:10 -->	gismo (i=luca@129.194.56.110) has joined #debian-devel
apr 13 09:21:37 <Yoe>	right
apr 13 09:21:42 <Yoe>	brb, restart X server
apr 13 09:21:43 Tcl interface unloaded
apr 13 09:21:43 Python interface unloaded
**** LOGGEN GESTOPT OM Thu Apr 13 09:21:43 2006
Hah.
wouter@country:~$ startx
bash: startx: command not found
wouter@country:~$ X
X: cannot stat /etc/X11/X (No such file or directory), aborting.
wouter@country:~$ su -
Password: 
country:~# apt-get install xserver-xorg
Reading package lists... Done
Building dependency tree... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
Since you only requested a single operation it is extremely likely that
the package is simply not installable and a bug report against
that package should be filed.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
  xserver-xorg: Depends: xserver-xorg-core but it is not installable
                Depends: xserver-xorg-video-all but it is not going to be installed or
                         xserver-xorg-video but it is not installable
                Depends: xserver-xorg-input-all but it is not going to be installed or
                         xserver-xorg-input but it is not installable
E: Broken packages
country:~# apt-get install xserver-xorg-core
Reading package lists... Done
Building dependency tree... Done
Package xserver-xorg-core is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
E: Package xserver-xorg-core has no installation candidate
country:~# apt-get build-dep xserver-xorg-core
Reading package lists... Done
Building dependency tree... Done
E: Build-Depends dependency for xserver-xorg-core cannot be satisfied because no available versions of package libxmuu-dev can satisfy version requirements
Believe me, it's painful to have no X server available. Update: okay, by getting packages from experimental I've been able to get myself a somewhat working X again. Except that xkb doesn't load my modified keymap, which is horrible, and setxkbmap refuses to do anything when I say "setxkbmap wouter" and, on top of that, quits by segfault for good measure. I'm hoping that's fixed in the version that's been uploaded to unstable, but I can't check that—at the time of writing,buildd.debian.org doesn't even have a log file for some of the xorg stuff yet. Though some parts are in the building state at this very moment...

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.

Joey Hess: 30

Well, this will be one birthday I'm sure to remember. After all the rigors of transatlantic flight I arrived in Madrid just as my clock rolled over, spent a scarce hour and a half trying to finally get some sleep and then out into the evening to see the city. I had less than a day in Madrid, but I feel I've met my tourism quota walking thru the park and all around downtown: Fountians, drums, monuments, boats in the lake, famous steets, robot dancers and the jugglers in the square, strange cricket-sound balls. Amaya's hospitality is a force to be reckoned with (as are her cats), and there's a great group of debianistas here. Dinner ran late into the night, and I was lucid for most of it despite lack of sleep, and thanks to their brilliant jet lag amangement, woke up bright and early for the next leg of the trip. In the bus to Extremadura now.

Matt Brown: Loading GPG / SSH Keys from a USB Key, Round 2

Back in January I talked about setting up some scripts to automatically load ssh/gpg keys into the appropriate agents when you plugged in a UBS key. I had quite a number of people ask me for my scripts, but they just weren’t quite ready. I’m still not entirely happy with the solution that I’ve come up with, but I figure its working well enough to get some feedback now. It’s based very heavily on the usb-storage script originally written by Sean Finney, so I think that means I owe him Pizza now. However while its based on the usb-storage script it has changed in a few major ways: The mounting of the partition is the key change and I’m still tossing up whether the way I’m doing it is best or whether I should return to having it handled by the script. The primary reason for changing it was to allow the partition to be mounted in a stable location (as opposed to a random directory under /var/tmp) so that I could symlink from appropriate places in my home directory to the partition on the key. The symlinking is needed to keep GPG happy as the gpg-agent seems to store only the passphrase and requires access to the private key whenever you need to sign/encrypt something. The way ssh-agent works is much nicer in this respect, in that once you’ve loaded a key into the agent it doesn’t need to refer to it on disk again. Currently I’m using autofs to mount the partition as needed and this seems to be working well. It’s probably possible to go back to mounting the partition at a stable location from within the script without too much hassle. You can grab the script from http://www.mattb.net.nz/debian/misc/manage-keys The remaining details for my configuration are below: First, setup udev to rename the key partitions to a static name and then fire the script at the appropriate times
/etc/udev/rules.d/usbkey.rules

ACTION=="add", KERNEL=="sd?2", SYSFS serial ="A0494386139B005B", NAME="%k", SYMLINK="usbkeys", RUN+="/usr/local/bin/manage-keys"
ACTION=="remove", KERNEL=="sd?2", RUN+="/usr/local/bin/manage-keys"
Then setup autofs to mount the partition on demand
/etc/auto.master

/media/usb /etc/auto.usbkey --timeout=10

/etc/auto.usbkey

keys -fstype=ext3,ro,noatime,nosuid,nodev :/dev/usbkeys
I keep only id_dsa and secring.gpg on the key and symlink from the appropriate places in my homedir to /media/usb/keys/

matt@argon:~$ ls -l .ssh/
total 76
-rw------- 1 matt matt 612 2006-04-12 22:45 authorized_keys
-rw-r--r-- 1 matt matt 2694 2006-04-12 22:46 config
lrwxrwxrwx 1 matt matt 22 2006-04-13 01:08 id_dsa -> /media/usb/keys/id_dsa
-rw-r--r-- 1 matt matt 612 2006-04-12 22:46 id_dsa.pub
-rw-r--r-- 1 matt matt 58851 2006-04-12 23:10 known_hosts
matt@argon:~$ ls -l .gnupg/
total 2336
-rw-r--r-- 1 matt matt 126 2006-04-12 22:56 gpg.conf
drwx------ 2 matt matt 4096 2006-04-12 23:07 private-keys-v1.d
-rw------- 1 matt matt 1175737 2006-04-12 23:29 pubring.gpg
-rw------- 1 matt matt 600 2006-04-13 01:51 random_seed
lrwxrwxrwx 1 matt matt 27 2006-04-13 01:08 secring.gpg -> /media/usb/keys/secring.gpg
-rw------- 1 matt matt 10560 2006-04-12 23:27 trustdb.gpg
And that’s basically it. The script takes care of the rest. The main problem I’m having with the script at the moment is that it doesn’t autolock the screen when you remove the key because gnome-screensaver-command is lacking the necessary environment variables to find the DBUS socket it needs to talk to its backend. Need to read up on DBUS/gnome-screensaver and sort out how to fix that tommorrow. Update: Updated example udev config so it doesn’t run a script out of /home

Simon Richter: Madrid

Okay, the group has assembled in front of the bus that is going to bring us to Extremadura. Off we go!

Eric Dorland: The Pain of the GFDL GR and the DPL throws down

(aside: I love acronyms) The GFDL GR is particularly painful for packagers of GNU software like, say, automake. While I voted for it, and I think it was the right thing, it's almost physically painful to have to split my package apart for such ridiculously trivial 3 lines of Front and Back Cover Text:
     Permission is granted to copy, distribute and/or modify this
     document under the terms of the GNU Free Documentation License,
     Version 1.2 or any later version published by the Free Software
     Foundation; with no Invariant Sections, with the Front-Cover texts
     being "A GNU Manual," and with the Back-Cover Texts as in (a)
     below.  A copy of the license is included in the section entitled
     "GNU Free Documentation License."
     (a) The FSF's Back-Cover Text is: "You have freedom to copy and
     modify this GNU Manual, like GNU software.  Copies published by
     the Free Software Foundation raise funds for GNU development."

New DPL Anthony Towns has started his term, guns blazing. I like his idea. Making it easier to contribute to Debian can only really be a net win. The obvious objection is that this will allow untrusted people to upload to Debian. But does the current New Maintainer process really guarantee that an applicant is not malicious? I don't think so. It only weeds out impatient attackers, not determined ones. Now, if we really do believe that it is too dangerous to allow these "Debian Maintainers" direct upload, their uploads could go into their own queue. A queue that would be viewable by any "Debian Developer" to vet the package and approve it. I believe the Fedora Extras project does something similar.

Simon Richter: Geek travel

I'm on my way to the airport, and, from there, to Extremadura via Madrid. I have my soldering iron with me.

11 April 2006

Bernhard R. Link: only DDs should be allowed to upload packages

Anthony Towns writes:

"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."

I think the whole point of NM is to make sure we can trust people. This will be extremly different from sponsorship, as I hope no sponsor takes a packages and just uploads it, but makes sure it is as correct as any of his packages, using all his/her experience.

Even some little game or package for special use can cause severe headage, as the maintainer scripts can delete stuff outside that package or open security holes. Things having that much power should only be in the hands of people we actually know and trust. Thus some DD should be responsible. And I doubt that there are enough DDs wanting to be responsible for something another person does when they give a in blank upload privilege for some package without any chance to look what gets uploaded.

That said, I like the idea to make sure the Maintainer in the .changes file and the owner of the key that signed it are the same. (It's nicer to change it to get the mails yourself and bounce them to the person you are sponsoring, but I sometimes forget it). Does the field yet has any meaning other who get the mails from the queue daemons and dak?

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.

10 April 2006

David Pashley: Creating a Certificate Authority

Sometimes you need to generate several SSL certificates, but don't want to pay money to a Trusted Root, and self-signed certificates just won't cut it. If you've ever had this dilemma, just for you, here's an article describing how to set up your own trusted root certificate and how to import it into several common applications. If you want me to add your favourite application, feel free to email me with instructions and screenshots if appropriate.

Simon Richter: Good I got a calendar

The next two months are going to be quite stressful, but hopefully also enjoyable. The kick-off is the Debian Embedded work session in Extremadura over the Easter weekend (my demoscene friends will hopefully forgive me skipping this year's Breakpoint), shortly thereafter followed by moving my stuff to a new flat (which allows some differentiation between sleeping and living room, whee!), then there is LinuxTag, which I'm not entirely sure I will fit into my schedule, then DebConf, shortly thereafter followed by the Wave-Gothic-Meeting and what happens then I have no idea yet. Probably madness.

9 April 2006

Andrew Pollock: [life] Movie of the year

Tonight Sarah and I went to see Inside Man, and conveniently managed to end our search for a half-decent cinema in the Bay Area at the same time. The AMC Mercado 20 in Santa Clara definitely has the best seating of all the cinemas we've been to so far. Century Cinemas, are so... last century by comparison. Anyway, back to the movie. Bloody excellent. I knew I wanted to see it from the moment I saw a trailer. It reminded me a little of The Thomas Crown Affair, a movie I enjoy for its plot. The movie was littered with hilarious one-liners that cracked up the audience. Denzel Washington was brilliant, and the plot was first-rate. Definitely one to see again, and definitely one to own.

Andree Leidenfrost: I am a Debian Developer!

Amazing stuff, after almost two years, I've become a Debian Developer! I've certainly learned a lot, met numerous nice people (mostly remotely unfortunately). My password is changed, my gpg key updated - so not long now, until I type the commands to make my first upload, undoubtedly with trembling fingers!

I'd like to thank all the people that were involved in making me a Debian Developer. Specifically, I'd like to thank H ctor for making me co-maintainer of mindi and mondo before I even knew what hit me, Ben for sponsoring me, Matthew for being my AM (We should play pool again one of these days!), and of course Amaya, who has helped in so many ways that I don't even know where to start, so I won't.

Thank you all!

8 April 2006

Miguel Gea: DD

I've been DAMnified.

Erich Schubert: Proof of concept virus for Linux and Windows

Many IT news websites have been reporting that there is a new proof-of-concept "cross-platform" virus for both Windows and Linux. This is largely overrated. There are a couple of reasons why this type of virus poses no threat to Linux users: So overall, this threat is very theoretic. However, the Linux community should consider defense mechanisms for this. Debian can already verify the integrity of most of its files via md5sums, but some tools (e.g. prelink, to improve application start times) will modify the applications and thus the md5sums. A couple of measures we could/should probably do: These measures could make it even less attractive to write attacks against Linux software. I can't assess the potential security issues we might "inherit" from the Windows platform by offering the Mono C# implementation. This basically means that some of the to-come malware for Windows will run on Linux, too. Only if users try to run their Windows shareware, of course. [Update: another win32+linux virus, from 2001. Noone cared, nothing happened.]

6 April 2006

Jeff Bailey: Has the hula hoop fallen?

Last weekend I found myself looking for something to hack on that wasn't something I see during my work day. I took a look at <a href="http://www.hula-project.org/Hula_Project">Hula</a>. I've wanted something like this for use at home. It would be nice if <span class='ljuser' style='white-space: nowrap;'><a href='http://auzure-skies.livejournal.com/profile'><img src='http://stat.livejournal.com/img/userinfo.gif' alt='[info]' width='17' height='17' style='vertical-align: bottom; border: 0;' /></a><a href='http://auzure-skies.livejournal.com/'><b>auzure_skies</b></a></span> and I could see one another's calendar, have our own Jabber server, and have easy access to our email through a local client or through webmail.<br /><br />There seem to be a steady stream of commits to Hula's SVN, but almost no discussion on the mailing list. I've sent in <a href="http://forge.novell.com/modules/xfmod/maillist/archbrowse.php/hula-dev/2006-March/001012.html?id=1613&amp;prjname=hula&amp;mlname=dev">one patch</a> to the Makefile so that make dist would run (<a href="http://forge.novell.com/modules/xfmod/maillist/archbrowse.php/hula-dev/2006-April/001014.html?id=1613&amp;prjname=hula&amp;mlname=dev">accepted</a>), and sent <a href="http://forge.novell.com/modules/xfmod/maillist/archbrowse.php/hula-dev/2006-April/001013.html?id=1613&amp;prjname=hula&amp;mlname=dev">another</a> asking for design information (No answer yet). In general, the codebase seems crufted with a bunch of legacy NetWare concepts. It's written in at least four languages (C, C , C#, and Python) and doesn't seem to have a testsuite. The code also currently doesn't run on powerpc without segfaulting.<br /><br />Ah well. Anyone know if there's another project that has similar aims and goals? Basically some sort of server software that will handle almost all of what evolution can hand to it, plus some sort of extensible interface so that it's reasonably easy to add things like Jabber servers, RSS/Atom Aggregators, etc.

Enrico Zini: Converging to a solution

Sustain a discussion towards solving a problem is sometimes more important than solving the problem. I can't decide if this is trivial or counterintuitive. Anyway it's been quite enlightening when it came out. I once took this note:
I found that with my projects, when someone posted a mail about a problem I would work maybe some days to find a solution, and just post the solution at the end. However, now I realised it's more costructive to have the problem-solving process itself happen online. This way, instead of keeping people waiting in silence for a few days they can get quicker feedback and extra informations, and they also have a chance to participate to solving the problem before I manage to. For example, when I have to interrupt to go home or sleep, someone else can pick it up and do another step. Plus, the entire problem-solving process remains documented, which will provide more written information for future readers.
This note was from a few months ago; however, I still fail to do it. Bad habits are sometimes hard to change. Please kick me about it :)

Erich Schubert: Planarity

Planarity is indeed an addictive flash game. I just did level 13 in 19:30 minutes. What are your scores like? This game was also featured in that cool Multi-Touch touchscreen video you might have seen some month ago. There is however a rather generic approach that will lead you to a solution rather reliably. Don't just move around random vertices, instead pick one and move it into the center, now grow the solution from that center node. The higher the level, the less space you'll have, so keep it dense! Always look at all "new neighbours" first, where to place them best to avoid having to swap them later. But by just walking around clockwise around the "convex hull" of what you've built so far, you get a pretty good network. I guess you can even prove it that you'll be able to solve it in O(n) that way when done right. In level 13 I this worked quite good for me, except I ran out of space some time. I then picked a random outer node, moved it to the very upper left, and moved the "covex hull" to the borders of the screen. From time to time you'll see you've made a mistake, but this can usually be solved by mirroring some group in your network. Update: Level 14 in 18:13 Minutes. Looked like this: Planarity screenshot with a small problem at the top edge of screen due to lack of space there. Update: Level 15 in 14:01 Minutes. The schema works perfectly, you have to touch each node at most twice (once when discovering, and maybe switch place with a sibling when discovering the new neighbours). All changes are local, and you don't actually look at the lines, just at the colored nodes. Unless of course you run out of space and have to rearrange.

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.