A politician named Ron Paul is running for the Republican party nomination for president. Tech Crunch has an article about his Web 2.0 based campaign which also includes a link to a google interview with him. Here’s the good things about him:

• He strongly defends the constitution and the rule of law, so he’s not a totally bad guy (unlike many of the current politicians who believe that the US president should be able to do whatever he wishes).

He wants to refrain from “helping” other countries with their “defense” - such help from the US has caused most of the wars and terrorism around the world since WW2.

He wants to reduce military spending to 1/3 current levels (he could reduce it to 1/10 current levels and still be able to prevent a combined attack by Russia and China).

He wants to restore liberty.

He seems to be in support of repealing most drug laws - but his statements weren’t clear.

Here’s the bad:

• He wants to remove income tax and give the smallest possible government - no consumer protection laws among other things.

He thinks that hospitals should be run by churches and have no government funded medical system.

He doesn’t want restrictions on pharmacists who refuse to sell certain drugs (IE the contraceptive pill) - but with no restrictions on who can be a pharmacist such things could be bought without prescription even…

Here’s the ugly:

• He claims that guns on planes might have prevented 9-11.

Still, he’s a lot better than any other Republican who seems to be in the running.

Share This

Like most geeks, I run my own mail server. The burden of administering it is much less than the increased flexibility in filtering incoming mail, let alone dealing with SPAM. My mail server configuration has remained pretty static the entire time, and controversially, I’ve always used qmail. The reason for this dates back to my first sysadmin job in the mid-to-late nineties, and the decision in those days did tend to be sendmail or qmail; with the security conscious choosing the latter. qmail’s delivery system is a little odd, everything on the left hand side up to the first “-” is considered a user, and everything after can be used for filtering. The default local delivery component takes this into account, so e-mail to scott-foo can be filtered by the /home/scott/.qmail-foo file. This gives a pretty natural way to deal with mailing lists; you subscribe with a unique address for that list, and all the mail goes into the right folder automatically. This has served me reasonably well over the years, with heavy patching across the daemon to add features such as LDAP integration, and SPAM filtering that I wanted. Unfortunately it’s been getting to burdensome to maintain. Since it’s not true open source software, and is effectively abandoned upstream, it’s not as up to date as I’d like. SPAM filtering tends to take place in the local delivery loop, rather than at SMTP time; and due to the strange delivery system, it’s unreasonably hard to perform any kind of sender verification or greylisting. Since every special address is filtered differently, it’s quite hard to add common filtering unless it’s pre-planned and you use addresses with a common prefix. The clincher has been dealing with super-sites like Launchpad which send huge amounts of different e-mails to a single address, and no facility to separate that from your published contact address. I needed a better mail server. So I’ve now moved to exim. I was surprised by how quickly I was able to pick it up, I did the migration in two day outages. The first to simply migrate delivery and stash the mail in one big folder, and the second to customise the delivery and filtering to my liking. I’ve also re-subscribed to mailing lists with single addresses again, so now I have a single filter rule which happily can filter Launchpad mails around as well. Happily I’ve been able to make a change I’ve wanted to for a while, home and work e-mail is separated into different Maildir/ trees; and mailing list subscriptions made with the most appropriate address. The magic of dovecot lets me create a fake scott+canonical user that uses the alternate Maildir tree, while still retaining my user permissions, etc. Overall I’m pleased with the new setup, and how the migration went. SpamAssassin needs some tuning as a little SPAM is still getting through, but otherwise it seems to be working well.

Oggi mi e stato passato il link a questo raccontino di fantascienza catastrofica… E carino, scritto bene, tecnicamente preciso (cosa rara oggigiorno). E anche decisamente intenso, specie in alcuni punti… Mi ha lasciato un po’ sotto shock, devo dire… Se vi va provate a leggerlo! Today I received a link to this catastrophic sci-fi short novel story… It’s nice, well written, and technically precise (which doesn’t happen so often). It’s also a bit shocking at points, and has definitely hit me a bit… Try to read it, if you want! http://baens-universe.com/articles/When_Sysadmins_Ruled_the_Earth

Stefano Zacchiroli blogs his thoughts about collaborative maintenance. He identifies two arguments/religions about it:

1. it is good because duties are shared among co-maintainers
2. it is bad because no one feels responsible for the co-maintained packages

And he says he stand for the first one. I’m not sure that those two positions really contradict. Sure, collaborative maintenance is a good thing, because it allows to share the load between co-maintainers, which often results in bugs being fixed faster. But collaborative maintenance creates the problem of the dilution of responsabilities, and the dilution of knowledge. In many cases, a single maintainer will have a better knowledge of a package than the sum of the knowledge of all co-maintainers. Also, sometimes, teams don’t work very well, and everybody start thinking that a specific bug is another co-maintainer’s problem. In the pkg-ruby-extras team, we have been trying different organizations over the past two years. We have now settled with the following:

• each package has a “main responsible person”, listed in the Maintainer field
• the team address is listed in the Uploaders field, as well as all the team members that are willing to help with that package (people add themselves to Uploaders manually. Another variant is pkg-kde and pkg-gnome’s automatic generation of the Uploaders field based on the last X entries of debian/changelog (pkg-kde variant, pkg-gnome variant).)
  Interestingly, we discovered that for several packages, nobody was really willing to help, so I’m wondering how other teams with (nb of packages) >> (nb of active team members) work.

Stefano also raises the point of infrastructure issues caused by the switch to the team model. I ran into one recently. My “Automated mails to maintainers of packages with serious problems” are currently only sent to the maintainers of the packages with problems, unless someone has problems in both maintained and co-maintained packages (in that case, all problems are mentioned). I thought for a while about sending mails to co-maintainers as well, but that would mean sending more mails… I might try that and see if I get flamed :-)

It seems that I've held up -at least for half a year- what I stated back in January - I come by bike to work almost every day, and really enjoy the time spent on two wheels. My times have -of course- improved, as has my dominion of the bike - I make ~10 minutes each way (must be a bit more on my way to work than on my way back, as it is uphill).
My city's government seems to be seriously promoting people to consider using the bicycle as means for regular transport and not just as a recreational device - I see some of its measures as quite silly, but some are just perfect. One week ago, while I was on the plane from Edinburgh, we had the first Ciclot n, a 32Km ride open to everybody (and of course, Nadezhda was among them). Over 70,000 people took part, reportedly, and it seems it will be held monthly. Besides that, yesterday we had the paseo dominical in Coyoac n very close to my house - What's that? Something similar to the ciclot n, only much smaller (14Km), much less publicized, and in a different place of the city every Sunday. Well, we started up the day at 8 AM by cycling from Metro Copilco to Miguel ngel de Quevedo, Av. Universidad, R o Churubusco, Divisi n del Norte and Henriquez Ure a back to Metro Copilco. We later learnt that around 10,000 people took part. 14 Km, 30 minutes - not bad, and quite enjoyable!
We didn't go for the second round, because we wanted to be by ~10 AM at Reforma, probably the city's most emblematic avenue, to be part of the demonstration marking one year of the electoral fraud. But... Well, we didn't want to just leave the bikes at home and go by metro - What can we do? Yes, take the open streets. We followed a bit of the path we had taken a bit earlier, then took Minerva, Insurgentes until Reforma (~45 minutes). And once we got to the meeting point, we didn't want to step down and crawl the bikes along... So we both found out that not only we dared take the main streets where people are not really used to cyclists and where taxi drivers will often try to make a point that if you don't own a car you should use a taxi and not a bike - We were able to cycle most of our way to Z calo, going slowly and moving through people, in what seemed to be almost an unthinkable feat for me just a couple of months ago. We can now control the bike, we can even be almost still while riding it, and not crash into anybody!
Of course, the way back was similar - We took our bikes across Obrera, Doctores, Algar n and lamos, then took Av. Universidad all the way down to Copilco, and -after some three hours riding, with my arms quite red and of course somewhat dehydrated and sore-butted- got home.
It feels great to have a well-deserved siesta! And... Well, biking is just too enjoyable. I guess we had ~45Km yesterday, plus some ~5 extra zig-zagging through the crowd. It rules.

ikiwiki rules my world! Today I switched debian-community.org and my personal todo list to ikiwiki, and I must say, I'm impressed and happy. Just being able to use svn+vim to edit and organize a wiki or more generally, information, really rocks. Joey, thanks a swarm of fish for ikiwiki!!

On a somewhat, very loosly related note, I've decided to give up on gnome and beryl, and go back to ion2 or maybe 3. Beryl and Gnome are nice and fancy, and it's good to show others that Debian can be beautiful, but a.) it's way slower than using ion as window manager. And b.) I'm now running 2.6.21 and have been using powertop... ;) Maybe I'll come back to a typical desktop UI with Lenny.. :)

And, now you might ask, how is this related? I formerly used Riot as Information Organisation Tool, which is written by the same author as ion. That said, I totally want to run a free fork of ion3 with a proper licence. I *heart* debian stable with custom repositories! :)

On debian amd64, there is /usr/lib64 directory which issymlinked to /usr/lib.It's useful since many upstreamexpect /usr/lib64 to exist, and changing every singleupstream isn't possible.However, there is one problem. Many libraries explicitly specify /usr/lib64, and that goes into libtool .la files and will generate a -rpath of /usr/lib64.libtool will ignore a set of pre-defined paths from -rpath,which is defined as sys_lib_dlsearch_path_spec,which is probably pulled from /etc/ld.so.conf on linuxsystems.The problem is, /usr/lib64 is a symlink to/usr/lib, and it is not included in library search path(although effectively, /usr/lib is included in the searchpath, so libraries in /usr/lib64 is searched).I am suspecting that this results in many -rpath set for/usr/lib64 on amd64 system.I think this is currently solved by running chrpath in debian/rules, but not all ofthem is fixed. Another way to fix it would be to patch libtool to ignore lib64.Hmm..

I am finally catching up with the remarkably thick goulash of email and blogs entries that comes from traveling for well over a month and today I read one in particular When is Open Source not Open Source? that captivated my interest for it compellingly addresses the dangers that follow from diluting, or one might say hijacking, the term open source. When people learn that I study “free software” one of the most common questions I get asked is: why did I chose free software over open source? The answer is quite simple: given that the bread and butter of my research covers ethics, freedom, and liberalism, free software is the obvious path to follow, yet I also feel like a lot of my work is still relevant to the open source camp because of the affinities between the two. I have long maintained that the ideological gulf between open source and free software is not so great nor impassable, but more modest. As most know, both share a certain strong commitment to access and in a strict technical sense they refer to the same set of licenses. Philosophically there is agreement that openness and, especially, non-discrimination are essential for the quality of software and often by close extension, the vibrancy of community responsible for the software. Of course, when pontificating the ramifications and implications of openness, they do part company and enter into different territories. Free software tends to flag rights and freedoms, while open source meanders into a discussion of markets, business, and competition and in this regard they do craft different visions of the social world and human behavior, etc. But the case that Karl Fogel writes about, where OSI is strongly opposing the use of the term open source for licenses that don’t adhere to the definition demonstrates where the two positions join. As Michael Tiemann from the OSI succinctly put it:

The FSF may have got the orthodoxy wrong, and the OSI may have got the interpretation wrong, but we both agree that prohibition of commercial use without special permission is antithetical to both positions.

There is a unmistakable kernel of agreement and it is great to see the OSI taking such a strong stance in this regard. Now, David Richard’s response, who seeks, I think, to essentially dilute the term open source, is as (or perhaps even more) fascinating for in a nut shell, and using a lot of florid religious imagery, it accuses the OSI of being too rigid! In his own words:

I believe the OSI has a wonderful opportunity to continue being relevant and helping to lead the movement forward. If, however, y’all choose to define your denomination of this religion in a way that we don’t fit in, that’s fine. No hard feelings. It’s your choice. You’ll ultimately be excluding a large congregation and we for one will continue trying to build a church made up of others like ourselves.

In response, I would say that the goal of F/OSS is not to be inclusive of anyone who wants to release bits of source code, but to create the conditions under which software, as it has been defined by the community, can be created. Join the church if you would like to make free/open source software as defined and you can go elsewhere (i.e., create a different term) if you are creating something different, even if it is only slightly different. Integrity matters. And again inclusiveness, if it comes at the expense of the main goal, is not a boon but a danger to F/OSS. The OSI will remain relevant by halting the dilution of the term OSI, not by expanding the definition so that it is left with no substance. And in contradistinction to what David Richard maintains, however, there is a great degree of flexibility within this domain but it does not lie in the strict definition of F/OSS but in the realm of interpretation. You are also free, as Mako and I have argued elsewhere to interpret the significance of F/OSS in multiple ways. And I think this is where the political strength of free software lies. There is interplay between a well-defined goal (in this case for creating free software) and a more flexible realm of interpreting the significance of these technical practice. And we wold lose and I might add, a lot if we became flexible about the strict definition of F/OSS and inflexible about its political significance. I get irked with folks like David Richards who would like to bend open source rules to meet their (often commercial) interests and I find it pretty na ve when folks say the political significance of F/OSS is just x (or worse should be x) for in reality its political significance lies in the fact that it has spawned multiple types of political and economic projects. And there is something almost playfully ironic, (or at least it makes me smile) in this fact. Though there is strict definition contained withing F/OSS, this strictness has, at least to some extent, encouraged by an extreme and very healthy form of political proliferation and promiscuity. More than anyone else I know, Mako has most passionately and thoughtfully argued for the importance of what I would call political clarity and integrity. That is, the importance of having a well articulated definition for social movements, for they act, as he says a rallying point to realize a social movement. Urging the Creative Commons to learn from F/OSS and dare to simultaneously narrow and more clearly define their goals, he states it quite nicely in the following terms:

Free software advocates have been able to use the free software definition as the rallying point for a powerful social movement. Free software, like the concept of freedom in any freedom movement, is something that one can demand, something that one can protest for, and something that one can work toward. Working toward these goals, free and open source software movements have created the GNU/Linux operating system and billions of lines of freely available computer code.

In essence, a definition that people can abide by, respect, and perhaps eventually cherish is the condition of possibility to make working political code. And given how hard it is to make social change happen (at least in comparison to build computer code), we should learn from what F/OSS has to offer. And at the same time there is another lesson embedded in F/OSS. The Free Software Definition is well defined; but it must be emphasized, narrowly so. It does not try to do everything and have everyone pledge allegiance to an inordinately complex set of commitments. Clarity, narrowness, and well-defined goals –> these three attributes have powered it far and wide and I hope it remains so. Now, since the term open source is not trademarked, we are left with the problem of how to challenge the current hijacking of the term. For the solution, I will leave you with Karl Fogel, who I think proposes a good solution:

Note that the OSI s objection is not to the Zimbra license per se. The objection is just to Zimbra s calling that license open source . They can use any license they want, but they shouldn t call it open source unless it actually is. Freedom is freedom, and no amount of spin will change that. So what should we do about this? The term open source isn t trademarked. Years ago, the OSI tried to register it, but it was apparently too generic. …But there is public opinion. What Danese and Michael are proposing doing is organizing a lot of open source developers (and I mean open source according to the traditional definition, the one the OSI and I and most other open source developers I know adhere to) to stand up and, basically, say All of us agree on what the definition of open source is, and we reject as non-open source any license that does not comply with the letter and spirit of the Open Source Definition.

Alex Hudson commented:

"Similar comments about another W3C WG: http://ln.hixie.ch/?start=1181118077&order=-1&count=1 W3C should be about authoring material for the web. It seems at the moment, they're more concerned with the stuff that happens after authoring - e.g., how stuff relates in "the semantic web". IMHO we still don't have any powerful tools for authoring either, so the idea that authoring tools will automate many of the "bolt on accessibility" tasks is pretty naive."

After implementing pingback, I have some respect for hixie. It's disappointing but not surprising to read those comments. Not sure what is meant by powerful authoring tools there. My tools are powerful, but I know they're not easy for new users. As I'm getting old and cynical, I'm not sure whether power tools can ever be correct and truly easy - just look at the pigswill spewing out of some Web 2.0 sites. niq sent me a link to the WCAG Samurai Errata and commented:

"The problem with WCAG 2, as with WCAG 1, is precisely that it's a Work of Committee, and seeks to represent too many irreconcilable viewpoints and egos. In some cases, even the ideas behind it are inconsistent. Many (myself included) regard accessibility as being about ensuring a reader with a physical disability can make use of a site (think Steven Hawking). That's also what HTML is designed to support. Others are concerned with the mentally impaired, also a worthy cause, but one that becomes counterproductive when its advocates fail to distinguish between a site that's inherently inaccessible because it presents a complex and challenging subject, and one that's unnecessarily difficult due to poor presentation. Add the two together, blend in some stupidity, and you get "accessible" sites full of classic "friendly" little illustrations like a "helpful" government booklet, and a horribly intrusive "alt" to explain each pointless "ethnic mummy and child" picture."

I think a Work of Committee could be useful, as long as you have the right committee. Thinking about that, I found the group membership list and I'm not sure that's the right committee. For example, I think the ex-Adobe Google-worker must surely have an irreconcilable conflict of interest (inappropriate use of Adobe's Flash and PDF formats and Google's Web Apps have done more than many to harm accessibility in the past IMO), yet is a leading light of WCAG 2.0 - maybe that's why it's gone so dark? Update: Thijs Kinkhorst comments:

"As I read in the draft, suggestions are still possible until the 29th, not the 27th of June."

I'm sure that's different to the email which started me writing this, but please go comment and see if we can make WCAG-2.0 useful.

A few months ago, the Washington Post featured an article about Joshua Bell playing his violin (which happens to be a Stradivarius) in a Washington metro station. Contrary to their expectations, nobody stopped by to listen. The article tries to find reasons for why this happened, digging into theories by a number of famous philosophers. While those are undoubtedly not far from the truth, let me dig up another theory: Joshua Bell may be one of the best musicians in the world; that doesn't mean he's one of the best street musicians in the world. You see, if you play your Stradivarius in a concert hall, you don't have to do much to get people's attention. If your name is Joshua Bell and you play in the New York Opera House, people pay good money to get a seat months in advance, they circle the date on their calendar, and they look forward to it for weeks. When the big day arrives, they dress up, they drive up to the opera house, they queue for the privilege of being allowed to show their tickets and being allowed in, they take their seats, and they wait in excitement and anticipation until the big moment arrives. If your name is Joshua Bell and you play your Stradivarius in a concert hall, people will clap their hands you before you've even started. You'd better make it be good, or they'll demand their money back. If, however, you play on the street, then that's a completely different matter. You don't get to have people circle the date of your street concert months in advance. You have exactly one second to let them know you're playing. You don't get to have an audience that will clap their hands the very moment they see you turn the corner; instead, you'll see an audience that would rather you did not stand in the middle of the way like that, so that they would not have to look out for you. In short, you don't get their attention on a silver platter; instead, you have to earn it. As someone who's done street music in the past, I can tell you that earning someone's attention isn't something you will do by playing the most difficult music that can be found. You should remember that you've got just a few seconds to catch someone's attention; from the moment they vaguely hear someone's playing, until that time when they're getting annoyed at the volume your, no doubt wonderful, instrument is making. If you want people to stop and listen, you need to do it in that very short timeframe. A wild and fast virtuoso piece, while sure to get you a great reaction by an audience in an opera house, is only a very noisy thing if you just get a few seconds of it—even if those few seconds are by the best violin player alive. The best way to get someone's attention is to give them something they recognize. The article notes the reactions from a few passers-by. It did not surprise me that of the three or four people who actually stopped and listened, one recognized the violinist as Joshua Bell, and the other had been a violinist himself in a previous life. Both had something they recognized, which made both stop for a few moments to check what they were seeing. That's what gave them more time to appreciate how truly beatifull this music was, and that's why they waited. The real way to get people to stop, to get a crowd around you, and to have them to listen to you, is not to play what gets you the best results in an Opera House or other concert hall. Instead, you should play something that will catch people's attention. A brilliant piece that is unknown will not do that. A funny variation on "Oh When The Saints" will, because people recognize the music. That's not to say that street musicians should only play stuff like "Oh When The Saints". Getting money from playing on the street has more to it than just the music you're playing; just as important is the place where you're playing, and the time when you're doing it:

• If you're playing in a busy hallway, then people will just hurry along. Stopping gets them angry other people walking in their back, so that doesn't happen. If, on the other hand, you play on a large market square or some such, then people are much more likely to stand and listen—people walk in all directions there at the same time, so you have to look out anyway.
• If you're playing in a closed metro station, you'd better not use an instrument that's too loud. If you do, that will make people move away from you, rather than towards you, because they'll notice they can not talk on their cell phones or some such. If they have to pass by where you're playing to get to where they're going, they'll increase their speed so that they're faster past you. Both options give you less time to catch their attention.
• If you're playing on a monday morning during rush hour, you're not going to be getting a load of success. Everyone is going to work, and you're just something in the background, not much more interesting than the guy who's changing the billboard. If, OTOH, you're playing in a busy shopping mall on a sunny saturday afternoon, you'll get a large crowd anyhow.

A good street musician knows these things, and applies them even without knowing. He'll instinctively know whether it's a good day to do street music, and he'll rather go to a bar and have a hot drink if it's not. So why didn't Joshua Bell get a crowd around him? Easy: he isn't a very good street musician.

I’ve just built a newer version of Gnash for Debian, which I want to push into experimental. I’ve created some binary packages for i386, powerpc (thanks, nueces), and amd64 (thanks, bencer), precompiled for sid, so that people might test them while the package waits in the NEW queue. You can also download the source package, but it might make more sense to create the latest one, getting Gnash from their CVS server, and the package building system from our subversion server: svn co svn://svn.debian.org/svn/pkg-flash/packages/gnash/trunk/ latest-gnash
cd latest-gnash
fakeroot debian/rules get-orig-source
cd gnash-0.8.0+cvs*.????
dpkg-buildpackage -rfakeroot

1. The first rule of DebConf: Bring every power adapter you have, regardless of the host country’s standard power outlets
2. The second rule of DebConf: Bring every power adapter you have, regardless of the host country’s standard power outlets

Right, so as announced I finished my thesis this week. Its translated title is (if anyone want to know)

"Design and Implementation of a Model for the Retrieval of Free/Libre Open Source Software using a Case-Based Reasoning System".

Writing it certainly was an educational experience but I am still happy it's done now. Especially the last weeks where rather unfunny, more so since about ten days before my deadline we had a massive heat wave here in Lower Saxony. Now that it's done I am still waiting for enthusiam to kick in. So far weariness still prevails. Maybe also because finishing my thesis does not yet end my studies. We also have to do written and oral examinations which will take place in July and after. So at the moment I spend my days mostly sleeping and trying to muster up enough wanderlust for my trip to DebConf7. (At the moment the prospect of traveling long distance with trains and cheap flights and then be surrounded by a few hundred happy people is still rather daunting.) Anyway, in order to give an impression of my last weeks and months and to sum this all up, a list of random notes, taken during the last weeks, of what I learned while writing my thesis:

• 6 months are NOT a long time!
• 10.000 chars are not enough to model a Debian package description
• 50 chars are not enough to model a Debian package name (YES, THAT MEANS YOU, libmaypole-plugin-authentication-usersessioncookie-perl!)
• osi.org does not belong to the Open Source Initiative but to Ontario Swine Improvement (Ontario Swine Improvement (OSI) is an industry-run organization dedicated to providing swine improvement and genetic products, programs, information and expertise. Our goal is to help Ontario pork producers achieve competitive advantages and excellence in the global market place.)
• I must not procrastinate.
  Procrastination is the mind-killer.
  Procrastination is the little-death that brings total obliteration.
  I will face my thesis.
  I will permit it to pass over me and through me.
  And when it has gone past I will turn the inner eye to see its path.
  Where the thesis has gone there will be nothing.
  Only I will remain.
• Dr.-Ing. Roland Bless rules! (So does his LaTeX class for theses.)
• Working without internet is possible. It is even better than working with internet. Simply leave gaps where you need to look up stuff and fill them in in the evening.
• Losing half a litre of blood does not impair my fitness for (brain) work.
• Working with version control requires a minimum of intelligence attention. Unfortunately mostly so when ending work (dead tired) and when beginning to work (dead tired).
• Side effects: Insomnia, itchy area on left leg, belly aches, little blisters on the sides of my fingers, headaches, slight but constant petulance.
• "I know what I want to say, getting it on paper is the least work." - WROOOONG!
• German is such a crappy language to write scientific texts in. Special greetings to the generic masculine. Gah!
• When the cat's writing her thesis ...
  The fun time's over now, darling ;)
• "I have don't really like proof-reading your thesis in PDF, can't you just send me the Word file?" is not what you want to hear from your proof reader.
• Good: Debian, vim, subversion, LaTeX, bibtex, evince, xpdf, pdftk, PostgreSQL, OpenOffice.org, dia, gimp, phpESP, tea, coffee, ramen, chocolate, electric fan, eating at the uni's cafeteria twince a day, raw cornflakes straight from the box, frida (my trusty laptop), power naps, pizza, people understanding my true problems, the freedom to burry myself in my work and absolutely and utterly neglect anything else until I am finished.
• The flat can look worse. Much!
• Bad:
  • The FSIL (student council for teaching students) belt grinding(!) tables on the balcony in front of the students' working rooms.
  • People trying to be nice and asking how it's going with the thesis.
  • Fellow students greeting me with "Hey still here?"
  • Our evil DPL blogging about his highly addictive monsterz just when I got to work.
• I'll do it after I handed in the thesis.
• I'll see a doctor about it after I handed in the thesis ...
• I should commit much more often (svn that is)
• How come there are so many extra 'i's in your thesis?" Because it's Linux!
• Sense of time is overrated.
• Print shop guy is mean.
  A = Me, overtired, having formatted and doing last changes to this document the whole night through and on until 20 minutes before the printing appointment.
  B = Print shop guy
  
  B: You know that's not A4 ...
  A: WHAT?!
  B: Yea, it's too big.
  A: WHAT?! But, but, I ... That can't be!
  B: I'm telling you, it's too big. See, 0.3mm too long and 0.12mm too wide
  A: ... *death stare*
  
  
• The examination office is now located in the fourth floor in the building next to the post office at the Hindenburgplatz.
• Tolimar is the most patient and understand guy I've ever known.
  Thank you!
• 6 months are SUCH a long time!

Okay, so with the “Bits from the DPL” talk that Sam and I shared now out of the way, that hopefully means finishing off the whole dunc-tank thing won’t imply any more conflicts of interest, potential or otherwise. And since we’ve now had the post-etch release team report, there shouldn’t be much to wait around for. I’d been kinda hoping to be able to come to debconf with a pre-prepared report of similar quality to the debconf6’s final report (or debconf5’s for that matter); but while I was going back through the discussion threads, it just got harder and harder to find a way of writing the report that didn’t seem like it’d just inspire the same arguments again. I think that’s avoidable – I know some of the people who were against the way dunc-tank ended up have indicated there are other approaches they might support, and it ought to be possible to summarise the dunc-tank experience in a way that lets us have a better idea what to do in the future based on that experience, than have the same disagreements we’ve already had. Anyway, my best guess is to try crafting the report via blogging or put it on a wiki or something. Anyway, there are three things that I thought we could usefully have in a report that wouldn’t devolve into the same old arguments (after all, if we at least have new arguments, that’s some sort of progress!). First of all is trying to have a real understanding of what happened with etch – getting a release out is complicated with lots of potential blockers beyond just “release management” work: d-i, kernel, toolchain, CDs, builds, bug tracking, whatever. Presumably dunc-tank only ever had a chance of removing release management as a blocker, and since we can’t redo the etch release while changing parameters like dunc-tank or Vancouver, at least having as clear as possible understanding of which blockers happened when, and what other influences might have been important the release process seems like a good way of understanding the influences that were and weren’t important, so we can have a better idea what to do in future. I’m figuring a reasonable structure might be something like:

• Release blockers between July 2006 and April 2007
• Analsyis of bug discovery/resoution rates between July 2006 and April 2007
• Comparison of major statistics for etch with previous releases (freeze length, etc)
• Comparison of etch with Ubuntu’s edgy release (October 2006, roughly the time dunc-tank started), and feisty release (April 2007, roughly the same time as etch’s release)
• Summary of other release timliness projects: Vancouver proposal, release assistants, BTS version tracking and changes to RC bug monitoring, transition monitoring through the entire release cycle, binNMU changes, improvements in experimental support, BSP marathons
• Summary of release quality projects: DFSG-free content, LSB support, security support for testing, QA meetings, piuparts runs, whole archive rebuild testing

The theory is that the above should provide the information to make a good judgement of what (if any) effect dunc-tank (or the other projects) had on the release, without implying a preconceived conclusion of whether dunc-tank’s “good” or “bad” or whatever. As well as looking at the release stuff in some depth, it seems to me to be pretty sensible to do a report on how dunc-tank worked financially. Anyone doing any similar sort of “let’s raise funds, then spend them on free software” is going to have similar issues in getting publicity, collecting funds, and actually spending them, no matter how they end up deciding on the harder questions of deciding who or what to fund. There’s not a lot to say there, and I don’t think there’s much that’s controversial there either, but there are a few problems and approaches to solving them that are worth reporting on. I think that’s about as far as you can get trying to cleverly avoid the controversy though. And presuming we rule out the idea of choosing a position on some of the controversial questions and advocating for that (“dunc-tank was good, paying release managers was awesome, we should do it again for everyone!”), the best idea I’ve had so far is to just try summarising some of the controversial questions that remain open, which Debian, or dunc-tank, or whoever can then address in whatever way we like – by GRs, or further debate, or more experiments, or leaving it to other people to do for us, or whatever. So having the questions and some of the arguments for various answers and summarising what happened with dunc-tank seems like a plausible way to go. The questions I’ve got:

• Is paid work compatible with volunteer work?
  • How the release managers and assistants reacted to doing volunteer work while someone was paid to do similar work
  • Other developers – some donated; others resigned or reduced work
  • Dunc-bank and QA initiatives
• How much distance should there be between Debian and whoever’s funding development?
  • Involvement of DPL and high-profile developers
  • Involvement of SPI
  • Statements from press reports about the relationship
  • Votes to support/endorse/recommend against
  • Donors being confused as to where to donate funds
• How should work or developers to be funded be chosen?
  • Potential for favouritism
  • Potential for misalignment with Debian’s goals
  • Choosing based on least controversy or most benefit
• How should paid “volunteer” work be priced?
  • Covering living expenses?
  • Comparable rate to similar proprietary/commercial development?
  • “Market” rates?
  • Full-time versus part-time work
  • Contracts versus prizes or bounties or rewards

No promises as to whether they’re the best questions, the best sub-points, or that we’re going to be able to come to an answer on any of them. :) Anyway, that’s my theory so far, no I need to grab some lunch before the next lot of talks – feel free to mail me, or talk to me in person, or blog responses or whatever…

yay, today is the Debian Day and for those not here with us in Edinburgh you can enjoy some of the cool stuff online:

Debconf 7 website:
http://debconf7.debconf.org

IRC:
irc.debian.org - #debconf, #debconf-uppertalks, #debconf-lowertalks, #debconf-upperbofs, #debconf-lowerbofs

Live Streams:
http://streams.video.debconf.org:8000/

Download and Install Debian (I recommend CD or DVD multi-arch, yes it will be installable on your regular PC, ibook and even on that shiny new amd64 server your company bought):
http://www.debian.org/CD/torrent-cd/

Use Debian Live:
http://live.debian.net/etch-builds/current/i386/

Join Debian - Yes, we're also recruiting! :-P
http://www.debian.org/devel/join/

Congrats to the organization team! :-) debian/rules

It is time for a DebCamp update, since I’ve been here three days now. I have mainly been working on picking up the slack regarding Debian/Ruby Extras. This meant: getting rid of a CDBS rule that substitutes the entire team in the Uploaders field, cleaning up some package, uploading some packages with new upstream, solving and filing bugs. During all this, the “picture” of the environment outside is actually only missing yellow/brown trees shedding their leaves. Ruby D-Bus 0.2.0 In between the Debian/Ruby Extras work I have been able to finish the documentation of our Ruby D-Bus protocol implementation. It is due for release this weekend and I think we’ll make it.

Doing a pub crawl in Belgium is a fun experience: you go to "several" bars (say, six) in a row, and drink a beer in each. You end up slightly drunk, but not so much that you don't remember who you are. And given the rule is "one drink per bar", and that other people usually are slower than you in drinking theirs, that helps improve the blood-per-alcohol ratio. Doing a pub crawl in Scotland is also a fun experience, but in a different style. Not only are their beers over twice as large as Belgian ones, they also have great Scotch. Both of which help getting you drunk much, much faster. After having seen the inside of five bars last night, and having had 1+1+1+3+2 drinks (if I'm not mistaken), it's a bit of a miracle I still made it in bed in one piece. One called Steve.

For about two weeks now it seems that a botnet is attacking one of my Gallery2 installations in order to either comment spam me or to solve the captchas:


121.132.186.55 - - [14/Jun/2007:09:09:27 +0200] "POST /main.php?g2_GALLERYSID=4cc6b5e4b7ce4a207957a07c081b6f65 HTTP/1.1" 200 12167 "http://gallery.foobar.net/main.php?g2_GALLERYSID=631acbacb15f2cfb83cdaf592721c082" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)" 0 gallery.foobar.net
121.132.186.55 - - [14/Jun/2007:09:09:30 +0200] "GET /main.php?g2_view=comment.AddComment&g2_itemId=7152&g2_return=main.php%3Fg2_itemId%3D7152%26&&g2_returnName=photo HTTP/1.1" 200 10349 "http://gallery.foobar.net/main.php?g2_view=comment.AddComment&g2_itemId=7152&g2_return=main.php%3Fg2_itemId%3D7152%26&&g2_returnName=photo" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)" 0 gallery.foobar.net
121.132.186.55 - - [14/Jun/2007:09:09:32 +0200] "POST /main.php?g2_GALLERYSID=b45c76223a933ba3bed6e09a9589a6cd HTTP/1.1" 200 12081 "http://gallery.foobar.net/main.php?g2_view=comment.AddComment&g2_itemId=7152&g2_return=main.php%3Fg2_itemId%3D7152%26&&g2_returnName=photo" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)" 0 gallery.foobar.net


Sadly Gallery2 seems to not offer the configuration option to disable comments for non-authorized/logged-in users, just only to disable captchas for some users/groups, but apparently disabling captchas for guests seems totally wrong for me.
Currently I'm blocking the hosts with an iptables rule whenever I see an attacking host by accident, but I guess that there should be a better option...

You probably all know tetrinet - if you don’t, you should really try that game. There are several servers for that game out there, and one of them is tetrinetx. It is packaged in Debian, but it has several problems:

• It doesn’t support tetrifast mode. So you have to deal with that stupid 1-second delay before the next block appears.
• The code is truly horrible. From main.c:

  #include "dns.c"
  #include "utils.c"
  #include "net.c"
  #include "crack.c"
  #include "game.c"

  That gives you an idea, right ?

A few years ago, I worked with a few friends on improving tetrinetx. This resulted in:

• Massive code cleanup
• Tetrifast support
• Stats stored in an MySQL DB, so you can compute nice stuff (time wasted per day, etc)
• More stats: blocks drop rate, etc.

This is hosted on sourceforge under the name tetrinetx-ng, but it hasn’t seen any activity for the last two years. It would really be great if a tetrinet fan could take over the project and start making it alive again. Then tetrinet.debian.net could support tetrifast ;) Also, I could try to setup a server with tetrinetx-ng. Someone wants to host tetrifast.debian.net for me ? Needed: MySQL DB + Apache (for the stats), + not being afraid of insecure code (doesn’t need to run as root)

Are you having trouble with your health insurance? Are they stalling on paying a bill? Denying a claim? Not telling you what the heck is going on?? Well you can and should take action to eliminate some of the mystery and move forward, and possibly win fight against the health insurance company. Thanks to my unpleasant ordeals with BCBS of NJ, I have compiled some handy resources and tips to get you started. Good luck and I welcome any other tips that you think should be here. Please email them to me at biella(at)gmail(dot)com Can’t get a straight answer when dealing with health insurance representatives on the phone? Are different representatives providing different and contradictory information? Does talking to the representatives leave you with a pounding headache? Then the following may be helpful: 1. Ideally you should tape record all conversations. If this is not possible, get the name or employee number of the person you are talking to and write down what they told you along with the time and date. If they have agreed to something, make sure they send it to you in writing. This sort of documentation may come in handy later when you are trying to contest or prove something. Is your insurance company flip flopping on a claim? For example telling you that the claim is still being “reviewed” but sending you statements that indicate it has not been paid and never will be? What action can you take to inch things forward? The following may help: 1. Most states have a Department of Banking and Insurance and they are there to help you. Many (perhaps all) provide a service for filing a complaint against your health insurance company and other insurance and banking companies too. When I used the service in NJ , I got assigned an investigator and their service was prompt and helpful. It was my experience that even though they were not able to resolve my issue, the insurance company started to make firm decision on many claims and this alone has been helpful. Before this, it was impossible to get a clear answer from them as to the state of all sorts of claims. They said “NO,” & you think they should say “YES, YES, YES, YES!!!!” In other words, appealing a denial: 1. This site has some great information on how to avoid a denial and what you can do to fight one. 2. Included on their site is the Health Insurance Laws and Benefits Tool which will provide specific information about your rights in different states. For example, you will want to know if there is an external or independent grievance system to appeal your plan’s decisions. In the case of NJ, which is the state I am fighting, the tool provided the following helpful information:

Does New Jersey require an external or independent grievance system to appeal your health plan’s unfavorable decisions? Yes, for all health plans.

On what grounds can you file your external grievance?
Investigational treatment appeal, medical necessity. What is the status of the external grievance panel’s decision?
Binding. External grievance systems allow you to take a dispute with your health plan to a doctor or review board unaffiliated with your health plan. Thus, both you and your health plan receive an impartial ruling on its decision to deny coverage of services or treatment. Additionally, you can file a complaint against your health insurer with your state’s department of insurance.

Additional Helpful Information and Resources 1. The message boards on lawyers.com are a great place to hit for information. I have found folks there helpful.
2. You many want to blog about your experience as you may get an unexpected response directly from your insurance company. I think there are pro’s and cons to blogging about your experience but it does provide a public face to your ordeal and allows you to chronicle exactly what has transpired.
3. If your cases is particularly shocking, do not hesitate to hit the local media.
4. If your claim has been denied by an external review panel, you may not have much luck suing but if there is no external review panel, you can and should also try Small Claims Court or other legal action. Further, even if your claim was denied by an external review board, you may have other options for suing, for example, due to their bad faith handling of a claim. And on that note, here is a great legal resource covering the topic.