When I returned home to my apartment today, I noticed the front door was open. I heard voices upstairs, so I didn’t close it. Later on, I heard the sounds of walkie talkies in the hall, so I poked my head out of the door to see what was going on. Apparently, someone in my apartment had been robbed; cops were in the hall, talking to the lady that lives on the second floor. However, while the thieves were carrying a TV outside and loading it into a car, apparently some cops happened to notice. There was some form of a chase, and one person was caught while the other got away. I checked the outside of the apartment building, but didn’t see any “Break into me! I have lots of valuables!” signs posted anywhere. Oh well, maybe there’s something else that makes this place a huge target for thieves. Or perhaps it’s just the neighborhood.

It’s official: I’ve joined the Free Standards Group as Chief Technology Officer and chair of the FSG’s Linux Standard Base (LSB) workgroup. (The FSG made some great additions to its board too.) This promises to be a breakout year for the LSB and for free standards in general, and I’m excited to be a part of it. Some of the things on tap for the coming year are:

• The LSB 3.1 release (which adds Desktop functionality to the ISO standard LSB Core, among other things)
• A crisp, well defined roadmap for LSB 4.0 and beyond, with increased emphasis on synchronicity with the major distros and stability, predictability and consistency of the LSB ABIs/APIs over time
• A renewed emphasis on increasing direct involvement of distros, ISVs, and upstreams in the LSB development process
• A developer outreach program that will make it easier than ever for software developers to target the Linux platform in a portable way (hint: ever wish there was a Linux Developer Network?)
• A franchised certification program that will allow third parties to integrate LSB certification into their own value-added certification offerings (our recent announcement that we’ve teamed up on a certification center in China is a hint of things to come here)

As with most major life changes, this one’s bittersweet in some ways, as in the process of embracing this exciting project, I’ve had to step away from another, namely Progeny, the company I co-founded way back in 1999 (!). It’s always hard to move on from something that’s been a big part of your life for such a long time, and it’s particularly hard when you don’t feel like you’re “done” yet. On the positive side, I leave Progeny in excellent hands, and I’m able to remain involved in that wonderful position called “advisor”. Speaking of Progeny, I’m exceedingly proud of all we accomplished over the years. Not only did we survive the .com bust, but we successfully reinvented ourselves in the midst of it all. Furthermore, we not only survived, we pioneered: we were among the first (if not the first) to build a business model around the customization and integration of open source code, a model that’s been adopted by some of the hottest open source startups of the past few years. I’m also immensely proud of the DCC Alliance—indeed, my new role with the FSG is, in a lot of ways, a natural progression from that latest waypoint in a string of projects that date back to 1993. That’s it for now. Watch this space for additional news about the LSB as it continues to unfold. Better yet, get involved and help make it all happen!

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’m in Korea. Lots to do:

• Figure out how to get Korean “Hangul” characters to show up in X
• Figure out how to change my date/time to Korean
• Get my locale setup for Korea
• Figure out how to input Hangul characters

I have Internet at home at long last. (I couldn’t get Internet in Australia without signing up for an annual contract!) 200kb/sec to Dreamhost. I also seem to have my own IP without a firewall. I’ll have to cook something up with iptables quickly. I am looking forward to going to Seoul’s “Electronic Market” and getting some bits and pieces. One of those new Seagate hard drives for my laptop I’m hoping. Perhaps an MP3 player too. Btw, upgraded to Wordpress 2.0. Notice any problems? Let me know…

Long time no blog I guess. Things haven't been that exciting on the Debian front for me. Many of you may have noticed the Xorg -8 packages just hit unstable, complete with minor annoying debconf bug (fixed in svn now). That work was almost all packaging bugs, most of which are now taken care of. All those changes apply to the 6.9 packages too, so it's like I'm getting a two for one. This means that the 6.9 packages will be pretty well cleaned up on the Debian side of things when they actually ship. Thanks to Sven Luther, Julien Cristau, and Ari Pollak we can build 6.9 for powerpc, sparc, and amd64 (although there's currently an unrelated bug on amd64 stopping us from building any X packages there). Hopefully we can get the remainder of the arches ready to go so that we can drop 6.9 in to unstable as soon after it's released as possible.

One of the very cool changes that's come about lately is that David Mart nez Moreno has taken up the torch for xterm and produced a package for experimental. xterm never really lived at X.Org, and now we're getting it from the real upstream source. So thanks to David we'll have an up to date xterm ready to go with 6.9. It's sort of a little taste of the modular tree: if you need to get an xterm update for some reason, then you don't have to update all of X in the process.

Terrifyingly, I've reached a point where I can start working on the modular packages the moment I sit down to do Debian work next time. I'm going to repeat what I did with 6.8 and start with the Ubuntu packages and work from there. Now that I know a little more about how the whole thing is laid out I feel a lot more confident in what I'm doing. Last time it was really by the seat of my pants. The scariest thing for me is that I finally have to break down and learn the autotools, which is something I've managed to avoid until now. That should be the biggest hurdle for me in moving the modular packages forward. I have no idea how long it'll take, although history has shown that my time estimates are about 1/3 of the time that it actually takes to do a thing :-) The first third of what I set out to do (get Xorg in to Debian) is finished. The second third will be when 6.9 is in testing. The final third is when the modular packages that I'm happy with land in testing. It may take the entire etch release cycle to run this marathon, but I feel like I've reached the halfway point around now, with 6.9 stabilizing.

I've started talking with people about where to go after all that. Once the Debian packaging work is done, I want to start working on the Xorg codebase itself, preferrably on making the xserver a little nicer on the user. I have a project or two in mind, but I don't want to start on them until Debian's X packages are well in hand for the forseeable future.

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.

Last time I blogged about the libglu situation, which I explained was necessary because of the C++ ABI transition in changing over from gcc3 to gcc4. libglu is the one library written in C++ in all of the X.Org source tree, so it was the only one that had to be broken.

It turns out we were wrong about that. libglu is indeed written in C++, but Marcelo Magallon pointed out that it only exports a C ABI, and as such it doesn't need to be transitioned. I have admittedly little experience with shlibs myself, so I didn't know such a thing was even possible, and no one else caught it either. The next version of X.Org, which will be uploaded as soon as I can get it built, will have this fixed, and nvidia-glx, and everything that depended on xlibmesa3-glu will hopefully install just fine once that goes in. Sorry about that everyone.

In addition, this upload should have correct MANIFEST files for all arches, which will hopefully allow it to build successfully on all of them. This will allow X.Org to transition in to etch after a week and a half. This will also unstick gnome 2.10's transition in to etch, which is now tied up with X.Org. Daniel Stone helped pull those MANIFEST updates together, which has been a huge help, so you should send him your hugs 'n kisses. There is an issue with libvgahw which a lot of people have reported, which causes problems when you switch to a virtual text console and then back in to X, which should be fixed in this upload as well (you can thank David Mart nez Moreno for tracking that one down before I could even blink). Finally, xterm bold fonts have been looking like garbage, but Eugene Konev came up with a patch to fix that, which I'm working on rolling in right now.

So if all goes according to plan (that's your cue to laugh mercilessly at me) the next upload will move in to testing just fine, leaving us with room to make larger improvements in the X.Org packaging, as well as working towards getting the (currently unreleased) next version of X.Org in to Debian.

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.

Many have tried to solve spam problem, even Micrsoft (with a quite strange solution ;-), but except personal solutions like well working and well-kept spam filters, no well-working general technical solution has been found yet. Although I really would like to see a technical solution and often think about this problem, I currently believe that this primarily is a social problem which cannot be solved solely with technic. UserFriendly’s Erwin seems to see it the same way and proposed today a quite drastical solution. There are good ideas out there (e.g. SPF, RBL, Greylisting and Teergrubing), but all seem to have their problems, too. Especially RBL often have administrative problems, i.e. if an entry is justified or not. Greylisting simply can be bypassed by being SMTP conform and trying again, so it’s usefulness will decrease permanently. And against Lutz Donnerhacke’s teergrubing, spammers seem to have found workarounds quite quickly. Haven’t heard much about it in the last years. (I just can’t remember what the drawback of SPF was.) For myself I’ve solved the spam problem with a learning SpamAssassin and sorting mail by spam-level into several mailboxes. The higher the spam-level of such an inbox, the more seldom I look into it. Works fine. For me. No general solution though, since the SpamAssassin needs to be fed with fresh spam regularly.

Beagle 0.2.1 is out. Beagle is a very useful desktop search engine for GNOME (but you can use it with KDE, too, or even without any desktop environment like I do). Despite the low version number it is already quite stable and usable, and has lots of features. It can index all kinds of files and information on your computer (txt, pdf, doc, emails, IM logs, IRC logs, source code, images, music, and whatnot) and provides a very nice (new) search interface (see screenshot). Yes, Google Desktop Search and Spotlight do the same thing, but neither is available for Linux, and neither of them is Free Software. They can "phone home" without telling you and do other funny things. With Beagle you can easily check what it does (use the source, Luke!). Oh, and Beagle can now also parse Ruby files, a simple filter I had written and submitted has been included in the latest release (well, actually it was there in 0.2.0 already, but I didn't tell anybody ;-)).

I finally got out to Barnes and Noble today to spend the last of my Christmas/birthday gift certificates. Bought the last two books in Robin Hobb’s Farseer Trilogy as I have the first book but haven’t read it yet, as well as the third book in Robert Jordan’s Wheel of Time series. Incidentally, I was told by a friend that it’s only worth reading the first three books of the Wheel of Time, as it goes on forever and ever with little development. Please correct me if I’m wrong. I was tempted to buy The Atlas of Middle-earth but was swayed by my OCD at having unfinishes series (what on earth is the plural of that word? serieses? I want to say it doesn’t change, but that sounds funny) in my bookshelf. I’m still not sure when I’m actually going to read all these books, but, uh, I’ll figure that out eventually.

A while back I started porting the GTK examples from Mono: A Developer's Notebook to IronPython and Boo, the results of which are available in my Subversion repository. Although I've not finished that task yet, I thought I'd investigate the state of the Ruby GNOME bindings by porting those same examples. They have the advantage of increasing gently in complexity. Before I go on, you can find the work in progress posted in the ruby-gnome/monodn branch of my Subversion repository. Now for a few observations. At the basic level, Ruby GNOME has a lot in common with all the other GNOME bindings out there. One distinguishing feature however is signal handlers, which take a Ruby closure as an argument. Look at this handler for closing the window, for example:

w = Gtk::Window.new("My Window")
w.signal_connect("delete_event")   Gtk.main_quit   

This is fine for simple handlers. Developers wanting to reuse handlers might wish to specify a method here to use. The best way of doing this I've found is:

def my_handler(but)
     ...
end
 
button.signal_connect("changed", &method(:my_handler))

This involves a little bit more magic, as you can see. I've also run into an unexpected barrier with subclassing and the class default signal handler. The subclassing example from the Mono Notebook shows an example of overriding the clicked method of a Button. In C# this looks like this:

class MyButton : Button  
 ...
 protected override void OnClicked ()
  
    hitcount++;
    base.OnClicked ();
  

In Ruby I would write this:

class MyButton < Gtk::Button
 ...
 def clicked
   self.hitcount += 1
   super
 end

However, when you click the button it's clear the overridden method isn't being called. I've filed a bug with what I think is the underlying problem. In this instance, I worked round it by adding a signal handler in the constructor:

self.signal_connect("clicked")    b  b.hitcount += 1  

At the moment it feels like I'm writing rather C-like Ruby, rather than it being idiomatic. But then again, I am porting examples from C# in as literal manner as possible, in order to facilitate comparison.

My laptop is now gone for repair of the backlight. While I have my HD at home (and an external casing for it), I don't have my usual work environment... So I will probably not do any Debian work until I have my laptop back; if you want to NMU (or adopt minit, where I did the orphan upload just yesterday), just send me an email. I should still be reading my email frequently. I hope with the repaired backlight the laptop will continue running until I've decided on a model to buy instead. Current favourites: IBM Thinkpad T43p (which supposedly is almost the same as my current laptop, and especially also has hopefully the same 1600x1200 15" display...), Samsung X20 or X50, maybe an Apple, or (which is really pretty, but seems overpriced) Samsung Q30plus. Ranked in order of importance to me: Display quality (shouldn't reflect too much, should be very fine) then weight. Everything else is rather uninteresting...

This is a blog entry I wanted to write for about six weeks now, but I was busy with other stuff. In December 2005 I got curious why 2.4.32 wasn't packaged for Debian and investigated the situation a bit.

There are several reasons why 2.4 is still interesting:

- Kernel 2.6 is still a moving target...

- Some hardware is only supported with 2.4, for example older laptops which need APM and don't work with ACPI. Also some non-i386 machines.

- According to popcon, 6-7% of the i386 users have a kernel-2.4 image installed.

Unfortunatly, nobody from the kernel team is really interested in working on 2.4 anymore. They do security fixes for the 2.4 kernels in woody and sarge, for which I'm very thankful, but that's about it.

Even though 2.4 is moving very slowly nowadays (mostly security updates, very seldom new drivers are including), this is more work than needed, because every fix needs to be backported to 2.4.27 (and 2.4.18 for woody).

Of course there are some issues which need to be taken into consideration when thinking about whether it's worthwhile to have 2.4.3x in Etch:

- it needs gcc-3.3 to compile, gcc-4.0 won't work. Period. So gcc-3.4 also needs to supported during etch's lifetime - which will be something like 2009 when etch+1 will become oldstable (by current release cycles)...

- it's not sensible to have powerpc and amd64 flavors, and probably others. So this kernel package will not be arch any. (Which is not really a problem, but unusual.)

- Both kernel 2.4 and 2.6 contain non-free firmware and drivers. I seriously doubt people want to deal with this issue and solve it for 2.4. For 2.6 it will be done, but for 2.4 ? As I see it, this is the biggest showstopper for 2.4 in etch, I would be happy to be proven wrong. As a starting point, you can look at this investigation by Bill Allombert about the the situation in 2.4.25.

Removing those files would be an option, but maybe we can also "borrow a better solution" from 2.6...?!

- if 2.4.32 or .33 shall be used in d-i/g-i, work on this integration needs to be started real soon now.

I have done some work on creating a linux-2.4.32 package which is based on the new kernel packaging. I got busy with videos for debconf-es2, so I didn't finish and commit this.

Horms made a presentation about the kernel packaging in debian for LCA and gave two options: a.) support and backport fixes for 2.4.27 or b.) go with 2.4.32. Somehow he did not consider the option of dropping 2.4 even if he calls it legacy ;-)

Besides technical reasons (security fixes handled by upstream, some driver updates and very few new ones) I think we should not forget that most people have no idea that 2.4.27 in debian is far closer to 2.4.32 than to .27, and therefore will think debian ships an outdated 2.4 kernel. So I think we should simply go for 2.4.3x, if it is sensible to support 2.4 in etch at all.

It "just" needs to be done, and I volunteer to do it (with the help of the kernel team, the porters and anybody else who wants to join), if this work will not be in vain.

Please send comments to the debian-kernel-mailinglist, where I posted this blog entry before. Thanks.

I just prepared and uploaded ipython 0.7.0-1 for Debian, and stumbled across some undocumented changes in the Ubuntu package... tretkowski@kyllikki:~% interdiff -z ipython_0.6.15-1.diff.gz ipython_0.6.15-1ubuntu2.diff.gz wc -l
501 They disabled the python2.2-ipython package, which is documented in the changelog. But there were two more patches added, which aren't mentioned in the changelog, there's just a mysterious "Resynchronise with Debian" entry. One of these two patches was integrated upstream a while back already.

You are Iron Man

Iron Man 60% Green Lantern 55% The Flash 55% Spider-Man 55% Catwoman 55% Hulk 50% Supergirl 45% Batman 45% Robin 42% Superman 30% Wonder Woman 25%

Inventor. Businessman. Genius.

Click here to take the "Which Superhero are you?" quiz...

I just prepared and uploaded ipython 0.7.0-1 for Debian, and stumbled across some undocumented changes in the Ubuntu package... tretkowski@kyllikki:~% interdiff -z ipython_0.6.15-1.diff.gz ipython_0.6.15-1ubuntu2.diff.gz wc -l
501 They disabled the python2.2-ipython package, which is documented in the changelog. But there were two more patches added, which aren't mentioned in the changelog, there's just a mysterious "Resynchronise with Debian" entry. One of these two patches was integrated upstream a while back already.