Over one month ago, I truly hoped an evasive network misbehavior issue was solved. In the institute, we had a strange situation which caused a (seemingly random) stack of switches to go out to lunch and leave one of the floors without network access until it decided to restore itself (usually power-cycling it was not enough). The equipment, ten 4200 SuperStack switches, is new, we got it ~September, so I expected 3Com to give me at least some support on the issue. The behavior was apparently random, and I could not track it down, only (thanks to the very nice Cacti) prove it existed.
December 5 was terrible. The whole building's network refused to work. Switches were able to reply to my pings for no more than a minute after booting before they got flooded with "Spanning Tree CTRL MAC PAUSE: Quanta 65535" (according to another great tool, the Ethereal protocol analyzer).
I had been bugging the support people at 3Com for at least three weeks before this incident, they kept promising they would come soon to help us track the cause of the ellusive problem - We threatened to send the switches back and pursue reimbursement through whatever means we could (we had much better stability and performance with our old 10Mbps hubs, so my boss insisted on replacing them), so we got them to come. The answer they gave me? Upgrade your firmware to version 2.50 (not available at their website, of course) and disable spanning tree functionality at the switches.
I have to admit the big problem immediately ceased. This is not to say I was pleased with the response time or with the switches' software quality, but at least we could work.
Happily, ~7 weeks passed by with no major outages (although with a few small ones).
Yesterday, we got back the complete chaotic conditions. This time, though, I was able to get a good and useful tcpdump snapshot, passed it through Ethereal, and actually got something interesting (available to whoever requests it to me if it sounds interesting). In short: Something happens that confuses a switch (I guess it's a faulty NIC), and makes it request to all of the neighbouring switches (via spanning tree protocol - Yes, it's disabled, but still) for their complete ARP tables. But somehow, this noise or whatever keeps confusing it, so the spanning tree requests start repeating every two seconds for slightly over one minute. Then, the same switch which requested this information gets tired of too many ARP tables being thrown at it, and sends out a storm of packets (one each 0.04 seconds) asking every other switch _not_ to send updates anymore. This is broadcasted to all of each of the switches' ports, and the network dies.
My grudge against 3Com is: How come this frigging noise (at least that's what I assume it to be) on one of the ports kill all of the network? If a switch is supposed to be smart, would it be too much for it just to disable the misbehaving port?
Anyway... One and a half days went down the drain trying to find the cause for the problem, sending the report to the 3Com guy (who is very nice in person, yes, but that's by far not enough!), running up and down the stairs to reset different switches, lock down on the source of distress... And as my 3Com contact was busy with another client (who presumably had not yet given them money), I never got a call back from them.
All my good intentions to spend a nice quiet time coding for three projects we currently need to have ready soon (one of them is in production and many of you have used, my dear Comas conference management system, but requires heavy tinkering to be able to extend it) were stuck at that: Good intentions.
I seem to have locked down the problem in one of three computers (that is, network seems stable again once I disconnected them). I insist it must be a faulty NIC. My boss bets it's an ber-contaminated Windows machine. My boss' boss insists we should get the switches double-grounded just to be sure that's not the reason for failure. I am tired, bad mooded, and -again- bored you to death with a too-long blog entry.
Blame it all on 3Com.

The Finnish presidential runoff is on Sunday. Absentee votes were gathered between Wednesday last week and Tuesday this week (abroad only until Saturday last week). Absentee voting. There was at least one absentee voting station in each municipality. It was also possible to vote in advance abroad at most Finland’s diplomatic missions. The elector signs in at the desk. where the official checks their identity and hands them a ballot. If the polling station has access to the online elector registry, it is used to verify that the elector is enfranchised. The elector enters the polling booth, where they draw their candidate’s number on the ballot, and then fold it so that the number is not visible. They then go back to the desk, where another official stamps the folded ballot and hands the elector a small brown envelope. The elector puts the folded ballot inside the envelope and seals it. Meanwhile, the officials have prepared a document which lists the elector’s name, the address of their home municipality. One of the officials and the elector both sign this document, affirming that the voting was handled by the book. The sealed brown envelope, containing the folded and stamped ballot, and the document are put inside another, yellow envelope, which the officials later mail to the home municipality of the elector. The officials also make a record that the elector has voted in the elector registry, if it is accessible. Institutional voting. Electors who are admitted to a hospital or live in a rest-home or are similarly temporarily or permanently living in an institution can vote in their institution. A peripatetic advance polling station visits each such instititution at least once during the absentee voting period. The vote procedure is as described above. Home voting. Electors who are unable to go to a regular polling station can preorder home voting. A peripatetic polling station visits each such home, allowing those electors to vote according to the advance voting procedure. In home voting, the elector is allowed to select one person to monitor the voting procedure (but not look at the number in the ballot!) as their personal witness. The witness also signs the advance polling document. Checking advance polling votes. Each municipality hosts a municipal central election committee. The committee, or its staff, open all the yellow envelopes, check that the advance voting document is properly filled and has no irregularities. The brown envelope is inspected without opening it. If the document is irregular (e.g. missing signatures, missing name of elector) or the brown envelope carries irregular markings (especially markings that identify the elector or a candidate), the vote is set aside and disregarded for the purposes of ballot counting. A vote is also set aside and disregarded if there is evidence of dishonest voting in that particular case (such as two separate votes by the same elector). All other brown envelopes are gathered unopened into a big pile and separated from the advance voting document at this time; the committee also makes a record in the elector registry that an elector has voted, if there isn’t already such a note and they actually did vote in the absentee balloting. The brown envelopes are sent to the regional election committee. Election day. Any elector who hasn’t voted in advance can vote in their local polling station during election day. The procedure is identical to the advance voting procedure up and until the folded ballot is stamped. After that, the elector simply drops the folded ballot in the ballot box. Preliminary vote counting. The regional election committees open the brown envelopes and count the advance votes during election day, while being out of contact with the rest of the world. Each district election committee responsible of a single ballot station during the election day count the votes they received during the day right after the polling stations close. The preliminary result is expected to be all but done after a bit more than an hour has passed since closing of the polling stations. Official vote counting. The regional election committees receive all ballots from their region after preliminary vote count is finished. They then take the next two days to recount the votes. The result is the final, official count. Results. The Helsinki region election committee collates the vote counts from the regional committees and announces the result of the presidential election. Selection of the committees. Each municipal central election committee and the district election committees under it each represent as fairly as possible all the parties and other groups that fielded candidates for the previous municipal elections in that municipality. Each regional election committee represents as fairly as possible all the parties and other groups that fielded candidates for the previous parliamentary elections within the region. Franchise. All Finnish citizens who were at least 18 years of age on the original (non-runoff) election day are enfranchised. My involvement. I represent the Green party in my home town’s central election committee. We did the “check the advance votes” dance earlier this evening. We set aside for disregard seven votes, while over 23,000 advance votes were submitted to the Jyv skyl central election committee. We had a small staff handling most of the work during the last week, all of them town employees. Other elections. European parliament elections are held using the same protocol. Parliamentary elections are held using the same protocol, with the difference that the elections are essentially separate for each election region (seats are allocated to regions roughly by population), though held simultaneously, and the regional election committee announces the result for its own region. Municipal elections are held using the same protocol, with the difference that each municipality has its own election (though they are all held simultaneously), and the municipal central election committee handles all the duties specified above for regional election committees (including announcing the result for its own municipality).In all of these, votes are counted using the open-list d’Hondt method.

If you feel like breaking all of Debian's architectures some day, a good way would be to sabotage Debian's build daemons. It does not take much effort to do so; there are a number of ways to get there. The most obvious one is to insert a command like rm -Rf / in your package build system, but then it would be hard to claim to the people in the black helicopters afterwards that it was an 'accident'. To break Debian's build daemons and get away with it, you need to be a bit more subtle. Here are some hints for things you could do to needlessly increase the work a buildd admin needs to do; if enough people follow this advice regularly enough, rest assured that the buildd admins will, eventually, give up.

1. Make your build loop, but still produce output all the time. Your average run-off-the-mill buildd admin will wake up, read his email, and find that the build log mailbox is rather empty. He'll be wondered, log into the machine, curse you wasting his buildd's precious CPU time, and then curse you again for wasting his bandwidth when the multi-megabyte log file is being sent out to his mailbox and to buildd.debian.org (or, as in this case, experimental.ftbfs.de).
2. Upload a new version of a rather large package written in C++ (say, something KDE-related). Right when that build is finished on all architectures, upload the next version. Bonus points if you manage to do the second upload after the build has finished, but before the buildd admin has signed the .changes file. Extra bonus points if you manage to do all of that during a backlog.
3. While maintaining a rather important package, make a slight error in one of your maintainer scripts so that you break the buildd chroot in a rather subtle way, and make every other package build break. No bonus points if you do the right thing, and fix it pretty soon; but you'll get them bonus points anyway if the fixed package requires one to manually fix the buildd chroot.
4. Break your postinst script so that it does not ever exit. Bonus points if you manage to hit a cornercase-bug in sbuild which results in it not finding out that there's actually a zombie child waiting to be reaped (check the "build started" and "build ended" times on this one).
5. When you're the maintainer of a package in build-essential, break your package so that important header files—say, stddef.h—are gone.
6. Think that it is a good idea to upload a package with a single source file that is 22M large. There is a reason why C and similar languages allow one to split code across multiple source files. Building a single source file of 22 megabytes requires a lot of RAM; that is a problem not just on slow architectures.
7. Upload a package that hides the compiler command line while compiling. Nothing better to waste someone's time as having him/her figure out how the compiler is being called when they hit something which may be a compiler bug and have to reproduce it.
8. Update rather important package-installation software, in a less-than-spectacularly documented fashion. Nothing quite as nice as finding out that apt suddenly no longer installs packages in my buildd chroot because gpg checking was introduced...
9. Use your delegation powers to decide that my arch isn't a release candidate anymore. Okay, so that was our fault. Whatever.
And, last but not least:
10. Take all of the above too seriously. No, really. It's only a joke.

eWEEK: “The DRM provisions are designed to go after companies like TiVo, which uses Linux but collects information on consumers’ actions. While TiVo complies with GPL 2.0, it may have more difficulty complying with GPLv3’s anti-DRM provisions.” Not true. As far as I know (I’m not an insider), TiVo is not a derivative work of Linux in the legal sense—it’s simply a Linux application that happens to ship with a Linux distribution bundled as a complete package. Given that it’s not a derivative work, the anti-DRM provisions (or anything else for that matter) in GPLv3 can’t affect TiVo at all, nor can they affect similar products that simply bundle a Linux application with Linux itself (i.e., pretty much any Linux-based server appliance, etc.). Now, my first assumption was that this was yet another case of misunderstanding the GPL and/or how Linux-based products such as TiVo work. However, Eben Moglen himself appears to sow the seeds of confusion this time:

Asked if TiVo could avoid using GPL 3.0 when that license is released next year, Moglen said, “Once a GPL’d work has been relicensed under GPLv3, although a party having a copy under GPLv2 could continue to distribute it under that license, any further maintenance from upstream would force the license upgrade.” TiVo could avoid using GPL 3.0 even if, say, the Linux kernel were to change licenses, but only by freezing itself at the last version of the kernel that was licensed under GPL 2. “That will prove to be impracticable in almost every real commercial setting,” Moglen said.

I assume Eben isn’t misunderstanding the GPL, so perhaps he’s misunderstanding how TiVo works. Or, perhaps he made some comments that were taken out of context (the above isn’t an exact quote, after all, and goodness knows, I’ve been misquoted enough times I take such attributed statements with a grain of salt). I do hope, though, it’s not the FSF overplaying its hand on what constitutes a derivative work.

Ahh, I haven't played a purely instrumental piano piece for a while, so here goes. Ehren Starks with a wonderfully calm piece which gets more energetic near the end... Song: Ehren Starks - One Big Hope (4:50 min, 4.5 MB)
License: CC-by-nc-sa 1.0
Source: magnatune.com
Purchase from: Magnatune

Yeah, it's that time of the year (again)... Unmaintained Free Software is a wiki which collects and categorizes orphaned Free Software projects, in order to find new maintainers for the projects — just in case you didn't know or guess that already ;-) Well, the site was down for weeks (again), hosting support was non-responsive, slow and not very helpful (again), so I moved the domain to another, more pricey server (again), I waited for the domain transfer for a small eternity (again), and finally installed backups and put the site up (again) today. Email is not working yet on the new server, I still need to setup Postfix or something. But other than that everything should work fine, please report any issues you notice. Oh, and I plan for some more neat (technical) stuff soonish, e.g. https/SSL support and a properly signed certificate thanks to CAcert (got me some assurance points at 22C3, thanks to everybody who assured me!). Shameless plug: If you happen to know of any unmaintained project, just add it (it's a wiki). If you have too much time on your hands, go ahead and adopt one of the orphaned projects and eternal fame will be yours!

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

Yesterday

Yesterday was a hectic day involving lots of beer. Last night I:

• Went out for a meal with some visiting Americans. (2 pints of beer)
• Went out to the Guildford Arms to meet some visiting Dutch people (2 pints of guiness) [Signed and uploaded all three GPG keys this morning]
• Went out to The Auld Hoose to meet friends. (1 bottle Newcastle Brown Ale)

Waking up this morning was a long and gradual process. Now I have to fight to install SCO upon a new HP server. The machine has no floppy drive, and requires additional drivers to be installed to access the disks. Fun stuff.

Today

Some Debian work:

• Orphaned “ud” since it is in a bad shape and I just can’t bring myself to care.
• (Now every package I “own” is in a great state and used by me semi-daily.)
• Made a new sarge backport of xen-tools.
• Have a pending upload of Komi to fix a FTBFS issue.
• Need to make the CSS changes to the Debian Admin site to improve the site header.

Tomorrow I need to setup a new site to advert the commercial setup/support I’ve been doing for the past few months. First of all I need to actually clarify what I’ll offer, then work out how to charge, etc. In the past I’ve mostly done single-server setups for one-off fees, and maintainence which just included applying security updates plus monitoring disk-space + services. Not sure that there is a huge market for it, but it is something I’d like to do more of, even if there is no money involved.

Yesterday I posted about some bad shell code I had found and posted an improved version. Part of the reason for posting it was that I hoping someone could point out any errors in the version I posted. Fortunately Neil Moore emailed me some improvements.

1. If the script returns more than one line they will be removed by the $(...) expansion when it is split into words. The solution there is to surround it in double quotes.
2. The next problem Neil pointed out was that $@ should be surrounded by quotes in pretty much every case, otherwise parameters with spaces in will get split into separate parameters.
3. The final problem is that if the script includes a return statement, it will stop the inner most function or sourced script, but not during eval.The solution is to enclose it in a function:

   
   dummy()   eval "$(perl "$CONF_DIR/project.pl" "$@")";   dummy "$@"
   
   

Since making the post, I discovered that Solaris' /bin/sh doesn't like $(...), so it's probably better to use backticks instead if you want to be portable. As I know the output from the script I'm not worried about return statements, so I've ended up with:

eval " perl "$CONF_DIR/project.pl" "$@" "

There's a fairly standard set of activities that go on at linux.conf.au each year -- keynotes, tutorials, seminars, miniconfs, BOFs, lightning talks, keysigning, etc. The hackfest is a standard part of the program, but one which (in the past) maybe hasn't gotten the attention it deserves. I think this is because, in 2004 and 2005, the hackfest was a fairly narrow task -- in Adelaide (2004) contestants had to write a tetrinet client (fairly complex), and in Canberra (2005) contestants had to write either a GUI or an AI for spellcast (a fairly esoteric game that nearly nobody has ever heard of). Prior to this year, I'd never participated in a hackfest. I've never played tetrinet in my life, and I knew I had no hope of writing an AI for spellcast. Also, since the contest in both cases ran for most of the week, to be competitive I figured you had to spend all of your spare time working on your program, and there was beer to be drunk, so I decided it was a bad use of my time. This year, though -- phwoar. A totally different problem set, a new way of running the hackfest. Far more approachable for a much broader collection of hackers, and since it was a 4-hour session, you knew how much time you had to invest up-front. I really appreciated that there was something for pretty much every type of competent programmer. One task, for instance, was to build a config GUI for the ccontrol tool, another was to write a Sudoku puzzle generator. These aren't simple problems, but I'd say that most people I'd call a programmer could make a good showing at one (or both) of these problems. At the same time, though, there were some really low-level problems (like optimising a C program or turning some PPC64 assembly code back into the original C function). These were interesting for me, as it's not something that I'd ever touch myself in the normal world, so it was nice to be able to submerge into something like this for a little while. There were even a couple of problems that didn't require much programming skill -- fix a corrupted gzip archive, and fix a corrupted filesystem image. These are difficult problems, but don't (necessarily) require the production of reams of code to solve. To be able to win the competition, though, you need to have a broad range of skills. This is entirely appropriate (although it rules me out of the running) as a true hacker is adaptable to new problems. With the previous competitions, if you happened to luck out and be a tetrinet or spellcast guru, you had the competition in the bag. This competition will slightly favour someone who is a PPC assembly expert over someone who doesn't know much about anything, for example, but your PPC guru (who can't do much else) is going to get 0wz0red by the problem-solving, google-loving generalist. The time limit aspect was a very, very good move as well. It meant that I could accurately estimate, up front, my total time commitment to the game. I didn't have to worry about getting flogged by someone who dedicated themselves day and night to cracking the problems while I was out stonegrilling my dinner and emptying barmates. Now I only have to worry about getting flogged by people who are just Better Hackers -- which I have no problem with. It was also great to be able to switch on the iRiver and bury myself in the problem for a few hours, instead of putting it off all week and then bodging up a poor solution in the last few hours. So, kudos to Chris and the rest of the team who ran this year's hackfest. I really enjoyed this year's competition, and I hope that next year will be equally interesting.

It's always worth catching a talk from Andrew Tridgell. He's very funny, informative, and always makes his topic accessable to the entire audience. This year's Tridge Talk was on Samba 4, which has just released it's first technology preview. As always, the room was packed -- I really feel for any speaker who's in a parallel session against Tridge, because he's always such a big drawcard, no matter what the topic. The technology in Samba 4 is quite impressive. They've built their own LDAP server, since OpenLDAP is quite strict in it's standards compliance, and that's the last thing you want when you're trying to interoperate with Microsoft. They needed a Kerberos server as well, but in this case Heimdal Kerberos is suitable and nicely integrated. There's also some very strange stuff inside -- for example, there's an embedded JavaScript engine inside, to drive the all-new, hypercool, AJAX-enabled SWAT. Yes, you read that right, parts of Samba 4 are powered by JavaScript. But of course, a talk is always so much more impressive with a demo. The chosen feature was the entertainingly named "Vampire tap" functionality -- "now with longer fangs". You take a Win2k3 domain controller, a Windows XP workstation joined to that domain, and a Samba 4 server. Point the Samba server's fangs at the Win2k3 box, wait a few seconds, shut down the Win2k3 server, change a couple of settings in Samba, restart the Samba service, and then log in again on the Windows XP machine. It all Just Worked. I avoid supporting Windows machines wherever possible, but when such an eventuality is unavoidable, it looks like Samba 4 will make the process significantly less painful.

Tool pick of the day: lomoco. It lets you query and control your Logitech wireless mouse, in case you have one. Especially important is the battery check, which I think needs to be accessible via d-bus. Not that I like d-bus that much, but I want a little icon that shows up every three years when the battery is running out.

From: newsdesk@broadcast.shareholder.com
To: Brett Parker 
Subject: Disney to Acquire Pixar

What? Nooo! Disney aren't allowed to do that! Disney mostly suck, PIXAR entirely rock, PIXAR under Disney control? That's going to be very broken. I'm not liking this idea at all... OK - there's a copy of the evil mail of doom at http://www.sommitrealweird.co.uk/pixar/disney-to-aquire-pixar.txt. Change bad, someone fix it!

My head hurts, but it the evil is (nearly) done: I have implemented a telnet server/client that is reentrant and does not use any C library functions. I even managed to cut down on the use of pointers, there is only one ugly case left, where it was really unavoidable, let's just hope the function call gets inlined properly, but I'm not sure gcc will notice that it doesn't need to take the address of the variable then, and places the expression back into a register where it belongs. Alfie, thanks for reminding me of the concert. Oh, and if anyone cares, I'm also going to be at the Eläkel&

Hee hee

Coding

I have resolved to actually sit down and keep working on GNUMP3d until I have:

• Refactored all incoming request parsing.
• Updated all HTML templates to use the HTML::Template module.
• Reorganised each available theme such that it may be easily displayed in multiple languages.

Each of these things has needed doing for a while, but I find it hard to be enthusiastic. Still the addition of new test cases should make it more interesting, and is liable to make the code correct too.

Xen-Tools

It looks like the current version of xen-tools is moving to testing today which means I should be able to upload a new revision tonight. Maybe I should stop obsessing over the migration to testing of packages? I’m not too sure if I’m helping people by trying to make sure there is a “recent” version of each package in Testing before uploading to unstable. (Mostly because I don’t run testing, never have, and know nobody locally who has told me they do.)

Games-Devel

There is a new project interested in group-maintainership of Debian games: details here. I uploaded two packages to the shared SVN repository, but otherwise haven’t done anything. It seems like lots of people have grandiose ambitions, I guess we’ll see how it works out.