While preparing a new upload of python-support containing a workaround for #396840 (python2.3 inadvertently removed from all pyversions calls), I noticed a very nice side effect: it enables support for python2.5 for all modules using python-support. Extensions are still not built, but it means python 2.5 in etch will have at least a few add-on modules.

I fell less than 2 feet and managed to get a minor fracture of my radius at the elbow, so I'm in a sling and will get to practice being right-handed for a few weeks. Typing so slowly feels almost like being struck mute.

I m running a computer club at the school in Ghana where am volunteering as a Free Software advocate at the moment (as you probably know already). At first I tried to spread a little bit of general hacker attitude by introducing an internal wiki and blog, and by explaining what Free Software is. Then some students indicated interest in a programming course, so I held python lessons in the club (Sessions 3, 4, 5, 6, 7, 8, 9 and 10). Unfortunately, interest was declining over time, and while the first lessons had over ten participants (not to speak of the 20 at the very first one), it soon fell to around four. There was also some fluctuation, students leaving, others joining (and then of course lacking the lessions from the earlier sessions).So today, with four students who only recently joined, I started something new: I introduced the game infon, by fellow entropianian Florian 'dividuum' Wesch. It is a networked battle area where bugs compete over food and fight each other. Suitable for the computer club makes it the fact that the bugs are not directly controlled, but the players write their intelligence (using the simple language lua) and only upload code to the server. They can even do this while the game is running and it was a very fun game to play at GPN5 in Karlsruhe. You can read my infon-tutorial, and it s mostly non-SOSHGIC specific.I got them far enough to type the code that I presented as an example, to get it running, and to extend it slightly. I am only hoping that they will dig in a little bit deeper until next week. I think that you can only be successful in learning programing or similar things if you spend some time doing it besides the classes, and I did not see that happening when I was doing python. Maybe I was going too fast or the text-only way of doing it was discouraging, but I did expect them to starting having their own ideas at least after we were programming a simple text-based maze in the club.

I'm pleased to see that the McGill Student Union is now refusing to allow blood drives until anti-homosexual discriminatory questions on the questionnaire can be dropped. The problem is one of stupid questions combined with discrimination. My friend Katy put it best about when she went to fill out the questionnaire: "No, I can't guarantee that I know my partner's sexual history. But I'm willing to bet my life on it."

According to an article on a recent Public Health Agency of Canada report:

The PHAC report reveals that 51 per cent of those infected with HIV continue to be men who engage in homosexual activity.

(Note that the lifesite.net is a Christian, pro-life, anti-gay website. I don't have time at the moment to dig out either a better source or the original report.)

Perhaps I'm doing my math wrong, but at the point when 49% are those who don't identify as homosexual (and 40% of those are women), then you've probably got a third to half a chance that someone in that line isn't a man who's had sex with a man and could be HIV infected.

I hope that the McGill protest puts enough pressure on Health Canada to review this policy and drop the discrimination completely.

So the Zune's big killer feature is (heavily DRM'd) wireless sharing of music. While I believe this will finally educate the masses about the evils of DRM, I would rather have a way to "recommend" a piece of music and offer a snippet for download to people near me, even without me being active in any way. If something like this catched on, and the transfer rates were acceptable, I could get a few new tunes on my daily commute, and learn about new artists this way. Throw in a rating system (doubling as spam protection), and a way for me to get the URLs of the artists' homepages for pieces I marked as "noteworthy" while they were playing into my browser easily, and this is the platform of teh phuture.

The stdarg API, which allows you to use a variable number of arguments to a function in C, is pretty fun. However, it's also pretty limited in what it allows, to a degree that it invites people to try and find workarounds to things you can't do with the API as it is documented. Unfortunately, this almost always breaks when the software is compiled on hardware that happens to be not your own, as there is a reason why stdarg is implemented the way it is: portability. A (not so) recent discussion on #debian-devel on OFTC showed to me how this confuses many people. Don't worry—it confused me too, the first time I had to think about it. The problem is that in order for stdarg to be able to do what it does, it needs to read function arguments from whereever they are stored. Where that actually is depends on the operating system and the hardware you're using; it could be on the stack, but e.g., the SPARC architecture actually has a mechanism to pass parameters using processor registers (although those are most likely not used when stdarg is in use, since the number of parameters that can be passed that way is obviously pretty limited). If parameters are on the stack, then you may be able to just access the memory as you would access any random variable; but it could also be the case that you need to take some specific steps to access the stack, or perhaps your architecture or operating system has some protection for stack-based security attacks, which would make it impossible to directly access memory on the stack that is actually part of another subroutine. So if you try to do anything that isn't defined in the stdarg api (like trying to figure out the number of arguments by peeking inside the va_list data type, or passing a va_list to another function without using the C99 va_copy macro) will break. Yes. Very sorry.

According to Aurelien Jarno, it's possible to run Debian/ARM and both Debian/MIPS platforms inside an emulator that itself is packaged and runs on Debian. Since fairly recently (about a month or two, I guess), the same is true for Debian/m68k. Granted, the emulator you need to install isn't called "qemu", but with ARAnyM (short for 'Atari Running on Any Machine') it is now possible to run Debian/m68k. And it's fairly easy to do, too:

• Download the installer images for Debian/m68k
• Install the aranym package
• Run aranym once. This will create a directory .aranym with a default config file.
• create a file to be used as a disk image: dd if=/dev/zero of=./disk.img bs=1k seek=2M count=1.
• Edit the configuration file. The important bits are the section [IDE0] and [LILO]. It's pretty self-explanatory.
• Run aranym-mmu -N -l.

There, you have a free m68k development machine! Note, however, that there might be issues with the network interface; the NIC in the emulated machine is unlike any real, actual Atari hardware. There is a driver for Linux, but I'm not 100% sure whether it's been integrated in the Debian kernels yet. I'm sure Christian will kick me awake on this, though ;-)

I was approved by Debian NM FrontDesk team today, then, only one step remaining to dispatch my application.

• Step 1: Application
• Step 2: Identification
• Step 3: Philosophy and Procedures
• Step 4: Tasks and Skills
• Step 5: Recommendation
• Step 6: Front Desk Check
• Step 7: Debian Account Manager check and account creation

I hope to be DAM approved soon, go go! :) By the way, tomorrow I will have a skills test to get a driving license, wish me luck!

While anyone who has had a 1) medical condition and 2) access to Internet in the last five years probably knows that patients are increasingly using the net (and now google) to diagnose medical conditions, it is only now that the medial establishment is starting to recognize or really admit to the reality of this widespread phenomenon and even doing studies on them, such as the one released a few days ago by the BJP Googling for a diagnosis use of Google as a diagnostic aid: internet
based study. The study sought to ascertain how effective google was as an aid in medical diagnosis. As various new outfits are reporting it is moderately high. What I love about this study and the corollary reporting is the naive tone they have to assume, transmitting the news as if the public knew very little about this, and would in fact, be induced into surprise!!!!!!!!!! when first facing the new. But in fact, I think it works in the opposite way. The surprise is that they took so long to admit to what was in front of us for many years now. While the news articles reporting on the study stay within the province of doctors, the report acknowledges, in fact opens with, the fact that patients may be forging the path in Internet-diagnosis. The authors write in their second paragraph:

It seems that patients use Google to diagnose their own medical disorders too. After evaluating a 16 year old water polo player who presented with acute subclavain vein thrombosis, one of us (HT) started to explain that the cuase of the thrombosis was uncertain when the patients father blurted out But of course, he has paget-von Schrotter symdnome. Having previously googled the symptoms, he gave us a mini-tutorial.. and the correct treatment for the syndrome. This experience led us to ask How googe is google in helping doctors to reach the right diagnosis

Again, what I love about the tone of this opening is that it is as if these doctors stumbled on a great but deeply hidden fact to make a breath-taking discovery, one that, however, since is it is SO very emergent and thus still not *really* verified by Science, they must proceed with great caution, qualifying with phrasees like It seems that patients use Google to diagnose their own medical disorders too . I am sure they and most doctors are personally are not so na ve but since this has been something virtually without no official acknowledgment among professionals and in the journals, the genre of writing just requires it to be framed cautiously. As fun to read are the comments, for they stretch from moral panic:

The implication that ‘googling’ be an adjunct to proper medical school training, continuing medical education through courses and reading peer reviewed journals is laughable and bordering on dangerous. I am shocked that this has been published by the BMJ.

to celebration:

For the modern dermatologist, the internet is indispensible and google is only the start, and for this reason a desktop computer with high speed internet access is an essential tool for all clinicians. Long live the information superhighway!

While others muse on the broader emacipatory possibilities

One can imagine the benefit to young doctor in developing country who now have access to a grand medical library in their hands.

I am especially interested in this very dynamic because it is one pillar propping my next project on psychiatric survivors, which exceeds the particular topic of challenges to psychiatry in its general focus on medical/patient reconfigurations following from Intent-based activism, self-help, diagnosis, and critique. And for those who think I have made a radical departure from my last project, here is where I see one (of two or three) threads of continuity: for patients are generating an enormous amount of amateur knowledge, that I think is not unlike the peer-to-peer production of software hacking, and it is a form labor usually accompanied by a strong critique of expertise and other medical practices. I am now reading some literature on patient activism, like the issue from the February 2006 in Social Science and Medicine that collects 11 articles on patient organization movements. For those who work on this topic, the collection is worth your while and the editorial introduction by Kyra Landzelius is stellar. It is not only written beautifully (which I think is rare for these openings because it is often a rote, unimaginative regurgitation but this was a pleasure to read) but provides an engrossing overview of some new trends and some of the diverging forms of politics that arise from what is really a motley bunch of organizations and contests in patient and anti-patient activsm. She opens by defining four spheres that shape and inform the forms of contents that are part and parcel of these patient movements, the four being: 1. Revolutionary feats in technoscientific engineering
2. Restructuring of healthcare systems across industrialized nations
3. A Revised contract between science and the public stemming from a criss of confidence in science
4. An upsurge in the articulation and diversification of health activisms (p. 530) These four are key but I was shocked that there was no specific inclusion—though it comes out plenty in the introduction in other ways of the Internet. For while I am no techno-determinist, the Internet I think, can’t be ignored for it has fundamentally changed the map and tenor of patient activism, allowing for more rapid connections between various stakeholders, providing a medium by which those officially unrecognized illnesses are given shape and form, and where an ethical cultivation of self-help, self-diagnosis, self-medication, along with copious critique and forging of alternatives is happening, right before our eyes, virtually in real time. It is the medium by which a new chapter of patient activism is being written and I think it is a real mistake not to give it serious attention and credit. And perhaps one of the most interesting things about it is that it without it, it would leave many otherwise home-bound, sick folks, without a medium by which to engage in political activity or even community self-help, for let’s face it, these take a lot time and energy. When you are sick and home-bound, for example, there may be a limited number of types of engagements you literally have the energy to partiicpate in and the Internet lowers the barrier of political entry because of its ease and because you can still type away, even when feeling otherwise totally awful… This may be a brute material point but nonetheless, key to understanding the political power of the Internet. Now of course the question left is will Google capitalize on this and create “Google Diagnosis”?

The last time I made any serious contributions to Wikipedia was back in 2001 or 2002. The community was exciting, friendly, and welcoming, and I enjoyed spreading the word as most non-technical people I knew had never heard of wikis or Wikipedia. Since then, I may have corrected the occasional typo or fixed a legal error, sometimes anonymously and sometimes under my account (apparently I “clarified the 13(c) protective arrangement issue” in the Urban Mass Transportation Act of 1970 back in the Fall of 2003, although I have no recollection of having done so), but I hadn’t started any new entries since the early days. At a recent presentation I attended by Sun’s Hal Stern, I learned that his eating club (Colonial Club) at Princeton University has a Wikipedia entry (as do all the other eating clubs). On further investigation, I learned there were no entries for any of the student cooperatives or other upperclassman eating options. To the uninitiated, it may be hard to understand why this matters beyond the insular Princeton community, but — suspend your disbelief just for a moment — the eating clubs have been called Princeton’s “peculiar institution” (a side-long reference to slavery) and have a storied and controversial history going back at least to the 1870’s (see, for example, this summary of the historical record from 1888-1993). It seemed to me that omitting the student cooperatives was akin to having a Wikipedia article on political parties that includes links to both the Republican and Democratic parties but leaves out any mention of the Green Party. Of course, the Green Party doesn’t wield the influence of either of the main parties, but its existence provides insight both into the American political system and the character of the two main parties. If no mention of the Green Party were included in Wikipedia, a foreign researcher attempting to learn about the American party system would come away with an incomplete and misleading understanding. The fact that the Green Party has not been particularly successful nationwide is, itself, interesting, useful, and relevant information. Although I wouldn’t pretend Princeton is as important or interesting as the American political system, it’s still a subject of scholarly investigation, and a topic that a fairly significant number of people are interested in learning about. I thought I would start basically a stub article for the Two Dickinson Street Co-op and spend a couple of days building it out and asking knowledgeable experts to contribute and add sources. Within a few seconds after I created the article, however, it was “speedily” deleted. A bit surprised, I tried to start an explanation as to why the entry warranted at least consideration for inclusion, and the article was deleted again and I found this message on my “talk” page:

This is your last warning.
The next time you vandalize a page, you will be blocked from editing Wikipedia. Diez2 14:55, 9 November 2006 (UTC)

I had gone from citizen to felon in two minutes flat! There then ensued several attempts to at least allow a debate on the deletion, but the article was unilaterally speedily deleted several times by several different editors. Even after one admin restored the article as not appropriate for “speedy deletion,” another admin stepped in and speedily deleted it again. I received some fairly acerbic retorts to my attempts — e.g. this: “We don’t have a page for every club in the world. If you want free web-hosting check out Myspace or usenet. Also anonymous postings do not make a topic notable or important.” (I’m not sure why he accused me of posting anonymously — I didn’t. Also, does “usenet” offer “free web-hosting?”) Finally, the deletion of the article was converted from a “speedy deletion” to a nomination as an “article for deletion” (‘AfD’), which allows at least for some discussion on the topic. The debate is ongoing — see it here — and some of the comments continue to be fairly corrosive. For example, one editor wrote:

• Strong Delete Fails WP:N, WP:V. It should be noted that on User_talk:Eagle_101 the editor of the article hs refused to give even just one reliable source of the article to assert it’s verifiability and notability. That alone should speak volumes for the article’s worth. Wizardry Dragon ^{(Talk to Me) ((My Contributions) (Page Moves) (Support Neutrality on Wikipedia)} 23:01, 10 November 2006 (UTC)

Another editor called the debate a “pointless waste of time” over a “vanity article,” although I can’t find that comment any longer. I admit that I created the article without knowing much about the process, and certainly with little understanding of the numerous acronyms, flags, and the several different ways an article can be killed. Apparently, I didn’t contest the speedy deletion properly, although it wasn’t clear to me from the deletion notice exactly what I was supposed to do, and I assumed the restoration of the article by another admin meant that it would persist for at least a few days. I thus deserve some of the blame for not doing more pre-posting diligence, but I was relying for the most part on my 2001-2002 experience where you could create an article, spend a few days improving it, invite others to contribute, etc., and articles with a colorable argument for inclusion would generally stay in. It seems the new Wikipedia is a much less kind and less gentle Wikipedia. As another participant in the process wrote to me:

This whole situation is so strange. It makes me feel like I just stumbled into somebody else’s trench warfare. The defenders of notability! I wonder how long the constant vigilance of volunteers will hold out…

Of course, a similar phenomenon has occured with many open source projects. Initially, the doors are wide open and everyone’s contributions are, if not welcome, then at least tolerated. I suppose it is a sign of Wikipedia’s success that the front gates are locked so tightly. Still, I wonder how many potential good faith contributors are now permanently alienated by an initial bad experience such as this one, and whether Wikipedia will ultimately suffer from it. Low barriers to entry have traditionally been a key element to attracting participants to peer production efforts, but they seem to break down in direct relationship to the project’s external importance. Incidentally, Stern’s edit to the Colonial Club entry, mentioning F. Scott FitzGerald’s characterization of the club, was quickly reverted by another editor as “nonsense.”

We're back in Montreal again after more than two weeks in San Francisco. It was great being in the Bay Area, especially since this time of year in Montreal is kind of crappy. Cold rain knocks all the red-yellow-orange leaves off the trees and into the gutter, where they turn brown and gray. Everything's damp and muddy and icy, but there's no snow yet. Blech. Our friend John Usher stayed at our apartment while we were gone, which was great for us since he watched our cats. We had our regular Friday Night Pizza together last night at 9PM, after a very long day in the plane. Traveling eastward is hard on the sense of time. But pizza night made it a little better. We went up to Le Comptoir on rue Masson this morning for breakfast. It's a nice little place that you can always get into, regardless of the time of day (like, say, if you try going out for brunch at 11:30 on a Saturday...). The menu is a little too much in the Montreal Kitchen Sink style (10+ pages of every kind of food under the sun), but the b n dictines are good, they have mimosas, and they serve caf au lait in big bowls. So what's not to like? John rented a new apartment in Old Montreal while we were away. He's been a vagabond since early this summer when he left McGill and went back to his hometown of Beer in Devon. His new place is great -- 2000 ft top-floor loft around the corner from Basilisque Notre Dame. I plan to abuse his hospitality and throw big parties in his home, if I can get away with it. One nice thing is that he found the place on Montreal Craigslist. I think that's a pretty good sign that CL in MTL is becoming worth using, although they still don't have an interface in French. I don't know how you get away with an non-localized international Web site in 2006. tags: montreal john usher le comptoir old montreal craigslist i18n

Web 2.0 Summit Wrap-up LinuxWorld.com published my article on Day 1 of the Web 2.0 Conference, which I have to say I think is pretty OK good. I had originally written a gossipy article about who was where and who announced what and what it meant for Linux users and the Open Source community. Don Marti, who edited the article, didn't like it. He told me to identify the key technologies mentioned at the conference that people could actually use and should know about, and write more about them. So I did, and I think the article is much better for it. Days 2 and 3 of the conference coverage come out next week. I really liked writing about the Web 2.0 Summit; it gave me a chance to talk to people in-depth about their work. I didn't draw as much out of the conference itself as I would have liked, but by working press on it, I had to find stuff that interested me and communicate that interest. Which made it fun. tags: linuxworld.com web2con don marti web 2.0

Que Rico I'm pretty psyched that planning for next spring's Wikitravel Get-together 2007 is going so well. The Get-together (despite my finest effort, this seems to be the final name for the event) will be a convocation of Wikitravellers from all over the world on one spot to meet, talk about issues, but most of all, travel. Our chosen destination for this year's event is Puerto Rico (the product of a months-long selection process, with two rounds of voting). Our coverage of PR in English Wikitravel is sub-optimal, and we hope that by bringing a bunch of wiki people to the island for a week to hang out and explore, we can greatly improve the travel guide for this big area. Participants will be doing research before the event (April 14-22 2007) to determine those parts of the island that need better first-hand coverage. Then, we'll convene in San Juan (Puerto Rico) for a weekend before spreading out to cover the rest of the island. We'll meet back up in SJ the next weekend for some discussions and meetings before flying off to our respective homes. It should be a really fun trip -- I've never been to the Caribbean at all, and I think PR sounds like a really amazing place to visit. And I think this style of meetup for Wikitravellers could be super-fun for future events; it will be cool to see how this one goes. tags: wikitravel get-together puerto rico san juan

Poppies One endearing custom in Canada for Remembrance Day is wearing small, red poppies on one's lapel, evoking the classic Canadian poem ''In Flanders Fields''. It's a beautiful tradition, but hard to watch a bit on this day in 2006, when Canadian soldiers are being killed not in Ypres, but in Kandahar by, among others, heroin drug-lords, for whom poppies have other meanings. tags: poppies in flanders fields remembrance day canada afghanistan

My post about securing an office received many comments, so many that I had to write another blog entry to respond to them and also add some other things I didn't think of before.

One suggestion was to use pam_usb to store passwords on a USB device. It sounds like it's worth considering, but really we need public key encryption. I don't want to have a USB device full of keys, I want a USB device that runs GPG and can decrypt data on demand - the data it decrypts could be a key to unlock an entire filesystem. One thing to note is that USB 2.0 has a bandwidth of 30MB/s while the IDE hard drive in my Thinkpad can sustain 38MB/s reads (at the start - it would be slower near the end). This means that I would approximately halve the throughput on large IOs by sending all the data to a USB device for encryption or decryption. Given that such bulk IO is rare this is feasible. There are a number of devices on the market that support public-key encryption, I would be surprised if any of them can deliver the performance required to encrypt all the data on a hard drive. But this will happen eventually.

Bill made a really good point about firewire. I had considered mentioning it in my post but refrained due to a lack of knowledge of the technology (it's something that I would disable on my own machines but in the past I couldn't recommend that others disable without more information). Could someone please describe precisely which 1394 (AKA Firewire) modules should be disabled for a secure system? If you don't need Firewire then it's probably best to just disable it entirely.

To enable encryption in Fedora Core 6 you need something like the following in /etc/crypttab:

home_crypt /dev/hdaX /path/to/key
swap /dev/hdaX /dev/random swap

Debian uses the same format for /etc/crypttab.

The Peregrine blog entry in response to my entry made some really good points. I wasn't aware of what SUSE had done as I haven't done much with SUSE in the past. I'm currently being paid to do some SUSE work so I will learn more about what SUSE offers, but given the SUSE/MS deal I'm unlikely to use it when I don't have to. Before anyone asks, I don't work for SUSE and given what they have just done I will have to reject any offer of employment that might come from them.

I had forgotten about rsh and telnet. Surely those protocols are dead now? I use telnet as a convenient TCP server test tool (netcat isn't installed on all machines) and never use rsh. But Lamont was correct to mention them as there may be some people still doing such things.

The Peregrine blog made an interesting point about Kerberised NFS being encrypted, I wasn't aware of this and I will have to investigate it. I haven't used Kerberos in the past because most networks I work on don't have a central list of accounts, and often there is no one trusted host.

I strongly disagree with the comment about iSCSI and AoE "Neither protocol provides security mechanisms, which is a good thing. If they did, the additional overhead would affect their performance". Lack of security mechanisms allows replay attacks. For example if an attacker compromises a non-root account on a machine that uses such a protocol for it's root filesystem, the victim might change their password but the attacker could change the data back to it's original values even it if was encrypted. Encryption needs to have sequence numbers embedded to be effective, this is well known - the current dmcrypt code (used by cryptsetup) encrypts each block with the block ID number so that blocks can not be re-arranged by someone who can't decrypt them (a weakness of some earlier disk encryption systems). When block encryption is extended to a network storage system I believe that the block ID number needs to be used as well as a sequence ID number to prevent reordering of requests. CPU performance has been increasing more rapidly than hard drive performance for a long time. Some fairly expensive SAN hardware is limited to 40MB/s (I won't name the vendor here but please note that it's not a company that I have worked for), while there is faster SAN hardware out there I think it's reasonable to consider 40MB/s as adequate IO performance. A quick test indicates that the 1.7GHz Pentium-M CPU in my Thinkpad can decrypt data at a rate of 23MB/s. So to get reasonable speed with encryption from a SAN you might require a CPU which is twice as fast as in my Thinkpad for every client (which means most desktop machines sold for the last two years and probably all new laptops now other than the OLPC machine). You would also require a significant amount of CPU power at the server if multiple clients were to sustain such speeds. This might be justification for making encryption optional or for having faster (and therefore less effective) algorithms as an option.

I believe that the lack of built-in security in the AoE and iSCSI protocols gives a significant weakness to the security of the system which can't be fully addressed. The CPU requirements for such encryption can be met with current hardware even when using a strong algorithm such as AES. There are iSCSI accellerator cards being developed, such cards could also have built in encryption if there was a standard algorithm. This would allow good performance on both the client and the server without requiring the main CPU.

Finally the Peregrine blog entry recommended Counterpane. Bruce Schneier is possibly the most widely respected computer security expert. Everything he does is good. I didn't mention his company in my previous post because it was aimed at people who are on a strict budget. I didn't bother mentioning any item that requires much money, and I don't expect Counterpane to be cheap.

Simon noted that developing a clear threat model is the first step. This is absolutely correct, however most organizations don't have any real idea. When advising such organizations I usually just invent a few possible ways that someone with the same resources and knowledge as I might attack them and ask whether such threats seem reasonable, generally they agree that such things should be prevented and I give further advice based on that. It's not ideal, but advising clients who don't know what they want will never give an ideal result.

One thing that I forgot to mention is the fact that good security relies on something you have as well as something you know. For logging in it's ideal to use a hardware security token. RSA sells tokens that display a pseudo-random number every minute, the server knows the algorithm used to generate the numbers and can verify that the number entered was generated in the last minute or two. Such tokens are sold at low prices to large corporations (I can't quote prices, but one of my clients had prices that made them affordable for securing home networks), I will have to discover what their prices are to small companies and individuals (I have applied to evaluate the RSA hardware). Another option is a GPG smart-card, I already have a GPG card and just need to get a reader (this has been on my to-do list for a while). The GPG card has the advantage of being based on free software.

One thing I have believed for some time is that Debian should issue such tokens to all developers, I'm sure that purchasing ~1200 tokens would get a good price for Debian and the security benefits are worth it. The use of such tokens might have prevented the Debian server crack of 2003 or the Debian server crack of 2006. The Free Software Foundation Fellowship of Europe issues GPG cards to it's members, incidentally the FSFE is a worthy organisation that I am considering joining.

Today I received a copy of the PIN for my MBNA credit card in the post, despite not having asked for it. In response, I've cancelled my account, and reported their incompetence to You and Yours. I suppose I shouldn't be all that surprised, since MBNA have a habit of randomly sending out unsolicited cheques (which also has worrying security implications), but I actually found it quite shocking to see the PIN that I'd chosen printed in clear text. Obviously, in the first instance they generate a random PIN, and print it out, but I was rather hoping that their systems would be set up so that that random PIN, and certainly any PIN subsequently selected by the customer, would not be available in clear text at any time. If I forget my PIN, they should generate a new one, not remind me of the old one. They should not be able to remind me of the old one. The two people I talked to seemed surprised that I would cancel an account that I've had for about 13 years over a single PIN in the post, but given that that's their policy, I don't think it's a massive leap to think that a corrupt postman might be tempted to collect these PIN letters (which are pretty easy to spot and most of which are not being expected, so won't be missed). Then, assuming that a reasonable percentage of people will match MBNA's laxness by setting all their PINs alike, the criminals will be armed with all the information they need to do a targeted mugging for the card(s), with an average return in tens of thousands of pounds, especially if they hospitalise/kill the victim to ensure they don't get to cancel the cards.

Sometimes doing a Google News search for debian turns up some fascinating little gems. Today’s was this article:

Einfeldt says that the project also plans to sell copies of the film, or at least one of the versions of the film. Taking a cue from the Debian project, Einfeldt says that there will be several versions, starting with the edit codenamed “Buzz.” He says that there will be another version codenamed “Rex” that will be sold on DVD and through other avenues like Lulu.com that cater to self-distribution.

Some interesting quotes in the article from Postgresql hacker and SPI treasurer Josh Berkus, along with a link to the Digital Tipping Point wiki.

I'm currently debating whether to go to linux.conf.au or not. I'd really like to go, because I didn't make it to Dunedin last year, and it really is the most rocking conference in the world. The catch is, I've already scored two work-funded trips this year, and I will have only barely returned from the second one by the time I'd be wanting to head off to Sydney again, so I don't feel right about asking for work to fork out for this, even though it's reasonably justifiable. I also want to go to Debconf in 2007, and I'd rather that one be covered. So I'll feel more comfortable forking out for it myself. So I now have to decide whether it's worth the airfare, the negative vacation balance, the two 20 hour flights in a week joy that is flying from San Francisco to Sydney and back again. And all I have to base this on is the title of the presentation and the presenter's name. Oh, the huge manatee! That said, on the face of it, there's enough tracks with at least one presentation that look like they whet my appetite that I would be prepared to go based on the face value of the program. I'll mull it over some more.

I just left a bunch of debian IRC channels, and only stayed in the DebConf ones and some technical ones I'm really interested in. While I can sadly admit this is related to be being frustrated by the way Debian has evolved recently, it's only partly because of that.

IRC is quite a timesink (ironically thats the name of my media server at home...) and I need to focus a lot more on stuff that brings money, cause I neglected that too much since I (again) became a freelancer more than two years ago.

Last weekend I've tested d-i on powerpc and I have 6 bugs or so to file, but I could only find the time to file one bug so far. Luckily the others are less serious :) (And even more luckily for me I have done my taxes now, which was the reason I only did the tests but didn't report them immediatly.)

I also have three blog posts half prepared, but no time and/or energy to finish them. One is about my new development toy, an imac, which I use for testing d-i and debian-edu powerpc. This is nothing really special, but the nice thing, besides bringing debian-edu to more archs than i386 (please contact me if you are interested in amd64...) about it is my old friend FAI, which helps me^w^wtakes care that I have to do nothing to get the machine back into the state I want it after I erased the installation to test stuff.

The 2nd one I will actually post later today and about the third one, I don't know.

I hope this plan works out and I will also find some time in future to work on the things in Debian I enjoy and/or find important. But at the moment unfortunatly doing stuff I don't enjoy is more important, as it pays the bills... Luckily this is only partly true, two out of three of my money projects are actually (mostly) fun. Only one is a pain, but it's the biggest and the most urgent one.

/me waves, see you later :-)

With all the talk about binary drivers, and Ubuntu's recent decision to ship them by default, I was going to try and rant or philosophize about the various issues it raises, and how I think ripping Ubuntu a new one for this move is justified, but instead I'm going to talk about kitties and happy things.

On the XSF front, the coolest news has come from people other than me. In addition to providing compiz updates and improvements, Thierry Reding has been busy cleaning up the Debian mesa packaging in the XSF repo. Mesa's Debian maintainer hasn't been very active over the past few months, so Thierry has stepped in to help out there.

Julien Cristau, who helped in the early work moving from XFree86 to Xorg, has returned to the XSF to take over maintainance of xterm, which I've almost completely neglected. Both these packages needed more dedicated maintainance than I could provide, and it's great to see them both being beaten in to shape.

Drew Parsons has been as industrious as ever, packaging updates for drivers so we can ship Etch with driver support that is very close to what will be released upstream as 7.2. In addition, he's packaged the modesetting branch of the i810 driver. This is an experimental development branch that will become the mainline in the nearish future, and it basically allows the driver to set modelines that aren't specified by the BIOS, just like other drivers.

Christian Perrier continues to rock the translations.

I've been doing unglamorous work bringing the Xorg docs in to the late 90's, thus making sure that we ship with docs so that users can tell what's on their systems.

Finally, Thierry has put a ton of work in building infrastructure to move the XSF svn repo over to git. I've been evaluating this, and hopefully we can make the move soon so that we hit etch+1 development running. Using git will provide an easier means of pulling from and pushing to upstream. Hopefully, downstream derivatives will also use git as well to facilitate this. I'm really excited about all of this because it feels like we're active across the board.

And now for the kitties. Nicole and I have adopted a cat. We get to take her home from the shelter next Wednesday, so if some random characters start to appear from me on irc, it's probably her fault. Rest assured that when I never run for DPL, she will be a far better running mate than Zeke. As a favor I would like to ask you, all my loyal readers: if I start to talk about my cat constantly, like one would one's own child, please punch me in the kidney. Thank you.

I was in a discussion about flash on a closed mailing list, so I'll post my comments here.

I believe that flash will soon be suitable for main storage on most desktop and laptop machines (which means replacing the vast majority of the hard drive market). Flash survives mechanical wear much better than hard drives (flash storage in a camera will usually survive the destruction of the camera), it produces less heat and less noise, and it has better seek times. It is more expensive, although the price is coming down and the main problem now is the number of writes that can be made.

Flash is widely regarded as being slow for bulk IO (benchmark results I have seen approach 10MB/s - while 60MB/s is common for cheap desktop IDE disks). I am not sure how much of this is inherent to flash technology and how much is due to the interface used to access the flash. I often work with Gig-E networks, but for my home use I only have 100baseT, so I have little need for more than 10MB/s IO rates at home.

It is generally regarded that a sector of flash storage wears out at between 10,000 and 1,000,000 writes depending on how recent the hardware is and who you talk to (some vendors are more optimistic than others regarding the usable life of their devices).

Let's assume that you have a 32G flash module running JFFS2 with an average of 2G free (30G of long-term data that doesn't change and 2G of space that is used for new files). Let's assume that the most pessimistic prediction for flash reliability of 10,000 writes happens to be correct. So if 10,000 writes are to be made to that 2G of space that means 20T of data written! If we assume that the machine will be obsolete in 5 years then that allows us an average of just over 10G of data written per day (20,000/365/5=10.9). On my laptop iostat reports the following after 5 days of uptime:

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
hda               1.94         9.94        20.33    4614118    9439808

I believe that this means an average of 20 blocks were written per second over the last 5 days with a block size of 4K (page size), this means 6.6G per day. Clearly something is wrong with my laptop as there should not be so many writes, but even so I wouldn't expect it to wear out within 5 years if I used only flash storage. Incidentally I do a lot of travelling and generally find that I'm lucky if a laptop hard drive lasts three years. So I could expect flash to last longer than a hard drive for my laptop use.

When flash fails I believe that only a small part of the data will be lost, which is better than the hard drive failure condition which is often to lose everything!

Also there is nothing preventing you from creating a RAID-1 of flash devices. Last time I checked the JFFS2 kernel code didn't support such things but that could be fixed if there was suitable hardware.

Note that JFFS2 is vastly preferable to using Ext3 or similar filesystems on a flash device. Flash needs wear-levelling (spreading the write load over all parts of the disk) for sane operation. JFFS2 has this built in to the filesystem, while Ext3 etc are designed to repeatedly write the same parts of the disk. This means that to use Ext3 you need a mapping layer that does wear-levelling which causes inefficiency. Also JFFS2 has compression built in (same method as gzip). This is good for smaller flash devices (EG the 32M storage that was common in iPaQs), and also reduces the wear on larger storage.

The biggest problem for me in using flash at the moment is the lack of support for XATTRs (needed for SE Linux) in JFFS2. KaiGai Kohei has been working on this, it's been a while since I checked on the progress so I'm not sure if it's got into the kernel.org repository yet.

Another problem with flash is that it is totally unsuitable for use as a swap device. This means that you need to have so much RAM that swap is not needed. Fortunately desktop machines with 2G of RAM are becoming common.

I finally got myself a nice digital camera. Nice as in, it fits in a pocket, it takes reasonably good-looking pictures, ant it's not a Canon so I can access it as an USB mass storage device. (For those who care, it's a Kyocera/Contax U4R.) So I've started using F-Spot (which is tremendously cool) and Gallery a bit more intensively than previously, and I noticed something curious: my pictures had wrong times. I thought that digital cameras stored them inside the picture files... Hmm. On to investigate. Time passes as I follow the threads of the information flow (use the source, Luke). Then I scream in horror. Then I go see something I hope is authoritative and therefore likely to have been well thought-out (read the spec, Luke). Then I scream some more. Let it be widely known that the Exif specification, which is the standard for embedding metadata into image files from digital cameras, encodes the date and time of the picture as a string. A fat, ugly, 20-character string. More precisely, the format is YYYY:MM:DD HH:MM:SS. I don't have anything against strings, they are rather easy to parse by humans (as demonstrated by strings /home/roland/images/photos/contax-u4r/kicx0700.jpg head). But they should be done right. In this case, it would have made a lot of sense to enlarge that string to 26 characters and add +ZZZZ or something similar. So as to be able to encode, say, a timezone, for instance, in order to, say, have dates and times that actually mean something, instead of something that may or may not be the current time plus or minus a random number of hours and minutes. I thought I could cheat by starting F-Spot with TZ=UTC f-spot (among my electronic gadgets, those that can't cope with timezones are set to UTC, with the exception of my alarm clock). The result is bizarre: the date is shown as being one hour late. I could understand if it were two (I'm at UTC+2 these days), but where does that one come from? I suppose I'll have to cheat differently, by keeping a patched version of F-Spot that interprets the TimeDate data from Exif as UTC, instead of using the current timezone. Or maybe I could do that in my hotplug script: it already rsyncs images from the digicam to the harddisk then makes sure the digicam's memory has at least $foo megabytes of free space on the card memory. I suppose it could also fiddle with the Exif tags on the fly. Anyway. People need to learn: text without encoding information is useless, cryptography without a web of trust is useless, and date/times without timezone info is useless. If one of my esteemed readers happens to be (or know) a member of the Exif specification group (I understand it's called "JEITA"), please tell them that this needs to be fixed in a future version of the spec. I suppose I'll have to live with it with my current digicam, but maybe the next one will be better in that regard. The pictures themselves are nice, though.

So I spent most of the (long) week-end hacking on various things, and behaving geekishly. Gforge 4.0 packaging goes along rather nicely. Packages built from current CVS won't use LDAP anymore (except for the old gforge-mta-exim, but you really should be using gforge-mta-exim4 or -mta-postfix by now). Shell accounts, e-mail redirection and mailing-list resolution now use direct PostgreSQL lookups. No more install-ldap.sh scripts running hourly and taking forever. No more nightmares setting up slapd and trying to clean after it when it explodes. Yay! Other news, on the video front: okay, I gave in, I finally accepted the next-best-thing that so many people have sent me. My raw1394 and dv1394/host0/PAL/out device nodes are now statically created by me, and symlinked by udevd via links.conf. Urgh. It means I can grab video from the camcorder, edit it, and export it back to the camcorder, all that in the same Kino session (and under a reasonably current 2.6 kernel). Editing video is nice, but it's not very useful if you have to carry your camcorder along at all times to show people, though. So I wanted/needed a free, working encoder for a nice codec that I could use. I wanted Theora. I whined for sometime, and I finally understood that Kino wouldn't have anything to do with it, and I had to use ffmpeg2theora. Blargh. Whatever, I grabbed it from upstream and packaged it (it's at http://roland.mas.free.fr/debian/ if you want it -- someone please ITP it, take it, write a manpage, and upload it to Debian). Now Kino can export to Theora, cool. Now I just have to find one media player able to play Theora correctly, and things will be fine. Xine only wants to play the Vorbis (audio) track, and shows me a visual representation of it. VLC is fine after like fifteen seconds, but it starts by playing audio too fast, then slows down, while video takes long before coming, then it comes up too fast and slows down to a normal speed too. As for totem-gstreamer... It starts by playing audio fine, but video is about 5-6 times too slow for as long as there is sound to play. When the end of the audio track is reached, all the video is played as fast as possible (and in total silence). Oh, and I also got my ass kicked at Freeciv. I used to play Civilisation for days in the good old Atari ST days, but I seem to have forgotten quite a lot. Or maybe I was no good to start with, who knows, the AIs never told me. So I need to practice against AIs, I suppose, before I next connect to a game server. Okay, so I spent the whole weekend on a computer. So what? It was raining anyway.