We had a tough time getting out of Encinitas yesterday. It seems like everything was going wrong. I'd forgotten to order food for a sick aunt and her family in New Jersey the night before, so I was scrambling with apologies and new orders all morning. Then, when we finally got out of town, we hit traffic for about an hour near Santa Ana. Blech! Fortunately, it's a nice stretch of California highway, and we could see Catalina Island off on the horizon to the west. Our Christmas-eve-eve (or Festivus, if you will) was spent at Maj's parents' house in Long Beach, with about 30+ Jenkinses plus various offshoots and friendly relations. They have a huge house near Long Beach/Belmont Shore, with a giant tiled patio area that goes right into the house. It was a good place for a party. Amita June got some nice gifts from family, including a screaming monkey doll dressed as Superman. Yeah, we already have one screaming monkey doll with an "I LA" t-shirt, so this new one will join our growing collection of screaming monkeys with poor sartorial taste. tags: christmas belmont shore festivus long beach amita june

Typewriters are broken Yesterday Amita June and I were playing with pyKeys, from the awesome pyToddler suite of tools, and I realized that typewriter keyboards are broken. I was showing her that when she pushed on the key marked "Q", a "Q" would appear on the screen. But that's not what happened: instead, a "q" appeared on the screen. That's not a bug in pyToddler, of course: that's just the way typewriters work. If you click on the button marked with a capital letter, it prints the lowercase letter on the paper or screen. To get the capital letter itself, you have to put the keyboard in another mode, or use a modifying chord key. I'm not sure why this is the case. It's clear why we use modifier keys to make capitals, since we type lowercase keys much more often. But why do keyboards show the capitals printed on the keys, then? tags: typewriter keyboard pytoddler pykeys

Free Culture Christmas If there's anything that gives a bracing jolt of Christmas cheer, it's 235 Creative Commons Christmas songs. Thanks to Uwe Hermann for compiling this fine list. tags: cc christmas open content music christmas song

One of the reasons I have only blogged 21 times in thirty months is because of the very kludgey work flow I had for blogging; I had to manually create the file, and then scp by hand, and ensure that any ancillary files were in place on the remote machine that serves up my blogs. After moving to ikiwiki, and thus arch, there would be even more overhead, were it not so amenable to scripting. Since this is arch, and therefore creating branches and merging is both easy and natural, I have two sets of branches -- one set related to the templates and actual blog content I server on my local, development box, and a parallel set of branches that I publish. The devel branches are used by ikiwiki on my local box; the remote ikiwiki uses the publish branch. So I can make changes to my hearts content on the devel branch, and the merge into my publish branch. When I commit the publish branches, the hook function ensure that there is a fresh checkout of the publish branch on the remote server, and that ikiwiki is run to regenerate web pages to reflect the new commit. The hook functions are nice, but not quite enough to make bloggin as effortless as it could be. With the movge to ikiwiki, and dissociation of classification and tagging from the file system layout, I have followed the lead of Roland Mas and organized my blog layout by date; posts are put in blog/$year/$month/$escaped_title. The directory hierarchy might not exist for a new year or month. A blog posting may also show in in two different archive indices: the annual archive index for the year, and a monthly index page created for every month I blog in. However, at the time of writing, there is no annual index for the next year (2007), or the next month (January 2007). These have to be created as required. All this would get quite tedious, and indeed, would frequently remain undone -- were it not for automation. To make my life easier, I have blogit!, which takes care of the niggling details. When called with the title of the prospective post; this script figures out the date, ensures that the blog directory structure exists, creating path components and adding them to the repository as required, creates a blog entry template, adds the blog entry to the repository, creates the annual or the monthly archive index and adds those to the repository as needed, and finally, calls emacs on the blog posting file. whew.

Zack asked for website meta languages for redoing his homepage. Well, I redid my homepage last february, using XML and XSLT. A monster XSLT stylesheet, because I wanted to keep my template outside of the stylesheet. I can not recommend XSLT. Using it for templating is quite messy. XSLT is okay if you want to transform one representation of the data to another; it's not if you want to add a lot of surrounding markup and things like a sitemap and similar navigation tools. This is next to impossible in pure XSLT, it gets better once you have some extensions (dubbed EXSLT, and supported by pretty much any xslt processor) or maybe with XSLT2. String manipulation is also a pain (at least with XSLT1); I gave up on generating a nice "last modified" date from my subversion tag. Supposedly XSLT2 has some functions that could make this easier (i.e. for parsing and printing datetime information), but the common approach with XSLT is to only supply the required minimum of function you need, and I'm not aware of an easy way to add custom functions, not to mention any large standard library that can efficiently be used (which is the true strength of Java, Python and C#, that they bring a huge collection of pre-written ready-to-use code with them). Of course there are some efforts to write XSLT libraries (especially for XSLT2), and this aforementioned EXSLT is some kind of standard library that even might be efficiently implemented in some interpreters - you can't rely on it to be there and to just work. XSLT isn't useless, but when it comes to presenting data to humans or writing clean, compact code it's not satisfactory at all. I'd give you my Makefile and XSLT file, if they weren't that messy... too many features; I'm generating two languages, a partially expanded navigation menu, etc. - my XSLT is 10k, my sitemap currently 4.5k, the template file is 5k. Anyway. Half a year ago, my favourite templating language was KID templating. I used it for some small projects such as my DNSoupdate tool to edit DNS zones via the DNS protocol (requires a nameserver such as bind which has support for DNS update, uses encryption). It was a perfect match for such tiny pages, but I'm no longer that convinced I still like it for larger projects. What's good about Kid: XML templating language, Python based, easy to use in whichever way you want by writing a few lines of python (i.e. easy to write a Makefile to generate a static version of you homepage) What's not good about Kid: only works with a Python interpreter. I'd prefer to have a templating language that can be used from multiple languages. However the Kid syntax relies on Python, which is really bad. Also I'd prefer to have some component-render model for more complex websites. The current setup is IMHO okay if you have one default layout and one content layout; but if you have multiple components that could be combined differently on the pages, it gets too messy. With my turbogears experiments, Kid was also not very performant (but that might as well be Turbogears fault). Right now, I'd probably still go with Kid. But I've been having a look at JSP 2.1, and JSF / Facelets in particular. There are some things about facelets that I really like (for example, that they use a proper XML syntax, instead of this bastardized almost-XML that JSP usually (ab-)uses). There is also some stuff that I don't like (e.g. the massive overengineering of everything surrounding it), and I have no idea how easy it will be to generate static pages in a scripted fashion, i.e. using it without a real webserver. Or I might just write it all in python, which is a nice language for manipulating XML, usually. Please don't just send me an email with your favourite templating engine. Like zack, I'm only interested in XML-based templating engines, which does not apply to most templating solutions out there. Clearsilver for example is another bastardization of XML. I'm aware of TAL/METAL, and find them quite interesting, but they were also not having this kind of componentization that I'm usually thinking in. [Update: some people have pointed me to Genshi, which is mostly Kid compatible. However, it still has mostly the same problems, e.g. the templates being not reusable in other languages than python, and that certain constructs are a pain to do (e.g. the page_specific_css recipe with more than one css file). Others have pointed me to smarty, but it's string-based and doesn't ensure valid XML output. (Which is very useful for e.g. generating atom or rss output) For example this is probably valid in smarty: if 0 <b> /if </b> - allowing errors is bad. Oh, and smarty is PHP, which is broken by design, a no-go. The best match to my ideas so far is XML::Template (for Perl, Python, Ruby, PHP) which is pretty close to what I've been doing manually when not using a templating solution. I don't know yet how well it handles recursion - I need recursive templates for the navigation menu on my homepage.]

The first step is to configure the CRM114 files, and these are now in pretty good shape as shipped with Debian. All that I needed to do was set a password, say that I'd use openssl base64 -d, and stick with the less verbose defaults (so no munging subjects, no saving all mail, no saving rejects, etc, since I have other mechanisms that do all that). The comments in the configuration files are plenty good enough. This part went off like a breeze; the results can be found here (most of the values are still the upstream default). The next step was to create new, empty .css files. I have noticed that creating more buckets makes crm114 perform better, so I go with larger than norm crm114 .css files. I have no idea if this is the right thing to do, but I make like Nike and just do it. At some point I'll ask on the crm114-general mailing list.

    % cssutil -b -r -S 4194000 spam.css
    % cssutil -b -r -S 4194000 nonspam.css

Now we have a blank slate; at this time the filter knows nothing, and is equally likely to call something Spam or non-Spam. We are now ready to learn. So, I girded my loins, and set about feeding my whole mail corpus to the filter:

 /usr/share/crm114/mailtrainer.crm               \
   --spam=/backup/classify/Done/Spam/           \
   --good=/backup/classify/Done/Ham/            \
   --repeat=100 --streak=35000                  \
         egrep -i '^ + train Excell Running'

And this failed spectacularly (see bug #399306). Faced with unexpected segment violations, and not being proficient in crm114's rather arcane syntax, I was forced to speculation: I assumed (as it turns out, incorrectly) that if if you throw too many changes at the crm114 database, things rapidly escalate out of control. I went o to postulate that as my mail corpus was gathered over a period of errors, the characteristic of Spam drifted over time, and what I consider Spam has also evolved. So, some parts of the early corpus are at variance with the more recent bits. Based on this assumption, I created a wrapper script which did what Clint has called training to exhaustion -- it iterated over the corpus several times, starting with a small and geometrically increasing chunk size. Given the premise I was working under, it does a good job of training crm114 on a localized window of Spam: it feeds chunks of the corpus to the trainer, with each successive chunk overlapping the previous and succeeding chunks, and ensuring that crm114 is happy at any given chunk of the corpus. Then it doubles the chunk size, and tries goes at it again. All very clever, and all pretty wrong. I also created another script to retrain crm114, which was less exhaustive than the previous one, but did incorporate any further drift in the nature of Spam. I no longer use these scripts; but I would like to record them for posterity as an indication of how far one can take an hypothesis. What it did to was have crm114 learn without segfaulting -- and show me that there was a problem in the corpus. I noticed that in some cases the trainer would find a pair of mail messages, classify them wrongly, and retrain and refute -- iteration after iteration, back and forth. I noticed this when I added the egrep filter above, and was not drowning in the needless chatter from the trainer. It turns out, I had very similar emails (sometimes, even the same email) in the Ham and the Spam corpus, and no wonder crm114 was throwing hissy fits. Having small chunks ensured that I had not too many such errors in any chunk;and crm114 did try to forget a mail differently classified in an older chunk and learn whatever this chunk was trying to teach it. The downside was that the count of the differences between ham nd Spam went down, and the similarities increased -- which meant that the filter was not as good at separating ham and Spam as it could have been. So my much vaunted mail corpus was far from clean -- over the years, I had misclassified mails, been wishy-washy and changed my mind about what was and was not Spam. I have a script that uses md5sums to find duplicate files in a directory, and found, to my horror, that there were scores of duplicates in the corpus. After eliminating outright duplicates, I started examining anything that showed up with an ER (error, refute) tag in the trainer output; on the second iteration of the training script these were likely to be misclassification. I spent days examining my corpus and cleaning it out; and was gratified to see the ratio of differences to similarities between ham and Spam css files climb from a shade under 3 to around 7.35. Next post we'll talk about lessons learned about training, and how a nominal work flow of training on errors and training when classifiers disagree can be set up.

In part 1, I described the problem of software installation on Linux; in part 2, I’ll describe the solution we came up with at the recent LSB Packaging Summit. After reading through the comments to part 1, let me first point out that our goal is to create a vibrant third party software ecosystem around Linux—you know, like the one Microsoft has built around Windows. No, it’s not about imitating Microsoft. It’s about being competitive. A platform is only as good as the applications that run on it. Bottom line: Many third parties have built their businesses around proprietary software, and we can’t just ignore them. And “ecosystem” implies decentralized, which I argued in part 1 was a key tenet of open source development anyway, i.e., this should be playing to one of our core strengths. So, if your “solution” is to tell ISVs (independent software vendors) to give us their source code so the distributions can include it because that’s just how we do things, you can safely skip the rest of the post below. You’re simply not going to agree that any of this is a problem. Ok. Assuming our goal is to create a vibrant third party software ecosystem (and everyone still reading agrees that’s a good goal, right?), we have the following challenges. First of all, the distribution vendors are hugely invested in their existing package systems, and for the most part, those package systems work extremely well. As I said in part 1, “if [an application] is in your distro of choice, you re only an apt-get or a yum install away from running it.” (I’m saying it again here because some of the commenters apparently didn’t see that. The tricky bit is “in your distro of choice”, which by definition is not the case with third party software.) Furthermore, a variety of highly sophisticated systems management solutions are built above those package systems, such as Red Hat Network and Novell ZENworks. This is a pretty important consideration, because these days, the “software management problem” largely involves managing software across the entire infrastructure, not just a single system. What problem then? This: ISVs have thus far been reluctant to use the native package systems. Why? THEY’RE hugely invested in “package systems” for other platforms, and every Linux specific thing they have to support costs money. In a world where decisions are ruled by cost vs. benefit, this is a pretty important consideration too. How do ISVs handle this today? For the most part, they ignore the package systems on Linux and do their own thing. Trouble is, while doing their own thing gives ISVs the flexibility to work cross platform, it ultimately makes their products integrate poorly in the broader systems management context because the package systems know nothing about them. What is needed is a way to bridge the gap between what the distros provide and what the ISVs want. But how? First off, we have to understand what ISVs want. The answer is simple: ISVs want to treat Linux as a single platform, which means they want to offer a single package for Linux, much as they do for Windows. So, if one commenter is right that “[t]he problem is that people (including software distributors) believe there s such [a] thing as ‘Linux’ as a target platform” and that “[i]f you re distributing software for ‘Linux’ then it won t be simple to install it, ever”, well, then Linux is destined to suffer the fate of UNIX. I’m not ready to give up so easily. Several commenters suggested that what we need is a brand new package system. That’s a non-starter—for one thing, the distros aren’t going to be too keen on replacing something they’re hugely invested in, and if ISVs aren’t going for RPM today, why would they go for something different tomorrow? No, to find a way forward, we need an evolutionary step from where we are today. From there, perhaps we can do more, but even the first steps can be quite valuable in their own right. To help find those first steps, we put some of the leading minds in Linux packaging in the same room (including the maintainers of RPM at Red Hat and Novell and the authors/maintainers of APT, yum, alien, and klik) along with ISVs large and small, server and desktop. The discussion pretty quickly converged on constructing a single API that could be implemented across the various package systems, because APIs make for nice evolutionary steps and can, done right, mask underlying implementation differences. Question is, what do ISVs need in such an API? Limiting the scope is key here, because providing an API that spans all the functionality of, say, RPM and dpkg is overwhelming to the point of being unworkable, not to mention more work to implement, which in turn makes it less likely to get into the distros so that ISVs can count on it being there, the whole point of this exercise in the first place. Fortunately, the ISVs don’t really need much. At the most basic level, an installer just needs to be able to query the system to see if it’s LSB compliant, and if it is, what version of the LSB it’s compliant with; and it needs to be able to “register” with the package system, so the package system knows about it, including what files it has installed. And that’s really about it. Importantly, because we assume an environment that’s LSB compliant, we don’t have to worry about dependencies, because everything is covered by the single LSB dependency, and dependency management is 95% of the package systems right there. We still need minimal dependency support—components can extend the LSB, and applications can depend on those other components being installed—but we’re talking on the order of a handful of components, not the tens of thousands of components typical package systems have to deal with. We only had a day, so we obviously don’t have a complete solution yet. For one thing, we barely touched on the issue of uninstallation (should we allow applications to register GUI uninstallers?), and the issue of how applications go about changing the system configuration still needs discussion (in a lot of cases, the assumption of LSB compliance means the installer is going to be well behaved, but there’s undoubtedly corner cases to be explored). And it’s going to take time for the API to be implemented and put into widespread enough use that ISVs can depend on it. However, everyone in the room did come to consensus pretty quickly that this was an important problem, and that providing a simple API that provides the minimum necessary functionality was the way to go. Perhaps most exciting, the very people whose support are needed to put the API into widespread use were in that room, and active participants in the discussion too. Everyone is certainly motivated: The distros get more applications, which makes the shared platform more attractive; and ISVs get lower cost, which tilts the cost vs. benefit equation in their favor, making Linux versions more economically attractive and potentially opening new markets. Because this is just a start, the FSG is launching a Packaging workgroup to continue the discussion we started at the Packaging Summit. If you’re interested in this topic, I’d encourage you to join the mailing list and get involved. There’s still plenty to be done. Update: One more thing: In addition to making it easier for ISVs to better support Linux by simply extending their existing installation scripts, the API approach really comes into its own when you imagine it implemented in things like Autopackage and InstallAnywhere. Let the market decide!

I have a fairly sophisticated Spam filtering mechanism setup, using MIMeDefang for SMTP level rejection of Spam, grey-listing for mails not obviously ham or Spam, and using both crm114 and spamassassin for discrimination, since they compensate for each other when one of them can't tell what it is looking at. People have often asked me to write up the details of my setup, and the support infrastructure, and I have decided to oblige. What follows is a series of blog posts detailing how I set about redoing my crm114 setup, with enough detail that interested parties can tag along. I noticed that the new crm114 packages have a new facility called mailtrainer, which can be used to setup initial css database files. I liked the fact that it can run over the training data several times, it can keep back portions of the training data as a control group, and you can tell it to keep on going until it gets a certain number of mails discriminated correctly. This is cool, since I have a corpus of about 15K Spam and 16K ham messages, mostly stored on my previous train-on-error practice (whenever crm114 classified a message incorrectly, I train it, and store all training emails). I train whenever crm114 and spamassassin disagree with each other. This would also be a good time to switch from crm114's mailfilter to the new mailreaver, which is the new, 3rd Generation mail filter script for crm114. It is easier to maintain, and since it flags mails for which it is unsure, and you ought to train all such mails anyway, it learns faster. Also, since the new packages come with a brand new discrimination algorithms which are supposed to be as accurate but also faster, but may store data in incompatible ways, I figured that it might be time to redo my CRM mail filter from the ground up. The default now is "osb unique microgroom". This change requires me to empty out the css files. I also decided to change my learning scripts to not send command via email to a 'testcrm' user, instead, now I train the filter using a command line mode. Apart from saving mails incorrectly classified into folders ham and junk (Spam was already taken), I have a script that grabs and saves mails which are classified differently by crm114 and spamassassin from my incoming mail spool and saves it into a grey.mbox file, which I can manually separate out into ham and junk. Then I have a processing script, that takes the ham and junk folders and trains spamassassin, or crm114, or both; and stashes the training files away into my cached corpus for the future. In subsequent blog postings, I'll walk people through how I setup and initialized my filter, and provide examples of the scripts I used, along with various and sundry missteps and lessons learned and all.

Kudos to Adam Kennedy, who explained more details on his very controversial Acme::Playmate talk and sort of apologized for his failed attempt at satire. He also writes about it here.

Food for thought:

• When you make a mistake, don t look back at it long. Take the reason of the thing into your mind and then look forward. Mistakes are lessons of wisdom. The past cannot be changed. The future is yet in your power. (Hugh White)
• Mistakes are a part of being human. Appreciate your mistakes for what they are: precious life lessons that can only be learned the hard way. Unless it s a fatal mistake, which, at least, others can learn from. (Al Franken, Oh, the Things I Know , 2002)
• Assert your right to make a few mistakes. If people can't accept your imperfections, that's their fault. -- Dr. David M. Burns

I’ve spent the last few days in Badajoz for the Debian QA meeting in Extremadura. It was my first Debian event, and it was really nice to finally meet all those developers I only knew over the Internet until then. The organisation was very good in general, and C sar G mez really deserves kudos and some rest now In addition to the usual mail processing, I worked on a few things:

• I processed some logs from a rebuilt of all packages in etch and filed about 20 RC bugs about FTBFS. I also did several libpng-related rebuilds, checking that etch packages that b-dep on it still build with the proposed new version. And I investigated a few bugs.
• I also worked on a dirty script to generate the List of packages with problems wrt release (packages in etch with RC bugs, or packages in unstable but not in testing). See the list sorted by maintainer, and the list sorted by popcon score. Despite the unavoidable high number of false positives, I think that some maintainers were actually unaware of the status of their packages, so the list was probably useful.
• I gave a talk about Collaborative QA. The idea is try to move from the current non-organisation (QA one by a bored developer, on his own, because the release is approaching) to a more organized structure (team ?), allowing to share the load and share information (blacklists, false positives lists, processes, etc). I’m not sure yet if this will work, because many people consider that the current way of working on QA is OK, but I’ve created the collab-qa alioth project, and will try to use it to store information about my archive rebuilds. More to come about this later.

In general, I was pleasantly surprised by the fact that all DDs there were very friendly, welcoming, etc. Quite different from the picture of the Debian project one can easily get by looking at the mailing list. It was really nice to have so many interesting discussions with interesting people.

I'm pretty happy to note that I've been invited to speak at South by Southwest Interactive in March on the subject of wikis and commercialization. I'm pretty psyched about the subject, as I think a rich and varied ecosphere of wikis -- from personal to informal clusters to formalized non-profits to formalized commercial ventures -- is a necessary step to the development of a read-write Web. OK, so, it wasn't like they invited me out of the blue -- I submitted an idea for a wiki panel a few months ago, and it got morphed into a one-person presentation instead. Which will be fun, since I'll be able to pontificate at length on this interesting subject. Maj booked us our hotel rooms in November -- I wanted to stay at the Austin Motel, but they have some kind of one-time callin system for the week of SxSW, and their rooms sell-out in an hour or so. We missed the callin time, which was no big deal. tags: austin wiki sxsw austin motel sxsw2007

Recidivista Bad Vista is a clumsy and confusing name. Who's running the Wordplay Department over at the FSF nowadays? I hope it's some wily Germans, and that "Bad Vista" is some sort of elaborate spa joke. But for some reason I doubt it. Offer to the FSF: I just registered recidivista.org today. It's an awesome name. It is yours for free if you promise to use it well and be funny instead of shrill. Deal? tags: fsf bad vista vista recidivista

Maptastic I'm pretty happy to note that I got around to developing a new MediaWiki plug-in that uses the Mapstraction library to switch between well-known-but-proprietary mapping services like Google Maps and unknown-but-open-and-cool services like OpenStreetMap. Each page on Wikitravel that's had some geo-data RDF magic added to it gets a link to the Mapstraction page, which will focus on that destination. Eventually it will have icons for each museum, restaurant, bar, hotel, or other feature of the city, and you could move them around or even edit their information through the map interface. But, for now, I'm starting small. More map-centrism will come with time. You can check out Montreal for an example of a mapped-up page right now. tags: mapstraction geohacking wikitravel RDF wiki maps

C-List So, I like this Are you an A-list Bloglebrity? tool on kineda.com. A simple re-packaging of some publicly-available data from Technorati, ranking blogs into lists by authority. Excellent hit-mongering. I'm sad to say that I'm still in the C-list on the blogging front, but that's really just dependent on longevity. I've only been doing this since last May -- errr, Flor al -- which is just 7 months (that's 49 months in blog years). If the A-list gets the Lear jets and the red-carpets, I don't know what kind of perks come along with the C-list. Free refills on your orange soda? tags: blogs c-list technorati

Parenthood One of the things that parents often notice is that they have a hard time relating to their non-parent friends. And, of course, single non-parents have a hard time relating to their friends who've bred. Why is it so hard for these two kinds of people to connect with each other? I think there are some superficial reasons, like having different schedules, different imperatives, different needs. But I also think there's something more fundamental about the split. Organisms who've survived long enough to successfully reproduce have realised one goal in life -- if you listen to Charles Darwin, the only goal in life. If you have children, you have found a purpose for yourself -- an answer to all those questions about who you are and what you're supposed to do with your time on earth. If you survive to breed, you have won the game. Now, it's not the only way of winning, and it's not really the most interesting game in town. But I know at least for myself, and for other parents I've talked to, there is an existential satisfaction in finding yourself almost accidentally filling this purpose. Having never felt before that I had a definite purpose, it's been a strange sensation. Non-parents don't get the same sensation -- or, at least, they don't get it in the same way. So they're still looking, thinking, questing, trying to find some answers. And that gives them a vibrant edge that fulfillment dulls. I doubt there are many non-parents who would be satisfied with the Darwinian answer to their questions -- spawning like crayfish isn't a very lofty goal in life. Or at least it doesn't seem so from the outside. I'm not sure how to tell my friends how my life's changed since we had a daughter -- how when I'm reflecting and summing up my life, I don't feel the same panic as I did before. It's a good feeling, though. tags: parents parenthood survival reproduction crayfish

Iraqi taxi This blog post with a graphic illustration of the process for a build-your-own Iraqi taxi cracked me up. It was also nice for giving me a link to Wrecked Exotics. No, it's not about drunk strippers, nor orchids that went unfed; it's crashed cars. tags: iraq blog wikitravel wreckedexotics

Interesting article by everyone’s hero Bruce Schneier on real-world passwords. Schneier analyzed the spoils of a phishing attack on MySpace that resulted in the collection of 34,000 usernames and passwords:

We used to quip that “password” is the most common password. Now it’s “password1.” Who said users haven’t learned anything about security?

We‘ll be attending The Killers‘ concert tonight. I’m not completely fan of their synthesized-rock-indie music, but she likes them so much and she made me dig their last album, Sam’s Town, like a thousand times in the car; so I acceded and bought the tickets online. She was even jelaous of a friend who is also attending, heh I wasn’t happy at all since they are still a more or less new band, they only have two albums released and prices for tickets were high as hell (ironic), but her surprise smile worth it, it definitively does.

07 Dec 2006, at the Open Source Developers Conference in Melbourne, at a lightning talk session, quoting Why there s few women in IT, at Richard Jones blog:

The conference last week was educational for the committee in a way that was completely unexpected:

Observation 1: During one of the lightning talks a presenter put some porn up on the big screen. He was peripherally discussing a Perl module called Acme::Playmate (which basically looks up Playmate info on the playboy playmate directory).

We (the committee) had never thought it would be necessary to have to explicitly say that it s not OK to put up porn. Or that we d have to actively discourage discussing a module that would clearly offend members of the audience.

Observation 2: I was amazed that Acme::Playmate exists in (and is blessed by) CPAN.

I spoke before the keynote the next day apologising to the attendees and our sponsors for what had happened.

Observation 3: Some attendees thought that we had overreacted by even saying anything.

At least one woman walked out the conference. The next morning, the organisers apologised to the attendees and their sponsors for the images.

You can read more, including the guy s name at Mary Gardiner's blog entry. Quoting:

I gave a 5 minute lightning talk at OSDC entitled Women in FOSS groups [...]. It was mostly an attempt to jam Adam Kennedy s lightning talk about Acme::Playmate, which featured lingerie shots of women (and maybe topless shots, I didn t want to watch it [...]). So mine featured pictures of women, fully clothed, with labels like Linux user and AI researcher.

I still wonder where the slides from the Debian ftp-masters s talk at Debconf 3 are available from, because of the technical content of the slides was good, only the way it was presented made this ftp-master team like a boys-only club where no women would ever belong. Because it made me want to walkout, but instead I stayed there and almost cried. Update: I found the slides.

Of course, this was 2003, it is all forgotten and forgiven, and Debian, including the speakers that gave this talk, has really changed since The Debian Women Project was started in Brazil, 2004. And I mean really changed. Even the ftp-masters scripts named after Elmo s Angels were renamed in the latest Dak release (look for What does each script do at The DebianEdu ftpmaster-Howto for the cuties names). I am no longer bitter about this. I am even happy it happened because it indeed motivated me to start the whole flamewar, as it even came up on Debian Weekly News - March 9th, 2004.

<peterS> Amaya: as Lincoln once said to Harriet Beecher Stowe: so you re the little woman who started this big war   (/me refers to the now famous -vote thread)

While I sometimes think Debian Women died from success, stories like this remind me why Debian Women is still needed and useful.

I work at the Ministerio de Administraciones P blicas, the MAP. My main task there is to administer an email cluster for something between 8.000 and 10.000 users, based on free software (LDAP, Postfix, Amavis...) which has been pretty fulfilling so far.

The problem they have is a lot of consultants from external companies that come for big or small projects and they know of no easy way of being able to grant enough permissions to achieve certain tasks without giving away the root password and having to change it every other day. I am one of these external consultants, only I am there for a long term project. I have been there for more than a year and a half now, and our contract was just renovated for two more years. This basically means I am doing my job pretty well.

But a couple of months ago, the company I work for, Alanta, agreed with the MAP on me giving a 12h a training session on sudo. After spending 100 hours in preparing my slides on a sudo workshop (spanish only, sorry), starting from file permissions to ssh public-private key pairs, and ending with sudo, a high amount of stress, as I had to work full time as I prepared this in paralel, I bitterly complained to my boss. (That s when the cleaning started, BTW).

So we had a nice lunch in which I was given a 200 EUR 2GB 2nd Generation Silver Ipod Nano. Which is nice, but taking into account that when I worked for IBM as a certified trainer I made something between 24-60 EUR per hour, depending on the subject, and all the material (slides, exercises, TOC and Trainer material) was already done for me, so I just had to prepare and give my lessons, I felt patronized and a bit insulted, even if I did not expect any compensation for this extra effort that really damaged my (mental) health. Getting presents in exchange for hard work doesn t make sense for me, specially when I can hardly make it to the end of the month, constantly being in (small, to be honest) debt.

But you could be making more money, couldn t you? Yes, sure. But at what price? I like the relaxed work environment and the lack of sexism in my current project. I have plenty of spare time, and my life quality is overall great, I can walk home from work, I am not juiced and then disposed of, despite the punctual stressful periods everyone gets every once in a while (which are rare here, at MAP).

And this thing will never run IpodLinux or Rockbox. I feel like I want to throw it out the window. It lacks support for my favourite music file formats, UTF-8 and hangs up more than MS Windows 95.

A few month ago, I blogged a way to spread Free Software effectively, especially in developing countries: By deploying Free Software in internet caf s, where most people learn their way around computers. Most of them (and there are a lot, much more than in Europe) have a buisness plan that relies on software for free, but currently they achieve that through pirating Windows and software like Cybercafe Pro. Back than, I wrote this more or less theoretically, but it happend that I ended up having some time to actually start working on it.While Free Software, especially Debian, provides a very good base to build internet caf s from, one key component is more or less missing: Software to hand out these codes ( timecodes ) to the customer, to let them log in and surf for the time they bought. Very recently, Zybacafe was released, but I did not really like it, nor felt like maintaining a Pascal/Lazarus based Debian package. So I went ahead and implemented my own ideas.The Idea is to keep it very simple, very modularized and integrate deeply with normal unix ideas. So what we have now is a PostgreSQL database (one table so far), and all communication just goes via this table, so we don t have to design or implement complicated protocols. A python gtk application for the front desk generates the timecodes that are then, on paper, passed to the customer. The workstations greet the user with standard GDM, but our pam modules authenticates the timecode instead of a username/password pair. While using the system, a small floating window informs the user about the remaining time. If he does not log out voluntarily, a system daemon will kill all his processes eventually.The long term mission is to form that into a Custom Debian Distribution that will install the server hassle-less, and besides being pre-configured for the internet caf s needs, also immediately serves as an automated installation server for the workstations (think FAI), all useing stock Debian packages, as far as possible. Another pam module could, upon login, mount the homedirectory as a copy-on-write overlay of a template user s home directory, and through away the changes afterwards. The goal is to offer easier installation, less maintenance, better robustness and more flexibility than the current common non-free systems.But, of course, this project needs help. First of all: Users! If you have any use for time-limited logins (Internet caf , school surf terminaly, parents with otherwise not to bed going kids), you can be an earliy adaptor. Developers are very welcome as well, and due to the modular structure, cooperation should be quite smooth.The development happens on alioth, where we have the subversion repositry, as well as on the Debian wiki page. Alpha packages for these components can be found on the alioth group s webspace. We do not have a mailing list yet, but feel free to e-mail me. We will set up a mailing list once there is a need for it. Thank s to the KACE for supporting this.

It looks like November-December are the most popular months for people coming to visit me, or crashing at my place in their way to their final destination.

In November I had the pleasure to host Sulamita, while she was on her way to India. One of the most interesting girls I have met this year.

Baby Jesus left yesterday, after spending several days at my place. He brought Salmiakki, smoked salmon and smoked reindeer with him, which I used to like before I became vegan (and later pescatarian). The salmon was incredible, though.

Just as I was writing these lines, Luk, who was also going to stay at my place before The Extremadura QA Meeting called me from BRU airport claiming his ticket had been cancelled :( I called C sar and found out that the travel agent they work with had not bothered to confirm several people s flights, so he will be coming to Spain on the 13th, just like everyone else. He will not be staying at my place, and will miss out on the smoked reindeer, that will be eaten by some other carnivore, I guess .

The great man I got the Linksys from lies sick in my bed, and spends almost as much time at my place than at his own, so I guess he doesn t count.

Almost one year ago I got a great present from a great man, a Linksys Wireless router with a serial port that he had soldered on it himself, running OpenWrt (White Russian). Sexy!

This toy has made me happy ever since, even though this great man insisted on me using WPA, which basically means most of my friends can t use wireless at my place (blame crappy firmware), and I still, from time to time, have some wire mess around my living room, but that is also fun, specially for the cats, so no complaints here :)

I recently upgraded to White Russian RC6, and this great man pointed me to a wonderful web interface to manage the system with: X-Wrt.
This web interface is very helpful for me, even though I can ssh into the router, I am used to my aliases, longer history, my way of working on the command line, which makes my ssh sessions there a bit frustrating, as I am getting old and a bit reluctant to changes. The web interface also has nice graphs and stats, a beautiful CSS layout, and it makes my life 100% easy. This stuff just works^Wrocks!

The installation system was so easy I was amazed. Just fill in a form with your Linksys IP address, click on install and you are done!

I miss https for the config interface, and I would love to find a Linksys model that supports OpenWrt and does DSL at the same time, so I could get rid of the crappy 3com doing the ATM part in bridge mode. Less devices, less power wasted, less points of failure, happier me.

The amount of packages available for OpenWrt is just amazing, and it has a package manager that slightly reminds me of apt-get. It can even do asterisk!

So if you own any of the supported devices, I encourage you to get rid of the crappy firmware they usually ship with, and have some White Russian fun with it, which also happens to be one of my favourite drinks :)

Enjoy!

I've started playing around with DBus a little. It's somewhat cute, I was able to quickly write a script that monitors my wireless network connection going up and down, and after some searching for useful documentation, I'm now able to tell gaim to disconnect when my wireless goes down and reconnect when it comes back. All with just a few lines of Python. While searching for some docs on the Gaim API, I stumbled upon the Skype DBus API. But it's crap. Evil stuff. (And not working, from what I can tell; I read somewhere they're using a totally outdated DBus version, and to use it you have to downgrade and break lots of other stuff). They've totally bastardized DBus. First of all, the trace of a DBus API I've found is on a system level, not a user/session level. It should be per-session; you especially don't want others to mess with your Skype. Instead of offering an API with sane methods to invoke, they offer a single method, called "Invoke", and a single callback called "Notify". Ouch. With these methods you're expected to do a ascii protocol something like this:

-> NAME UltimateProgram
<- OK
-> PROTOCOL 5
<- PROTOCOL 5

Note that the name choice is up to the connecting application; so you can cloak yourself as a different application; it will be displayed to the user when asking for confirmation, apparently. Another example how crappy Skype dbus is: their "dbus example in C" links to the Python example and the other way round. The C example consists of 2.4 MB precompiled example and about 100k source code (the example of course is a graphical client). For comparison, this is a complete example on how to reconnect all your Gaim accounts via python-dbus:

import gobject, time, dbus, dbus.glib
# get DBus inteface
sesbus = dbus.SessionBus()
gaim_obj = sesbus.get_object("net.sf.gaim.GaimService", "/net/sf/gaim/GaimObject")
gaim = dbus.Interface(gaim_obj, "net.sf.gaim.GaimInterface")

for account in gaim.GaimAccountsGetAllActive(): gaim.GaimAccountDisconnect(account) time.sleep(5) for account in gaim.GaimAccountsGetAllActive(): gaim.GaimAccountConnect(account)