Over the past week or so, I've decided to get around to listening to some of the "amateur" (in the same way that Open Source software is "amateur") podcasts that I've collected in the past couple of months (primarily so I can either archive them, or delete them and free up a bit of HDD space). As a great fan of radio, I've been pretty disappointed at the quality of the podcasts I've listened to. While I hadn't expected the BBC world service, there are a number of quite common mistakes I've noticed across several of the podcasts I've listened to. In the spirit of kaizen, I've noted down the really bad things that I've noticed, in the hope that someone who does a podcast, or is considering doing a podcast, might keep these simple mistakes in the back of their mind and avoid them. No podcast I've listened to so far has exhibited all of these symptoms (there's no way I would have gotten to the end of that hypothetical nightmare audio file) but most have exhibited at least one of these flaws. For a better general idea of how a good podcast might sound, listen to professional radio for a bit -- a lot of good shows are podcast themselves these days -- and get an idea of what a good show looks like. I'm also prepared to go further than just bitching about podcasts. If you do a podcast, and would like my (unprofessional but oh-so-opinionated) assessment of your podcast, please e-mail me at mpalmer@hezmatt.org with a link to your podcast, and I'll try to give it a listen and honest critique.

• Ad-libbing is a sometimes thing. I think I'm quite good at it (I gave my wedding thankyou speech unscripted and unrehearsed, and survived, so I can't be that bad) but I'd never consider doing a podcast without a script. In a podcast, all you have are your words, so if you're searching for words, or mangling them, it all falls apart. The downside to scripting is that you can end up reading your script in a monotone, without any life at all. I think practice with your script can probably improve that, but see the last point below.
• Waffle sucks. I'd say that scripting can help here, but if your script is full of waffle too, then you're SOL. Brutal editing is the only cure. The worst part here is that, since most people silently read faster than they speak, what looks fine on paper turns into something amazingly long and boring when read.
• Avoid meta-podcasts -- that is, don't talk about your podcast in your podcast. Something like "we're always looking for new content, see for more info" is bearable, but when 8 minutes of a 30 minute podcast is taken up with talking about the podcast wiki, mailing list, forum, ouija board, and so on, know that you're killing your audience.
• You do actually need content. Things that somebody out there is going to care about. A regular podcast is a brutal thing to commit to, and sticking to it must be hard at the best of times, but if you've got nothing interesting to say, don't record it, just have a short or missing show. We all know what filler sounds like -- you're not fooling anyone.
• Uhm is your mortal enemy. Not so much the occasional quick 'uhh' in the middle of a sentence, but I've heard "Uhmmmmmmm"s that went for at least 5 seconds. If you're that stumped for something to say, you need more scripting or editing.
• "Funny" voicing can be really distracting. Having a bit of life in your voice is great, but going completely off the charts only works for Robin Williams (and even then it's not a surefire hit).
• Whilst talking faster than a chipmunk on speed isn't a great way to run a podcast, you can easily fall into the trap of going too far the other way, and... talking... like... your... jaw... is... stuck... in... chilled... molasses...
• Why in the name of $DEITY are you reading out a long command line in a podcast? Sure, without the help of something like Annodex it's tricky to do commands and links the way you're supposed to (as text, dammit), but please do try. If your podcast is example-heavy, either consider dropping the podcast angle, or at the very least, provide an annotated transcript or "companion guide".
• You are allowed to do multiple takes of your podcast. Really. Read in small sections, and then stitch it together. Listen and retake a bunch of times until it sounds reasonable. (Aside: my one appearance in a podcast to date was about 15 minutes of recorded audio, before final editing. It took me about 7 hours to do -- admittedly, that included learning how to drive Audacity and do my editing, but I'd say I had at least 2 hours of mic time in there.)
• Some people just weren't cut out for "radio". You may be unable to stop your voice sounding like Lurch, or you get the giggles, or just can't think of interesting things to say "on air" -- whatever the problem is, you may just have to accept that you're better behind a keyboard than a mic. There's nothing wrong with that, but please be self-aware enough to realise it. No podcast I've yet listened to has been "kill it, now!" bad, but since I've only been listening to personal recommendations, I figure I'm mostly listening to the better class of podcast out there, and there's plenty of "give it up, please" podcasts out there.

I was in Oxford on Thursday for the Nominet EGM. There were a variety of changes that they wanted to make and while in general the principle behind them seemed good the detail was a bit worrying, and I believe had been badly communicated. However I was still surprised to find that the vote was defeated; I'd expected a narrow victory. There are some more details on The Register, who were the only people to send someone I believe. What's scary is the percentage of members who didn't vote. Nominet has just under 3000 members. I wouldn't have said more than 60 people turned up to the EGM, and some of them were Nominet staff or multiple people from the same member organisation. Only 10% of members actually bothered to vote. That's quite a pathetic number. Even if you don't take on the view point that Nominet are a member run organisation (and I do and I think they work very well in general and try to do the right thing and promote good practises), this was a vote that would have given the board the right to modify pricing as they wished. Surely that's something you're interested in even if all you do is treat Nominet as a normal supplier? There's more to the changes than that obviously, but I would have thought price changes were something that might at least make beancounters sit up and take notice. Do you work for an organisation who's a Nominet member? Were you aware there was an EGM taking place? Did your organisation vote? Are you aware there's a PAB election starting from this Friday? Are you planning to vote? Have you ever been to an AGM? If not, why not? What about the members lunches? It's somewhat disappointing to see such a low level of member involvement. Nominet do seem to try to talk to people and get their opinions, but you have to actually turn up for that to happen...

I've decided to take a look at emacs-muse (muse-el Debian package).I share many of JoeyH's sentiments with regards to what wiki should have.But maybe that's only an evidence that I'm an old-type.One thing I liked about emacs-wiki (which is what emacs-muse is a fork of)is that it allowed editing of wiki files from emacs, or whatever plain text editor,and allowed viewing of HTML after processing. They are just plain text, and can be controlled with version controlled systems.There was this nifty thing called elserv-wiki, which made emacs a webserver, and allowed wiki editing, but apparently, it's not available for museyet, and thus I can't make it a fully-fledged wiki engine.I'm slowly exploring the space.Apparently, emacs-muse doesn't really work right now for Japanese PDF generation, somebody needs to hack on it. HTML output works, so no problem right now.RSS output seems to be unavailable, along with handling of ChangeLog which used to exist in emacs-wiki.Anyway, I converted tokyodebian project webpage to emacs-muse, rather than hand-crafted HTML, and I'm happy.

I've done some research on writable plt on powerpc, and found that it is considered a problem, and is already fixed.New ABI is presented on May 2005, and is merged to binutils, and is included in Debian binutils in sid.Interested parties may want to look at binutils:bfd/ppc_elf_select_plt_layout.However, they need glibc/gcc updates to fully function.Apparently, fedora core seems to already have that.

As I've had to use Windows on a daily basis, I've found that I am no longer able to maintain my air of detached tolerance for the foibles of the system. In fact, I'm starting to get really infuriated with the utter boneheadedness of so many facets of it. Not so much things that are broken, as things that are done badly, and done so in the face of widespread examples of how to do it right.

Here are two simple examples that are emblematic of what Windows users have to suffer through.

(a) Mandatory file locks.

On Windows, every access to a file, by default, acquires a mandatory lock on it. Want to recompile the program you're working on? Sorry, you have to track down and kill all its running instances. Want to read that file on the network server? Sorry, you'll have to run around the office and ask all the people using it to close it.

Last week I got an email asking me to unlock a directory on our local fileserver so it could be renamed. It turned out that I was running an acroread process to view a PDF file...and that locked the directory from being renamed. Because, of course, the universe would implode if someone were to rename a file I had already loaded into memory. This is, however, better than how shared libraries are treated; trying to register a new version of a shared library with the system (the Windows version of ldconfig) will silently fail if programs have the old version mapped into memory. WTF? No, really, WTF?

Windows users get around this by having tools to find out which processes have a file open so they can terminate them with extreme prejudice. This is considered normal and acceptable behavior for a computer in the Windows universe. After all, in the real world two people can't use the same document at once, so why should they be able to do so on a computer?

(b) C# events.

They've been invented many times. Signals, events, hooks, whatever you want to call them, they're collections of function objects that are invoked when some particular condition occurs. It's a great way to make it easy to connect together objects that don't know about each other, they're simple enough that your average CS sophomore could implement them in a half hour, and the concept is so obvious (besides having dozens of examples of working and deployed implementations) that there's no way to screw it up, right?

Wrong.

Now, C# is generally a somewhat clunky language, but this is nothing to do with that (I am not, for instance, surprised that it's cumbersome to bind extra parameters to an event in a language that has little support for higher-order programming anyway). No, this is one of those utter idiocies that just make you scratch your head and go what the *@&# were they on when they did that? You see, when you call an event with no attached listeners, C# throws an exception. Just, you know, as a friendly way of letting you know that you didn't connect to that event.

But wait! It gets better! In order to test whether the event has any connected delegates (the Microsoft term for a function object), you ... compare it to the null pointer. Yes, that's right. Every time you call an event, you have to do this:

if(Event != null)
    Event();

...because, of course, an empty collection of events is clearly the same thing as a nonexistant object.

I really wish I could be a fly on the wall at the meeting where this was decided. My imagination supplies a scene along these lines:

Scene: A smoke-free office somewhere deep in the sterile labyrinth of the Microsoft campus

Programmer 1: "...and we call this bold new innovation 'events'! It's a way for you to perform method calls without knowing which method you're calling. We've found that it's amazingly useful when doing UI programming. I'm sure that introducing this new idea to the world will be yet another chapter in the Microsoft story of advancing technology!"

Programmer 2: "Have you checked the corner cases? What happens if there is no method available to call?"

Programmer 1: "Oh, of course! In that case, the list of methods is null, so we throw a NullPointerException. We thought about adding an IsEmpty property, but who would want to look up properties on the null pointer? Besides, hardly anyone will ever want to create an event that might not get connected to."

Programmer 2: "Uhhh, sure, that makes sense to me."

...!!!?!?!?!

So this is what I'm working on regarding the NVIDIA packages for Xorg 7.0, currently in experimental: First I already have patches sent in to address the new directory structure. Second I'm going to move the GL headers in nvidia-glx-dev back to /usr/include and thus have it confict with libgl-dev. Thirdly, I am relooking at the whole libGL.so mess (#208198)again as the other diversions will have to be changed. I will entertain solutions to the problem.

This post is going to be a little handwavey, but here goes. I really want to know what other Debian developers (and users, too, they’re in the same boat) think about this. So here’s the situation. You’re at a party — a college party, if you’d like to be precise, where all the things you saw in ‘Old School‘ happen — and by chance you are wearing a Debian t-shirt. There is consideration that doing this was a bad idea in the first place, but nevertheless, you’re there, and then the people you’re talking with start going on… First question from the peanut gallery: What’s Debian?
Second question, for those are looking closely at the words on the t-shirt (indicating that they have not quite had enough to drink yet): What’s Linux? For me, at least, it feels a little odd talking about heady stuff like Linux at parties like this. Not only is it awkward, it makes me feel like I’m getting a large ‘NERD’ stamp on my head no matter how I try to dilute it and explain it. It’s true — I am a geek. But I think it’s a bit of a faux-pas to flaunt it at a party where you’re more likely to see lots of “Mass Communications” and Political Science majors who, seriously, don’t give a damn. I’ve often tried to tell it off with “it’s a long story, not worth telling,” but all drunks love a good story. Just that this story isn’t particularly interesting! “So uh, to make a long story short, a lot of computer nerds got together and put together a lot of free software together, and it got called a ‘distribution’! Debian’s one of those distributions.” At this point, the hippies will have totally bought into it, because free is good, and free is love, etc. But they’re usually downstairs smoking pot and singing songs of liberation or whatever the hell it is that hippies do these days, so you’re still talking to the Mass Comm majors. So the question I’m really asking is: Is there a graceful way to explain Debian to people who don’t really care about it, but want a plausible answer? Should I just lie through my teeth and say it’s something they can identify with, like a band or a fraternity or something? That just sounds wrong, but if I try to sort of explain what it is, it’s hard to figure out how deep to go with it. This doesn’t just happen at parties, but it’s a notable example. Are there others in my situation? Am I the only DD in college in the USA who also has social interaction on a regular basis and inevitably stumbles on this dilemma? Help me out, guys…

Last night, the IRC debates for the ongoing DPL elections were held. Having a record number of seven candidates, it was at least from a candidate point of view very chaotic, the time between questions was not enough to both properly answer the questions and also read the responses of the fellow candidates. However, for the public, I guess the tempo was quite okay. I hope it's been an informative event for Developers, even though the nature of such debate doesn't allow for in-depth discussions. See the debian-vote mailinglist for that. Only about 24 hours left to answer questions... need to hurry. When finally reading though the debate answers now, I noticed Anthony Towns saying:

thanks to the wonders of blogging, there's plenty of opportunity to talk about things in a fun interesting way even when they're not finished, or not important enough to warrant a mailing list post

While I believe there's room for some regular reports on various Debian internal projects like I mentioned in my platform, this made me finally get around to actually creating a blog, something I've been meaning to do for over a year. And of course, I needed to because all the other teletubbies have a blog too! Anyway, I'm glad the campaigning period is nearly over, so I have more time for such things as a lintian upload, some PTS hacking, or study. And of course decide on my ballot for the DPL voting period.

Just about everybody hates backing up computers. But it's important. With more of our information being stored digitally -- even photos -- it's critical to back them up. At home, I've been using rdiff-backup for years now. Very slick. It stores backups on the filesystem -- they look as if you had used rsync. It also stores metadata (owner, mode, etc.) in separate files, so you don't have to back up using root. But the neat thing is how it handles incrementals. Incremental backups will update the backup image files to the current state, and store binary diffs to the past state. So you can access the latest backup instantly, and re-generate the previous state if needed. Very nice. I had just been backing up to a regular IDE drive. But this week, I ordered two Seagate ST3400601CB-RK external drives. The drives support both USB2 and FireWire. We will get a safe deposit box at a bank. At any given moment, one drive will be at home, and one will be safely at the bank. They'll be rotated periodically. At work, we've been using Amanda for years. It does its job well. (Except on AIX, where both dump and tar are broken in obscure, hideous ways, but that's not Amanda's fault.) Recently, I discovered Bacula. This looks very slick. It seems to be the direction Amanda would evolve, if it would ever evolve. We're going to test it out soon. And besides, who wouldn't love a program whose slogan is "Bacula: It comes in the night and sucks the essence from your computers"?

I always liked those "Bits from the foobar team" mails. So the other people knew that stuff was going on, and that the members of the other teams were doing something. Therefore I just started it with a small mail to -project about event and press stuff. I hope to post such mails more or less regularly in the future to keep you informed.

Well we've just had two more Aussies arrive off the boat. Welcome to Daniel and Tanya. Daniel's starting at the usual place of employment next Monday, and we brought them along to the Thursday night outing to the regular watering hole. It's always good to hear more Aussie accents.

Today, I had the "pleasure" to experience a new form of wiki spam in the Unmaintained Free Software wiki. Or at least it was the first time I had seen it... The registered wiki user "Drunkers" (yes, the spammer scripts not only spam anonymously, they also create real accounts lately!) spammed several pages in the wiki, adding tons of spam links, hidden with fancy CSS and other tricks. Nothing unusual so far. Another registered user ("Mootlif3") reverted the spammer's changes with comments like "reverted (spam)", "unrelated links removed", "deleted spam links", and "damn spammers". Or so I thought. The real "wtf" moment emerged when I checked what "Mootlif3" really had done. He didn't really revert the changes of the spammer. He only removed a few of the links from the page, leaving most of them still in there! So it would look like a nice (human) wiki user had helped out with cleaning spam, but in reality he only created a false sense of "security" for people who really want to clean the spam... Damn spammers, indeed.

My too-long absence from writing much here can be ascribed to two, differently pleasant, activities. First, a fantastic vacation in Cuba, and second, the redesign and launch of the XTech web site. Of the first, come to my place for dinner and I'll bore you at length about how amazing it was. Of the second, I'd like to bore you right now! Thanks to Ruby on Rails and a few late nights, the XTech site now has these new features:

• Full conference schedule (apart from 6 Mozilla talks I'm still nailing down)
• A blog. With go-faster Atom 1.0 stripes and everything!
• Details on the newly-added Ajax Developers' Day.

A few more details on the Ajax Developers' Day. As I mentioned before, when putting together the schedule we felt there was a lot of excellent content still missed out (I'm still feeling guilty at having rejected proposals from many good friends and excellent speakers). So, we put together an extra day at the beginning of the conference where we could go further into detail on Ajax technologies. This day, featuring speakers such as Simon Willison from Yahoo!, XML expert Kurt Cagle and OpenLaszlo's Max Carlson, will allow those working on Ajax projects--either deployment or toolkits--to meet, discuss best practice and move forward on new ideas. Although it's a day-long event, we didn't want to make the price tag as high as a full-day tutorial, so you can register for the cost of a half-day tutorial. A few implementation details If that all sounded a little like advertising, here are some technical details worth sharing. The site's CMS is built on Ruby on Rails. Development was done on Linux, with the help of WINE to check out the view from Internet Explorer. The newsletter is managed by the absurdly wonderful CampaignMonitor. This conference not for sale Before I went on vacation, there was some debate in various quarters about paid-for plenary and keynote slots in conferences. Though I hope it is obvious, I wanted to state where I, and thus the XTech conference, stand on this issue. It has always been my policy to maintain a strict separation between the commercial and editorial aspects of XTech. Although each year there's always a company who thinks they can buy a speaking slot, I never let this happen. The content of the conference is formed by editorial selection by the programme committee, who take the scores from the peer review panel as their primary guide. Aside from what I hope shows in the excellent quality of the talks and generally interesting keynotes (yes, we get it wrong occasionally!), there are two effects on the conference.

• Sponsors are that much more respected. When a sponsor respects the delegates' time and intelligence, but still attends, you know they're serious about engagement with attendees.
  
• A higher portion of the conference cost is in the registration fees than for some other conferences. We're still trying to keep the costs as low as we can, but we're not prepared to compromise the quality of the schedule by letting vendors buy talk time.

I hope this explains a little of my position. As a stance, it often creates more issues for me than it solves, but I believe it preserves XTech's reputation as a conference where you can hear some of the best no-fluff presentations on web technology.

I spent some time yesterday putting watch files in most of my packages. Watch files have been around for a long time in Debian, but hasn't reached the exposure it perhaps deserve. They're used by uscan to check for newer upstream versions of the source. What's even more useful than running uscan is the Debian Watch Health Status pages (which are also helpfully linked from the QA developer's page, but that functionality appears to be broken at the moment) which parse the watch files as well and provide a nice web interface to look up your packages and others and see where upstream is at. Unfortunately, for this to work properly the package needs a watch file, and according to the statistics, only ¹/₃ of all packages have watch files. So here's a quick tutorial, just plop a suitably modified version of these examples into the debian/watch file in your package and you're off to the races. If you're packaging foo and the source tarballs are on ftp.foo.org your watch file will look something like this:

version=3
ftp://ftp.foo.org/pub/foo/foo-(.*)\.tar\.gz

Some things to note: the version line is just there to allow for future enhancements without breaking backwards compatibility. For the location specifier, the last part after the final / is a regular expression (notice the .'s are escaped). The pattern inside the parentheses is what gets parsed as the upstream version number. For HTTP the syntax is almost identical:

version=3
http://www.foo.org/files/foo-(.*)\.tar\.gz

This snippet will download http://www.foo.org/files/ and look for href's corresponding to the rest of the pattern. For projects hosted on Sourceforge, there's a handy syntax for that, and uscan will take care of figuring out its annoying mirror system. If it's project bar, and the source is called libbar:

version=3
http://sf.net/bar/libbar-(.*)\.tar\.gz

There are many more details in the uscan man page. I think it would be great if more maintainers put watch files in their packages. It's one of those touches that really sets Debian apart from the rest.

The Latin American Free Software Install Party (FLISOL) will take place in 12 countries of the continent, including Cuba, and featuring Argentina and Colombia. In Venezuela, it’s happening in ten cities in several regions of the Country, including Los Andes, Los Llanos, the Central Region and the Paraguan Peninsula. I’m organizing the event in Caracas, which already has a webpage (in spanish) FLISOL will take place on March 25th, a Saturday, but in several cities of Venezuela we will have a two-day event. In Caracas, it will happen on Friday and Saturday. We will feature hands-on workshops and demonstrations (featuring a Debian GNU/Linux hands-on workshop), a Keysigning Party (it won’t be massive, though) and a Web Frameworks and Application Servers Forum, featuring Rails, Catalyst, J2EE, and Zope. I expected David to be in Caracas for the FLISOL, but he’s gonna travel to San Crist bal to participate in their FLISOL. I don’t expect a big attendance to the event (the Auditorium of the Science and Technology Ministry, the main sponsor, has capacity for circa 200 people) but I hope it becomes a fresh event, different from those we’re used to. This will be, also, a good preparation for the World Forum on Free Knowledge, the National Free Software Congress and the DebConf. I hope the main topic on the FLISOL will be the recent, terrible, awful, and completely disgusting Ubuntu security flaw.

Here's a fairly sweet perl hack that I just wrote. Test how much of a the guts of a program comes from sweet, delicious CPAN, and how much is nasty perl code you wrote.

joey@dragon:~> cpan-purity cpan-purity        
usage: cpan-purity [--verbose] [--mine=regexp] -- program args
** CPAN Prurity test results: 98.08% pure CPAN code.
** 7107 lines in 24 files were from CPAN, and 139 lines in 1 files werenot.
joey@dragon:~> cpan-purity -- perl -e 'use Coy; die "whups, gotta go.."'
        -----
        Two rabbits walk. A 
        pair of lovers beside a pool. 
        A trout in the dam.
        -----
                Homer Simpson's commentary...
                whups, gotta go.. 
                        (Sayings of -e: line 1.)
** Looks like that was a perl one-liner..
** CPAN Prurity test results: 99.98% pure CPAN code.
** 6028 lines in 16 files were from CPAN, and 1 lines in 0 files were not.
joey@dragon:~> cpan-purity --mine=debconf dpkg-preconfigure
dpkg-preconfigure: must specify some debs to preconfigure
** CPAN Prurity test results: 70.49% pure CPAN code.
** 6745 lines in 41 files were from CPAN, and 2823 lines in 20 files were not.
joey@dragon:~> cpan-purity ikiwiki
Forcing /home/joey/src/ikiwiki/ikiwiki to run without taint checking..
usage: ikiwiki [options] source templates dest
** CPAN Prurity test results: 91.59% pure CPAN code.
** 12273 lines in 27 files were from CPAN, and 1126 lines in 1 files were not.

After all, writing more perl code is bad, but CPAN rules, right? So they tell me. That was a lot of fun to figure out how to write, pity it's too special purpose for moreutils. :-) Oh and by the way, the extra 600 lines shown in ikiwiki, up from the 300 lines it was two days ago include nearly everything you'd expect in a modern wiki, from templating to user login and registration, etc. It's nearing 0.1 state.