My spare time has been quite limited this month and last. I've had to freelance work on a shopping cart, my alpaca farm website Alpacas of the Coast and keep up with my TV watching ;) I have been working on the Nvidia packages on and off. So far in the next release will be:

* New upstream.
* remove xserver-xorg-core dependency.
* add cuda files (closes: #463776)
* add bzip2 to build-depends. (closes: #466139)
* add uploaders field that went missing: (closes: #454999, #472448)


linux-modules-nonfree-2.6 support will be added too.


Then, hopefully I can catch up with the legacy versions. Anyone who would like to join the packaging team feel free to contact me.

I have a small set of config files and cfengine scripts that I want to deploy on every machine I own. Of course, the Debian way is to put them into a package, and install that. So far so good. Problems arise when trying to maintain this package on several different $HOME directories - depending on where I am when I want a change. Using $vcs (svn in this case) works, but I'd also like source packages. Only that I occasionally forget where I put the repository. Or uploading new source packages is too tedious. The later problem was solved by a cute combination of dput and reprepro. My .dput.cf has targets that rsync the package over to my server, and automatically install the packages into the repository there. For the repository problem, Stefano Zacchiroli's debcheckout comes to the rescue. Vcs-Svn: in debian/control points to my svn+ssh:// repository. Instant "DWIM" checkouts! (To actually make this work, the latest cfengine tweaks add deb-src lines for my local repository that were previously missing.)

This is fairly obvious in theory, but it’s the kind of thing you don’t always think about: when receiving patches via e-mail, it’s possible to have Mutt directly color them as vim or colordiff(1) does. I have this:

  % grep rc_diff ~/.muttrc
  macro   index   \e,sd   ":source ~/.mutt/rc_diff\n" "source ~/.mutt/rc_diff"
  macro   pager   \e,sd   ":source ~/.mutt/rc_diff\n" "source ~/.mutt/rc_diff"
  % cat ~/.mutt/rc_diff
  color body brightblue default   '^\+.*'
  color body brightred default    '^-.*'
  color body brightgreen default  '^(--- \+\+\+) .*'
  color body brightyellow default '^@@ .*'

Update: In case there was some confusion, the rc_diff snippet above is meant to be sourced only when there’s a mail with a patch, otherwise it’ll highlight parts of normail email too. The way to disable again, though, is quitting Mutt...

I am trying to add some order to the mess that is the Launchpad translation repository. Problem is, strings translated just once through Launchpad stick around forever, even if you change them in upstream later. In effect, a lot of translation bugfixes were not reaching Ubuntu users. I thought I had that covered. Unfortunately it's not the case. I just noticed that in the Launchpad package list sorting by changed strings only sorts the first page! Initially I had noticed random package names and mistakenly thought that the whole package list was sorted. The whole list (~1500 packages, shown in 75 package chunks) is sorted by "importance", so it's basically random. Good luck finding modified packages in that haystack. Seeking computer-literate monkeys.
Earn up to five bananas per hour!
Must be able to use mouse. Unless... how about increasing the batch size? Turns out that in Launchpad the batch size is not capped, so by changing a URL parameter you can just set it to a high number, wait a few short moments, and get the complete list of packages. Sort that by changed strings and we're done, right? We're done finding the local translations, but not fixing (reverting) them. The new, larger list reveals that there are more than a few of those with quite more than a few strings that should in 99% of the cases be reverted to packaged versions. Here's how that works: Monkey operator instruction manual

1. Click on 'Packaged' radio button for all 10 entries on page (no batch size modifications allowed here...)
2. Click 'save'
3. Repeat until the page says 'No more translations'
4. Done. Not! When you click the 'Save button', the starting offset is changed for the next page. However, the translations you just marked are removed from the list at the same time. So, if you were looking at translations 1-10, after pressing 'Save & Continue' you will actually be looking at translations 21-30, not 11-20! To get to the 'lost' translations, you have to retrieve the list from the start again. So, load the initial page and go to step #1 to fix the remaining half of translations. Next time you reach this step, half of those will be left. Next time, half of half of those. Isn't that fun!

Where's that monkey ad again? A brute force solution could be to write a script. That could save some bananas. Not that we could run out of them as this whole thing is pretty much bananas. That does not look like a clean solution though. Does anyone know if there there is a better way?

We are currently developing a new feature for the dak instance running on ftp-master.debian.org: Release transitions. It basically means that the Release team has the possibility to block uploads of packages to unstable. I will describe the exact way how this will work in a mail to the release list, after aj merged my branch into mainline. But that should be pretty soon now, aj and myself did some code changes today and it looks ready now. Basically we will have a Yaml formatted file where the transitions are defined, together with a target package/version. As soon as that package with that version reaches testing the block is no longer in affect, but until that is the case every upload of a listed package will get rejected. We do check the testing version for every upload here to ensure that such a block, which is a pretty hard action, will be turned off as soon as the package transitioned, even if no Release team member is active at that time to remove it by hand. The release team will have a wrapper, dak transitions, which spawns an editor so they can define what they want as transitions. When they save and exit we check if the Yaml parses and then copy it over. The same wrapper is also used to clean the file from old transitions and to let the release team see what is defined in some nice, human-readable, way. (For the rest of the world I hope that the QA page will include information found in the file, which should be available later from http://ftp-master.debian.org/testing/hints/transitions.yaml. Or a little perl/ruby/python script for developers to run at home, so they can check if their package is affected). Its Yaml and easy to parse, even human-readable. :) I think it will be a nice feature helping the release, as huge transitions now can be done without the fear that one single upload will break them.

Debian is part of the Google Summer Of Code again this year (2008).Last year was quite successful, so we hopefully will get at least as many slots as last year.Applications will be possible March 24th to March 31st. This means, you should already starting writing your project proposals and get feedback by possible mentors. Ideas can be found in the Debian Wiki, but notice these are just ideas. You are by no means limited to what we're proposing there.As for writing an application, here are some general notes:

• Start writing early, submit early. The early ones get best exposal to mentors. When we read the nth proposal for the same project, we're usually quite bored already. Especially with respect to feedback this IS a benefit for the early proposals
• Don't just copy & paste. We're not stupid. We want to know if you understand the subject and have good ideas, so show that. We're not interested in your ability to access the Wiki, we trust you on that one.
• Communicate. Open Source is about communication and collaboration. So get feedback from people who work on the related subjects and possible mentors. Don't keep your application secret. You don't have to be afraid someone could steal your application (remember, we read the applications, and we can tell who has just been using copy & paste and who is able to answer our questions!) - but you DO need the feedback to improve your application.
• Use all communication media. The GSoC web application has it's limits (e.g. by not being open yet). So make use of the IRC channels (#debian-soc in OFTC) and the mailing lists for your project. We'll also use these to judge your application, not just the web interface. "Has been asking good questions on the mailing list" is one of the best verdicts you can get.
• Bring in your own ideas. We're looking for talented, interested people, not "stupid work horses". So show what you've got.
• Don't be afraid of challenges. This is all about stepping up to a challenge. We'll help you succeed. If you e.g. aren't experienced in Python yet, but the proposal says "Required skills: Python", just be honest. Mention that you're a good Ruby coder, and we'll trust you on being able to pick up Python in a short timeframe. And maybe even just start already in filling such a gap.

In turn, we (= the mentors and admins) will try to (again - we did that last year) have at least three mentors read through your application, provide feedback on it and judge it. We don't draw lots for the slots, but we'll rank the applications based on the scoring by the mentors. We'll also try to assign you a fallback mentor in case your mentor has to step back for whatever reason and to give you additional people to talk to.

Occasionally I post (or could post) things that are not fit for Debian Planet (non-English) or Ubuntu.lv Planet (unrelated to Latvian or Debian/Ubuntu matters), so I finally budged and switch the planet feeds to their own categories so that such things can be managed on a per-post basis. Anyone know a Wordpress plugin that would allow to set multiple default categories?

I tend to favour text-mode applications (I’m sure vim, irssi, zsh and mutt account for most of my keystrokes, in that order), but there are times when a graphical application is called for, for example the browser. Or when I just find it more convenient, for example the music player. Lately, though, I’ve been pleasantly surprised by a couple graphical applications, for which I had text-mode versions which worked more or less acceptably: a random-note taker (I was using vim), and a dictionary (/usr/bin/dict). I’ve replaced these two with Lars’ Notetak, and StarDict. I’ve found that having them constantly running in desktop #2 (which is one keystroke away) beats having to start up vim or dict each time. Curiously enough, in both cases the main interface of the application is a text input line which offers some kind of “incremental search” functionality. StarDict is packaged in Debian (package name stardict-gtk or stardict-gnome), and Notetak, being Python, is easy enough to run from source (the page claims there is a Debian repository there, though I can’t access it).

I just discovered that, since I enabled the TV over DSL option, Tele2 limited my downstream bandwidth to 8mbps (instead of 20 mbps). All the time. Even when I don’t use the TV. Because allowing 20 mbps could have affected the quality of TV reception (when the TV is off?). They proudly advertise that offer as:

• unlimited DSL up to 20 mbps
• 41 TV channels and 32 radio channels included

It seems that they forgot the “OR” in between.

Last week, while I was already busier than I like, the cpu fan of my pegasos powerpc server blew off, and the resulting heat then killed the CPU. Which was quite a pain, as I used powerpc vservers on it, for which I had no replacement hardware. Or so I thought.

Time for an advertisment break: I'm giving away my oldworld powerpc macs, if you are interested in a beige G3, a 7200 or 4400 powermac, contact me. I doubt anyone will, these machines are more then ten years old. So I will probably give them to recycling next week. Be fast!

I'll also give away my pegasos2 board (and case) to the first person asking.

To make a two day story very short, I now run my vserver on a ten year old iMac, the very first model in a translucent case with build-in monitor, with 160 megabytes of RAM and 233 Mhz powerpc CPU. Yay. It's actually ok for what I need it.

The insane part is the booting. The hard disc has a MSDOS partition layout, as this is what the pegasos uses. But the iMac of course needs a HFS layout, so I need to use a boot CD, for which I've used a modified installer CD, where I replaced the kernel and initrd with the one I want. (Mostly because I didn't remember how to create a bootable CD on macs.) For some reason, the mac wouldnt boot this CD directly, so I've decided to use OpenFirmware (OF) to load yaboot (the bootloader) from CD manually and then yaboot will boot the kernel which can mount its root filesystem even from a disk with msdos partition layout :-)

And now I'll tell you about the magic of forth in OpenFirmware - which was only needed because I was stubborn and kept the kernel inside the directory install/powerpc on the CD... In OF you need to seperate pathes with backslashes, but with the OF installed on this iMac you can't type them! (No comment on that.) But you can use forth to evaluate them...

And so I use '" boot cd:,"(5C)install"(5C)yaboot" evaluate' in OpenFirmware, in which I get a prompt through pressing alt-windows-O-F while powering the machine on, to boot my main server at home. Easy.

I don't intend to do this very often (it runs 24/7), my new server has a XScale IXP422 266 mhz CPU and runs Debian armel :-)

But more on this later, now I need to throw out more old hardware, stuff I will never use again and which just takes physical space. Modern hardware is tiny - as can be seen on this huge pic! :-))

Oh, I almost stayed with powerpc: The "Conceptronic Grab'n'GO CH3WNAS" has nice specs too, is a bit cheaper and should be able to run Debian as well, but there are some missing bits until a 2.6 kernel will run and I wanted a solution which works today. And the FSG-3 (has better specs, that is, more RAM and more ethernet ports, allowing 4 vlans and) runs the new armel port already, the sub architecture patches "just" needs kernel mainline inclusion and there is no d-i support yet. But if you press the reset button on poweron, it will query a bootp server for its own IP address and for a file called zImage-recovery... :-)

And for those who care about the finished FOSDEM 2008 videos: unfortunatly I had even more hardware issues (which I refered to in the ... blog posting last week), which blocked me from working on them. But I will resume this work now (most of it is done by the computer anyway). Now, that I brought my laptop to warranty repair and put the disk into my desktop... To be clear: the laptop incident now is not the case I blogged about last week when I just wrote "..." - that was another machine where I intended to postprocess the videos on and now use as my laptop and to postprocess the videos on. I guess now you can somewhat imagine what I thought when my laptop broke two days ago on a harmless wednesday evening?

Hardware. It's great when it works.

Well this has been a busy week, and no mistake. Still I've advocated a new individual who wishes to become a Debian Developer. I guess now I get to watch second-hand to see how long the process takes! (I messed up though; the first sponsored upload for her has the wrong mail address. It'll get REJECTed, and then we'll try again. D'oh.) In more optimistic news this weekend I'm going to attempt to finish painting my front room. The painting of this room was started n the 3rd of February. So we're coming close to two months. A new record! Also this weekend I must write some letters ... Tonight will involve some Balvenie and a copy of The Godfather (part 1). ObQuote: Eight Legged Freaks.

I just read an interesting blog post about Montenegro [1]. Apparently a key to the process of becoming a country was acting like it was inevitable. It seems that this method can be applied to many areas, one of which is the contest between Linux and some proprietary OSs. For many years monopolists have convinced people that it was inevitable that they would monopolise all areas of software development. Why use any other software (even if it is more reliable, faster, has more features, and is cheaper) if a monopolist is about to dominate the market? The monopolist changes sometimes, the monopolist from ~1990 to now is different from the monopolist of the 1970’s, but the tactics of a computer monopolist remain the same. The way to beat this is largely to just ignore them. There is an ongoing debate in some circles about when Linux will be “ready for the desktop“. I’ve been running Linux as my primary desktop environment since about July 1998, it’s almost 10 years of having Linux as my primary desktop environment. It seems inevitable that the Linux will take over the desktop - it’s far better for desktop use than it was 10 years ago when I switched. Some people claim that Linux lacks driver support. Every piece of hardware that I’ve wanted to use over the last 10 years has had adequate support. Often second-hand hardware works best with Linux, hardware vendors have no reason to continue to support their old products on newer operating systems (they make more money if you buy new hardware to run the new OS). Not only is hardware support for Linux adequate, but long-term support is far superior (and I often get to use cheap second-hand hardware). Now that an increasing number of hardware vendors are supporting Linux for their new hardware (Intel, AMD, and most laptop vendors are doing some good work in this regard). It seems that everyone who has tried both says that writing drivers for Linux is easier than writing drivers for proprietary OSs, so it seems inevitable that Linux will end up with better driver support by all metrics. Linux is designed for users. DRM (Digital Restrictions Management) is not something that interests Linux developers. Run Linux and your computer will obey you and give full quality audio and video. It seems inevitable that Linux will dominate the AV section of the market (it already dominates the computer work involved with creating movies). Free software (of which Linux is merely the most famous and popular example) is based on the principles of open design and open standards. When you use a free software program to save a file then you can be reasonably sure that you will be able to read it back again in a few decades. Most free software uses file formats that are well documented and standardised. Sometimes there are bugs in programs and new versions will use files in a different way, this is sometimes a case when you rely on a bug in an old version. Using the older version of the software is sometimes required to properly access old data. Fortunately when you have the source to the older programs they can be compiled on new systems (so different types of CPU won’t matter). Also the lack of DRM means that an OS image can be virtualised. One thing that is on my todo list is to create a set of virtual machine images of some of the most commonly used distributions of Linux so I can easily compare distributions of 10 years ago with modern distributions - it’s not technically challenging and there is no particular technical or legal obstacle to doing this. This would also mean that if someone gave me a file in some strange format from 10 years ago I would have a better chance of reading it. It seems inevitable that as the value of data increases the desire to avoid OSs that prevent people from accessing their own data will also increase, and that will eventually squeeze out most closed software from the market. This doesn’t mean the end of proprietary software, merely the end of software that holds user’s data hostage. The majority of the world’s population does not use computers. The computers that they end up using will be cheap because they can’t afford to waste so much money on new hardware. To make cheap machines means that there will be limited resources in terms of RAM, mass storage, and CPU power which require more efficient software. Also to properly take advantage of machines with small screens and other limitations changes to the design of the software will be required. It seems inevitable that the most open software will be adapted to such environments more readily than proprietary software. Now this doesn’t mean that we can take a break from development. In the free software community there are usually many different programs to perform a particular task with competition between the developers of the various projects. The fact that a monopolist is inevitably going to lose it’s position is of little relevance to the competition between the various free alternatives.

• [1] http://www.airs.com/blog/archives/115

Share This

About a year ago, I bought a Norhtec MicroClient Jr., a complete 200 MHz MMX-compatible SoC (“Vortex86”) PC so small that it fits into your hand or onto VESA mountings. Althought thought as thin client, the machine has 128 MB RAM and runs Debian from either netboot, USB stick, CF card or 2.5” harddisk without problems and not even that slow. Later last year, we needed more MicroClient Jrs. at work and since the MicroClient JrSX had a 300 MHz 486SX-compatible SoC processor (“Vortex86SX”) from MSTi and 128 MB DDR RAM instead of SD RAM, we expected them at least in the same performance range and bought a few for ETH and I also bought one for myself. Well, they were about three times slower, since the FPU is missing, not all programs from Debian Etch work fine, e.g. X doesn’t work without patching and recompiling (with Sid, X works, but not the kernel anymore)… BTW: I had both machines with me at FOSDEM ‘08 at the Debian booth and the MMX-compatible machine also at Chemnitzer Linux-Tage (CLT) at the Symlink booth and in Kurt Gramlich’s talk about ecological computers. So if you saw them there, just imagine the same case, with a twice to three times faster CPU and four times the amount of RAM, but with roughly the same carbon foot-print! For our thin client purposes at work we now use ALIX boards from PC Engines (Mini-ITX format) with 500 MHz AMD Geode processors. They’re much faster than the MicroClient Jr. and need even less power. Today, while surfing around on some Mini-ITX shops, I found some computer in obviously MicroClient Jr. case, but with 500 MHz VIA Eden processor and 512 MB of RAM. I first couldn’t believe it. They are selling it as eTC-2500. Since eTC-2300 was one of the brandings of the MicroClient Jr. which is called eBox-2300 officially by the manufacturer DM&P, I searched for eBox-2500, but didn’t find anything useful. Then I looked at the manufacturer’s product page at CompactPC.com.tw and found the eBox-4300 — so it’s really true, they managed to fit a board with 500 MHz VIA processor and half a Gig of RAM into the already fscking small space inside the MicroClient Jr. case, and even without needing more power: Still 15W from the power adaptor. Next stop was Norhtec’s Website. And yes, they also have a new MicroClient product: The MicroClient Sr.. I really need to have one of those for my MicroClient collection! ;-)

Yesterday was the annual March Madness Half Marathon in Cary, IL -- and this year marked the 30th anniversary of the race. The race is getting more and more popular as the start to the running season, and an early race for those in Spring marathon training. This year, and it had sold out in a matter of days. As for the race, I wasn't running it all that well. My legs already felt heavy when I was doing a casual four-miler the day before with our local running group. Similarly, I didn't feel all that loose yesterday. By mile four or five I was getting into a decent rhythm, and I was then running fairly steady 7:15s until about mile 11 when I ran out of gas and had to slow down. Final time was 1:36:38.15 -- not only several minutes slower than last year's but also slower than two years ago.

Unsurprisingly, there is a deal of common ground between a SQLite backend and a GDA backend. Both need simple routines that convert library data into SQL statements but each has very different ways of reading that data back from storage.
I've spent today doing upstream work (whilst also getting my central heating system replaced). Gutted the house, gutted the library - what's wrong with that?
However, I've decided to make these new functions private to the library rather than exporting them. Simple reason really - they are one-way routines.
One day, QOF will support UPDATE statements and one day a bit later it will also support DELETE and even DROP but those require changes within the library like "unregistering" objects that the current code simply doesn't expect.
Eventually, this kind of SQL support can make a usable query interface for quicklist and a few other stalled projects (like DWI). The principle gain is to allow QOF objects to evolve and adapt but retaining compatibility will be a challenge. (QuickList is likely to only support a read-only mode for some objects and require that others are renamed before being amended.)
The other advantage of this refactoring is that the SQLite backend in libqof2 will be a lot smaller than before. Migrating the code hasn't increased the size of libqof2 either because so much deprecated code has been removed when bumping the SONAME.
I'm sticking with the roadmap of not looking to release libqof2 until after Lenny but that gives me plenty of time for internal reworking to get the GDA backend functional.
So far, I have been able to create a test GDA data source, add a table and data, delete the data and drop the data source. Not bad! (I test with SQLite but XML, MySQL, PostgreSQL and other ODBC connections are supported by GDA without changes to the QOF code.)
As ever, implementing new functionality needs a new test case so that has also been started - only 20 tests so far but worth doing.
Other changes before libqof2 - at the request of the original developer - will include updating QOF-Generator to work with libqof2, updating the old HTML example pages to provide a "QuickStart Guide" and other introductory documentation. Whilst I'm doing that, I'll probably also work on the Emdebian website documentation that also needs improved coordination.
Also note that pilot-qof and gpe-expenses are already libqof2 compatible. All that will be needed is some way for those to provide the username and password variables that some GDA connections would need. (The QOF GDA code already has support for such settings, it just needs to be implemented in the respective frontends.)
First set of changes are now in QOF CVS.
(Yes, CVS - I just don't see the appeal of all those new-fangled RCS versions - subversion is about as "modern" as I need. I just don't need the hassle that comes from git fanboys (or any of the other RCS versions) - nor do I need the hassle of migrating CVS to SVN.)
What I would say is that of the various SVN WWW interfaces, websvn stinks, view svn is a bit better but the only one I really like is Trac. For a single large project, Trac is much more friendly IMHO.

A few years ago, Elvera Voth, a musician that grew up a few miles from here was back in the area. Her specialty is vocal music, and one evening, she led a hymn sing at our church.

During the event, she talked about how much music can touch the heart. Elvera remembered many years ago that a woman in the church was leaving for a service trip to India. She would be gone for 7 years straight. None of her family or friends would be able to see her during that entire time.

The day she was to depart, friends, family, and church members went with her to the Santa Fe station in Newton, KS. While waiting for her train, at some point, the group started singing. Elvera remembered that they sang So nimm denn meine H nde (Take thou my hand, O Father) and Ich bete an die Macht der Liebe (O Power of Love).

Elvera remembered they sang in the station, and the high, wood ceilings made it sound like the music filled the whole building. I can't think of a better goodbye than that.

Elvera remembered so many details about the event, but two things she didn't remember were who was leaving and what year this happened. So I remembered this story for awhile, but didn't really follow up on it.

Then last December, our neighbor Hildred called. Hildred and her sister live on their old family farm about a mile from us. They're some of the older members of our church, and I believe both of them have lived on that farm their entire lives. Hildred heard that I am gathering photos for a book about the centennial of our church, and she offered to bring some of them over. Knowing that it was cold and dark outside, the roads were snowy, and that Hildred drives a car at least 40 years old (because "Daddy said this is a good car"), I offered to drive to their place. "Oh no," she said, "it's no trouble. I like to get out. Besides, I haven't seen your house since it's been remodeled!" So she came over.

Hildred had stacks of amazing old photos from the church and the community. And she had a stack of photos and letters from India, where her aunt Augusta Schmidt was a nurse for 14 years. She was very proud of her aunt's service to the needy there. I started to put things together in my head and asked her if she remembered singing at the train station when Augusta left for India. "Oh sure," said Hildred, as if everyone knew about that.

So that's how it happened that the "historical moment" on Feb. 10 was about Augusta Schmidt. Each month during church, leading up to our centennial in October, we have a brief time where we highlight some interesting story from the church's past. I happened to mention this one at a historical committee meeting.

So, on that Sunday in February, someone got up and told everyone about Augusta's life. She was born in 1894 and graduated from college with a nursing degree in 1927. She heard about India at a conference, and quickly felt that God wanted her to serve there. She left for India in the fall of 1927, and would serve two 7-year terms there.

She wrote that India was a beautiful land, contrary to things she had heard. The city where she worked (I believe it was Bombay, but I'm not positive) had hallmarks of a wealthy city, such as educational institutions, hotels, etc. However, it saddened her greatly to learn that 80% of the people in the city were homeless and slept on the street. No doubt this played a role in her dedication to service there.

After we learned about Augusta, the choir sang So nimm denn meine H nde -- one of the songs that Augusta heard at the train station back in 1927. Imagine you were there, 81 years ago, seeing a friend off on a trip across continents, not to see her again for 7 years. Then the people there start singing a cappella...

So nimm denn meine H nde und f hre mich Bis an mein selig Ende und ewiglich! Ich kann allein nicht gehen, nicht einen Schritt; Wo du wirst gehn und stehen, da nimm micht mit.

Take thou my hand, O Father, and lead thou me, until my journey endeth eternally. Alone I will not wander one single day. Be thou my true companion and with me stay.

You probably weren't there that day in 1927, or even the day in February when the choir sang the song. I wasn't either because I had the flu that day. But I borrowed the cassette recording of that day's service, recorded using the best we have right now -- the wrong type of microphone pointed the wrong way, onto a cassette tape that has certainly been reused way more times than anybody knows.

Click here to listen.

The choir sang the first verse in German, verse 2 in English, and the whole church joined in on verse 3. I'm told there weren't many dry eyes in the church after that. After all, how could you keep a straight face singing "Take, then, my hand, O Father, and lead thou me, until my journey endeth eternally" right after the narrator read about Augusta's retirement and death, saying, "there, I was surrounded by friends, but most of all, by the sovereign love of God who had been with me my entire life."

Postscript

Remember Elvera Voth, from whom I first learned this story? In 1961, she moved to Alaska. Elvera taught at several universities; founded the Anchorage Opera; directed the Alaska Festival of Music, Anchorage Boys Choir, and Alaska Chamber Singers; and there is Elvera Voth Hall at the Alaska Center for the Performing Arts.

But her best work, I think, happened after she retired and moved back to Kansas in 1995. In 1998, Elvera founded the East Hill Singers, a choir composed mainly of minimum-security prison inmates, plus volunteers from the community. Elvera has inspired so many people, taught them that they have value, that they can succeed and make themselves better. One of the said:

Can you imagine what a standing ovation feels like after being told all your life that you are worthless?

And another inmate commented:

It made me feel like maybe I'm not just being punished. I mean, I am being punished for what I did. But being in this program made me think that I can also come out well, better a better person.

It all makes me think. What an amazing thing these two women with love in their hearts have done to make this planet a better place. Is it even possible to do that by using weapons that kill and power to frighten?

As Elvera puts it, "many of the men in prison will be back in the community soon. I'd rather have them as a neighbor with hope in their hearts than with hate in their eyes."

I've been sucked into this alternate reality game, "The Lost Ring", which involves 6 people who woke up with amnesia in labyrinths around the world, blindfolded, with a tattoo "Trovu la ringon perditan". It involves a lost Olympic sport, lots of Greek mythology and history, and lots of puzzles and detective work. Currently 26 pages of a codex are being tracked down from hiding places all around the world, with ones in Cardiff and Austin recovered over the past few days, one in Shanghai that I hope will be reached soon, and a location just discovered in Stockholm (in a bread store!), that someone needs to go check out. (Update: Jon read about it in my blog and went and got photos! page 1 page 2.) This is the first time I've played an alternate reality game, but the way the story is told, through blogs, podcasts, youtube videos, email with the characters, and recovered documents like this, is quite compelling. Also interesting is all the use of Esperanto, as well as characters who speak Spanish, French, German, Chinese, Japanese, and Portuguese, so that translation is an ongoing part of the game.

I’ll blush and admit that I’ve always been a bit of the “my package my castle” type. But things change, and now I feel differently about my packages. I toyed with the idea of adding myself to the low threshold NMU list, but it didn’t make me very happy for several motives:

• first and foremost, it places emphasis on the upload as the basic unit of collaboration, whereas I think such unit should be the commit
• places the information on a network location, whereas I think the information should be more readily available and near the package itself
• uses “non-maintainer upload” to describe itself, which is already something else

Then there is the collab-maint project in Alioth, which is nowadays intended as a general purpose area for small teams or groups of co-maintainers to collaborate in their packages, without needing to create a full-fledged Alioth project. Every DD and many non-DD have write access to it, but a package being there does not mean that its maintainers want other people to use such write access on their packages. But, alas, there is no standard way of saying that you do want people to make use of that access, and how (of such way could also benefit projects that make use of the Debian acl, to advertise the fact). So, as a first draft to fill in these gaps, I’ve migrated several packages of mine to the collab-maint umbrella, and added a X-Collab-Maint header to debian/control to signal that I’m open to collaborations on them. For me, a header felt the best way to express this information, since it ends up being very accessible (only one apt-cache showsrc away). As Zack points out to me, though, having it in a header doesn’t necessarily mean the source of the header has to be debian/control forever (think e.g. what debtags does) — this leads to interesting possibilities, like changing the policy without an upload, or setting the same policy for a large set of related packages. As for the contents of the header, I think a reduced vocabulary would work best. As a start, this is the one I’ve been using for my packages:

• commit-branch: please commit your stuff into a branch, so that I can review and merge it. Other people could just use commit if they prefer commits to trunk directly.
• upload-10: feel free to make an upload with your changes if I haven’t acked them within 10 days. Other people could use upload-with-ack, to signal that you’re happy for other people to upload, but that’d you like to review first. Or even upload-0.

Other stuff that’s could be specified includes whether people making a commit should notify the maintainer or not, before letting the upload day count tick. But, if the idea seems worth it, I’m sure we can debate it to death on -project, or something.

Ldap seems like a good database to store accounts in: Lots of tools can use it, it's easily integrated into pam, and lots more. But one sometimes just hits borders in the data model of openldap: There are no semantics available. So, let me give you an example. Take e.g. the dnsZoneEntry attribute in the debian.org-ldap. Actually, one wants to allow anyone to write into that attribute in his own entry. But - and that's a big but - one wants to have two additional checks before writing: One is that one cannot claim any dns entry already used by someone else. And the other is that the format needs to comply to specific standards. Now the question is, is there some way to use ldap with more semantics? Or does one need to write ones own backend to do that (and in all the non-plain-db*-backends, it is specified that one needs to write his own authorization code as well). Or some other recommended way to do that? (Or is the only existing incarnation of that ActiveDirectory?) Update: Thanks to Faidon Liambotis I know now about the overlays in openldap. The standard overlays unique and constraint will probably solve the case above - of course, I have a few more complex cases, but that are at least good starters.

Another week has been spent in a repetition course in the military. Readers of my blog will know that this means playing poker (I lost about CHF 7 this week — we just play for fun at CHF 5 for 50 chips) and watching movies. Tron and Kill Bill Vol. 1 from my collection, and the extremely funny Adams bler which I didn't know before. The story centers around a neo-nazi serving some time in some kind of rehab in a church where, it is soon discovered, the priest in charge of the whole thing is not that much in charge, even of himself. I'm told that I also should watch I Kina spiser de hunde by the Danish Anders Thomas Jensen (writer and director of Adams bler, writer of In China they eat dogs.) Also recently watched Casino Royale (the recent Bond movie. I haven't seen the 1967 one yet.) and The Gold Rush: the 1942 version with added spoken narrative and music by Chaplin. The DVD does contain the original 1925 silent movie, too, where especially the ending is a bit different. And finally lots of episodes of , ! (Nu, pogodi!), which was the Soviet equivalent to Tom and Jerry (not a clone, it is entirely different.) I can highly recommend this to everybody who likes cartoons.