Search Results: "will"

13 April 2006

Aigars Mahinovs: Cranfield - arrival

My first 24h in Cranfield. This will mostly be interesting for close friends or relatives. (690 more words in the post)
Continue reading ...

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

12 April 2006

Jesus Climent: Double personality, triplestereo.com

Trying to boost a bit my career as a DJ, I will be publishing some of my promotional mixes under TripleStereo. Enjoy them.

Jose Carlos Garcia Sogo: Where are people?

As shown in the image below, the highway (A-6, Spanish North-West main route) is almost empty. The image is from 18:56 CEST, and the problem is that it was supposed that this highway (like every other highway going out from Madrid) had a very heavy traffic jam today, as we start Easter holidays today. But almost no one of those has even a light traffic jam. At this rate, it will be impossible to reach the 2 million of car movements predicted for today. Update 04-13-2006 12:33.- And people appeared, as you can see in the left of the new image. And I waited till today to go to my parent's for not getting any traffic jam. DGT camera - A-6 empty DGT camera - A-6 full

Joey Hess: a random thought

If you base any opinon about something in Debian on the presence of a cabal, your conclusion will be fundamentally incorrect.

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.

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

Ian Murdock: The shot heard round the (Linux) world

David Berlind: “In a way that seemingly minor conflicts around the world can erupt into flash points between superpowers, the bottom line is that if a consolidation wave sweeps through the industry in 2006, it’s this acquisition of JBOSS that will have sparked it.”

Lars Wirzenius: Debian: Packaging tutorial next summer in Finland?

I met someone from HP Finland yesterday and he gave me a tentative promise that HP would be willing to give its auditorium for free if I want to arrange a Debian packaging tutorial during the summer. I've given such a tutorial to some friends, and it would be fun to do it again, if there's interest. The way I imagine it currently would be that there's a theoretical lecture first, say one hour, that covers the basics of packaging. The second part is hands-on training, where everyone builds packages, and if they have problems, I and others will help. Depending on how long we want to make this, we can then continue with more lectures, and maybe more hands-on stuff. In my calendar, the weeks starting June 10 or June 17 would be ideal. This would, of course, be completely free for participants, and open to everyone. If you would like to participate, either as a student or as a teacher, please drop me a note. Nothing is binding right now, I'm mostly just interested in how many people are interested.

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.

Uwe Hermann: How to hijack an already running X11 application via ssh -X?

Dear Lazyweb, I have always wondered whether it is possible to "hijack" an already running X11 application on a remote server... Say I have a box at home which has a running X11 server with many applications, e.g. Firefox, xchat, xmms, whatever. Now, say I'm somewhere else with my laptop and login with "ssh -X" into my home box. I can now start X11 applications and they will be shown on my laptop screen. So far so good. But... how can I get one of the applications that were already running before I logged in from remote to be displayed on my laptop screen? Is it possible? How? Just curious.

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.

Erich Schubert: Python pitfall of the day: <tt>def function(var= )</tt>

I was hunting an odd bug in a python program of mine. Here's a condensed code snippet for explanation:
class odd:
        def __init__(self, a, b= ):
                self.b = b
                self.b["a"]=a
one = odd(1)
two = odd(2)
print one.b["a"]
That code looks reasonable, doesn't it? The parameter "a" is required, but other parameters can be given in a hash. So what output would you expect? The output is 2. The reason is as follows: Python creates an empty hash, and b is a reference to this hash per default. To the same hash each time. So the code is basically equivalent to
class odd2:
        default_for_b_in_init =  
        def __init__(self, a, b=default_for_b_in_init):
                self.b = b
                self.b["a"]=a
and not (as I had expected):
class odd3:
        def __init__(self, a, b=None):
                if not b: b =  
                self.b = b
                self.b["a"]=a
Obviously, both behaviours make sense, and the python way is somewhat consequenter. So be careful when using default values in functions! Non-reference types such as integers are fine, so is None, and of course any outside objects you want to be the same for each call. Don't assume the def statement will create any new object. Even shorter example:
def test(a, b= ):
        print b
        b["a"]=a
test(1)
test(2)
will result in the output
 
 'a': 1 
again there is only a single hash b.

11 April 2006

Julien Danjou: Status of Xen in Debian

As you may have read it in the latest DWN, Xen is now (almost) supported by Debian. Actually, it is currently stucked in the NEW queue since yesterday. The packages are also available on our Alioth webspace.
Special flavor of glibc, libc6-xen, is also upcoming, thanks to Aurelien Jarno ! Err, what else to say ?
That the Xen upstream sources are not very clean for now. There's still a lot of tools not needed that are furnished, the sources are a mess, and there is no stable API for now. You may have seen Xen kernels in experimental, but the kernel team has removed them for now. It will probably not be possible to distribute Xen-enabled kernels as long as Xen won't be more stabilized. I really wish that it will be integrated in kernel vanilla sources, since this could calm down a bit big changes, and help having a more stable version. Just see that between 3.0.1 and 3.0.2 version, the way used to compile Xen kernels changed from a special arch xen to a subarch xen. That's better, for sure, but such important changes in the same major branch are quite disappointing. Finally, I would say that Xen is now usable with Debian. I use it for more than 6 months now, and it is quite stable, no huge bug. You will just have to wait that #346387 is fixed to compile your own kernels with patches we provide.

Ross Burton: Building Debian Packages In Scratchbox

Every week I spend half an hour wondering why I can't build Debian packages inside Scratchbox. The error is "you must be root" which is solved with fakeroot, but I'm already running debuild with fakeroot... That, of course, is the problem. debuild will clean the environment before starting dpkg-buildpackage, which wipes all traces of the Scratchbox magic away, breaking fakeroot. Despite debuild being an essential wrapper around dpkg-buildpackage in the normal Debian world, in a Scratchbox it's a big no no. I really must remember this! NP: Debut, Bj rk

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

Wouter Verhelst: DPL election finished.

Well, the electorate made its decision; aj won. It's not a secret that aj wasn't my first choice, and so I'm a slight bit unhappy about the result—but that, of course, won't keep me from congratulating aj with his new position. My reservations aside, I'm sure aj's enthousiasm and passion for the project will ensure he'll do great job as DPL. That being said, I can't help but notice that the result was a very close one, this year. As Adam Borowski noted on the debian-devel mailinglist, Steve had higher margins in every choice-to-choice race in the vote, except that 6 (count them: six) people voted aj above Steve. So, here's an applaus for Steve, too, for a result well earned.

Edd Dumbill: Catching up

Most of my energy recently has been devoted to organising things for XTech 2006, now just over a month away. Here are some XTech-related snippets: MacBook  My new computer has arrived, an Apple MacBook Pro. I know I wrote some time ago about how disappointing it was for free software advocates to be using a non-free OS, and I am rather sad about this in some ways. I'll be writing in the near future about my impressions of the platform, and reasons for buying this machine. Writing My latest piece on Debian has been published over at O'Reilly, Installing Software on Debian. We've been a little slow getting through the publication of these, so I'll try and hurry the next few along. Rails Rails continues to impress. I wish I had more time than I do to use it, as it feels so right to work with. With Matt Biddulph I'll be teaching a day on Rails at XTech 2006. In the meantime, I highly recommend Chad Fowler's Rails Recipes, it covers the most common requirements from real-world web applications. Oh, and I'm scheduled to attend RailsConf this June. My paper was (not too surprisingly) declined for the conference, but Matt's was accepted.

Next.

Previous.