I have written and currently maintain PURI, a ported version of Franz's open-source URI (Uniform Resource Identifier) library. The Franz library uses a number of Allegro specific optimizations. I've tried to remain true to their optimizations by using similar optimizations on other Lisp implementations where possible. However, the is one non-Allegro specific optimization that has caused a number of people some trouble: that the library expects input strings to be simple strings rather than generalized lisp strings. That has caused at least 3 people to mention the issue to me. I pondered the best solution for a bit. Likely, the optimum result would be to write a macro that emits generic functions specialized to both simple and generalized strings. However, I took a simpler route: I removed the simple-string specific optimiztions (such as using schar rather than char). I expect the reduction of trouble for library users outweighs the run-time overhead. A few bug fixes including accomodating a change in the function of SBCL's shink-vector, and PURI 1.4 is now available.

Usually waking up an hour after your flight has left is a bad sign -- like, a sign of imminent doom, that things are about to get horribly worse. At least, that's how it usually feels and this being the third 6:25am flight I missed in 2005, I was well-accustomed to that feeling. Luckily I got re-routed through Tampa, then Los Angeles, and I finally ended up in my San Jose, CA destination with a lovely Val awaiting me. She seemed shocked; said I was far shorter than she expected, then she realized I was walking with a group of Stanford basketball players and that, though they dwarfed me, I still managed to have at least an inch on her. (Val is "5'9 and three quarters!", according to her.) A lot of the visit was a bit of a blur. After arriving, I quickly showered, and was promptly told by Val that my skater rat apparel just wouldn't do and that our New Year's Eve party was meant to be dressy. A black shirt and some funky necklace managed to placate her, luckily, as well as my excuse of having just flown in from out of town with no instructions to dress pretty. Off to the party, where I met a load of brilliant and entertaining people, including Lina who was positively heartbroken by the lack of fireworks.
Lina and me in the ballpit The next day included eating vegan duck for breakfast, visiting Google offices for fun (not profit), getting lost with Val in some frightening redwood forest, Indian food in SF with Janet, Jen, and Val. Actually, the Indian food might deserve an entry of its own -- the owner of the restaurant actually spoonfed me, which was bizarre and funny. Afterwards, we went to visit Kristal and laughed at various things, including the most hilarious website ever. "Oh yeah baby, check out my throughput." Of course, that feeling of imminent doom was not entirely wrong. I contracted some kind of California Plague while there and spent my flight back doubled over with body aches, fever, and chills. Overall, well worth it. Happy New Year, everyone!

I've always seen the relationship between users and developers in the Free Software world as fluid and more of a partnership. That means trying your best to fix problems yourself, and if you can't, make it as easy as possible for other people to fix it. Here's an example of a bug that isn't helpful:

The user tried to install
http://ftp.mozilla.org/pub/mozilla.org/extensions/sage/sage-1.3.6-fx mz.xpi
He is told he needs to edit his preferences to permit this, and given a button.
It turns out instead he needs to edit about:config, and set
xpinstall.enabled = true.
And indeed when he finally does, installation fails as it is an
invalid file or something.
One would be much more confident if there were a debian sage package.

It is not at all clear what the submitter is complaining about. Do they object to the preference setting for software installation? Is there a bug installing extensions? Or do they want sage packaged in Debian? Bug reports should make it clear what the submitter thinks the single problem is. When asked if the were really wanted an RFP bug, the response was:

Please reassign it that way if that is correct. All this is over my head.
Thanks.

If you've submitted over 1000 bugs maybe learning how the bug system works and is organized is a good idea? I'm not trying to attack Dan, but he is a good example of not being helpful.

I've been relatively quiet lately because I've been plodding along, working on modular packages for Xorg. For those who don't know, the next release of Xorg will actually be two releases of the same code. One release, 6.9, will be based on the old monolithic build system. This system requires me to build every single part of Xorg whenever I want to update any one part. This means that whenever I push out an Xorg fix, no matter which component it's in, you have to download all the other components even if they are 100% identical to the previous version already on your hard drive. We've all lived with this for a long time, and while it's not pleasant, we all seem to get by. The packaging apparatus for this system is mature, stable, and well understood, if complex. That's why I've been able to get the 6.9 release candidate packages out to experimental fairly quickly after they are released.

The other release happening is for 7.0, which is obviously a major version number bump. The actual code you run for 6.9 and 7.0 is 100% identical, but the build system has been totally rewritten around the venerable autotools (you know... configure /make/make install). Each piece has been split out from the others so that you can build any one component without building all the others. This means that if we want to ship a driver update, you don't have to download all of the fonts and other things that weren't touched. That also means that you won't have to install the drivers for cards you don't own if you don't want them. Furthermore, it lowers the barrier for things like hacking on X significantly.

The problem with the modular tree is that the packages for it are brand new. Ubuntu shipped modularized versions of the libraries, and I've already stolen those, fixed them up for Debian, and built them locally (they're sitting in our svn repo, but running them won't get you anything at this point.) The server and driver packages are brand new, and I've been taking the packages from Ubuntu's development branch and working on them for Debian. Today was a milestone day because in addition to the libs, with Daniel Stone's constant help I've finally managed to build packages for the modular X server itself. Now I can't run it yet (I haven't packaged the drivers and a few other bits) but the fact that I managed to produce what will be a functional server package is a huge step, and constitutes the cornerstone of the whole thing.

Once we can create packages that can actually run on at least the machines of the XSF, we can start looking at getting the packages in to the archive. Since these aren't well tested like the monolithic packages, we'll have to do a lot of polishing to get them to the same level of quality. My goal is to get that done for etch though, and I think we can do it. Exciting things are happening, and I'm hoping that the modular packages will encourage more people to hack on X, leading to even more exciting things. Build that momentum.

After seeing everyone shill for their favorite scm lately, with most of the predictable ones getting the attention, I thought I'd throw my choice out there, just to see it represented.

I primarily use svn with my work on X in Debian, and it's a wonderful system. Fortunately though, I don't have to maintain the repos, and when something goes wrong I can cry to our beloved DPL to get his admin on, and he fixes things up. This works out fairly well for me as a basic user, but I don't want to be dealing with these sorts of hassles for smaller projects. The distributed scm thing appealed to me in this sense, so when arch started to become a serious buzzword in the Debian crowd I had a look.

Well, more than a look. I fought for over a month with tla and baz and found that they were both so unuseable and poorly documented that I couldn't do more than scream and cry. bzr looked cool, but it wasn't ready (I sorta tried to manage one of the X.Org releases in Debian with it and failed miserably). Darcs was slow and in a minority language, which was a major turnoff for me. And I don't have a ton of diskspace, so git was out. Svk struck me as a hack (it still does) so I didn't want to go with that. Monotone was ok, but not good enough, so I sighed, gave up, and went back to svn thinking that this was as good as it could get. Indeed, we added a quilt-based patch system to the Xorg packages, so now I have a mini-scm (quilt) inside an scm (svn) and it works amazingly well.

But one of my friends just got hired by the people who make Xen, and he mentioned that they used mercurial, and asked if I had tried it yet. I scoffed and said no, and that all scm's suck harder than anything has ever sucked before, but I had a lot of time to kill while I was waiting on an X build, so I gave it a look.

Mama, I'm home. I was stunned that I was able to pick up mercurial in about half an hour after tearing my hair out for over a month with arch.

The UI is apparently very darcs-like (by accident, according to the mercurial author) which is known to be fantastic. Branching, merging, etc is simple as can be so far, although upstream is still working out better methods to deal with merging.

It's very fast, built for large trees (i.e. the kernel) so it will be suitable for managing X with (although I haven't tried this yet, but I plan to). For X, I'll need something fast to keep my sanity. This rules out darcs and baz (which has somehow managed to get amazingly slow in addition to being difficult as of late).

Unlike git, it keeps changesets in xdelta format rather than storing whole files, so it doesn't eat my hard drive.

It's written in python, so it's something I could hack on if I want to.

It supports an easy server setup with apache, and you can push your repos and serve them via static http if you don't have a server, like me.

Like monotone, it exposes hashes to the user, but unlike monotone it also provides a local revision number to make sure you don't spend all your time copying and pasting hashes, which is what put me off from monotone.

It has a fairly small command set, with 39 commands in the current tip (i.e. HEAD) as opposed to the > 150 in baz which made me weep.

It feels like using bzr, except it's here now and ready for production. Indeed, it's already used in production in making Xen.

There's a bunch more that I won't talk about, mainly because these are the things that have grabbed me. A note of caution is that I've only been hacking on local projects by myself (mainly configure-debian) with it, so I don't have the tons of real world experience with multiple trees that the thing is built for yet. I'm thinking about putting up a parallel mercurial tree to the XSF tree just for fun (the svn repo would remain the canonical one) if people are interested and I can find a server. I hope though, that all the people out there who, like me, were bouncing around trying out scm after scm and never being quite happy with any of them at least give mercurial a fair chance. I'm still amazed at how much I like it, and I think some others might feel the same.

Yesterday, the right-wing PAN candidate for the presidency of Mexico, Felipe Calder n, made a declaration that shadows the current president, Vicente Fox (from his same political party) almost look like a genuine statesman. (some links, La Jornada, El Universal) - And that's no easy feat, given that Mr. Fox is -so far- the nation's most prolific president... When it comes to stupid sayings.
How come Calder n rose so quickly to become a statesman? Let me first go through a bit of history. Not much, promise. Well, I'll do my best.
Twelve years and one month ago, Mexicans woke up with the frightening news we had a violent guerrilla group in Chiapas, one of Mexico's richest states, but one with the highest percentages of poor people - and, not coincidentally, of indigenous population as well. This uprising was very soon known all over the world - And its leaders quickly learned how to ensure they would not be prosecuted and exterminated: Simultaneously with the fighting, they made as large a media coverage as they could, strongly supported in the Internet democratization of the information that had just begun. Thousands of people all over the world understood their ideas -at least what they said at that time- and spread the word. I had my first trip in Europe with my (now) wife in 1996, and we saw many grafittis stating Viva Chiapas, Viva EZLN... It was amazing.
EZLN was (is) specially hard for the government to kill. As they don't do military sabotages, terrorism or so on, it is very hard to justify military action. After 12 days of fighting, a truce was decreed. The truce was broken once, in the early years of the Zedillo government, but officially there is a cease-fire, observed by both sides. The Zapatistas have took the ideas and further promoted them, with action. My Chiapas-born friend Alex Ju rez often tells me about the tremendous cultural difference between the Zapatista territories and the paramilitary ones - In the Zapatista areas, you see indians reading books, working their land, organizing themselves in the Fair Government councils, and strongly opposing alcohol and drugs. Just the opposite from the other areas.
EZLN shifted their strategy some months ago, going beyond stating their wishes for a fair regime and waiting for the government to look at them. I still don't really understand where they are heading, but the Sixth Declaration of the Lacandon Rainforest turns them into a political movement, clearly separated from the existing regime. They do not seek to be elected, they oppose every party and candidate. They define themselves as an anticapitalist movement, located down and to the left - Lets see where this goes to.
Well, back on track... One of the president's most famous stupid quotes is that, during his campaign, he promised to solve the Chiapas conflict in fifteen minutes. Well, it's been either fifteen very long minutes, or he just hasn't had any time to devote to those dirty indians. Mexicans are very frustrated by the lack of importance this man gave to one of our country's longest and most desperate needs.
Of course, Felipe Calder n must do something in this regard. Fox's shadow is a big one, and this little man must try to escape from Fox's biggest mistakes. So he just came with a formula that I don't know why no statesman thought of before: Instead of negotiating, instead of working to solve a very difficult problem, he declared he will unilaterally declare peace with EZLN.
I wonder if this year's Nobel prize will go to such an abnegated, smart and selfless person. Man, we could take this same solution to Darfur, to Israel/Palestine, to Congo, to Chechnya... If rulers all over the world start declaring peace unilaterally, all of the world's problems will be solved! What comes next, he will declare (maybe as Salinas did) that we are a first world country? Poor people are only sad reflections in the sand but don't exist in his reality?
Please, Mexicans: The man is clearly schizoid. Are you happy with Foxilandia? It seems that alternate realities are part of the PAN's action program. If you are not satisfied with Fox's results (who is?), don't vote for this guy. We will all regret it.

After experimenting a bit with Haskell and using it for some toy projects, I decided to see if there was any chance it could be used for a non-toy task; i.e., one where it might one day be necessary to actually have fast code. As a proxy for this, I decided to try a very simple task: counting the number of lines in a file. As input, I generated a file with a million lines of random data and an average of 40 bytes per line; all the Haskell programs were compiled with the current GHC in Debian unstable and with optimizations enabled.

The baseline is, of course, our friend "wc":

real    0m0.084s
user    0m0.043s
sys     0m0.040s

(this and all other timing data was taken after "cat /tmp/testwc.txt > /dev/null" to ensure that the file was cached) Now, it's probably too much to hope that a Haskell program will run as fast as a C program does, since the C program can run in a tight loop. But it seems reasonable that it should be possible for Haskell to be competitive with the trivial Python implementation of this program -- after all, Python is interpreted and Haskell is compiled.

import sys
n = 0
for line in sys.stdin:
   n += 1
print n

Running this simple Python program under "time" produces the following statistics, a bit less than 10 times slower than the C version:

real    0m0.698s
user    0m0.643s
sys     0m0.050s

The trivial Haskell program to count the lines of its input is:

main = do c <- getContents ; print $ length $ lines c

Note that this is basically identical to the Python program, but expressed in a functional style. Pretty, but how does it stack up?

real    0m6.744s
user    0m6.426s
sys     0m0.213s

OW! Ten times slower than the Python code, and a good 80 times faster than "wc"! The gap can be lowered to "only" 50 times with the following program --

do c <- getContents; print $ length $ elemIndices '\n' c

-- but surely it's possible to do better. I'd expect that the expense here is in the use of lazy streams for IO; eliminating them gives us the following code:

wc :: Handle -> IO Int
wc h = do a <- mallocArray bufSize :: IO (Ptr Word8)
          loop a 0
    where loop a n = do amt  <- hGetBuf h a bufSize
                        elts <- peekArray amt  a
                        (if amt == 0
                         then return n
                         else loop a $! n + nlCount elts)

At this point, we're basically using Haskell as a (bad) imperative language. This function allocates a buffer, repeatedly reads into it, and counts the number of newlines in the buffer (I dropped some auxillary code to keep the post short). The $! is important; without it, even though this routine is tail-recursive, Haskell will still allocate an unbounded amount of memory to store the return value. (because, of course, it's terribly important to remember that you're actually returning "1+2+3", not "6")

So, how does this unreadable, hand-optimized version of the code perform?

real    0m1.980s
user    0m1.757s
sys     0m0.094s

That's right -- I've eliminated most uses of higher-level functional techniques, and the Haskell version is still two times slower than an ultra-high-level interpreted language, while also being uglier and harder to read! Ouch. It appears the old performance albatross of functional languages is not quite dead yet.

Call For Papers for the 4th. World Forum on Free Knowledge is now released in english (non-official translation, sorry for mine) and spanish. The WFFK is a Community-organized Forum, made possible by the sponsorship of Government Enterprises and Private Enterprises, as well as Volunteers and Donations. The first was made in Caracas, on November 2004, in the installations of the Universidad Bolivariana de Venezuela, with the sponsorship of the Venezuelan Oil Company, PDVSA. The second WFFK was made in Thiruvananthapuram, in Kerala-India, under the name Free Software, Free Society in May 2005, and the third WFFK was made in Maracaibo, Venezuela, with the support of several Institutions, including PDVSA, CONATEL and serveral others. Impressed by the success of the 3rd. WFFK, a group of people is organizing the fourth, which will take place in Puerto La Cruz, Venezuela, in October 2006. This is the first ocassion a Call For Papers is being done, because the Forum will have a Congress inside it, as well as selected articles. In the past, we only had selected articles and invited speakers on a certain basis. This time, a Call For Papers will also be done, so we can invite nice speakers to come and share with the attendance. Last time in Maracaibo we had David Moreno Garza with us, as well as several Debian Maintainers and Co-Maintainers with us, from Venezuela and Colombia: Ernesto Hern ndez-Novich, Polkan Garc a, Ernesto Crespo, V ctor P rez, Ana Delgado, Gerardo Curiel, Manuel Garc a, V ctor P rez and myself (am I missing someone?). So this was quite a MiniDebConf! Let’s make the 4th. a complete one

Last weekend I moved all of my websites from my expensive dedicated server solution to a shared server solution. So far everything has been working out great - the transfer of files went fine, and some of the automatic services that are setup for you, such as automatic secure webmail which is always nice to fall back on when you're at say, a public kiosk or something. The switch saves me approx. US$720 a year, which is going to be great for my finances. However, I'm always wary when I move to a new place that something is going to be horribly wrong, so it's watch-like-a-hawk time. One of the consequences of moving to the new server is using IMAP for reading mail. I am amazed, shocked and appalled that I didn't discover this earlier, but mutt has a caching mechanism, which increases the joy of reading both large Maildir mailboxes and IMAP mailboxes. To enable, just put set header_cache="/path/to/some/directory" in your .muttrc file - things go 10x faster after the first cache. In the same spirit of switching for a new year, I decided to switch my finances up a little bit. I'm currently migrating to using the StackBacks system for managing finances. This is the budget for the generation of consumers who would rather carry around a debit card than a bunch of cash, and is especially good for weaning yourself from credit cards. At the same time, I'm switching banks from a national chain to a local credit union.

I'm always amazed at the number of bad shell scripts I keep coming across. Take this snippet for example:

TEMP1= mktemp /tmp/tempenv.XXXXXX    exit 1
perl $CONF_DIR/project.pl $@ > $TEMP1
if [ $? != 0 ]; then
  return
fi
. $TEMP1
rm -f $TEMP1

There are several things wrong with this. First it uses a temporay file. Secondly it uses more processes than are required and thirdly it doesn't clean up after itself properly. If perl failed, the temp file would still be created, but not deleted. The last problem can be solved with some suitable uses of trap:

TEMP1= mktemp /tmp/tempenv.XXXXXX    exit 1
trap "rm -f $TEMP" INT TERM EXIT
perl $CONF_DIR/project.pl $@ > $TEMP1
if [ $? != 0 ]; then
  return
fi
. $TEMP1
rm -f $TEMP1
trap - INT TERM EXIT

Of course this can all be replaced with a single line:

eval $(perl $CONF_DIR/project.pl $@)

This weekend, Terah and I drove up to Nebraska to visit Cliff and Marilyn. We have never met them before, or even talked to them on the phone. We just know them from blogs -- Marty (Cliff's nephew) introduced us to them. We really had a blast -- quite a fun weekend, and we met lots of interesting Morrows. I supose there's always something unexpected that happens when you visit people you've never met. With this visit, it was singing in a Baptist choir. Terah said, "Well, we've never even been to a Baptist service in English, but sure, sounds like fun!" I think it took Cliff about 2 seconds to decide we should both sing in the choir once he realized we're in our church choir back in Kansas. I suppose that's risk you run when you go and visit a choir director. Off course it's all fun with Cliff. We really enjoyed it, and Cliff & Marilyn's daughter did a fantastic job on the piano. When we first arrived at Cliff & Marilyn's place, the first thing Terah noticed was that Marilyn had set out a giant Hershey's kiss and a Dr. Pepper for her! This was great. Terah's still talking about it, and is very impressed with a solid piece of chocolate that large. At dinner on Saturday, I think Cliff and Terah were having a bit of a competition to see who could have the driest sense of humor and the most sarcasm. Maybe it was just a little Kansas bias, but I think Terah gave him quite the run for his money, and even edged him out by a bit. Terah was also something of a celebrity around the Morrows, in one way anyway. It seems that, one way or another, almost everyone had heard about her carefully-planned underwear rotation scheme. And had gotten quite a good chuckle about it -- as well they should. Cliff asked us to bring some photos of our home and family with us. I think he might be regretting that now. I downloaded as many as I could fit onto a laptop -- about 3000 -- to give us plenty to look at. Of course, we didn't look at 3000 photos, but you just never know what might come up. Cliff and Marilyn did a wonderful job of not falling asleep anyway. We also got to see their photos, and they have some spectacular ones. Marilyn enjoys stereo photography and has some incredible stereo photos. I especially enjoyed the pictures of Germany. Marty's parents were also around this weekend and were full of interesting stories. His mom makes a wonderful cheese spread. I think I need to have a putty knife to spread it on nice and thick. It's the sort of cheese spread that's good enough to layer on about twice as thick as the cracker. The cracker is just sort of a cheese delivery device. I kept hearing that Marty had told the Morrows all about me. They all claimed that Marty said only good things about me. But we all know how the Morrows like to tell stories. So I made sure to get a few about Marty before we left, just in case. Don't worry, they're all good, Marty. After church Sunday, there was a carry-in meal. We knew about this in advance, and Terah brought some of her famous chocolate-cherry cookies along from Kansas. Cliff later admitted to stealing "no more than one" during the sermon. But he couldn't quite say it with a straight face. Terah's cookies were a hit, though -- it seemed that lots of people were trying to figure out who brought them. A few enterprising people pulled out the lid from the pan, but of course seeing Terah's name there didn't really help all that much. I think she promised recipes to about half a dozen people. We went geocaching Sunday afternoon. Cliff, Marilyn, and their grandson came along. We found the Summit Lake #1 cache with their grandson -- it was his first time geocaching, and I think he enjoyed it. Well, that was a long post. I'll probably remember more to write about later in the week, and stay tuned for photos!

About two months ago, I started thinking about a highlevel, implementation-independent networking API for Scheme. Riastradh’s TCP proposal is well thought-out, but I was thinking of something that would extend naturally to other protocols such as Unix domain sockets, or SSL/TLS. I took the TCP proposal, generalized and extended it a bit and. The result is online, I am appreciating comments! I currently don’t have the time to polish this up to SRFI-ready quality and submit it, but hopefully will do so next year. Implementation Status After harvesting some feedback from the #scheme community, I started to implement my proposal for Scheme 48 originally as patch against the development version, but since that is unfortunatly not publically available, I decided to split it off and make it work with vanilla Scheme 48 1.3. Currently, the implementation covers almost the whole TCP part, modulo some holes to fill out. For the curious and brave, there is a snapshot tarball of the code is linked from the CSW - be aware that this is in half-finished state.

We all know a long time that CVS sucks; the author of that article (in 2002) listed his main gripes with CVS: missing file renaming and not being able to remove directories. So far so I agree completly, these two things make CVS annoying to use, and everyone, even casual CVS users, will stumble upon these mis(sing) features. At that point, both subversion and what later became GNU Arch (to my knowledge, the first Free Software, distributed RCS) were in pre-1.0 versions, but becoming ready for use by the braver souls. While subversion has certainly fixed the renaming and directory problems, subversion has a fundamental shortcoming, making it an obstacle for FOSS to reach its full potential: it restrains the developer that may come along and want to experiment with the code. And no, it is not enough that the developer can checkout the latest code and submit a patch to the mailing list. This might work on projects where such patches are both trivial and quickly fed into the repository. But for more serious work, you will want to keep track of your work for yourself, either so you can review and alter the steps (changesets) done later on, or since you have to submit it piecemeal anyway. It could also happen that another, non-privileged developer wants to work on a thing that needs your modifications, before your patch has been approved and committed, or even before you are fully done with polishing it up fully for inclusion into the mainline. This other developer may also be just interested in your work and like to test it, and while doing so, he finds a little bug and wants to fix it. All this does happen in the real world, even on a large scale, e.g. with Linux distributions, and it’s called branching. The problem with non-distributed RCSs is: you need write access to the repository to create a branch. This is both true in CVS and subversion (although in CVS, branching makes little sense, as merging is a real PITA). To get write access, you have to go through whatever hurdles there may be in that particuliar project until you are deemed worthy of commit access. It is of course clear why it has to be that way: would the developers of that project grant everyone and their dog commit access, they would soon be busy with undoing the damage done by commits that don’t meet quality (or other) criteria, and not having any time left for hacking. This is not a problem with a distributed RCS, however - you simply have (typically) one person maintaining the “official” version of the source code, typically that’s the same person that rolls release tarballs. For example with Linux, it is Linus (for the development branch). That person can have their own repository, where everyone else only has read access, and selectively pulls changesets (patches) from repositories of peer developers. I hope I was able to made clear why using non-distributed RCS for a FOSS project can restrain the possibilities, limiting indivual freedom. So, if you believe in freedom (and software freedom in particuliar), consider giving a distributed RCS of your choice a try. I can heartily recommend darcs, (altough I’m not sure how it scales to bigger projects) but there are several alternatives out there. And in case you want to migrate an existing project, or give your users and developers a choice of RCS, you can use tailor to migrate your old repository, or even establish a two-way gateway between two RCS.

Note: Yeah, I'm abusing the latest Debian flamewar meme for some attention mongering. Sue me. A few days ago, I have tested my cheap, crappy webcam I bought more than a year ago for the first time. Using the latest SN9C10x driver (which is already included in recent 2.6.1x kernels) worked fine, i.e., the USB webcam was recognized. I tried running sonic-snap (site is currently down, try the Google Cache) in order to get snapshot images and/or videos off the webcam, which initially didn't work. But I soon found out what the cause of the problem was and created a trivial patch which fixed the problem for me. Then, after I made myself look like an idiot by reporting a bug against a non-existing sonic-snap Debian package, I finally sent the patch to the upstream author. I'll probably ITP the package, though, as I might be using the webcam more often... I also tested the webcam with Gnomemeeting for some videoconferencing fun, which didn't work at first either. After some stupid guessing and googling, I finally found out that you need to apt-get install libpt-plugins-v4l2, which is not installed by default (why?). Other than that (and apart from the really, really crappy image quality of the webcam), it worked really nice... Here's the exact lsusb output for Google to parse, other people might be searching for this info:

Bus 003 Device 003: ID 0c45:602a Microdia Meade ETX-105EC Camera


Fred Wilson: “I will not buy music that I cannot remove the DRM from.” I agree wholeheartedly, though the strategy I use is the one Fred dismisses in the first paragraph, namely burning the music to CD and ripping it back, sans DRM, to MP3 format. Yes, it’s a pain, but it beats having to jump through all the digital hoops at some indeterminate point in the future when all I want to do is queue up a song I’ve legitimately purchased and have probably forgotten where I bought the thing, let alone what magic pixie dust I need to decode it. Sure, the MP3 format has issues too, but at least I know my music will play anywhere. (Since I’m on the subject, I’m looking for some sort of a virtual CD burner, which the operating system thinks is a CD burner but which is actually a piece of software that converts the tracks it “burns” to MP3 format. Anyone know if such a beast exists? That would certainly do wonders to curtail my contribution to the world’s coaster supply.) In practice, DRM isn’t as much as a problem for me as it seems to be for other people. Personally speaking, I don’t want to be in the music storage business—I’d much rather stream music on demand from some digital jukebox in the sky, which is why I’ve been a Rhapsody customer since 2003. (Greg Papadopoulos sums up my thinking pretty well exactly here: “I’ll bet that we will look back of this era of quasi-networking and wince, ‘How did we ever live that way?’ And the idea of wanting to carry all of your content with you will seem both old-fashioned and rather ridiculous.”) In my case, DRM is normally a non-issue—I simply route around it. Rhapsody has come a long way since I first started using it in 2003: They added a Rhapsody To Go service, which more or less solves the “disconnected operation” problem (though I still tangle with DRM issues from time to time if I go for too many days untethered), and they finally embraced the web, though the current web offering leaves much to be desired—the Linux plugin still doesn’t support Firefox 1.5 nearly two months after its release, the web interface has huge gaps compared to the jukebox software (you can’t access your music library on the web, among other things?!), and they don’t seem to be taking advantage of the new web platform at all (where, oh where, are the RSS feeds of my favorites, recommendations, etc, so I can mash them up with other stuff?). At the end of the day, I suspect the “economic boycott” James Governor calls for is the right way to fix the DRM problem. For my part, I’m voting with my wallet by supporting the model I want to win out in the end (that your music library will live on the web, not on your PC or in your pocket) and by buying music, in those rare cases when I do want to manage my own music library rather than letting someone else do it for me, from legitimate music services but opting out of the silos the platform providers are trying to build around me as a byproduct. Above all, I resist the temptation to climb into the big, beautiful lockbox Apple is building for us. As Clayton Christensen recently told BusinessWeek, I’m firmly convinced open standards will win out in the end:

Look at any industry — not just computers and MP3 players. You also see it in aircrafts and software, and medical devices, and over and over. During the early stages of an industry, when the functionality and reliability of a product isn’t yet adequate to meet customer’s needs, a proprietary solution is almost always the right solution — because it allows you to knit all the pieces together in an optimized way. But once the technology matures and becomes good enough, industry standards emerge. That leads to the standardization of interfaces, which lets companies specialize on pieces of the overall system, and the product becomes modular. At that point, the competitive advantage of the early leader dissipates, and the ability to make money migrates to whoever controls the performance-defining subsystem.

I don’t know about the rest of you, but that day can’t arrive soon enough for me.

Don t you love it when it looks simple and then it is actually simple, but you are not up to the task?

I am loving the xlibs-dev transition, really, I mean it! Two of my packages, fkiss and xdigger got bit by this issue, and I immediately fixed the bugs with a little help from a script provided by Moritz Muehlenhoff. really cool.

So I follow instructions in The Debian Wiki, run the script, check with pbuilder, upload and profit! Fun! End of world hunger! Err, almost. So I get all excited and decide to look at the bugs. And I find a nice one: #346347. Not bad, gpsim FTBFS, Luk also took a look at it and didn t really like what he saw, it neede no xlibs-dev or substitute for them and sitll FTBFS.

But wait! Just by looking at gpsim s bugs page, I find out that there s a New Upstream Version(tm) (#248931) available since 1 year and 241 day ago. Also, NMUs that have not been acknowledged for as long as almost two years... Not nice. And there s even a patch (#345215) for building it on, GNU/kFreeBSD... how sexy!

So I get all obsessive about it. But newer upstream needs a newer libgtkextra-dev version (#347397), which of course was not packaged (don't we all love Murphy?) and that s where I am stuck at. I loathe libraries. But still I gave it a try. And failed. Several times.

Fun? Yes! Profit? Nope! Do you want to take a look at it? Easy. It s all here.

Amaya also FTBFS. And I want to NMU amaya. Badly. Since I first heard about amaya, and realized that I am named after a web browser (sucky as it might be) and after getting many IRC highlights (every time that amaya FTBFS is mentioned on IRC), I have been wanting to use/adopt/NMU it. Amaya NMUs amaya, how recursive can it get?

I will go to bed now, and try not to keep thinking about it, not because I want to become an early riser, Gunnar, no need to worry! But reading about it I thought it would be healthier for me to wake up everyday at the same hour, so that s all I am aiming for. If you know me, you might be rolling on the floor laughing as you read this. So am I! But, if you know me, keep in mind that I have been drinking coffee with no sugar since August... Hey! You are not laughing anymore?

Vi and Emacs are doing fine. Emacs was not pregnant after all, or so the vet told me. It was hard to see her slowly become herself after surgery. Vi was perfectly OK all along, but she looked terrible. Anyway, she felt better by 6am the next day and came to bed, perfectly groomed, and purring like nothing had happened. A week has passed and she has started doing the gory part today... she s biting away the scar tissue, and it bleeds a bit. Oh my Spaghetti Monster!

I just came back from the vet. I left Vi and Emacs there and will pick them up after work, as today they will be spayed and neutered (450 EUR total). I am all shaky inside.
My little cats! (Well, not so little, as Emacs started acting like if she was in heat only a few hours before I had to take a plane for my Holidays, so I guess she is not so little anymore, nor is Vi, who seemed completely fascinated by her new behavior. Anyway, my vet knew this would happen one month in advance, when we were arranging an appointment for the surgery that will be performed today).

Good luck, my babies!

Today I was running out the door chasing the dog. The dog saw a person walking on the street and ran up to see her. I managed to get a hold on the dog and bring her home, but on the way back, theres this mini slope. Of course I'm bringing dog back inside and didn't think of this and get my sneakers covered in mud as there is a big ditch at the bottom. :(

So here's my instructions on washing shoes:

- First toss them in the washing machine on a low water level setting. Add in a bit of laundry detergent to help get the stink and mud out.
- Next take them out and stuff them with newspaper. Don't let the chunks of newspaper be too thick or it will not absorb as well. Leave newspaper in both shoes for 30-45 minutes.
- Now its time to let them air dry. The best approach is to put a fan in front of them. The more power the faster they dry. Right where I live right now, its the middle of a heat wave. So I realized the big air conditioning fan and motor outside is going around 24/7 and with huge amounts of hot air. If you take the latter approach, the shoes are usually dry with 1.5-2 hours, especially since it runs at least 10000 rpm. Otherwise the in house approach may take 4-6 hours. Also note that the air blown out from under your refrigerator is also good.

So in under 3 hours you can have your shoes squeaky clean with a nice smell, and be dry.

Tommi Kyyr , IFPI finland:

Now, we need to understand that listening to music on your computer is an extra privilege. Normally people listen to music on their car or through their home stereos , says Kyyr and continues; If you are a Linux or Mac user, you should consider purchasing a regular CD player.

This madness began in 2001, when EU passed EUCD, the European version of DMCA. Next year, Ministry of culture introduced the first proposal for the Finnish implementation of EUCD. After fierce criticism from EFFI and various citizens, the committee studying the proposal rejected it before parliaments vote, demanding that the ministry must consult everyone effected by the change in law. When creating this proposal, practically only Music Industry pressure groups where heard.

Fast forward September 2005, and Ministry of culture and Music Industry pressure groups are pushing the second proposal a lot harder. All the parts from we hate are still there - No interoperability, chilling effects on security research and freedom of speech, and so on. Minister Karpela Claims that she is surprised by the criticism, and complained that people should have criticized properly during the law preparation phase (Not telling that EFFI _WAS_ heard during preparation, and their opinion was ignored).

The Media was alsoquick to to find out, that Jukka Liedes, the bureaucrat who actually wrote the Law Proposal, has a also a position ESEK, a Finnish Music Industry Pressure group. Such corruption is almost unheard in Finland.

On friday, the "Grand Committee" passed the law forward without modifications, for the parliament to vote on later. A requirement was appended that "Ministry of culture must ensure, that all users are able to view/listen to copyprotected content". Several The chairman of Grand Committee, already declared the appended part "Naive". Which it very much is. Entertainment industry is not going to relax copyprotection for say, Linux users in Finland...

The worst part? According to the current proposal,

Downloading music from internet without copyright holders permission is not a punishable offence, but breaking copyprotection of a CD you have bought, is.

After talking with some LinuxTag guys about which kind of talks are still missing for the upcoming LinuxTag, I submitted another proposal for a still only roughly sketched talk: KISS – Keep it simple and stupid, also on the web.

KISS – “Keep it simple and stupid” is an old and successful principle in the Unix world: Small and simple programs, doing only one thing, but they’re doing perfect, fast and reliable. This principle can also work on the web and make webservers or surf terminals out of already discharged computers.

I planned to show “simple” (or at least “simple to use”) tools like Blosxom or the Website Meta Language, a more slim webserver than Apache (e.g. fefe’s fnord or one of the ACME webservers thttpd, mini_httpd or micro_httpd), slim web-browsers (e.g. like Dillo, Opera, glinks, ViewML or Minimo) and one or more Linux distributions optimized for low end PCs. While thinking about low end PCs, usually the following distributions come to my mind: DeLi Linux, fli4l and Debian Woody. But none of them seems to fit for my talk as perfectly as I would like:

• DeLi Linux is no bad distribution, since it’s designed especially for 386 to Pentium I, but I have some strong disagreements with the maintainer of DeLi Linux, since he sees a very small package list as necessary requirement for a distribution for old PCs. He states that distributions for old PCs “don’t have that many harddisk space” (beyond other, more realistic arguments — but it seemed to be his main argument) while I see a rich package diversity as an quality criteria. (One of the reasons, why I like Debian and dislike Ubuntu.) So I’m not sure if I should present a very raped DeLi Linux to the audience, just to make it fit my needs, although I’m quite curious about his upcoming 0.7 release with the low end, KHTML based ViewML webbrowser. (Apart from me seeing PHP5 and KDE as a big nono on old PCs…)
• Although I still like Debian Woody very much (you know that old story… ;-), it is just too old for making a talk about how to turn old PCs into being usable again. Sarge would be fine, but it was suggested to showcase an easy and fast way to get something ready to run, and I can’t give the auditors a list of all the Debian packages with low resource consumption and therefore usable on low end PCs.
• I haven’t used it yet, but fli4l seems to be very good distribution to turn an old PC into a ISDN or DSL router, even without harddisk. The last time I had a look at fli4l, it used an Apache as (optional) webserver, which wouldn’t fit into my scheme, since I would like to show an alternative to Apache. But as I found out today the recently released version 3.0 of fli4l uses the already mentioned ACME mini_httpd. Cool! They’re on the right way! ;-) Unfortunately it only seems to be used for serving information pages about the fli4l status and not as common webserver. (Please correct me, if this is wrong! I would appreciate it, if I’m wrong at this point. :-)

Since I first read about viewml on the DeLi Linux page, I looked for Debian packages of viewml today. apt-cache search hasn’t found anything on Woody or Sarge and packages.debian.org is still down, so I used Google. I found out, that there at least was a viewml package in Debian since at least 2001, so I expect, it just didn’t make it to stable. But I also found this interesting page on a webserver called www.ubuntulite.org. Ubuntu Lite? That sounds very interesting, since I see Ubuntu not as the baddest idea (expect for it’s horribly resource hunger and only offering one package per application by default ;-), but having an Ubuntu derivative prepackaged for low end PCs and with several webbrowsers instead of only Epiphany (and probably Firefox, don’t they?) would be perfect for my purpose. So I’m currently downloading an Ubuntu Lite ISO and will give it a try on one of my Pentium MMX boxes. Unfortunately it doesn’t seem to support Pentium I or AMD K5 since Ubuntu itself only supports i686 and upwards. :-/ But this also means, that it’s no occasion for my Pentium I Compaq LTE 5100 (which I probably will name pony), but currently, after Bartosz’ recent post on Planet Debian, it looks like Debian GNU/kFreeBSD could also be an interesting OS, since it fits all requirements perfectly: Free, Modern, Exotic and all conveniences of Debian. ;-)

Now Playing: Jefferson Starship — We Built This City