While it's obvious that being a kernel developer is absolutely the best thing anyone in life could ever aspire to, I'm finding it increasingly difficult to justify not having just given up and gone off to be an analyst instead. Two stories stuck with me this week. The first claims that we can expect Android netbooks to be on sale within a year or so. The reasoning behind this? Android runs on x86 and has a MID profile. Oh, yeah, and it sounds like a cool idea. Sure, we need to ignore straightforward facts like, oh, I don't know, it being UNSPEAKABLY PAINFUL TO DO OS DEVELOPMENT ON ARM, and hence it being NO SURPRISE WHATSOEVER TO FIND THAT BUILDS AND RUNS ON COMPUTERS THAT ACTUALLY GO FAST AND SIT ON PEOPLE'S DESKS. Or that MID refers to the class of devices like Nokia's internet tablets or, well, any of these and not a netbook. And, leaving those, the evidence we have for this is that "It sounds like a cool idea".

It's easy to write an article on why something sounds like a good idea, and even easier to make it sound like a good business plan if you're not the one who's going to lose money on it. But yeah, maybe Google's going to push for Android on netbooks. It's going to be a kind of crowded place to be, what with Microsoft and Intel and Canonical and Xandros and half a dozen Chinese Linux distributions that you've never heard of and really hope never to again once you've seen their distributions, but it's possible. And so these guys might even be right. But the sum total of their insight here is that (a) Google have a product, and (b) Google might want to enlarge the market for that product. The rest is a collection of extraneous facts designed to make you think that they've actually done something more impressive than typing make, and frankly if that's enough to get you noticed then gentoo users the world over are missing out badly.

It's ok, though. There's worse. Google are making a secret OS, which by my count means that there's been eleventy billion people inside Google working on a fucking OS for the past TWENTY YEARS and this time we can tell not because people have, y'know, gone to Google and seen it, but because they're busy leaking information about their secret OS by removing the user agent string from a bunch of their web traffic.

Of course, as Clint points out in his article, Google's a web company and so would want to produce a web OS. The obvious way to develop this web OS would be to, uh, run it on top of Android, an OS currently entirely unsuited to desktop use due to little things like the lack of decently accelerated framebuffer drivers on any hardware you can currently obtain (rather than, say, any of the operating systems already deployed in Google, all of which share one striking feature - the ability to RUN A WEB BROWSER AT A DECENT SPEED). And even though basically everyone in Google seems to have an Android device, it'd be vital to prevent anyone from knowing that they used Android to browse the web, so scratch the user agent.

But that makes no sense. So what Clint's clearly getting at is that people using the Google web OS are browsing the web using the Google web OS, and so remove the user agent string to avoid leaking that information. That makes sense, up until you actually think about it. A web OS would run in a web browser. Why would you run a web browser in a web browser?



Google's not an OS company. They don't employ enough people to develop a full OS and releasing a Linux derivative themselves would just be a way of tarnishing their brand in a hideous manner. Any move into the home would have to be in the form of appliances with known hardware configurations, and seriously, what's the point? It's not a big enough market. If Google's going to push applications, it's going to do it through the browser. And if it's doing it through the browser, then right now it doesn't matter what the underlying OS is. There could be any number of reasons for the mystery of the missing user agent strings, but if it's because Google are trying to prevent people from working out that they're developing an entire software stack that they're going to push out onto arbitrary hardware then I have an Android netbook to sell you.

That'll be $50,000, please.

Lintian 2.1.4 has just been uploaded to unstable. I'm trying to stick to a weekly schedule for releases while the pace of development justifies it, so this upload is a week after the previous upload. (We're targetting only unstable at this point and don't plan on having any of these versions release with lenny. Lintian is the sort of package for which the freeze isn't as relevant as it is for typical end-user packages.) It fixes 13 bugs and, most importantly, cleans up all the bugs that were tagged patch in the BTS. There are lots of minor changes, including a lot of new tags for random problems. The one that will catch the most people is that dh_clean -k is now deprecated in favor of dh_prep (thanks, Adam D. Barratt!). I got to spend a lot of time this week working with the new Lintian test suite and link it a great deal. I've converted some of the more targetted old test cases to the new framework and sent out a long message to the team list on things that I'd like to add to it. The complete test suite now takes a lot longer to run, since it's broken down into more separate test cases and each one is a package build, but we're making up for that by making it easier to run all test cases that apply to a specific tag. There aren't many structural changes in this release, just a lot of bug cleanup and random fixes. I think at least one more bug-fix release is needed to get the pending bugs back to where I like to have them (under 100 total), and then I have a large backlog of structural improvements that I'd like to work on. It's unclear, of course, how much time I'll have to work on that. I could happily make a full time job out of working on Lintian (well, for a few months, at least). I wish I could spend this much time working on it during the rest of the year, but I can still enjoy getting to dig into it during occasional vacations, and hopefully I'll be able to do a few things during work weeks. Many of the patches that went into this release were based on work by Raphael Geissert. Thanks to him for all of his work on Lintian.

Today, Terah and I set out for some geocaching. Jacob s daycare was back in session (he goes twice a week), but we both had the day off. Jacob enjoys geocaching, but he does make it a lot slower. So we dropped him off at day care today, and headed off. We were also scouting out good places for future tent camping along the way. We didn t know exactly where we d manage to go, so I had downloaded over 100 geocaches to my new GPS, prepared for many options! Not long after we found our second cache (in Canton, KS), Terah asked, Did you hear that hissing from the tire? No . We were about 5 miles from town. I happened to have an air tank with me (because of a different tire with a slow leak). I shot some air in it, and we made it to Canton Service just fine. They fixed both tires, and my uncle who was there getting tire work done himself was quite surprised to see us pull in bright and early at about 9:00! After our tire was fixed, we headed northeast. We found some more caches, and drove around the two lakes near Herington, KS. We saw hundreds of geese perched on the icy lake and hiked a bit in the area to find a cache. Then it was on to Council Grove for lunch. I do believe this is the first time we have ever walked into a place that looks like a restaurant and only after we are seated realize that we re in a museum. Council Grove has an amazing historic downtown the most history per capita of any town in the west! the travel information AM station proudly proclaims, with 25 historic sites and a population of 2500. Got a chuckle at that one. We drove by the oldest continuously operating restaurant west of the Mississippi (it was closed), so we turned around and stopped at the Trail Days Bakery and Cafe that we had passed a few blocks back. We walked in the side door, into what looked like a meticulously-restored old house. We were seated at a table, given menus, and the waiter explained, By the way, you re eating in a cafe that s also a museum. Please feel free to look around, and don t miss the basement and upstairs, too! So it turned out that the Trail Days Bakery and Cafe is in the historic Terwilliger House. The house was about to be razed, when Shirley and Ken McClintock heard about it and tried to get some people interested in saving it. When nobody else stepped up, they did they formed a non-profit, and with a lot of hard work from themselves and others, managed to restore it from its state as a run-down gas station to its former beauty. They operate the cafe as a way to raise funds for the preservation of the house and the other historic buildings they have moved to the site to restore. Oh, and Shirley and Ken were our cooks and waiters today! We showed up there at about 1PM, right at the tail end of the lunch rush. Another couple happened to be there at about the same time. They were traveling across Kansas from west to east, specifically avoiding the interstates so they could see the small towns along the way. We got to talking about geocaching and their home town near Colorado. Then we got to talking to Shirley about the music CDs that they had for sale and the history of the place, and the Ken told us all about the Native American pictograph that they had discovered carved into the wood in the house. By the time we left, we had probably been there almost two hours. Oh, by the way, Terah had ham and beans ( just like mom used to make , she said), and I had what can be best described as a sloppy joe made out of bison meat. Both were good, but eating in this beautiful old house was even nicer. Then we drove down the road a bit to the old apothecary. Yes, it s still a drugstore in every sense of the word: you can get your prescriptions filled there, and they also still have the original soda fountain (dating back to 1920 if memory serves), serving up all the stuff you used to find in a drugstore. We chose somewhat boring items, I guess: Terah had a chocolate shake (the made-in-front-of-you-fresh kind), and I had a root beer float. So, what would have been a quick lunch in a different town turned into a few hours in Council Grove thanks to a very helpful leaky tire this morning that threw us off schedule! After that, a few more caches on the way back towards home. We picked up Jacob, and he and I found the last cache of the day which he, of course, loved. Then home. We only found 8 caches, but had a lot of fun.

I'm trying to work on having days that are somehow individually memorable this year. So far.. 0 (leap day) Finally tackled the chapter on monads. I'd read various explanations a year ago, but was swimming in syntax I didn't understand. After percolating for a year, and learning to read the syntax better, monads turned out to make very simple sense. (I can't say the same about Johnny Monad.) I had been meaning to write sometime about a method I used in ikiwiki to let expressions in a mini-language, that normally are evaluated to match a set of pages, instead be evaluated to explain why they succeed or fail. It's a cute technique, though hard to explain. Now I'm pretty sure it's just a monad. So I don't have to explain it! 1 Visiting Abram's falls this time of year, the canyon is in constant wintry shadow. The falls are not frozen, but have icicles twice my height, and there are rank upon rank of icicles all down the walls, an ice cathederal. It's a bright sunny day, but on the whole hike, I only get into the sunlight once, briefly, at the top of the giant steps. Then back into the shade. Back at my car, I'm suprised that it's only 3 pm, feels like it should be 5. Made a pecan pie with daddy's pecans and eggs. 2 A grey day with snow and worse. The paper's rss feed repeats "dozens^Whundreds of wrecks" over and over, as if to make up for there being no 60 point type. I'm reading Ted Nelson's book Geeks Bearing Gifts. The chapter summaries seem better than the actual book. And the on-demand printing makes me think I'm reading a poorly laid out web page, rather than something typeset. But I love that he goes all the way back to the invention of the alphabet and of hierarchical categorization and suggests all the basis for modern computers is arbitrary and/or wrong. Eating ginger duck downtown I look up and a pizza delivery guy has slid out of control right in front of me and crashed.

While searching for different options to share files among different computers in a local LAN I found via Planet Ubuntu giver a little util which uses avahi/zeroconf to publish shared folders or files. It is a easy tool, that works and that serve well its purpose. But its development has stopped some time ago, and that means that nobody has cared to port it to Windows, where it would be an interesting tool to avoid the need of using windows network to share folders, which in an ad-hoc network tends to work problematically. These little gems should receive more care from freedesktop.org, GNOME Foundation, Canonical, Novell, as are the utils that make a difference in desktop expecience. Having a nice visual effects is not enough to attract people to free destops, but having tools that make everyday life is.

The other day, I wanted to prepare some videos of my favorite reggae and soul tunes for uploading them to YouTube.. My goal was very simple: prepare a video with a static image and the music I wanted to upload.. After briefly digging for a simple software to do that, which I could not found, I said "hey, why not doing it with liquidsoap !". Well, that is fairly easy ! Video support in liquidsoap is very young, but the amount of things that can be done is already quite important, so I though this would be an interesting example.. All you have to do is to prepare a PPN version of the picture, using convert /path/to/image.jpeg /path/to/image.ppn and have the mp3 or ogg file in an other place... From the scripting point of view, the only difficult thing is to have liquidsoap stop at the end of the song.. As liquidsoap is mainly a streaming language, it is not designed to be able to stop easily. It should be made better soon, but for now I had to use a special trick: compose sequentially the song with a blank source. On the blank source, I add special metadata such that the output file is reopened with a new title when the song has ended. Eventually, the shutdown is triggered when adding the new metadata on the blank source. Here is the code: The result is just what I wanted (surprisingly !): The other videos can be found here.

A teacher in Arizona steals Linux CDs from a student and then accuses a Linux distributor of being a criminal [1]. Even though she had used Linux in the past she didn t believe that software was free. Of course that implies that in the past she had performed actions that she believed were criminal. Neat Little Mac Apps interviews Marshall Kirk McKusick - he describes how the BSD Daemon logo was designed and one of his most significant bugs [2]. OurDelta.org offers MySQL builds with some extra features and support [3]. I was recommended to use their builds by Arjen Lentz of Open Query [4], as one of my clients is going to use the services of Open Query it seems best to use the Our Delta builds if only to get better support from Open Query. The extra features in the Our Delta builds seem interesting, but I m not sure that my client needs any of them at this time. The Global Guerilla blog reports on a man who single-handedly invaded the most heavily guarded power station in Britain and shut it down to protest against new coal power stations [5]. The entire blog is worth reading, the author has a lot of interesting ideas. PhpMyVisites is a free web site analytics system that competes with Google Analytics [6]. I haven t implemented it yet, but it looks promising. It seems that PhpMyVisites is not being updated any more (not even security updates) and the replacement is Piwik [11]. Andrew Lahde was a fund manager who made significant amounts of money by betting on the inability of US mortgagees to repay their debts, he wrote an interesting goodbye letter (Telegraph.co.uk) [7]. He now has a Wikipedia page which gives some interesting background to his career [8]. An Employee of the Financial Times is famous for flaming Andrew [9], I have submitted a comment pointing out that being famous for flaming someone who is more successful than yourself is nothing to be proud of and suggesting that he advocate his own political views when criticising those of others - I doubt that it will get through moderation. It s a pity that Andrew doesn t have a blog, I would like to read more from him. At CCC a paper by Alexander Sotirov, Marc Stevens, Jacob Appelbaum, Arjen Lenstra, David Molnar, Dag Arne Osvik, and Benne de Weger on how to crack the PKI infrastructure used for SSL signing was presented [10]. The root cause is some CAs still using MD5 even though it was broken a long time ago. Updated to note that Piwik is the replacement for PhpMyVisites.

• [1] http://linuxlock.blogspot.com/2008/12/linux-stop-holding-our-kids-back.html


• [2] http://www.neatlittlemacapps.com/show/nlma-episode-048-interview-marshall-kirk-mckusick


• [3] http://ourdelta.org/


• [4] http://openquery.com.au/


• [5] http://globalguerrillas.typepad.com/globalguerrillas/2008/12/journal-climate.html


• [6] http://www.phpmyvisites.us/


• [7] http://www.telegraph.co.uk/finance/financetopics/financialcrisis/3219870/The-astonishing-sign-off-of-a-wealthy-fund-manager-in-full.html


• [8] http://en.wikipedia.org/wiki/Andrew_Lahde


• [9] http://blogs.ft.com/gapperblog/2008/10/yours-truly-angry-mob/


• [10] http://www.phreedom.org/research/rogue-ca/


• [11] http://piwik.org/

Last week, I spent some time building a good (that I liked) feed auto-discovery tool to use in Ruby for other project I m building, rFeed. I liked CPAN s Feed::Find, and at some point I made a wrapper class to run a Perl script using such module, however, I wasn t happy by mixing it all. So, Feedbag was born:

>> require "rubygems"
=> true
>> require "feedbag"
=> true
>> Feedbag.find "log.damog.net"
=> ["http://feeds.feedburner.com/TeoremaDelCerdoInfinito",
 "http://log.damog.net/comments/feed/"]
>> planet_feeds = Feedbag.find("planet.debian.org")
[ ... ]
>> planet_feeds.first(3)
=> ["http://planet.debian.org/rss10.xml",
 "http://planet.debian.org/rss20.xml",
 "http://planet.debian.org/atom.xml"]
>> planet_feeds.size
=> 104
>>

It makes smart use of relative and absolute bases, hrefs, links, content types, etc. It is also a single Ruby file, so you can grab it and use it on your application. Plus, it only requires Hpricot as dependency. It can find all feeds linked on a web page, but it will return the most important at the beginning of the resulting array, so you will have the important one on the first results (see example above with Planet Debian). Synopsis, README and a brief tutorial have been placed at axiombox.com/feedbag. You can also take a look at the git repo, hosted in GitHub.

Something that's bothered me and Emdebian in general for months is that it should be simple to compare two repositories and work out which packages need to migrate, which are behind etc. using perl. apt-cross has had rough support for this for some time but it isn't general - it relies on the apt perl bindings.

Recently, the shell scripts for Emdebian Grip became too complex to maintain long term - and far too slow. The main reason was the difficulty in getting all the relevant repository data into memory within a shell scripts. So, I turned to perl and the result is the tenth package to be derived from emdebian-tools source: libdebian-packages-compare-perl - Debian::Packages::Compare - emdebian repository comparison support. So far, it is meant to run on the server because various elements of meta-data need to be read from the repository configuration and that means relying on reprepro. In time, I hope to extend it so that this meta-data can be set arbitrarily so that the module only requires a pair of Packages files - at which point it can be extended to handle a Packages.gz file too (it already looks for and handles the Sources.gz file). The module includes bespoke handling for Emdebian TDebs and the locale root layout.

It reads the Packages file, create a hash of Package and version - once per arch, one per suite, one pair per repo. The underlying libparse-debian-packages-perl is a very simple module, there probably isn't any point putting extra data into the comparison hashes, get the data necessary and load the full Packages data separately using get_single_package.

This module is currently tied to the repository layout used by reprepro in order to identify the architecture list and various other pieces of meta-data. In time, functions can be added to provide such lists.

The module expects to find all repositories beneath a single base directory:

$base/$repo_name/conf/distributions

If $base is undefined or if the repository directories cannot be found, subsequent functions each return undef.

etc.

Example code:

use Debian::Packages::Compare;

my $base = '/path/to/repositories/'
&set_base($base);

my $debu = &read_packages ('unstable', 'filter');
my $gripu = &read_packages ('unstable', 'grip');
my %debianunstable = %$debu if (defined $debu);
my %gripunstable = %$gripu if (defined $gripu);
foreach my $pkg (sort keys %debianunstable)

if ($debianunstable $pkg 'source' ne $gripunstable $pkg 'source' )

# $pkg is either not in grip repository or is a different version




The main features for subsequent versions will involve more verbose error handling.

Currently just in Emdebian SVN, I'll be releasing to Emdebian fairly soon. If there's interest, I could put it into experimental but I think it needs that meta-data handling code first.

Debian::Packages::Compare.pm.

Time for another ftpmaster blog. It s not like we stopped doing things. :) It seems we, somehow, got a pretty active coder (yay), Michael Casadevall. In the last few days I merged multiple code changes from him. The first was a different output format for our NEW queue overview page. It is now also available in 822 Format for all those people that want to use the data in their tools. Like QA for example. Today got a second change touching this, we now not only list NEW/BYHAND in there, but also our incoming (accepted) and Proposed-Updates queue. There is also a patch waiting to fix up the pretty weird code thats around the DM stuff. Will fix some of the many bugs and weirdnesses in the current implementation. And it seems he is right now trying to get rid of apt-ftparchive, the beast that makes our dinstall run take so long. Oh we will be so happy when we got rid of it. :) Also, we do have two new people as trainees for ftpteam. If that works out, we will have yet another 2 new members in our team. Yay.

Recently the Debian Administration website has been besieged by spammers submitting bogus comments. I also run a couple of blogs which are constantly having random gibberish submitted to them - although it is less of a problem there because I approve them manually due to the offline nature of my blog, and the blog compiler I use. Regardless I figured it was time to do something about it, in part because Chris Searle suggested that I should be able to query arbitrary text for spammyness due to my experience with fighting email spam. (As it turns out that is not so useful experience. Comments and emails are not the same. The same header-trickery you see in bogus email, false EHLOs, etc, are not useful concepts to carry accross.) Anyway we were saying, I was going to do something? So I did. My solution? An XML-RPC server which you submit your comments to. This will return either:

OK	The comment is clean.
SPAM:[reason]	The comment is spam, and the optional reason explains further

The server itself is very simple, and it comes with a collection of simple plugins which do the job of testing different things. More plugins will almost certainly be added over time - so far I've seen the lotsaurls plugin capturing most of the SPAM, although the DNSRBL lookup is also working nicely having captured live spam without my touching it. Huzzah. & etc.. If there is any interest feel free to let me know, although as the server is open, and the client side usage is documented I imagine other people could run with it easily enough too - avoiding me becoming a single point of failure. For reference my initial change to hook this up live on the site was only a few lines of code - although later I did need to make some additional changes to make it cope with failures, & etc. ObFilm: Ghostbusters

I've started using Lua some months ago, while looking for a more powerful way to configure awesome. At this time, around March 2008, Lua seemed to be the best language to integrate inside the core system of awesome. I still think that Lua was a good choice, but after 8 months, it shows some important drawbacks. I'll try to keep my explanation simple and to make you understand everything, even if you do not know Lua. I refer here to Lua 5.1 Design flaws Length operator Lua has a length operator on its objects, known as #. It can be used to get the size of various objects.

return #"lol" 3

This operator works for table, string, etc It's possible to define this operator by setting a __len meta-method on a userdata value. The problem is that you cannot redefine it on string or table objects, see:

> a =   "hello", "world"  
> return #a
2
> setmetatable(a,   __len = function () return 18 end  )
> return #a
2

Indeed, looking at the Lua core code:

     case OP_LEN:   
       const TValue *rb = RB(i); 
       switch (ttype(rb))   
         case LUA_TTABLE:   
           setnvalue(ra, cast_num(luaH_getn(hvalue(rb)))); 
           break; 
             
         case LUA_TSTRING:   
           setnvalue(ra, cast_num(tsvalue(rb)->len)); 
           break; 
             
         default:    /* try metamethod */ 
           Protect( 
             if (!call_binTM(L, rb, luaO_nilobject, ra, TM_LEN)) 
               luaG_typeerror(L, rb, "get length of"); 
           )   
             
           
       continue; 
      

You clearly see that tables and strings always use the internal length operator, never the __len meta-method. That's for me a design problem, which will cause more trouble. We'll see later. __index and __newindex metamethods Lua defines two useful metamethods, which are __index and __newindex. Both can be set on a table or any other object. __index will be called upon each read access to an undefined key on an object, and __newindex upon each write access. Example

> a =  
> setmetatable(a,   __index = myindexfunction, __newindex = mynewindexfunction  ) -- function are not defined, this is just an example
> a[1] = "hello" -- This will call __newindex metamethod
> return a[2] -- This will call __index metamethods
> return a[1] -- This will NOT call __index

The last line does not call __index meta-method because a[1] does exists. This is a problem when you want to use table as object, because sometimes you want to monitor access to the table elements. This can be easily worked around using a proxy system: you don't store things in the table you manipulate, but in another table.

> a =  
> realtable =  
> setmetatable(a,   __index = myindexfunction, __newindex = mynewindexfunction  ) -- function are not defined, this is just an example

Where meta-methods are something like:

function myindexfunction(table, key)
   return realtable[key]
end

function mynewindexfunction(table, key, value)
   realtable[key] = value
end

This way, our a table will always be empty, and realtable will have the data. At every read or write access to a, the meta-methods will be called. This is very convenient and widely used hack. But this has serious drawbacks: as we saw before, the length operator (#) cannot be redefined on a table. That means #a will always be 0, and you cannot get the table length anymore, except by defining another method or a special attribute. Also, Lua has several functions in the table library that are used to manipulate table in a easy way. The problem is that standard functions like table.insert or table.remove do raw accesses to the table. Meaning that if you do table.insert(a, 1, 1) it will insert the value 1 at the key 1 into a, without calling the __newindex meta-methods, breaking all your beautiful object-oriented model. Another solution is to use a userdata object, like done in the Lua newproxy function (which is under-documented). The problem is that it breaks all the other functions that are waiting for a table as argument, because they see a userdata, not a table. So this time table.insert is now more usable, which somehow fixes the problem, but not in the right way IMHO. However, this allows to use the __len meta-method. Development model The development model of Lua is, from my point of view, non-existent. There is no public version control system repository available, so there's no chance to really contribute to Lua. It seems only a defined set of people work on it and therefore, the development system is very closed to my eyes, in comparison of usual projects. Conclusion I still think Lua is a good choice, because it is very easy to integrate into any C program, and to expand to fulfill your needs. However, some bad design choices were made, and the poor and closed development model chosen does not allow to have a good overview of the future of Lua. This has been well stated by the authors themselves.

A recent post by Adrian von Bidder got me to reread the "Printing dialogs and GNOME" thread that Linus started on the GNOME mailinglists a few years ago. I don't know how or why I missed it back then, but I did see this little gem in a post by Mike Shaver:

You and I are not interesting GNOME users, in part because we already _are_ GNOME users. The interesting GNOME users are the ones that haven't tried it yet, and we need to figure out why they haven't. There are lots of things that I want in GNOME, but if they aren't going to bring a hundred thousand of my closest friends along as well, I would hope that nobody goes out of their way to do them.

That is precisely what is wrong with the GNOME people. While encouraging new users to try and use GNOME certainly is a good and worthy goal, it is this mentality of 'only the new users matter, the existing ones can go f*ck themselves' which will ultimately drive away users. Of course this post is a few years old, and I'm not involved in GNOME development in any way, so this mentality might have gone away now; but I don't hold my breath.

In experimental you can find:

• blender 2.48a: Finally (sorry for that) packaged. Upstream release logs: 2.47, 2.48.
• python-networkx 0.99 and its companion python-pygraphviz 0.99: Quite a huge step forward, to polish things before a 1.0 release.
• hugin 0.7.0: Lots! of things changed since the last upstream release. Grab it!
• libgphoto2 2.4.3: Upstream release logs from 2.4.1 and even older.

Some of those packages have been there for quite some time already, but experimental being what it is, a bit of advertisement is always welcome I guess.

Nicola Benaglia reported bug #510000 on Sunday December 28th. As bug #500000 was reported as of Sep 24th 2008, this marks a considerable slowdown of our bug reporting rate: between bugs 400000 and 500000, it always took us nearly exactly two months to have 10000 bugs reported. Here, we needed more than 3 months! This is a 50% drop in the bug reporting speed. I think we can conclude this is a very good illustration of the considerable drop in the development of Debian, while everybody is awaiting for the release of Lenny. You still have a few days to correct your bet for bug 600000 date. Ah, and the very same day, the result for the very controversial vote about firmwares has been published. Even though it is very hard to interprete, I think that the very very low rating of option 1 (worded as "Reaffirm the Social Contract" but indeed meaning "let's be Free Software Zealots and nitpick every single bit of firmwares so that we can be sure to never release Lenny") clearly shows that Debian developers still have their feet in reality. So, now let's release the bloody thing...and prove the world we still exist...

This is a continuation from part 1 but can be enjoyed on its own too, like a good red wine. It s a bit early for me for red wine, though.

May

• BBC TV: Click: Free=beer and facebook-flaming - my letter was never broadcast, as far as I know
• Fuel Price Bleating and Biking - one of the last non-work articles to appear before I split them off into their own page last summer.
• Told You So: Exhibitions and Spammer Registrars and Quick Question: opticaljungle.com = publicdomainregistry.com? - these were about similar topics and I may have new developments to report early in 2009.

June

• BBC website, TV and Technology - some background comments on the BBC as they try to figure out what to do with new media. Auntie is a bit clueless about new things.
• 7 Reasons Why Firefox 3 Download Day Sucks - the big news for web development was a new major version of the almost-free-software web browser. It s a big improvement on version 2, but still had some brown paper bag mistakes and the download day marketing idea put clueless news media (see previous item) before users. Continued in FF3 day 3: first impressions, FF3 day 6: security flaw and banks and FF3 day 10: security flaw 2, more banks, looking for a new browser.

July

• Standing for Election to SPI Board Again - my most popular page ever, by number of page views anyway. It was spammed to hell so often that comments are now switched off. I suspect the US Election had more to do the popularity of this article than my unsuccessful candidature for the Software in the Public Interest board.
• Batting Against Three Strikes through the Back Door - I m a member and ambassador for ThePhoneCoop and TTLLP are agents/resellers for them, so this misguided EU law-making was worth some of my time. Writing about it here got me a response from Neil Parish MEP that I don t think I would have got otherwise. It s a terrible shame he never sent a reply from Malcolm Harbour.
• LugRadio Live Event Review - a review of one of the most populist UK free software events by one of their most vociferous critics (back before they went all Creative Commons warm and fuzzy) was always going to be popular, which is partly why I wrote it, but not the whole reason: I m delighted that the event should return in the future. It s not perfect, but it s pretty damn fantastic. A tech conference crossed with a rocking gig by the strangest boyband ever, with a cheerleading racoon and some very cool people.
• Good News on the Koha 3.0.0-final Approach - another surprisingly popular marginal comment. I ve currently broken/desynched/something my local git tree. I m going to repair it by New Year and then start writing up more Koha explorations and sending patches upstream.

August

• SPI Meeting Announcement and Why People Don t Join SPI - I think this summary is still relevant today and I hope that I can help improve things in 2009.
• Is Yahoo Now Even Worse On Spam? All of the big unpaid webmails have problems, but Yahoo (and so BT Internet) are worse than most.

More to follow in a couple of days

Can anybody point me to a beginners tutorial for running PyGTK on OS X?I've written this little BPM tap program in PyGTK, that gives you a speed plot and confidence interval, works well for me.A friend of mine would like to use it, but is running OS X, and doesn't know much about computers. I know next to nothing about OS X. I know it already has Python2.5 installed, and that's about it.So anyone got a tutorial that doesn't require previous knowlege about using fink, ports or whatever? Something that I can point a real novice user to?Via email please, my blog intentionally doesn't have comments. Erich AT Debian DOT org.[Update: so far, I've only had requests about my bpm toy and about the same kind of instructions, but no links to refer people to...]

Over the next few days, I m looking at the most popular articles from this site and my previous news website during 2008. I ll be doing it in three parts. Popularity is measured by page views from local access logs, but some articles were actually more popular in the months after they were first posted, so it s not completely accurate, but let s be forgiving over the holidays, OK?

January

I must have been writing rubbish because nothing got that popular at the start of the year, but some of my older pages continued to be popular throughout 2008:-

• Online Banking with GNU/Linux, Firefox-based browsers or Free Software (started in 2007) - I really should move that list to another address because I think it s going to be around for a while.
• alt.satellite.tv.europe Frequently Asked Questions (first posted in 2006) - again, could do with a better home.
• Annoying blog comment misfeatures: letter images - until people recognise the limitations of CAPTCHA , this is probably going to be a popular page.

February

• SPI Meeting Wed 27 Feb 1900Z irc.oftc.net/#spi - I think this started my regular meeting announcements, which has been a surprisingly popular series and has expanded into a whole category of SPI articles here.
• The Myth Of Deregulation - this was meant to be a marginal rant. Its popularity (and the subsequent comments - some of which were unpublishable or their authors requested removal) surprised me and so I started writing more about social enterprise, cooperatives-sw member businesses and how they interact with GNU/Linux software and web development.

March

• Annoying Judge Resurrects Software Patents in the UK - notable only for pointing out that Symbian is not a UK company. It was probably news to some software developers, which is probably why it made my popular articles list.
• Debian Project Leader IRC Debate or it might have been Random recent threads from planet debian - for the first part of the year, I m looking at what page spiked on which day, but I posted twice a few days apart, so I can t tell which article on the page was popular.

April

• UK mobile micropublishing choices? - for the trip that motivated that article, I used twitter, but I m actually updating identi.ca over XMPP from my mobile now.
• Better Free Software Organisations? - I ve read the Yunus book mentioned in the comments on the Advogato repost of this article and I ve a review which will appear on this site later. It includes a bit of a flaming of the simplistic and IMO factually-incorrect dismissal of cooperative businesses, so I wonder if it will get a few responses from Yunus-fans.
• Explaining web site improvements: what s important to you? It seems that April was a good time for asking questions: this is a third popular question-based article. The website discussed has now been approved and ordered from TTLLP, but the work is not yet scheduled.

That s the first few months of 2008 done. I ll post the next few months in a couple of days. Hope you re enjoying the holidays if you re having them. I m sure I am

I switched to git from mercurial about 4 months ago. As Matt Mackall (the main author of mercurial) has pointed out, my arguments were partially just excuses for the switch, because everything could be fixed in mercurial as well (eventually). On the other hand, I really wasn't expecting to switch when I invested time and energy to learn mercurial. Also because I thought that git doesn't have such a nice documentation, has a steep learning curve and the community is hostile, because it is developed by the kernel people who are famous for sometimes being not so nice on the mailinglists (as I now found out, none of these are true). I was getting annoyed by small things one by one, after finally I said to myself enough is enough, let's just switch.

So as to the steep learning curve --- it took me a day or two to being able to do what I want, so it seems to me it's really easy to learn once you know some distributed vcs. I found out the documentation is much better than in mercurial --- in git one just types "git help command" and a full man page fires up with lot's of information and examples. In mercurial, one just gets a couple lines (compared to git) of help in the terminal, without examples. Also the first (actually second) thing I noticed is that "git log" (and other commands like "git diff") doesn't scroll out my terminal, but uses "less" automatically -- that's just great. The first thing I noticed is that git is superfast for almost every operation, especially it's noticeable with "git diff". As to the community, I only had a chance to send a few emails to the git list, so I cannot really say, but so far it's very responsive and friendly.

However, those are just little things that can (and I am sure they will) be fixed in mercurial as well. What is a big thing are branches, especially remote branches. One just fetches a remote repository and then works with it like with any other local branch, e.g. one can switch to it, or just "git log some_remote_branch" to see what is in there. One can easily compare them etc. With mercurial, I was using "hg out" and "hg in" commands to see what changes I will pull or push, but those commands require internet connection, so it really sucks and it's slow. In mercurial, I was using different directories for different branches, but that's just extremely inconvenient and also slow (creating a new branch is just a matter of adding one file, not copying the whole repository --- for example with the sympy hg repository, I often had to wait several seconds to clone a repo, while with the git repository it's just instant) and big (in terms of megabytes).

The bible of Mercurial, the hgbook says:

In most instances, isolating branches in repositories is the right approach.

But I think it's the wrong approach. The only argument for doing this that I accept is that sometimes you are not sure which branch you are in in git --- well, I use this trick (actually, just read the documentation of __git_ps1 in /etc/bash_completion.d/git), so my bash line always says which branch I am in using the red color. I never do any mistakes with this.

Anyways, I could continue like this (e.g. check out "git svn", "git rebase -i" and many other things), but you can read why git is better for example here, no need to repeat here. I am very happy now and I can only recommend to learn git.

So let me also say some things that are worse in git --- one thing that could be improved are URLs of the gitweb (hgweb urls are neat, gitweb urls use "?id=..." stuff). Another thing is that the debian package git is not git! You need to install git-core to get git (but this seems to be getting fixed).

There is also an interesting discussion happening right now in the debian-python mailinglist about switching the DPMT repositories to git. I think almost all opinions (for and against) were already stated, but if you have some opinion that wasn't yet said, please do so.

The Debian Python Modules Team is discussing which DVCS to switch to from SVN. Ondrej Certik asked how to generate a list of commiters to the team s repository, so I looked at it and got this:
emilio@saturno:~/deb/python-modules$ svn log egrep "^r[0-9]+ cut -f2 -d sed s/-guest// sort uniq -c sort -n -r
865 piotr
609 morph
598 kov
532 bzed
388 pox
302 arnau
253 certik
216 shlomme
212 malex
175 hertzog
140 nslater
130 kobold
123 nijel
121 kitterma
106 bernat
99 kibi
87 varun
83 stratus
81 nobse
81 netzwurm
78 azatoth
76 mca
73 dottedmag
70 jluebbe
68 zack
68 cgalisteo
61 speijnik
61 odd_bloke
60 rganesan
55 kumanna
52 werner
50 haas
48 mejo
45 ucko
43 pabs
42 stew
42 luciano
41 mithrandi
40 wardi
36 gudjon
35 jandd
34 smcv
34 brettp
32 jenner
31 davidvilla
31 aurel32
30 rousseau
30 mtaylor
28 thomasbl
26 lool
25 gaspa
25 ffm
24 adn
22 jmalonzo
21 santiago
21 appaji
18 goedson
17 toadstool
17 sto
17 awen
16 mlizaur
16 akumar
15 nacho
14 smr
14 hanska
13 tviehmann
13 norsetto
13 mbaldessari
12 stone
12 sharky
11 rainct
11 fabrizio
10 lash
9 rodrigogc
9 pcc
9 miriam
9 madduck
9 ftlerror
8 pere
8 crschmidt
7 ncommander
7 myon
7 abuss
6 jwilk
6 bdrung
6 atehwa
5 kcoyner
5 catlee
5 andyp
4 vt
4 ross
4 osrevolution
4 lamby
4 baby
3 sez
3 joss
3 geole
2 rustybear
2 edmonds
2 astraw
2 ana
1 twerner
1 tincho
1 pochu
1 danderson
As it s likely that the Python Applications Packaging Team will switch too to the same DVCS at the same time, here are the numbers for its repo:

emilio@saturno:~/deb/python-apps$ svn log egrep "^r[0-9]+ cut -f2 -d sed s/-guest// sort uniq -c sort -n -r
401 nijel
288 piotr
235 gothicx
159 pochu
76 nslater
69 kumanna
68 rainct
66 gilir
63 certik
52 vdanjean
52 bzed
46 dottedmag
41 stani
39 varun
37 kitterma
36 morph
35 odd_bloke
29 pcc
29 gudjon
28 appaji
25 thomasbl
24 arnau
20 sc
20 andyp
18 jalet
15 gerardo
14 eike
14 ana
13 dfiloni
11 tklauser
10 ryanakca
10 nxvl
10 akumar
8 sez
8 baby
6 catlee
4 osrevolution
4 cody-somerville
2 mithrandi
2 cjsmo
1 nenolod
1 ffm
Here I m the 4th most committer And while I was on it, I thought I could do the same for the GNOME and GStreamer teams:
emilio@saturno:~/deb/pkg-gnome$ svn log egrep "^r[0-9]+ cut -f2 -d sed s/-guest// sort uniq -c sort -n -r
5357 lool
2701 joss
1633 slomo
1164 kov
825 seb128
622 jordi
621 jdassen
574 manphiz
335 sjoerd
298 mlang
296 netsnipe
291 grm
255 ross
236 ari
203 pochu
198 ondrej
190 he
180 kilian
176 alanbach
170 ftlerror
148 nobse
112 marco
87 jak
84 samm
78 rfrancoise
75 oysteigi
73 jsogo
65 svena
65 otavio
55 duck
54 jcurbo
53 zorglub
53 rtp
49 wasabi
49 giskard
42 tagoh
42 kartikm
40 gpastore
34 brad
32 robtaylor
31 xaiki
30 stratus
30 daf
26 johannes
24 sander-m
21 kk
19 bubulle
16 arnau
15 dodji
12 mbanck
11 ruoso
11 fpeters
11 dedu
11 christine
10 cpm
7 ember
7 drew
7 debotux
6 tico
6 emil
6 bradsmith
5 robster
5 carlosliu
4 rotty
4 diegoe
3 biebl
2 thibaut
2 ejad
1 naoliv
1 huats
1 gilir

emilio@saturno:~/deb/pkg-gstreamer$ svn log egrep "^r[0-9]+ cut -f2 -d sed s/-guest// sort uniq -c sort -n -r
891 lool
840 slomo
99 pnormand
69 sjoerd
27 seb128
21 manphiz
8 he
7 aquette
4 elmarco
1 fabian
Conclusions:
- Why do I have the full python-modules and pkg-gstreamer trees, if I have just one commit to DPMT, and don t even have commit access to the GStreamer team?
- If you don t want to seem like you have done less commits than you have actually done, don t change your alioth name when you become a DD (hint: pox-guest and piotr in python-modules are the same person)
- If the switch to a new VCS was based on a vote where you have one vote per commit, the top 3 commiters in pkg-gnome could win the vote if they chosed the same! For python-apps it s the 4 top commiters, and the 7 ones for python-modules. pkg-gstreamer is a bit special