This week, following the announce of the freeze, I upgraded most of my home cluster to Etch. The upgrade went surprisingly smoothly, although I had a bit of a scare when the kernel upgrade pulled in a bunch of dependencies that resulted in the forced removal of all previous kernels. This minor scare asides, kudos to everyone who made this new Debian release possible! My only disappointment about Etch is that we're stuck with Firefox 1.5.0.7 instead of 2.0.1 or Iceweasel. Then again, speaking of Iceweasel: Forget it! Breakages it introduces have been marked as pending or patched for a number of weeks and yet there's still no updated package. At this rate, better wait until Etch r1 or Lenny to introduce it, rather than release Etch with a browser fork that has not undergone several months of thorough testing! This got me thinking about life after Etch, or more specifically, about what I'm gonna do with the packages I maintain. The Dunc Tank debacle and similar other unfortunate events that overtook Debian this year have prompted me to reevaluate my motivation. Another unrelated issue is, I've been working in software development for more than 10 years and my guts are telling me that it's time to move on so, while my computers will still run on Debian or Ubuntu, I don't intend on doing any more development per-se. Thus, I have already taken the initiative of soliciting co-maintainers for most of my packages. The Debian GNOME team agreed to be added for Planner, which is nice given the sheer number of bugs that are regularly found against this package. CUPS-PDF, Gaim-IRChelper and NumlockX haven't seen a meaningful bug in ages and can be rebuilt using bin-NMU magic, so they're pretty much taken care of. This leaves the issue of the Estonian and Russian dictionaries (plus a large patch in my personal repository that would upgrade Aigars' Latvian dictionary to generate the Aspell wordlist from his MySpell wordlist) open. For these, native speakers that develop for Debian or Ubuntu would be welcome to join me. What next? I have a couple of interesting offers, one on the Business side of computer hardware manufacturing in Estonia and another one as the manager of a western company's Latvian office. The tricky part in either case would be the immigration process: despite close to 9 years of living right here in Europe, I am still perceived as foreign labor whose hiring must be thoroughly justified (in the case of Estonia, I even need to request an explicit exemption to the immigration quotas), whereas if I had been granted EC Long-Term Resident status or Finnish citizenship, I could just sign the contract and notify the local authorities of my change of address. Instead, 9 years later, I'm stuck at the passport control queues for non-EU citizens with its disgustingly suspicious border guards. Sigh! Thus, while I indeed have shares in Linutop (yes, we are finally shipping - stay tuned for details) that might eventually turn into gold, I also have close to zero motivation left in my personal life, because lingering European bureaucrazy prevents my talent from reaching its customers - turning all my attempts at having a career into a neverending series of bitter disappointments. Is it any wonder that I'm so adamant about getting out of the Rat Race to return to more gratifying creative activities like composing and photography, then? Post Scriptum Actually, there is a second disappointment about Etch: we are stuck with Evince 0.4.0, at a time where upstream just released 0.7.0 with strong recommendations that everyone upgrade to that. Heck, even Ubuntu has 0.6.0 already. I find the Evince situation way more annoying than the Firefox one, because, from a user's perspective, Evince 0.4.0 fails to display several PDF documents that more recent releases handle just fine.

I previously blogged about UTF-8 Migration Tool, a GTK2 wizard that helps users upgrade their legacy locale and recode text files to their UTF-8 equivalent. After merging a number of patches from Nicolas Fran ois to fix various parsing issues, I am now happy to report that the package has entered Debian's unstable distribution. Plenty of migration cases remain untested, though, and the Debian i18n team particularly welcomes testing for locales that utilize a non-default legacy encoding or that contain an @modifier part. If no major issue is found, the goal would be to release this package with Etch to help users migrate their system to UTF-8.

Kenshi sent the following GPG-signed message to the Debian CUPS mailing list today:

Hi folks, As you know, there are many bugs about CUPS including Release-critical and I haven't an enough time to fix them. My primary motivation was to internationalize/localize it. Now it is already implemented by upstream. Unfortunately CUPS is too complex for me to maintain. I haven't a time to track bugs, I haven't an enough knowledge about Postscript or printer specific codes, and I haven't any testbed of user's printers. If you'd like to become primary CUPS maintainer instead of me, I pass a baton happily :) Of course I'll support you such as uploading. Thanks,

Interested parties should contact kmuto directly to manifest their intention.

Linutop will makes its first public appearance tomorrow at Solutions Linux in Paris. French developers who are interested in getting their hands on one of our 50 development units should call up Fred at 0685868576 and schedule an appointment. Others who just wanna see the Linutop in action are welcome to drop by booth D 16 during the exhibition. Meanwhile, rumor has it that someone else might be dropping by Montr al for the February meeting of FACIL with a mysterious Free Software -powered aluminum box...

A few weeks ago, the Linutop team received a request for its source code. We had already anticipated the GPL source offer clause in our development plan, so it was just a matter of myself getting around producing a source code ISO image. Piece of cake, right? Almost. You see, Linutop includes a custom kernel package and several separate wireless module packages, so the the following command would not work as expected:

apt-get --download-only --ignore-missing source $(dpkg --get-selections   cut -f 1)

Why is that? Because APT ignores the --ignore-missing option whenever executing the source command. Instead, Roland Mas suggested that I used this simple Bourne loop:

for p in $(dpkg --get-selections   cut -f 1) ; do apt-get --download-only source $p ; done

Done this way, the source code of each package is fetched individually and, if any package's source is not available, APT exits but the Bourne loop moves on to the next package in the list. Nifty, isn't it?

Dear Lazy Web: I am developing a severe hatred of Gaim 2.0, because some of its dumb features hamper my productivity. Are there any simple configuration tricks that could fix the following issues:

• How can I make Gaim stop auto-hiding its conversation windows?
• How can I make Gaim stop auto-toping its dialogs and windows?
• How can I make Gaim stop stealing the focus all the time?

Would you happen to know the answer to any of the above? Best Regards, Mr.Linutop

I recently blogged about putting together the Linutop source code ISO. The resulting image has now been uploaded to our wiki. The ISO's content is divided in two sections:

• Debian source packages for all the software used on our reference platform.
• Linux kernel source with our custom kernel configuration and kernel patches.

Developers who are interested in producing customized OS images should download this ISO and consult the wiki for details on developing for the Linutop.

One funny thing about being a foreigner is the linguistic choices people make when communicating with me. Case in point: my new job at Artec. This being Estonia, there's a plethora of languages to choose from: Estonian, obviously, but also Russian, English and Finnish. Russian is possible because 30% of Estonians are ethnic Russians (or related Belorussians and Ukrainians) whose ancestors were relocated during Soviet times. Russian also remains strong as a language of trade, especially among the older generation, while English tends to replace it for the younger generation. Then, Finnish is widely spoken in Northern Estonia, because of Tallinn's proximity to Helsinki and despite Southern Estonian being linguistically closer to Finnish. People's choice, whenever discussing work-related matters with me, varies accordingly: some prefer to use English while, for others, Finnish comes naturally. Then there's a handful of older collegues who feel uneasy speaking either English or Finnish, so they address me in Estonian, placing special care on clearly articulating every word and on speaking at a slower pace than normal (to Finnish ears, Estonian essentially sounds like Finnish on fast-forward and with unusual choices of vocabulary). I have yet to see anyone try Russian with me, although a few people have noticed that I get the overall idea, just as long as they articulate clearly and speak slower than normal. Then again, our ethnic Russians are so well integrated that they speak Estonian all day long, even among themselves, and I have been able to observe the same pattern everywhere I've been in Estonia. From that perspective, I think that Russia's claims about "oppression of ethnic Russians in Estonia" are greatly exaggerated.

One aspect of Ubuntu that I really enjoy is the sheer amount of constructive feedback a maintainer gets about the usability of their packages. In my case, CUPS-PDF [1] [2] has been a landmark example of how beneficial this feedback can be: See, one long-standing goal at Ubuntu has been to include the capability to generate PDF documents "out of the box" and regardless of which Desktop Environment is used. Many people considered that CUPS-PDF would be an excellent tool, but various technical issues prevented this from working in a security-conscious way. Once that issue was taken care of, someone pondered how the PDF queue could be automatically created at installation time? It turns out that we're almost there: with the upload of version 2.4.6 into Debian today (which should propagate into Ubuntu within a few days), only one configuration step remains: the selection of a PPD driver. Everything else is automatically detected and configured by CUPS itself. Kudos to our friendly upstream, Volker, for implementing this driver magic in his back-end code! Enjoy!

Today, getting increasingly tired of the incoherent User Interface in Gaim 2.0 release candidates, I fetched the recently uploaded release 2.0.1 of Pidgin (same software, different name; the result of a trademark dispute) from Debian/unstable and built it against Stable dependencies. First impressions: excellent harmonization of the behavior between supported protocols, thanks to a new user status handling that is common to all protocols, coupled with unified a icon theme. Overall, this feels much more consistent in everyday use and it serves to blur the distinction between protocols to maintain the focus on the conversation taking place. However, two major annoyances:

1. The old behavior of stealing focus, every time a tab pops open, is still there. AAAAAAAAAAAAAAAAAAAAAAAAARRRRRRRGH!
2. Extremely tiny fonts in the conversation window and trying to make them inherit the default system font size via Pidgin's built-in GTK plug-in simply fails.

Conclusion: libpurple may be technically amazing, but Pidgin really is in desperate need of a complete UI overhaul.

hi, planet && iso8859-15 to utf8 with netatalk magic Hi, Planet!
Welcome to my blog, and thanks to Martin for subscribing me. I m not going to bother you with any details about me, if you have any questions feel free to ask me on freenode or oftc (in case you re wondering: my nick is bzed).

After a longer time of planning we ve upgraded our main file server at work: New machine, new storage (7TB - woohoo!), Etch instead of Sarge and UTF-8 for file names instead of ISO8859-15. Everything not a too complicated thing, except for renaming the about 10,000,000 files from ISO8859-15 to UTF-8 in a proper way.
In theory this is easy, as convmv happily takes care of the problem. But this did not work for us unfortunately, as we re not only providing NFS and Samba services, but also AFP (Apple_Filing_Protocol) via netatalk. Years ago you had to choose ISO8859-15 if you wanted to allow your Apple and Windows users to see the same, non-broken file names - not only because AFP didn t support UTF8 before version 3, which came out with OSX1). Normally you d think that a server would not allow a client to write a file with a file name which includes not supported characters - again, OSX and netatalk go their own way here:
Characters which are not supported by the underlying file system are character(!)-wise encoded using the CAP encoding. So we had to find a way to

• convert file names from ISO8859-15 to UTF-8
• replace CAP encoded characters by the appropriate UTF-8 character

Luckily netatalk ships the uniconv(1) util2) which is able to take care of this problem. It also updates the CNID3) Database at the same time. There s two things you need to take care of in case you re using the dbd CNID backend:

• uniconv assumes that cnid_metad is listening on port 4700, you need to start it first. Don t run afpd at the same time!
• If you ve specified external CNID dbpaths in your AppleVolumes.default (normally they re located in the root of each volume, prone to be deleted by users accidentally), you need to move the .AppleDB directory into your volume s root directory, otherwise uniconv will create a new CNID database. Just move it back as soon as uniconv is finished.

Be careful: uniconv assumes that all colons in a file name are part of a CAP encoded character. That s not a problem as long as you have only Mac and Windows clients accessing your server, as both systems do not allow colons in file names. In our case we found a number of cache files from Nautilus (which is running on our sunray/Solaris web-surf terminals as default browser) with colons in the file name. I hope no user will miss them Including a final synchronisation of all files to the new storage, about two hours it took uniconv to convert the file names and a aunch break, we were finished after about 14 hours of work. Until now it seems that our users didn t notice the change at all, except for those who realized that they have much more free space now. Looks like a successful weekend so far! 1) and uses a NFD variant of Unicode normalization (UTF-8#Mac_OS_X), but netatalk takes care of this and translates it into the NFC form, which is used on most other platforms 2) it s called netatalk-uniconv in Debian and shipped with netatalk 3) Catalog Node ID, another crust from old Mac OS versions

Copy of a mail I sent to debian-www earlier today. I don't think it warrants posting to -devel-announce, but I post it here to make it visible to people not usually following debian-www. Since I seem to sense an increased stream of offers to help out with packages.d.o coming my way (but maybe that is just wishful thinking ;) I wanted to give a short update on the development of the current code and the status of the infrastructure so that nobody can claim he wanted to help but failed due to lack of information.

• The code in the CVS is seriously lacking in many regards, especially update and CGI speed. It runs pretty stable though and since we excluded robots from using the CGI scripts it seems to run with at least enough speed to keep any big complaints from rising. (If anyone is interested, packages.d.o currently has about 200,000 page hits a day, with a notable decrease – up to 50,000 – during the etch freeze and a similar increase after release)
• packages.d.o is currently run on puccini.d.o, this host is exclusivly used for this purpose. Adminstration is be done by group pkg_maint, current members are Martin 'Joey' Schulze and me.
• The same code is also used to create the page packages.ubuntu.com, see branch ubuntu in CVS. packages.ubuntu.com is run a private server of mine and only administrated by me.
• Everybody with write access to the website has also write access to this part of the CVS. The code run on packages.d.o is updated once a day during the update cron job. Since there is no staging ground for changes, any commits should be made with extreme care...
• Last year Jeroen van Wolffelaar and I started to develop a new version with the goal to make dynamic page generation possible which allows for faster update of information and more flexible presentation. We coordinated our work by using a SVN repository located at svn.wolffelaar.nl.
• This development was stalled several times when he and/or I had no time to actively pursue it.
• In April 2007 I decided to revive the development to get the code in a state ready for deployment. Since I was by then inititated in the wonders of distributed scm, I decided to move the code to yet another repository, namely git (for cloning use git://source.djpig.de/git/packages.git) There is also a ubuntu branch there but it is in a rather sorry state atm regarding site layout.
• I think the new code is currently in a state where it could be safely deployed to packages.d.o but I'm currently waiting for an etch upgrade of the host since the code has grown some dependencies on stuff only available in etch. The next possibility for this to happen is probably during Debconf.
• I don't know yet how to handle the SCM stuff when the code is to be deployed.
• You can try out this new code base at packages.debian.net (Might be slightly out-of-date sometimes since I don't run the cronjob as often as possible to give packages.ubuntu.com more ressources)
• Bug reports and patches against this version are very much welcome, please send them directly to me (but feel free to CC debian-www if you want to have an open discussion on the matter in question).
• Bug reports and patches against the version currently in use should be directed to the BTS as usual.
• If there is interest we can make a little improvised BoF about packages.d.o at Debconf.

It is not high crowded here, but we have about 2-3 visitors at any time at the booth. No Tags

A number of recent events reminded me of how much time has passed since I started using Linux. Among these, the retirement of several 32-bit CPU architectures from the list of supported platforms on Debian and Ubuntu. The first architecture to fall was m68k. Release Managers at Debian proposed to drop support for m68k after Sarge, which indeed happened: Etch was released earlier this month and, for the very first time in Debian history, without m68k support. Granted, a number of dedicated developers are working on porting the GNU toolchain to Coldfire (an embedded platform that supports about 80% of the m68k instruction set) and good chances are that they will succeed but, let's not fool ourselves: m68k is gone. Around the same time, Ubuntu dropped support for PowerPC, just before releasing Feisty. Granted, there is still some PPC64 hardware being manufactured, but this is on the server side and thus getting farther away from the desktop market that constitutes Ubuntu's core business. Of course, given the plethora of 32-bit PPC hardware in circulation, in the form of second-hand Power Macs, the platform still has some lifespan left but, again, let's not fool ourselves: PowerPC is gone too. And now, a message sent to Debian mailing lists suggested that, as of Linux kernel 2.6.21, support for 32-bit SPARC was broken and, due to an insufficient developer interest for maintaining the GNU toolchain, 32-bit SPARC was likely to be dropped for the Lenny release. Yup, we really cannot fool ourselves: support for 32-bit architectures really is gone. Not surprisingly, my own computer collection has followed a similar trend: this morning, my beloved PA-RISC host left for the home of a happy computer hobbyist who had won the online auction on it. My Atari TT030 is likely to follow a similar route fairly soon. Ditto for the exotic Atari Stacy sitting besides it ...and let's not mention the huge stack of Pentium II and K6 desktop hardware sitting in the corner. Looking back, I'm glad to have shared so many brilliant years with 32-bit hardware. The variety of CPU architectures and hardware designs was quite a learning experience. This being said, life goes on and my current needs are fully covered by my Linutop and by my aging ThinkPad. Thank you for all those years, 32-bit computers. Enjoy a well-deserved rest in bit heaven.

I just got back from taking Zach Copley to the airport, and for the first time in a few days I'm sitting in front of my desktop computer again, trying to get back on track. I think it's probably a good idea to get my notes about RoCoCoCamp down on electronic paper while the experience is still fresh in my mind. (I wrote about the first day in Journal/29 Flor al CCXV). Saturday morning I got up considerably later than I had the day before, and I took my time getting to SAT. Which was OK, since things went much smoother in the morning. The only really annoying thing about Saturday was that I had to wash about 50 cups by hand -- we'd run out of clean cups, and I couldn't figure out how to run the dishwasher. It didn't take long, but it meant that I had my head down in the sink as people came in and didn't get to spend as much time talking to them. I was glad to hear that people had a good time going to L'Utopik on Friday night. Apparently a few people who'd flown in late on Friday got a chance to meet up with the experienced crew at L'Utopik, so they were well-prepped for Saturday. Probably the biggest buzz of the pre-sessions was SJ Klein's pair of functional OLPC laptops. They were cute and fun -- I got a few minutes to play with them, and I enjoyed the interface tremendously -- although it took me a few tries to open it. People were fiddling with them throughout the day -- including Amita June, who came late in the afternoon -- and Tristan P loquin even blogged about them. My first session was about wiki and other technologies, which I titled Wiki And.... (I borrowed the name from Last Exit to Brooklyn, in which it seems no-one eats anything but "coffee and".) My main point was that a) wiki people tend to overuse wiki where other software tools may be more appropriate and b) we need to be careful with impedance mismatches when using wiki with technologies with other cultures behind them. Wikis and blogs mismatch; wikis and forums mismatch. You need to work out ways to make them work culturally. As a proof-of-concept that there are ridiculous applications for wiki, I created in about 3 minutes before the session the wikiclock. It's a computer clock that runs on wiki technology: the time is kept up-to-date by human beings editing the page, rather than with software. I was so pleased with myself that I twittered about it, and from there it's taken on a life of its own. The clock is implemented on the amazing minimalist system pageoftext.com. I heard about p.o.t. from Liz Henry's April report from Palo Alto Wiki Wednesday, and I think it's totally great. It's a cross between a pastebin and a wiki -- like an open-edited ImageShack for text. Brilliant. The second session I did was a hyper-focused one on a particular Semantic Web problem. Both Wikitravel and Open Guides have tons of information on "places" in various cities. (That is, restaurants, bars, nightclubs, hotels, museums, parks, etc.). It would be good to export our data on these places to each other, so we could possibly keep them in sync. For example, if a restaurant changes its hours , that info could be updated on The Open Guide to London and automatically synched to the Wikitravel page on London. So we went over some ways to do this kind of interchange; we'd brainstormed before about it on the Open Guides' RDF Workshop, but it was good to sit down with Earle Martin and do some face-to-face hacking on the idea. We don't yet have a vocabulary for it, but we'll get something going on the new wikirdf.org site (which also emerged from this session). I had a great lunch with a lot of people from RoCoCo on the terrace at the Bar St. Sulpice, about 8 blocks away on rue St. Denis. The sun was out, it was cool, and we had a very nice time. It was especially nice to see Marcus Bornfreund and Tina Pipers of Creative Commons Canada, who'd come to talk about the PDwiki, a project to collaboratively document Canadian works in the public domain (see Canadian Public Domain Registry Announced). We talked quite a bit about the social challenges of getting a community excited about such a dry subject, but I think we got some good ideas about it. In the afternoon I led a session on MediaWiki. We were lucky enough to have Tim Starling sit in, and he told everyone about the new developments going on with MW. He's refactoring some very deep parts of the storage and rendering sections of the code, which will result in considerably better reliability, performance, and flexibility. I think it sounds great. I had to work the registration desk for the last session of the day, which was pretty great because I ended up baby-sitting Anoushka Jaroski-Biava for most of the time. But I missed Robin Millette's cool talk about BuzzyBee, which looks to be really fun to play with. We rounded out the evening with music, pizza, and beer at the SAT. tobias.dj played some great dance music, and we had some wiki-collaborative VJ-ing using the SAT's fancy screen systems. All the kids were there -- Mark and Allegra's daughter No ma as well as Amita June. Fun. Sunday morning I didn't have to start coffee until 9AM -- luxury! We had a great Open Space Technology convergence -- a way to turn the discussions of the previous few days into action items for going forward. I did a convergence session on the future of RecentChangesCamp. We had most of the interested parties available (except for the RCC Portland organizers, who had to fly out early that morning). We made some decisions about future RCCs, and we made some plans for next year's RCC -- in the Bay Area (California). Last night we brought back the Keiki gang to our house, since it was great to have them all in Montreal for the event. We did a big brainstorming session on next steps to launching the project, and we also did some graphic design review of potential logos. We have some great designs coming; I'm really happy we got Sarven Capadisli and Bridget to work on the site. I had to crash out at 10:30PM -- Amita and I fell asleep together -- but others were up late talking and thinking. I don't know how they did it -- I was all talked out by the end of RoCoCo. All in all I had a fantastic time -- the event far surpassed my expectations. It was hard -- too hard. I bit off far more than I could chew. But I think we did a good job of establishing Montreal as a technology city -- Wiki City Canada -- in the international mind, and I think we also brought together some really interesting people for some fruitful and productive work. You can see some of the projects that came directly out of RoCoCo on the FutureChanges page -- an ingenious name courtesy of Pm. And there are some indirect ones that we can expect soon. tags: rocococamp recentchangescamp wiki open space montreal barcampmontreal keiki wikiclock pageoftext

Cause and solution So, Technorati has a good listing for rocococamp items, but I especially liked Steve Faguy's post: Wiki: The cause of, and solution to, all of life s problems. Steve was an extremely game participant in the event, which I think was pretty incredible. He wrote a good overview of wikis in the Montreal Gazette this year. A funny thing happened on Friday evening during the daily wrap-up known as "Evening News". We had Open Space's minimalist instructions posted on the walls of the SAT, so people would see and remember them. Steve pointed out that the first of Open Space's "four principles" is grammatically incorrect: Whoever comes is the right people. He said, "In the spirit of wiki, I'm going to correct it right now!" And to applause, he got up with a marker and changed the "is" to "are". This stimulated an interesting discussion. One person noted that the "is" is there because possibly only one person could show up for a session, and that's OK. Finally, Brandon CS Sanders stood up and said, "I like 'is' because when we come together like this, we form a cohesive group, however temporary -- 'a people'. So I'm going to change it back." And he did -- to lots of applause, again. Steve came up to me at the end of the night, laughing. "I got reverted! I should have started an edit war!" It was a hoot; he's got a good sense of humour. tags: stevefaguy rocococamp wiki openspace brandoncssanders

<div xmlns='http://www.w3.org/1999/xhtml'> <h1><a name="hi_planet_iso8859-15_to_utf8_with_netatalk_magic" id="hi_planet_iso8859-15_to_utf8_with_netatalk_magic">hi, planet // iso8859-15 to utf8 with netatalk magic</a></h1> <p> <em><strong>Hi, Planet!</strong> <br/> Welcome to my blog, and thanks to <a href="http://blog.zobel.ftbfs.de/" title="http://blog.zobel.ftbfs.de/" rel="nofollow">Martin</a> for subscribing me. I m not going to bother you with any details about me, if you have any questions feel free to ask me on <a href="http://freenode.net/" title="http://freenode.net/" rel="nofollow">freenode</a> or <a href="http://www.oftc.net/" title="http://www.oftc.net/" rel="nofollow">oftc</a> (in case you re wondering: my nick is bzed).</em> <br/> <br/> After a longer time of planning we ve upgraded our main file server at <a href="http://www.architektur.tu-darmstadt.de" title="http://www.architektur.tu-darmstadt.de" rel="nofollow">work</a>: New machine, new storage (7TB - woohoo!), Etch instead of Sarge and <a href="http://en.wikipedia.org/wiki/UTF-8" title="http://en.wikipedia.org/wiki/UTF-8">UTF-8</a> for file names instead of <a href="http://en.wikipedia.org/wiki/ISO8859-15" title="http://en.wikipedia.org/wiki/ISO8859-15">ISO8859-15</a>. Everything not a too complicated thing, except for renaming the about 10,000,000 files from ISO8859-15 to UTF-8 in a proper way. <br/> In theory this is easy, as <a href="http://packages.debian.org/unstable/utils/convmv" title="http://packages.debian.org/unstable/utils/convmv" rel="nofollow">convmv</a> happily takes care of the problem. But this did not work for us unfortunately, as we re not only providing NFS and Samba services, but also AFP (<a href="http://en.wikipedia.org/wiki/Apple_Filing_Protocol" title="http://en.wikipedia.org/wiki/Apple_Filing_Protocol">Apple_Filing_Protocol</a>) via netatalk. Years ago you had to choose ISO8859-15 if you wanted to allow your Apple and Windows users to see the same, non-broken file names - not only because AFP didn t support UTF8 before version 3, which came out with OSX<a href="#fn__1" name="fnt__1" id="fnt__1">1)</a>. Normally you d think that a server would not allow a client to write a file with a file name which includes not supported characters - again, OSX and netatalk go their own way here:<br/> Characters which are not supported by the underlying file system are character(!)-wise encoded using the <a href="http://netatalk.sourceforge.net/2.0/htmldocs/configuration.html#id2898845" title="http://netatalk.sourceforge.net/2.0/htmldocs/configuration.html#id2898845" rel="nofollow">CAP encoding</a>. So we had to find a way to </p> <ul> <li> convert file names from ISO8859-15 to UTF-8 </li> <li> replace CAP encoded characters by the appropriate UTF-8 character </li> </ul> <p> Luckily netatalk ships the <a href="http://netatalk.sourceforge.net/2.0/htmldocs/uniconv.1.html" title="http://netatalk.sourceforge.net/2.0/htmldocs/uniconv.1.html" rel="nofollow">uniconv(1)</a> util<a href="#fn__2" name="fnt__2" id="fnt__2">2)</a> which is able to take care of this problem. It also updates the CNID<a href="#fn__3" name="fnt__3" id="fnt__3">3)</a> Database at the same time. There s two things you need to take care of in case you re using the dbd <a href="http://netatalk.sourceforge.net/2.0/htmldocs/configuration.html#CNID-backends" title="http://netatalk.sourceforge.net/2.0/htmldocs/configuration.html#CNID-backends" rel="nofollow">CNID backend</a>: </p> <ul> <li> uniconv assumes that <em>cnid_metad</em> is listening on port 4700, you need to start it first. Don t run afpd at the same time! </li> <li> If you ve specified external CNID dbpaths in your <em>AppleVolumes.default</em> (normally they re located in the root of each volume, prone to be deleted by users accidentally), you need to move the .AppleDB directory into your volume s root directory, otherwise uniconv will create a new CNID database. Just move it back as soon as uniconv is finished. </li> </ul> <p> Be careful: uniconv assumes that all colons in a file name are part of a CAP encoded character. That s not a problem as long as you have only Mac and Windows clients accessing your server, as both systems do not allow colons in file names. In our case we found a number of cache files from Nautilus (which is running on our sunray/Solaris web-surf terminals as default browser) with colons in the file name. I hope no user will miss them <img src="http://bzed.de/lib/images/smileys/icon_wink.gif" alt=";-)" /> </p> <p> Including a final synchronisation of all files to the new storage, about two hours it took uniconv to convert the file names and a aunch break, we were finished after about 14 hours of work. Until now it seems that our users didn t notice the change at all, except for those who realized that they have much more free space now. Looks like a successful weekend so far! <img src="http://bzed.de/lib/images/smileys/icon_biggrin.gif" alt=":-D" /> </p> <p> <strong>update:</strong> full html in the feed. </p> <div class="tags"><span> <a href="http://bzed.de/tags/debian" class="wikilink1" title="tags:debian" rel="tag">debian</a>, <a href="http://bzed.de/tags/linux" class="wikilink1" title="tags:linux" rel="tag">linux</a> </span></div> <a href="#fnt__1" id="fn__1" name="fn__1">1)</a> and uses a NFD variant of Unicode normalization (<a href="http://en.wikipedia.org/wiki/UTF-8%23Mac_OS_X" title="http://en.wikipedia.org/wiki/UTF-8%23Mac_OS_X">UTF-8#Mac_OS_X</a>), but netatalk takes care of this and translates it into the NFC form, which is used on most other platforms <a href="#fnt__2" id="fn__2" name="fn__2">2)</a> it s called netatalk-uniconv in Debian and shipped with <a href="http://packages.debian.org/stable/net/netatalk" title="http://packages.debian.org/stable/net/netatalk" rel="nofollow">netatalk</a> <a href="#fnt__3" id="fn__3" name="fn__3">3)</a> Catalog Node ID, another crust from old Mac <acronym title="Operating System">OS</acronym> versions </div>

Busy day yesterday; the first day of RoCoCoCamp, and the first day seeing a lot of friends and friendly faces from out of town. I was out of bed at 6AM yesterday. I stopped at St. Viateur Bagel on Mont Royal and got 10 dozen bagels -- enough for our expected crowd. I got to SAT at about 8AM, just in time to start the coffee machines. The big percolators I rented for the event require about an hour to make coffee, so if people were going to be coming in at 9AM, I really wanted to get them started by 8. Alain Bernardeau from computation.to got there soon after, and set up the spare computers his organization is lending us. Brandon Sanders, Mark Dilley and Nathan R also came in early, looking for work to do. I got them all into the job of setting up the food for breakfast. By 9AM we were trucking along, and I figured I'd go try a cup of joe, which should be ready. But all I got from the carafe was cold water. The percolators draw so much current that they'd blown a circuit. Guillaume, the SAT tech, and I tried about 8 different ways to keep them running, but nothing worked. Finally he put them on the 220V industrial circuit, which they didn't blow. Awesome, but at 9:30AM, with almost everyone there, we had no expectation of coffee for another hour. Yikes! But by the time people started filtering into the circle for starting the event proper, coffee was rolling and I was much relieved. Our facilitator, Deborah Hartmann, gave a great bilingual introduction to Open Space Technology and got the ball rolling. I always have a moment of dread during the beginning of a Open Space event: what if this is the time that Open Space doesn't work? But it did, again, which is great. The first session I went to was Zach Copley's, about consensus-supporting software features. Brandon Sanders had some great cases from AboutUs's adult content policy. We shared a lot of Wikitravel's culture, too. I also stopped in to talk about Wikitravel:RDF with Reini Urban, who was demoing Semantic MediaWiki. It's a neat project, and it's a different tack than I've taken with Wikitravel. I'd like to see the two approaches harmonized at some time in the future. Lunch came quickly, and we had far too much to eat. I spent a lot of time talking to Simon Law about possibly using Open Space in some way for BarCampMontreal. I think it's a good idea -- it's growing to a point where our current format is straining under the load. We also talked about ubiquitous wikis and the cool browser Amaya, where Web pages are in edit mode by default. It's a good idea. After lunch I had a chance to hang out with Earle Martin of Open Guides and talk about wiki and the geospatial web. Mark Jarowski of Wikevent was there, and together we've decided to hammer out a RDF vocabulary for exchanging RDF data about business listings. It's the kind of productive talk I like having. I also spent some time with Jack Herrick talking about wiki entrepreneurship. Jack had a prepared presentation about wikiHow's business experience, which was really great, and provided a great case study for talking about commercialization of wikis in general. With Angela Beesley and Ray King around us, we had most of the interesting wiki content businesses represented. Pretty neat. It was a really productive first day, but by the time we got around to 5PM I was exhausted. Maj, Zach, Mark, Niko and I all went to our new house at 4690 rue Pontiac to meet Allegra and their two daughters, No ma and baby Anoushka. We got pizza and had beers and sat on our new couch and had a good old time. Technorati's rocococamp tag shows a lot of other positive responses on the Web: Matt Forsythe's sketches from RoCoCoCamp, NathanR's continuing paranoia, CITIZENShift (which quotes me, when I was talking about wiki entrepreneurship), and Patrick Tanguay.

I'm off to SAT again this morning. Should be a fun one, and I hope to get a little more time to myself before the event starts today. tags: rocococamp barcamp barcampmontreal recentchangescamp wiki wikitravel

It's been a busy week here and I've been lax in updating my blog. It's probably a good thing to put on the chopping block -- of all the possible things going on in my life -- but I'm regretting not keeping up with it. We had a good weekend last weekend. Maj's Mother's Day present request was to clean out all our closets in the house and take extra clothes to the Petits Fr res up the street. It took most of the day Saturday, and we finished with twelve garbage bags full of clothes for the Fr res. Check out Maj's photo of the pile of clothes. Sunday morning Amita June and I made Mama a nice breakfast of waffles and (tofu) sausage. Amita's job was to stir the batter (which she did a good job at) and not to touch anything hot (not so good). That afternoon, Maj went to get a haircut at the salon down the street, and I took the opportunity to give Amita June her first haircut. I think she looks like Twiggy. This week has been a maelstrom of activity. We have RoCoCoCamp coming up on Friday, and we're still tying all the loose ends together. I had most of my tasks done yesterday, so at the organizational meeting last night I saddled myself with more. D'oh! I think my main work this week is going to be encouraging local Montreal tech scenesters to come. I especially want to make sure that important women in the local Internet scene are present, so I'm going to copy Hugh McGuire's invite for BarCampMontreal2 and do some link-baiting:

• Martine Page, filmmaker and journalist who's an anchor of the local blogging community
• V ro B., vodcaster and blogger and general communicator
• m-c turgeon, podcaster and blogger and founder of Stars of the Web
• Marie-Joe, who provides a crucial link between the local blogging and game communities and is obsessed with Wikipedia

tags: mothersday amitajune rocococamp barcampmontreal montreal women

Interview There's a really good interview with me and Maj on the Internet Brands Developer Blog. It's gotten into the short list of interviews I point press to when they want background about Wikitravel -- along with the Creative Commons interview. I'm really glad that IB has started this blog to give the outside world a peek at what's happening out there in El Segundo. And it's also a great way for IB to highlight some of the Open Source work they're doing, like the neat-o new AJAX tool kit IBDOM. tags: interview ib ibdom ibbydev