(when your wife/SO is not around)

• Finally get around to play with the PowerPC you have had standing besides your desk for about a month.
• Discover that it still doesn't boot, since it can't find its hard drive. Also discover that it doesn't want to talk to your USB keyboard.
• After a while, think of removing and replugging the SAS connectors, which fixes the boot problem. The machine now runs YDL.
• Decide you want to install Debian instead of YDL, but also wonder how to do that safely since you still can't talk to Open Firmware.
• Search for the RJ45-to-serial adapter you got with the box. Discover you probably wired it wrongly the first time around. Break it when you try to rewire it.
• Find that spare DB9 connector you had lying about, find soldering iron and fix up the connector.
• Become very, very confused, since you get perfect output, but input still doesn't work. Discover you managed to solder all the connections mirrored. It worked with effectively just one wire, not even shared ground. Resolder.
• Download Debian ISO, burn it on a DVD. Get annoyed at the machine for failing to boot from the DVD.
• Set up netboot, boot from network.
• Discover d-i doesn't install a kernel, nor a bootloader, do that by hand.
• Oops, bootloader didn't work. Iterate a couple of times of running mkofboot until it suddenly feels like booting from the hard drive.

Hurrah! And it only took like six or seven hours. Notes for later: This is an YDL Powerstation, the magic mkofboot invocation is mkofboot -b /dev/sda1 --filesystem raw; the raw bit is needed for IBM hardware. The firmware also cares about whether the partition is marked as bootable or not, so make sure to mark it as such.

Dear Adrian, I can only but complain about the "Guide Through The Linux Sound API Jungle" that you mention in your last post. All that is said there about OSS is pure FUD and only reflects a deep ignorance of the current project. It is a pitty to spread misinformations that deprecate the work of others without even trying to understand it. Here is what is said about OSS in this document:

The Open Sound System is a low-level PCM API supported by a variety of Unixes including Linux. It started out as the standard Linux audio system and is supported on current Linux kernels in the API version 3 as OSS3. OSS3 is considered obsolete and has been fully replaced by ALSA. A successor to OSS3 called OSS4 is available but plays virtually no role on Linux and is not supported in standard kernels or by any of the relevant distributions. The OSS API is very low-level, based around direct kernel interfacing using ioctl()s. It it is hence awkward to use and can practically not be virtualized for usage on non-kernel audio systems like sound servers (such as PulseAudio) or user-space sound drivers (such as Bluetooth or FireWire audio). OSS3's timing model cannot properly be mapped to software sound servers at all, and is also problematic on non-PCI hardware such as USB audio. Also, OSS does not do sample type conversion, remapping or resampling if necessary. This means that clients that properly want to support OSS need to include a complete set of converters/remappers/resamplers for the case when the hardware does not natively support the requested sampling parameters. With modern sound cards it is very common to support only S32LE samples at 48KHz and nothing else. If an OSS client assumes it can always play back S16LE samples at 44.1KHz it will thus fail. OSS3 is portable to other Unix-like systems, various differences however apply. OSS also doesn't support surround sound and other functionality of modern sounds systems properly. OSS should be considered obsolete and not be used in new applications. ALSA and PulseAudio have limited LD_PRELOAD-based compatibility with OSS.

And here is what one of the devs from OSS answered to this [1]:

It's pretty inaccurate FUD (From the URL address - it's Pulseaudio's author, right? I'd have expected him to know better). He's basically judging OSS per the old OSS/Free drivers, which is like 5 years ago, and even that he does wrong. First, *all* current implementations/emulations of OSSv3 do sample conversion. It's not even a property defined by the API but by the underlying drivers. Second, even OSSv3 supported surround, USB cards, etc. Third, arguing that "it cannot be virtualized" is disproven by the amount of emulations and alternative implementations existing out there and working in practice. (The main difficulty is mmap() API, which is very rarely used anyway, and even that can be done with, say, oss2pulse). Fourth, complaining about OSS API being awkward, is... well, awkward when you compare it to ALSA API, if you could compare it, since most ALSA API isn't documented. It's kinda funny he advocates using ALSA API (not in the quoted part above, but last time I read his blog he suggested it). Actual ALSA devs advocate against it, but using a sound library with multiple backends [2].

If you read some documentation, you can understand that OSS has been the target of some kernel developpers that didn't like it to be reused in a commercial product, back in the 90s. Hence, ALSA was launched, and OSS was progressively discarded, while constantly being the target of FUD like this. OSS has then lived for almost 10 years in the dark side of the force, but eventually did the way back in July 2007. Ironically, now most of the developpement in the linux kernel is driven by commercial interests. Most of the original complains about OSS are now fixed, including all the FUD written in this guide. In particular, software mixing is now supported. Being also part of a project that writes code to handle sound input and output, I can only but complain about the mess in the area of sound APIs in linux. However, OSS should really be reconsidered. In particular, its API is designed in order to abstract as much as possible access to the sound card, so that application writers have as less as possible to do with sound conversion and the like Those who have tried to use ALSA may for instance compare that to the "set rate near" call in its API: this call will set the rate to what the hardware support and let you handle the conversion... For each application... Also, OSS API is available across all unices, except OSX, and there is even a BeOS port going on. Finally, OSS API is POSIX oriented, reading and writing on the sound card, being a matter of calling few ioctls and then reading from the device file. In the future, OSS developpement will most probably be done as a community project, and I believe it is now time to stop spreading false ideas about the project, and give it as much attention as the other projects. For the debian users who want to try OSS4, a package is available in the packaging team's svn repository. It has been sitting in NEW for some time, I hope it gets accepted at some point.

DISCLAIMER: Paranoid rant ahead. You ve been warned. Every two years, around this time of the year, I feel concerned: it s voting time in Brazil. For quite some time now, Brazil has had electronic voting, but that doesn t make me more confortable with it. Yes, having the results within the same day is an enormous advantage, but I am not sure about the security of the whole process. You can call me paranoid (and surely I am a bit), but there are some things that give me the creeps about it. For a start, let s look at the operational process. The voting machines are certified and sealed by Electoral Justice officers the week before the voting. They are opened in the electoral section by those officers in the presence of common citizens. Those citizens are called to work in the Electoral process usually for four or five elections in a row, being replaced after that by newcomers . The voting machines are not connected to any network. During the day, voters come with the voting document (voting is mandatory in Brazil), one of those citizens enable the voting machine by typing the document unique number in it, the voter give his vote and go home. Then the voting machine is unable to receive votes if not enabled by entering another document number, and it goes on and on the whole day long (pretty boring work ). At the end of the day, the president of the section (usually the most experienced of those citizens) close the voting machine, prints a tally sheet , hand a colored 3 -inch floppy disk to the Electoral Justice officer with the votes and go home. Other officers will pick up the voting machines later on. The first officer then goes to the voting processing central of the Electoral Justice and within hours we will know the result of the election. As you can see, there are lots of points of failure in the whole process! All this sealing of voting machines are just a matter of trust. First point: there s no way we can know for sure if the machine does what it s suppose to do. Even if officers say that they randomly choose machines to be tested, there s no way to know how random is that. There s a report [pt-BR] made by a prestigious university (English summary here), stating that 1/3 of the voting machines in a particular studied state had corrupted log-files (among other important security problems!). This study also showed differences in the countings (sometimes as large as 20-thousand votes!)... Hey! This is supposed to be a deterministic system: if nothing in the conditions changed, counts should always match! Until recently, closed-source software were used in the voting machines, but that has changed recently. I doubt that it makes any difference, since we ll never really know what is actually running in the machine. Surely, Electoral Justice officers know (or should know), so we d have to trust them So second point: we don t know how the voting is processed within the machine. (Also, we don t know for sure the machine doesn t have a network connection. It may have a wireless connection we don t know about and can be passing all the votes to someone else, or even receiving instructions But since that can be spotted with a scanner, I ll trust other paranoids have already done that.) Surely the machine must be enabled before every vote with the voters document number. If it were not, how could we know that no one voted twice, or that a non-voter have voted? But we don t know how the machine records that! Third point: we cannot know if the voting machine database doesn t link the voter to the vote. That is a nasty one it opens up the possibility of voting by intimidation . Also, the tally sheet that is printed at the end of the day only brings the total of votes, the total of absent-voters, and the votes each candidate (or party) have received. So, on to the fourth point: there s no way of knowing for sure that your vote was counted right (or was counted at all!). At least a copy of this tally sheet is glued at the entrance of the voting section, so an independent audit only on the numbers is do-able (although hard to do!). What happens to the colored disk between the voting section and the voting processing central is not known. It goes with the officer and what he does with it is just a matter of trust. Now for the most insteresting point: the security is based on the color of the disk!. The Electoral Justice checks if the officer handed the right colored disk and puts the data in the system. Surely (?) they might have some way to check data integrity other than that On the same issue, maybe even worse: even if the disk is not tampered, but just read (or copied) by the officer before being handed, and if the database links the voter to the vote, this information is valuable, and may be sold. Finally, since we don t know (and have no way to know for sure) what the machine does, we don t know if the machine keeps a copy of the voting database in it. So when it is taken back by other officers, we cannot know whether the same thing that may happen to the disk also could happen with the machine. I am missing a lot of things about the whole Brazilian E-Voting process, and also I surely have missed other points of failure. I heard of fraud in the past, with paper ballots, and those were pretty nasty frauds. But this whole tale of impossible fraud in e-voting is nothing but a tale (as fraud is more than possible!). I think we have to begin investigating other systems, surely with cryptography involved. A system like Debian s, far from perfect (we all have to trust secretary s word on the secrecy of the voting system key), is much better, for instance. I understand that it s not simple enough for non-geeks, but there might be a way! It doesn t need to be a whole new system! I would be happy if, as an example, the tally sheet printed a hash of my vote that I could verify later on or if the security of the disk is not just color-based or if the tally sheets had a way of being validated and be available on-line for auditing (and not just glued at the entrance of every voting section). Look! I am not distrusting any officer a priori... I think the message is auditing should be made easy... then I could trust a version of Linus s Law adapted to E-Voting: Given enough eyeballs, all frauds can be discovered .

Russell writes about the iphone. I think he's missing a few things.

The open nature of the PC wasn't inherently what brought it greater success. The open nature of the PC meant that it could spawn an ecosystem of third party hardware vendors, sure. It also meant that it could be cheaply cloned by other manufacturers, ensuring competition that drove down the price of hardware. The net result? x86 is ubiquitous, sufficiently so that even Apple use a basically standard[1] x86 platform these days. Low prices and the wide availability of software that people wanted to run bought the PC the marketplace, with Microsoft being the real winners. Apple hardware remained more expensive for years, and the compelling MacOS software was mostly limited to areas like DTP. Nobody else had any incentive to buy a Mac.

Now, let's look at the phone market. Third party hardware vendors? No real distinction between the iphone and anything else. Sure, anything remotely clever has to plug into the dock port, but developing something to work with that also gets you into the ludicrously huge ipod market. Other phone accessories are either batteries, chargers or headphones. That's really not going to be what determines market success.

Competitive cheapness? When you have a multivendor OS like Android or Windows Mobile, you might expect there to be more opportunity to compete to undercut each other, offering equivalent platforms for less cost. But that's missing something. In the same way that the home computer market has basically consolidated towards PCs, the phone market has already consolidated. Your smartphone has an ARM in, probably along with an off the shelf GSM chip and some 3D core (generally something from Imagination, though in Android's case Qualcomm seem to have come up with their own core - I haven't been able to find out if it's derived from something else). There's no realistic way to make a phone with equivalent hardware functionality and quality to the iphone and sell it for significantly less money. And if you figure out how to, Apple get to take advantage of the same price reductions in their next generation hardware. And, being Apple, they'll probably find some compelling wonderful design feature that costs them nothing extra but makes you want it more anyway. So hardware competition probably isn't going to be what determines market success.

Which leaves two things - advertising and applications. Apple are good at marketing. This is unfortunate, because I'd really rather live in a world where everyone running MacOS was running Linux instead, but we seem to suck in comparison. The good news is that Microsoft also seem to, so maybe we'll have our act together some time between now and Apple crushing us to death. So, assuming current trends continue, Apple's marketing probably isn't going to kill the iphone. Which leaves one thing: applications.

The obvious argument against the iphone's success is that, as a closed software distribution platform, it's less attractive to developers. I don't think that's true. If we look at the console market, the gp2x was hardly a PSP killer. Or a DS killer. You could possibly argue it was a Gizmondo killer, but only if you ignore the Finnish mafia. Being an open platform doesn't immediately result in you killing closed platforms. You need developers, and you need applications. Otherwise nobody's going to buy your hardware, even if it costs $10 less than an iphone and has a few extra bits of plastic. What attracts developers? An attractive development environment and a revenue stream. Android has one real thing going for it here - it's not tied to Objective C, and so there's probably a larger number of potential developers. But let's be realistic. If you're a competent developer, you can move from C++ or Java to Objective C without too much effort. And if you're an incompetent developer, you're not going to be deciding the future of a platform.

Apple have made it easy for people to write applications that share the iphone's delightful[2] UI. There's almost active encouragement to write beautiful programs that integrate well. Sure, the platform limitations bite you in weird ways (like the no background running thing), but Apple have come up with hacks to smooth most of those over. The iphone is a wonderful device to develop for. Sufficiently delightful that there was a huge developer base even before Apple had released the SDK. What does that tell you? Developers actively want to write for the iphone. In fact, they wanted to even before there was a real revenue model. Mindshare means a lot.

What are we going to see in response from Android? To begin with, uglier applications. I'm sure that'll get better over time, but right now the Android UI just isn't as well put together[3]. It's functional, even attractive. But it's not beautiful. And lowering the bar to developer involvement means the potential for more My First Phone Application. Windows Mobile and Symbian have huge numbers of applications. They're mostly dreadful lashups of functionality you'd never want and a UI that's ugly enough to make you want to stab out your eyes, coupled with a nag screen asking for a $10 donation to carry on using it assuming it hasn't crashed before it got that far. To be fair, a lot of iphone stuff isn't much better. But proportionately? Right now the Apple stuff has it. I never want to see another listing of Symbian freeware.

At the moment, Apple wins at providing compelling applications. They may be a gatekeeper between the developer and the user, but right now that's not causing too many problems. Well. It wasn't. The recent fuss about Apple dropping applications because of perceived competition with their own software is an issue. If a developer is going to spend a significant amount of time and money on an application, they want a reasonable reassurance that they're going to be able to ship it. And, right now, Apple's not giving that. It remains to be seen whether this has long term consequences, but there's some danger of Apple alienating their developer base. If those developers move to another platform, and if they create compelling software, Apple might stand some real competition. At the moment? Apple has the hardware, the OS and the applications. They have the potential to take over broad swathes of the market. But they also have the opportunity to throw it away. And that's what's going to decide the success of the iphone - a closed platform is not inherently a problem, but it gives the vendor the option of removing one of their key advantages. If Apple get through this with their developer popularity intact, I don't see the open/closed distinction as having any real-world importance at all.

The relevance to Linux? We're not going to succeed by being philosophically better. We have to be better in the real world as well. Ignoring that in favour of our social benefits doesn't result in us winning.

[1] It's slightly more legacy free than a "genuine" PC - there's no i8042, and things like the gate A20 hack aren't implemented. But it'll boot DOS (given enough effort), so hell, it's a PC

[2] And yes, I genuinely do think that the iphone's UI is better than anything else on the market. There's no reason someone else, including us, couldn't have got there first. But we didn't, and now everyone gets to play catch up. Shit happens

[3] I have no idea where Apple gets its UI engineers from, but someone needs to find the source and start waving huge piles of money to pick them up first.

Now that bug #500000 has been reported, let’s have a look at all our other bugs, using UDD. Number of archived bugs:

select count(*) from archived_bugs;
 count
--------
 402826

Number of unarchived bugs marked done:

select count(*) from bugs where status = 'done';
 count
-------
  8267

Status of unarchived bugs (”pending” doesn’t mean “tagged pending” here):

select status, count(*) from bugs group by status;
    status       count
---------------+-------
 pending         53587
 pending-fixed    1195
 forwarded        6778
 done             8267
 fixed             167

The sum isn’t even close to 500000. That’s because quite a lot of bugs disappeared:

select id from bugs union select id from archived_bugs order by id limit 10;
 id
-----
 563
 660
 710
 725
 740
 773
 775
 783
 817
 819

Now, let’s look at our open bugs.
Oldest open bugs:

select id, package, title, arrival from bugs where status != 'done' order by id limit 10;
  id       package                                         title                                            arrival
------+----------------+----------------------------------------------------------------------------+---------------------
  825   trn              trn warning messages corrupt thread selector display                         1995-04-22 18:33:01
 1555   dselect          dselect per-screen-half focus request                                        1995-10-06 15:48:04
 2297   xterm            xterm: xterm sometimes gets mouse-paste and RETURN keypress in wrong order   1996-02-07 21:33:01
 2298   trn              trn bug with shell escaping                                                  1996-02-07 21:48:01
 3175   xonix            xonix colors bad for colorblind                                              1996-05-31 23:18:04
 3180   linuxdoc-tools   linuxdoc-sgml semantics and formatting problems                              1996-06-02 05:18:03
 3251   acct             accounting file corruption                                                   1996-06-12 17:44:10
 3773   xless            xless default window too thin and won't go away when asked nicely            1996-07-14 00:03:09
 4073   make             make pattern rules delete intermediate files                                 1996-08-08 20:18:01
 4448   dselect          [PERF] dselect performance gripe (disk method doing dpkg -iGROEB)            1996-09-09 03:33:05

Breakdown by severity:

select severity, count(*) from bugs where status != 'done' group by severity;
 severity    count
-----------+-------
 normal      27680
 important    7606
 minor        6921
 wishlist    18898
 critical       29
 grave         209
 serious       384

Top 10 submitters for open bugs:

select submitter, count(*) from bugs where status != 'done' group by submitter order by count desc limit 10;
submitter                        count
----------------------------------------------------+-------
 Dan Jacobson                     1455
 martin f krafft                    667
 Raphael Geissert                    422
 Joey Hess                            392
 Marc Haber                368
 Julien Danjou                         342
 Josh Triplett                    331
 Vincent Lefevre                    296
 jidanni@jidanni.org                                    260
 Justin Pryzby      245

Top bugs reporters ever:

select submitter, count(*) from (select * from bugs union select * from archived_bugs) as all_bugs
group by submitter order by count desc limit 10;
                  submitter                     count
----------------------------------------------+-------
 Martin Michlmayr                4279
 Dan Jacobson               3652
 Daniel Schepler     3045
 Joey Hess                     2836
 Lucas Nussbaum        2701
 Andreas Jochens                   2605
 Matthias Klose            2442
 Christian Perrier           2302
 James Troup                   2198
 Matt Zimmerman                  2027

You want more data? Connect to UDD (from master.d.o or alioth.d.o, more info here), run your own queries, and post them with the results in the comments!

I don't really know why I found myself looking at the gitweb for automake just now, but I noticed that they've finally committed something I've wanted for a bit (but was, of course, too lazy to code myself)[0]

AM_MAINTAINER_MODE was the subject of huge debate when it first came out. It's the bit that can set itself so that the autotools scripts won't get regenerated even if the source files for those have been touched.

The problem is that by default, that's the wrong thing to do. A developer with the source (which I assume anyone with the source is. Otherwise their distro is probably handling all their compilation needs) *wants* those updates to happen automagically. In a distro, however, it's occasionally necessary to patch the autoconf bits, which means that you're trusting the installed autoconf on either the builder or your machine to consistently do the right thing in an automated fashion. And hopefully leave you with a readable debdiff in the end.

I'm hoping that AM_MAINTAINER_MODE([disabled]) becomes a standard thing to do with autoconf-based packages.

[0] http://git.savannah.gnu.org/gitweb/?p=automake.git;a=commit;h=861c19856121d8e875e30268dee6033ded6fc7ae

Just spent a good two^Wthree hours trying to configure awesome 3.0 to match my awesome 2.x setup. Docs are effectively nonexistant. So far, I'm stuck on several fronts:

• I want to be able to left click on a titlebar and drag to resize. Without pressing the modkey. But the definition for that is set deep within awful.lua, which is not a configuration file, and so I cannot see a good way to configure it.
• Why can't I resize an xterm to 80 characters wide? It jumps between 79 and 81.
• Why is it that despite using the same font as with 2.0, enough additional vertical space is used by the title bar and status bar, that I get one less line in all my xterms? It's using only a few pixels more than before, but that's too much..
• How do I configure a textbox so that, if I click on it, a command is run? Update: Figured this one out, for example: mympd:mouse_add(mouse( , 1, function () os.execute("awesome-mpd show &") end)) (Note that if the command isn't run in the background, and opens a window, it will deadlock awesome.)
• Can't figure out how to use awesome-client to add a value to a graph widget. (I'm sure this is simple, but I haven't stumbled over an example. I'd use wicked, but it's not packaged.) Update: Figured it out via the source: mpgraph:plot_data_add("foo", "10")
• Can't figure out how to make a textbox widget have a fixed width and truncate the text in it. Since it's displaying the currently plaging song, using the default dynamic width would make everything on my status bar jump around. Update: mytextbox.width=100
• There's no emptybox widget aymmore, so how do I add horizontal padding between widgets? Best I've managed so far is an empty textbox with a defined width.

Anyone else hate lua, or at least build-your-own-WM-in-lua config files for window managers that used to have simple config files?

I’ve just installed Eran Sandler’s OpenID Delegation Plugin [1]. This means that I can now use my blog URL for OpenID authentication. I’ve also included the plugin in my Wordpress repository (which among other things has the latest version of Wordpress). One thing that I consider to be a bug in Eran’s plugin is the fact that it only adds the OpenID links to the main URL. This means that for example if I write a blog comment and want to refer to one of my own blog posts on the same topic (which is reasonably common - after more than two years of blogging and almost 700 posts I’ve probably written a post that is related to every topic I might want to comment on) then I can’t put the comment in the URL field. The problem here is that URLs in the body of a blog comment generally increase the spam-score (I use this term loosely to refer to a variety of anti-spam measures - I am not aware of anything like SpamAssassin being used on blog comments), and not having OpenID registration also does the same. So it seems that with the current functionality of Eran’s plugin I will potentially suffer in some way any time I want to enter a blog comment that refers to a particular post I wrote. deb http://www.coker.com.au etch wordpress My Wordpress Debian repository is currently available with the above APT repository. While it specifies etch it works with Lenny too (my blog currently runs on Lenny). I will eventually change it to use lenny in the name. For the OpenID server I am currently using the OpenID service provided by Yubico as part of the support for their Yubikey authentication token [2] (of which I will write more at a later date). I think that running their own OpenID server was a great idea, it doesn’t cost much to run such a service and it gives customers an immediate way of using their key. I expect that there are more than a few people who would be prepared to buy a Yubikey for the sole purpose of OpenID authentication and signing in to a blog server (which can also be via OpenID if you want to do it that way). I plan to use my Yubikey for logging in to my blog, but I still have to figure out the best way of doing it. One thing that has been discussed periodically over the years has been the topic of using smart-cards (or some similar devices) for accessing Debian servers and securing access to GPG keys used for Debian work by developers who are traveling. Based on recent events I would hazard a guess that such discussions are happening within the Fedora project and within Red Hat right now (if I worked for Red Hat I would be advocating such things). It seems that when such an idea is adopted a logical extension is to support services that users want such as OpenID at the same time, if nothing else it will make people more prone to use such devices. Disclaimer: Yubico gave me a free Yubikey for the purpose of review. Update: The OpenIDEnabled.com tool to test OpenID is useful when implementing such things [3].

• [1] http://eran.sandler.co.il/downloads/openid-delegate-wp-plugin/


• [2] http://www.yubico.com/


• [3] http://www.openidenabled.com/resources/openid-test/checkup

Share This

Today I committed a little code change to our dak repository, implementing a “Valid-Until” field in the Release files. This should be used by apt in a way to horribly die if it can’t download a new Release file after the date given in that header. (Or well, present a nice message to the user. Whatever, same thing :) ). (This is intentionally not a client-side option, as this way the archives can define a (for them) sensible timeout) Reason: We got Bugreport 499897 today, describing a possible attack wherein an adversary causes the vicitim to use an outdated copy of the security mirror, thereby preventing the victim from getting security updates. See the linked Bug (and the RT ticket linked from there) for more text on this. As apt does the right thing and ignores unknown fields in Release files, I went and added the field already. It would be great if we could have an apt implementing support for this in Lenny. A patch only addressing this change shouldn’t be too long. But as we are near a Release I don’t think thats too likely (feel free to prove me wrong), so I hope for a Lenny point release OR a Security Advisory for it (depending on how much the security team does want this feature). Comments: 0

Thanks to Wolfger for pointing out an HTTP 500 while trying to greet me by comment. :D I totally forgot about upgrading Net::Akismet to the new version that comes with my patch, as described previously. All the while I was thinking Net::Akismet was doing too good of a job keeping out comment spam, when it may as well have kept out all comments :( But its my fault, really. Among other things, Jerome has finally started a new grassroots group for the OLPC effort here in the Philippines, fresh from the success at the recently-concluded SFD. There's now an IRC channel up too, with logs available locally (text-only, until I can set up a web and fileserver frontend.) I'm personally interested on running a port of Inferno and perhaps help out on the TODOs for it.

Ok, my apologies, the Latin is incorrect, but the idea is this: I have run into an important limitation of Google's domain registration system. Buyer beware. Lately, I have been using Google Apps to register domains. At $10 a year for new domains, which come with all the nifty Google applications, email and so on, it's a really good deal. However, there appears to be a potentially crucial problem: you can't sell or transfer the domains, as far as I can tell. I would love to hear that I am wrong on this, but the person helping me through Google's support channel first told me to "enter the new credit card details in the Google Checkout account associated with the domain". Uh, sorry, but I want to transfer the whole thing, lock, stock and barrel. After another round of email, I got this:

To assign a different Google Account to the subscription you'll need to modify your billing information by following the steps listed below:

• Enable automatic renewals for your account.
• When you receive email notification of the impending charge, visit the link to the 'Ordering page.' - Authorize a new purchase for your domain registration renewal. This will replace the old subscription and charge your new billing information on the subscription expiration date. Automatic renewals will also be enabled going forward.

If you don't have automatic renewals enabled, your email notification won't include an 'Ordering page' link to change the Google Checkout account and purchase or renew Google Apps. You must first enable auto-renew to be sent this link.

I don't want to have to wait for the email notification, though! The domain won't be automatically renewed until sometime next spring. Hopefully this is either an oversight on my part or something Google will fix soonish, as buying a domain name that you can't sell or otherwise give to someone else is of very limited use for some things. No, I haven't gone into business as a domain name speculator/squatter, the domain in question is InnsbruckExpats.com, a site I registered for a friend a bit more than a year ago.

I don’t have the expertise to intelligently explain the entire global financial meltdown myself, but here are a few resources that merit wide dissemination, especially if you are a podcast-listener:

• The Planet Money Podcast. NPR’s Adam Davidson hosted one of the most memorable episodes of This American Life on the Giant Pool of Money (complete PDF transcript). He has springboarded that show into a frequent short podcast in these times of peril. He finds a near-perfect balance between accessibility and complexity for a non-specialist but educated audience. It’s also entertaining. Of all major media outfits, NPR is miles ahead on the podcast front.
• Paul Krugman’s blog. Admittedly on the partisan side (”Conscience of a Liberal”), Krugman’s analysis is deep both on politics and economics. Steve drew my attention to this excellent illustration of the flaws with the current approach to bailout:

Just stumbled over this meme at Adrian (the meme seems to be started by madduck involuntarily), and since I’m fascinated by how people choose hostnames since my early years at university, I can’t resist to add my two cents to this meme. To be exact, I have two schemes, one for servers out there somewhere (Hetzner, xencon, etc.) and they’re all wordplays on their domain name noone.org, e.g. symlink.to.noone.org (short name “sym” :-), gateway.to.noone.org (usually an alias for one of the machines below), virtually.noone.org (always a virtual machine, initially UML, soon a Xen DomU), etc. So nothing for a quiz here. My other scheme is for all my machines at home and my mobile machines. I’ll start this list with the not so obvious hostnames, so the earlier you guess the scheme, the better you are (or the better you know me ;-). One more hint in advance: “(*)” means this attribute or fact made me choose the name for the machine and therefore can be used as hint for the scheme. :-)

azam

My first PC at all, a 386 with 25 MHz and MS-DOS. (Got named retroactively(*). Hadn’t hostnames at that time.)

ak (pronounced as letters)

Got it from my brother after he didn’t need it anymore. It initially was identical to azam, but once was upgraded to a 486. Still have the 386 board, though.

azka

My first self-bought computer, a pure SCSI system with a AMD K5-PR133 and 32 MB RAM. Initially had SuSE 4.4 and Windows 95 on. Still my last machine which had a Windows installed! :-)

m35

Same case and same speed as azka. Used it for experimenting(*) with Sid years ago.

azu

Initially also an AMD K5-PR133, later replaced by a Pentium 90 and used as DSL router.

azl

An HP Vectra 386/25N book size mini desktop I saved from the scrapyard at Y_Plentyn before his (first) move to Munich. The cutest(*) 386 I ever saw.

ayce

A 386 with 387 co-processor(*) and solded 8 MB of RAM.

ayca

A 1992 Toshiba T6400C 486 laptop bought at VCFe 5.0.

bijou

My 1996 ThinkPad 760ED, which is still working and running Debian GNU/Linux 5.0 Lenny (I started with Debian 3.0 Woody on it and always dist-upgraded it! :-)

gsa (pronounced as letters)

My long-time desktop after azka. A Pentium II with 400 MHz and 578 MB of RAM at the end. Bought used at LinuxTag 2003, it worked until end of last year when it started to suddenly switch off more and more often and now refuses to boot at all. Hasn’t been replaced yet though. I mostly use my laptops at home since then.

gsx (pronounced as letters)

An AMD K6 with 500 MHz I got from maol and which was used as Symlink test server more than once. (It was the machine initially named symlink.to.noone.org because of that.)

hy

My 32 bit Sparc, a Hamilton Hamstation.

hz (pronounced as letters)

My 64 bit Sparc, an UltraSparc 5.

tub

An HP Apollo 9000 Series 400, model 400t from 1990.

tpv (pronounced as letters, too ;-)

My Zaurus SL-5500G.

tryane

A Unisys Acquanta CP mini desktop with a passively cooled(*) 200 MHz Pemtium MMX. Used as DSL router for while, but the power supply fan was too noisy.

lna (pronounced as letters)

A 233 MHz Alpha

loadrunner

An IBM ThinkPad A31 running Sid. I use it as beside terminal.

pony

A Compaq LTE5100 laptop with a Pentium 90 running Sid.

dagonet

A Sony Vaio laptop which ran Debian GNU/kFreeBSD until it broke.

Those who know me quite good should already have guessed the scheme, even if they can’t assign all the names. For all others, here’s one name which doesn’t exactly fit into the scheme, but still is related in someway, but you need to knowledge of the theme’s subject to know the relation:

colani

A big tower from the early 90s designed by Colani.

Ok, and now the more obvious hostnames:

rosalie

A very compact Toshiba T1000LE 8086 laptop running ELKS and FreeDOS.

amisuper

Also an old Symlink test server from maol. He named it “dual”. 2x(*) Pentium I with 166 MHz. Unfortunately doesn’t boot anymore.

visa

An IBM NetVista workstation running Debian GNU/kFreeBSD. My current IRC host.

nemo

My ASUS EeePC running Debian 5.0 Lenny.

pluriel

My current WLAN router running FreeWRT.

c1

My MicroClient JrSX, an embedded 486SX compatible machine with 300 Mhz for VESA mountings.

c2

My MicroClient Jr, an embedded Pentium MMX compatible machine with 200 Mhz for VESA mountings.

c-crosser

My Lenovo ThinkPad T61 running Debian 5.0 Lenny.

c-cactus and c-metisse

The KVM based virtual(*) machines on c-crosser running Sid and Debian GNU/kFreeBSD.

jumper

My NAS(*) at home, currently a TheCus N4100. Soon to be replaced by some Mini-ITX box.

Any one who hasn’t guessed the scheme yet? For those understanding German it’s explained at the end of my old hardware page. For all others I suggest either to look at the domain name in my e-mail address (no, it’s usually not noone.org). Still not clear? Well, feel free to ask me for all the gory details or mark the following white box to see the scheme as well as the explanations for nearly all hostnames hidden in there:

All the machines are named after Citroëns. Old machines after old Citroëns, current hardware after current Citroën models or prototypes. Those names starting with “A” are 2CV derivatives since the 2CV was Citroëns “A” model. “AZ” was the 2CV, AZU and AK were 2CV vans and everything starting with AY (e.g. AYA, AYA2, AYB – but those don’t sound that nice ;-) is Dyane based, but I currently only use Méhara names (AYCA is the normal Méhari, AYCE the 4x4 version). Interestingly not everything starting with AYC is a Méhari: AYCD was the Acadiane, the Dyane van. HY and HZ are variants of Citroëns “H van” (HX, HW and H1600 as well, but they don’t sound that nice), TUB was the pre-WWII “H van” prototype and later the nickname of the “H van” in France. TPV was the name of the pre-WWII 2CV prototype and an abbreviation for Toute Petite Voiture (French for “Very Small Car”), hence the Zaurus, my smallest Linux box, got that name. Rosalie was the nickname of a rear-wheel drive pre-WWII Citroën. M35 was a Wankel engine prototype of the Ami 8 and the Ami Super was the 4 cylinder version of the Ami 8. Bijou was a 2CV based coupé build by Citroën UK in the late 50s and early 60s. Visa and LNA were 2CV predecessors which were available with 2CV engines, but were stopped before the 2CV. GSA and GSX are GS late derivatives. C1, C2, (C3) Pluriel, C-Crosser, Jumper and Nemo are current Citroën models and C-Cactus and C-Métisse are recent Citroën prototypes and show cars. The 2CV Dagonet was an aerodynamically optimised 2CVs by Jean Dagonet in the 50s. The Tryane is an aerodynamic and fuel efficient, three wheeled car by Friend Wood based on the 2CV and with a body of wood. And Colani once dressed a 2CV so that it broke several efficiency world records. The Namco Pony was a 2CV based light utility truck (similar to the Méhari, but with steel body) built in Greece under license in many variants. And Loadrunner is the name of some CX six-wheeler conversions.

Some links about the naming items:

• Tryane II
• An original Loadrunner and a just recently built Loadrunner. I even saw the base of exactly that one in RL shortly before it was converted into a Loadrunner.
• Luigi Colani
• Dagonet
• Namco Pony
• C1, C2, C-Crosser, C-Cactus, C-Métisse, Pluriel, Nemo, Visa, LNA, GSA, Ami Super, Rosalie
• AZAM, AZL, AZKA, AZU, AK, AYCD, Bijou, TPV
• HY, HZ, TUB.

Hope you had fun. I had. ;-)

Now playing: Willi Astor — Gwand Anham Ära

For the impatient reader: New lintian in experimental, please test and give feedback. You will miss most changes though unless you read the rest of the post (Hint, Hint ;)) During the past week I've uploaded new lintian versions to experimental which we designated to be release candidates for 2.0.0. Code-wise the changes are not that much more intrusive than for many of our past releases, but they change the way lintian classifies tags in a fundamental way, thanks due to the hard work of Jord Polo in his Google Summer of Code project (mentored by Marc Brockschmidt). Lintian Tag Classification, old and new Previously lintian classified tags only in one dimension, in the categories "Info", "Warning", and "Error". While this worked reasonably well, the difference between the categories was not very well defined. The general idea was that everything violating a "must" in Debian Policy or endangering the building or usage of the package should be an "Error", i.e. something very similar to the definition of RC bugs (except that not all "must"s in Policy are deemed worthy of filing RC bugs). Some errors were downgraded to "Warning" or even "Info" though on the basis that their detection was too prone to false positives. Due to this it was a long existing desire to split the classification of tags into two dimensions, one for the impact/importance of the tag, and one for the certainty of its correct detection. This should make it easier for people to interpret and/or filter the output. At various points in the last few years people began to work on this but quickly gave up, usually overwhelmed by the sheer number of tags (728 in 2.0.0~rc2) to classify anew and to make sure that the old and new categorisation could exist side-by-side (because breaking backwards compatibility was not really feasible). Finally this year Jord Polo decided to tackle this task as a Google Summer of Code project, with great success. Tags are now classified in two dimensions "Severity" (with the possible values wishlist, minor, normal, important, serious, which are intentionally very close to the available severities in the Debian bug tracking system), and "Certainty" (possible values: wild-guess, possible, certain). A third classification by "Source" (i.e. Policy, Developers Reference, ...) is planned but not yet fully implemented. For backwards compatibility there is a mapping of these new classification to the old ones (which lead to a few reclassifications of tags). The default output of lintian is unchanged. The new output formats that support the classification are still experimental (see below). How to use it You can specify exactly which levels of Severity and Certainty you want to have displayed with the new --display-level (-L) option. Please see the manual page for the details, but to give you an idea, the default behaviour (i.e. "show warnings and errors" in the "old" vocabulary) is equivalent to specifying

-L ">=important" -L "+>=normal/possible" -L +minor/certain

And to get a report with only severe tags we're very certain of, you could use

-L ">=important/certain"

which will only display tags that have severity "important" or "serious" and a certainty of certain. There is also the (intentionally undocumented) option --exp-output which allows you to play with some experiments we're doing with the output format. --exp-output format=letterqualifier will give you an output very similar to the "classic" one, but with additional information about severity and certainty. --exp-output format=colons gives you a colon-separated format which includes all the possible information lintian currently has available during tag output and which should be easily machine-consumable. Note that these formats are experimental and might be changed at any point without notice. If you're interested in using alternative formats for lintian output, please join the mailing list and talk to us about it. Etc. Other changes include the usual share of bug fixes and of course: New tags

• description-contains-dh-make-perl-template
• doc-base-uses-applications-section (actually a split of doc-base-unknown-section in two tags)
• embedded-pear-module
• embedded-php-library
• improbable-bug-number-in-closes
• maintainer-also-in-uploaders
• maintainer-script-ignores-errors
• manpage-has-errors-from-pod2man
• ored-build-depends-on-obsolete-package (actually a split of build-depends-on-obsolete-package in two tags)
• package-superseded-by-perl
• versioned-dependency-satisfied-by-perl
• windows-devel-file-in-package

Credits This lintian release is brought to you by (sorted by number of changesets):

• Jord Polo
• Frank Lichtenheld
• Adam D. Barratt
• Raphael Geissert
• Russ Allbery
• Niko Tyni
• Marc 'HE' Brockschmidt

Since I was watching Don Armstrong’s talk about Debbugs’ SOAP interface I wanted to use devscripts' bts to get a list of boinc’s top five bug reporter. Finally, this is possible with devscripts (>= 2.10.36):

bts status file:-  bts select source:boinc archive:both  \
    egrep "^originator"   cut -f2-   sort   uniq -ci   sort -n \
    tail -n5
 2 Riccardo Stagni <unriccio@email.it>
 3 Martin Michlmayr <tbm@cyrius.com>
 6 Robert Millan <rmh@aybabtu.com>
 6 Thibaut VARENE <varenet@debian.org>
10 Sandro Tosi <matrixhasu@gmail.com>

Sweet - Thanks Debbugs and Devscripts maintainers!
And congratulations Sandro (or thank you - whatever you find appropriate)!

went to a concert (thanks to my flat-mate david). rebekka bakken. great voice. highly recommended.

& when I came home the new issue of profil was already lying in front of the door.

Leaving Doc Watson early, I headed up State St. in a hurry, taking the sidewalk to avoid the crowd in the road. But I had to stop to listen to a few classics from a five-piece string band, sitting under the awning of Uncle Sam's Loan Office, in front of the display of old stereos and swords. Bunch of real old-timers. Pulled myself away only to pass by an even better, six-piece band in the entrance to The Gold Man pawn shop. The fiddle was played by a girl who couldn't be older than ten. I wanted to listen to them some more, but I managed to pull myself away in time to get into the Paramount and get a good seat for the Red Stick Ramblers. Conclusion: This town needs more pawn shops. And it's Rhythm and Roots time in Bristol. Best bands so far: Mike Marshall's trio, Cephas and Wiggins, Larry Keel and Natural Bridge, Chatham County Line.

The other night I was relishing in the irony that during the era when the American government became most regulation averse, fully touting and embracing the idea of free markets, it also had to save a core sector of our market, leading effectively to a partially nationalized financial sector. I was going to write about the irony made visible by our current financial crisis but Karl beat me to it and said it better than I could or did. Most papers have not mulled over this irony but here is one place where it was raised

This is the highest bug number as of now. Will we turn bug #500000 this week-end? This is fairly unlikely. So, the best chances to win the bet are for Rene Mayorga. If I'm wrong and #500000 is reached before Sunday 23:59 UTC, then Fabian Fagerholm wins the bet. Suspense... Fabian, I *will* watch your own bug reports! MBF forbidden for you...:-)

From blizzard’s blog 1. Take a picture of yourself right now.
2. Don t change your clothes, don t fix your hair just take a picture.
3. Post that picture with NO editing.
4. Post these instructions with your picture.