I'm not surprised with the positive Etch reviews after testing freeze, people here on planet.d.o definitely shouldn't. There are corner cases, but new installs (debian desktop anyone?) and a lot of upgrades scenarios (sarge->etch) are already ok. If you're surprised, you've wasted too much time around tanks in the last months, sorry.

Why? Debian is about us. The result of our work and feedback from our users, that are potential contributors in a much more powerful manner than alternative solutions. We've problems, tons of problems, but if you feel and wants to be part of our community stay tuned about the result of your work and the work of others members of the community during each development cycle. There's a lot under the hood, just ask.

For those who care about surprises, ignore this message and keep following just the politics. That's your choice, not mine.

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.

My wife Rachael and I are pleased to announce the birth of our first children, Thomas James and Katherine Elizabeth, born on Friday 22 December at 9.02pm and 9.12pm. Katherine (l), Thomas (r)The twins and their mother are all doing very well, and I'm enjoying learning some new skills. I can't think of a better way to start Christmas.

I'm pretty happy about the way the 'Ten Web 2.0 APIs you can really use' episode of the LinuxCast came out so well. I'm not very used to talking for recording, and like everyone I don't particularly enjoy hearing my own voice recorded (do I really sound like that?), but it was fun to do, and I think it's a nice adjunct to the Ten Web 2.0 APIs you can really use article itself. tags: api podcast linuxcast linuxworld

Tijuana We're on a trip in Southern California this week, so we decided yesterday to go to Tijuana for the day. Maj, Amita June and I got out of the condo we're staying at in Encinitas early in the morning -- well, early for a vacation day -- and headed down to downtown San Diego. It's a trip of about 25 miles, with one tricky turnoff at highway 805 that seems to get me every time I visit this part of the world. Going into Mexico with a car can be a bit of a hassle. Many American insurers don't cover cars going into Mexico, and you'll often get asked about insurance when you cross over. There are some quick-and-dirty insurers on the border that can give you one-day insurance or other short-term coverage, but we have a rental car right now, and most (all?) rental car companies forbid with bitter, mouth-foaming forbiddance driving the car across the border. Fortunately for us, San Diego has a great way around this problem. Their trolley system goes from downtown San Diego right up to the border in San Ysidro. So, we picked it up in the Civic Center downtown, after a brief stop at the Downtown San Diego Vistors Center (to get tourist material), a shopping foray at a stall outside of the downtown Macy's (to get Amita June a pair of purple Crocs), and a side trip into the Westin for a bathroom break. Man, the Westin in San Diego has nice bathrooms! I'd heard about these trolleys in the past, and I guess I'd expected a kind of fancy tourist train, but it's really just the Blue Line for typical light-rail trains for San Diego and its suburbs. The seats were comfortable, but the train right-of-way went through some of the least scenic parts of Southern California I've ever seen. There's something about this corner of the United States of America that's depressing and end-of-the-world; I get the same feeling about other borderlands, like around Plattsburgh and Laredo. The end of the line for the trolley is completely opaque as to how get into Mexico. We wandered around past some ugly strip malls until Maj spotted a tiny oblique walkway that said "US PROPERTY SUBJECT TO SEARCH AND FINE" and in much smaller letters "a Mexico - to Mexico". We went through a wiggly walkway and across the no-man's land between the scary metal fence at the US border and the actual Mexican customs area. Nobody was there, but we got the feeling we were being watched. At the end of this weird walk was a very nice tourist info center, where we got some maps and brochures and such. Another 10 minutes walk through the streets up against the fence, we got to Avenida Revolucion, the central way through the Tijuana/Zona Centro. It had been a while since we'd been to a city with aggressive touts, so getting yelled at by people in shop doorways or in the street was a bit of a jolt. I hate the invasion of my anonymity, and I'm pretty reflexive about saying "NO NO NO NO NO" to everyone, but Maj is a little more practical. "If everything is run by aggressive sideshow barkers, you're going to miss out on everything," she points out. "Sometimes, you have to say 'yes', even if you don't like the way the question was asked." By the time we hit av. Revolution, we were pretty tired, so we stumbled into the first restaurant we found -- El Torito, a big nightclub with go-go cages, a mechanical bull, and a tattoo parlour on premises. I was attracted by the racy Absinth Mexico posters. "Family restaurant, family place," said the touts, seeing the baby in the stroller. Sure. The food wasn't bad -- I made the mistake of ordering the fish Vera Cruz, but the waiter made a smelly-face and suggested I get the shrimp instead -- and the cocktails at 1PM were generous and inexpensive. Probably the nicest part was a guy with a guitar who came over and asked to sing. "We've got enough music," said Maj, pointing at the ceiling where loud disco tunes were booming. But he was insistent, so we let him play, and he sang a loud Besa Me Mucho that drowned out the Ricky Martin and had us, the waiter, and nearby diners singing along by the end. Amita June was fascinated by the sounds, and clapped along when he was done. After lunch we walked down av. Revolucion, which had a dense layer of souvenir shops and discount pharmacies offering Viagra and Cipro without a prescription. One weird repeated theme was donkeys painted as zebras, hooked up to carts where you could sit and get your picture taken for $2. Some of the donkeys looked pretty good in their zebra stripes, but most looked pretty bummed out. I'm not sure why tourists would expect to get their picture taken with a zebra while in northern Mexico. It got a lot nicer as we got down to the end of the block, and we kicked ourselves for being so lazy when we passed Chiki Jai, a charming little restaurant with tiled walls and rough wood furniture. Much more to our tastes than El Torito. We stopped at the monumental Jai Alai courts, with a beautiful facade and a nice statue out front. Ducking into the Tia Juana's next door, we did a diaper-change break and had some chips and salsa and pineapple juice (and Dos Equis Dark on tap for Papa). Then we started walking back to the border. On our way back, we got off of Revolucion and walked over to the city's Cathedral. It was a much more realistic part of the town -- shopping and bars and restaurants, true, but less ridiculous touristy crap. When we got to the cathedral, there was a holiday street fair going outside, with games and food stalls and people laughing and walking around with kids. It felt a little more human than the pressure-tactics-dense world of Revolucion. On our way back to the border crossing, we dipped briefly into the red light district at the head of av. Constitucion (who knew?), then made the long slog back to the USA. We didn't get much in the way of souvenirs, but Maj bought a nice set of luchador dolls for her brother, complete with a tiny wrestling ring. The line at the border was huge, and we had to wait at the trolley station for another 30 minutes before one left for SD again. By the time we got back downtown, around 5:30, we really weren't up for a dinner in the San Diego/Gaslamp Quarter like we'd originally planned. So we piled into the car, paid the $20 parking to get out, and headed right into rush-hour traffic that led to the over-populated and under-networked North County (San Diego County). Would I take the trolley to Tijuana again? Maybe. Next time, I'd probably go to one of the stops between San Diego and San Ysidro, where there are free parking lots and a little less hassle. tags: tijuana san diego travel san ysidro

Hazards of vacation homes I was just rifling through the fridge here at the condo in Encinitas and found what I thought was a delicious Abita beer, the fine drink you have when you can't handle another hurricane in New Orleans. But it turned out to be an Abita Purple Haze, a gross raspberry-wheat beverage. Unfair! It has probably been stuck in the back of the fridge of this condo for years. Fortunately there was still another Stone Pale Ale, from the North County local microbrewery, to satisfy my lunchtime beer needs. tags: stone brewing abita beer

Time for a gadget update. I've bought an iPod Shuffle last month which was an excellent buy. It's very simple and just does what it needs to do, nothing more and nothing less. Thanks Steve. Google was nice enough to send me a digital photo frame that can load flash cards containing photos, movies and mp3s. Thanks! It looks a lot better than all the loose pictures. I bought some technical stuff at the traditional IBA computerjunk-for-charity auction, namely an old spotty keyboard, two USB ports and a CueCat barcode scanner: .C3nZC3nZC3nZE3fZE3n1CNnY.bNjW.CxzZCNnWE3rZC3nZCq. It scans a lot of the items I have around the house, but I'm still not sure to what actual use I'll be able to put it. If Jaap succeeds on making a RAID array out of the two floppy drives he bought, I'm doubling his bid. XS4ALL sent me a 3 megapixel digital video camera (!), a USB Voice over IP phone and to top it off a gift voucher for a free vlaai. I'm overwhelmed with the generosity, thanks a lot guys!

The Lexus GS 450 hybrid petrol/electric car has been given the award for Australia's best luxury car!

The judging for this contest rated fuel efficiency as low importance, because luxury car owners traditionally aren't very concerned about such things. The Lexus won because of it's quiet engine (can't beat an electric motor at low speed), high performance (3.5L petrol engine that outperforms mode 4L engines because of the electric motor assistance), safety, security, and other factors.

There has been an idea that hybrid cars are only for people who want to protect the environment at all costs. The result of this contest proves that idea to be false. The Lexus won by simply being a better luxury car, the features that benefit the environment also give a smoother and quieter ride and higher performance - which are factors that are very important to that market segment! Also it wasn't even a close contest, the nearest rival achieved an aggregate score of 9% less (a significant difference as there was a mere 2.5% difference in score between the 2nd place and 5th place).

This of course shouldn't be any surprise. The high torque that electric motors can provide at low speed is well known - it's the reason for Diesel-electric hybrid power systems in locomotives. It was only a matter of time before similar technology was introduced for cars for exactly the same reasons. The next development will be hybrid Diesel-electric trucks.

Big week for me in and around the media. Huzzah for fame and fortune!

Web 2.0 APIs I'm really happy that an article I wrote for Linux World on Web APIs for software development was published. Called Ten Web 2.0 APIs you can really use, it covers the APIs available today that are really useful for more than just gee-whiz mashups. I'd covered a few of the services when I did a story for LW on the Web 2.0 Summit, so Don Marti asked me to follow up with a full rundown on the world of Web APIs right now. tags: web2.0 api web api linuxworld article

Wikitravel on the AP wire On the other side of the media lens, Wikitravel is one of the sites featured in an article on the API wire by Anick Jesdanun called Travelers contribute to online guides. Although the article covers a lot of other travel sites, and even has some sour grumpiness by proprietary travel guide publishers, I think it's very favorable to Wikitravel. tags: wikitravel ap anick jesdanun travel guides

Thanks, Tom Also, it was nice of Tom Brown from Stuffopolis in talking about his OpenID Podcast to say that the OpenID extension for MediaWiki is "excellent". Gawrsh! tags: openid stuffopolis tom brown mediawiki excellence

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!

Johan Rydberg has recently announced his Free Software (GPL) firmware implementation named GNUFI.

GNUFI is designed to be a firmware compatible with the Unified Extensible Firmware Interface (UEFI) specification. GNUFI is designed so that it can be adopted to different runtime environments; such as a legacy BIOS or U-boot environment, or as a LinuxBIOS payload. At this point there has not been any official release of GNUFI. The version controlled source repository can be accessed using Bazaar:

bzr branch http://gnufi.openbios.org/gnufi.dev

If you're interested in early testing and/or helping with development also checkout the wiki / bug tracker and the mailing list.

In the finest tradition it is Christmas-time and my computer is dead. OK slight exaguration. I have two computers I regularly use:

desktop.my.flat

This is my main development machine, which I sit in front of and work at most days.

itchy.my.flat

This has several roles:

• xen
  • So that I can run Sarge for building security updates.
• caching name server
• backup server

(Both of these machines run Sid.) The backup server is the important use for this machine. Every four hours I do a full database dump + rsync of d-a.org, my personal server, and my desktop system.

The backup machine, itchy, is currently down because of a failing hard drive. I’ve ordered a replacement computer (a bit extravogent considering I could have got by with just a new disk drive). This will be my first 64-bit machine, and also my first machine with hardware support for virtualisation. The new machine should arrive on Saturday. Once it does I’ll rotate it in. The new machine will become my desktop. My desktop will become the backup, and the old machine with the failing drive will be donated to my Sister. (Who I was due to give a machine to already. I will need to get a new disk but that will be done shortly.) I think I’ll try sticking with Etch on the new machine, and possibly make the backup machine run it too. I guess I don’t need sid yet… Besides Xen makes new installations easy

This morning I received an email from the AMD Developer Center advising me that I need to fill out their NDA if I want access to their development machines.

I have a vague recollection that when AMD64 was first released I was very keep to get access to such hardware and had applied to AMD for access to their machines.

Of course now the second-hand market is full of AMD64 machines and I've got one in my server room so it's not as useful as it once was. I don't even know why AMD would still run a developer center given that everyone who wants AMD64 machines can cheaply buy as many as they want and organizations such as Sourceforge and Debian provide access to such machines for their members.

While I appreciate what AMD is doing, it probably would be best if companies could adopt a standard timeout for electronic correspondence. If someone doesn't follow up for X months then you should assume that they are not interested.

Well, this is first post. I have managed to migrate my blog over to Ikiwiki, including all the historical posts. The reasons for migration was that development on my older blogging mechanism, Blosxom, entered a hiatus, though recently it has been revived on sourceforge. I like the fact that IkiWiki is based on a revision control system, and that I know the author pretty darned well :-). One of my primary requirements for the migration was that I be able to replicate all the functionality of my existing Blog, and this included the look and feel (which I do happen to like, despite wincing I see from some visitors to my pages) of my blog. This meant replicating the page template and CSS from my blog. I immediately ran into problems: for example, my CSS markup for my blogs was based on being able to markup components of the date of the entry (day, day of week, month, etc) and achieve fancy effects; and there was no easy way to use preexisting functionality of IkiWiki to present the information to the page template. Thus was born the varioki plugin; which attempts to provide a means to add variables for use in ikiwiki templates, based on variables set by the user in the ikiwiki configuration file. This is fairly powerful, allowing for uses like:

    varioki =>  
      'motto'    => '"Manoj\'s musings"',
      'toplvl'   => 'sub  return $page eq "index" ',
      'date'     => 'sub   return POSIX::strftime("%d", gmtime((stat(srcfile($pagesources $page )))[9]));  '
      'arrayvar' => '[0, 1, 2, 3]',
      'hashvar'  => ' 1, 1, 2, 2 '
     ,

The next major stumbling block was archive browsing for older postings; Blosxom has a nice calendar plugin that uses a calendar interface to let the user navigate to older blog postings. Since I really liked the way this looks, I set about scratching this itch as well; and now ikiwiki has attained parity vis. a vis. calendar plugins with Blosxom. The calendar plugin, and the archive index pages, led me start thinking about the physical layout of the blog entries on the file system. Since the tagging mechanism used in ikiwiki does not depend on the location in the file system (an improvement over my Blosxom system), I could layout the blog postings in a more logical fashion. I ended up taking Roland Mas' advice and arranging for the blog postings to be created in files like:

 blog/year/month/date/simple_title.mdwn

The archives contain annual and monthly indices, and the calendar front end provides links to recent postings and to recent monthly indices. So, a few additions to the arch hook scripts, and perhaps an script to automatically create the directory structure for new posts, and to automatically create annual and monthly indices as needed, and I'll have a low threshold of effort blogging work flow for blog entries, and I might manage to blog more often than the two blog postings I have had all through the year so far.

Are comment-less blogs missing the spirit of blogging?

It seems to me that the most significant development about blogging is the idea that anyone can write. Prior to blogs news-papers were the only method of writing topical articles for a mass audience. To be able to write for a news-paper you had to be employed there or get a guest writing spot (not sure how you achieve this but examples are common).

Anyone can start a blog, if there is a community that you are part of which has a planet then it's not difficult to get your blog syndicated and have some reasonable readership. Even the most popular planets have less readers than most small papers, but that combined with the ease of forwarding articles gives a decent readership.

It seems to me that the major characteristic that separates a blog from an online newspaper is the low entry requirements, anyone can create one.

Every news-paper that is remotely worth reading has a letters column to publish feedback from readers. Of course it's heavily moderated and getting even 50% of your letters published is something to be proud of. But it does create a limited forum to discuss the articles that are published.

It seems to me that creating a blog and denying the readers the ability to comment on it is in some ways making the blog less open than a news-paper column. When such blogs are aggregated in a community planet feed it seems that they go against the community spirit. It also drives people to make one-line blog posts in response, which I regard as a bad thing.

The comments on my blog are generally of a high quality, I've had a few anonymous flame comments - but you have to learn to deal with a few flames if you are going to use the net, and people who are afraid to publish their real name to a flame don't deserve much attention. I've had one comment which might have been an attempt to advertise a product (so I deleted it just to be safe). But apart from that the comments are generally very good. I've learned quite a few useful things from blog comments, sometimes I mention having technical problems in blog posts and blog comments provide the solution. Other times they suggest topics for further writing.

There are facilities for moderated blog comments that some people use. If you have a really popular blog then it's probably a good idea to moderate the comments to avoid spam, but I'm not that popular yet and most people who blog will never be so popular. At this time blog moderation would be more trouble for me than it's worth.

In conclusion I believe that the web should be about interactive communication in all areas, it should provide a level playing field where the participation of all individuals is limited only by time and ability. Refusing comments on blogs is a small step away from that goal.

I'm currently in (the really lovely) Philadelphia airport again, waiting for my connecting flight to San Francisco. I'm rapidly arriving at the conclusion that it is easier to enter the US once you've landed on US soil, than it is to depart from the country bound for the US. I had the most harrowing experience of my life this morning, trying to check in for my return flight. Due to the way various people's itineraries worked out, I ended up having to share a taxi from Badajoz to Madrid Airport at 12:30am. My flight didn't depart until something like 12:20pm, but the bus with the bulk of the people on it wasn't going to get me to the airport with less than 2 hours before departure, and I didn't want to risk missing my flight, especially given I'm feeling under the weather. So I got to the airport at about 4am, having had little sleep in the taxi. Terminal 1 has a real dearth of seating for people waiting to check in. I spent 4 hours trying to make myself as comfortable as possible on the hard floor, and didn't get a lot of sleep then either. For the record, check-ins (at least for US Airways) seem to open around 4 hours before the scheduled departure time. So I went to check in, and the way they were working it was there was a bunch of podiums out the front of what I would consider a conventional check-in counter. The people at these podiums then proceeded to give you your first Spanish Inquisition. I'd previously remarked to myself at how trivial it was to get into Spain... I was asked the purpose of my trip to Spain. I told the woman it was for a business meeting. She then asked where I'd spent my time I Spain. I told her Badajoz. She asked if I had a hotel receipt to show for it. I told her the accommodation was paid for my someone else. She then asked if I had any business cards to show for the business meeting. Sheesh, I thought. Luckily I still had all the copies of people's keys leftover from the keysigning we did, and some of them were in a business card format, so I pulled out a fistful of them and gave them to her. Oh, and she wanted to see a copy of my itinerary, and seemed satisfied that the flights were a reversal of what got me there in the first place. She wandered off with my passport, itinerary and the fistful of "business cards" and came back, seemingly satisfied that everything was in order. She stuck little blue stickers on my luggage and passport (the size of an Australian convenience-store price tag) and I was allowed to wait for the next check-in person. The rest of the checking-in process was fairly normal. I can appreciate the airline wanting to avoid having to deal with passengers being refused entry to the US, but I had a valid US visa in my passport, so that should make all of that a moot point. I don't know why I had to prove my trip's legitimacy to the airline. So I thought that was the end of it. Hardly. Terminal 1 of Madrid Airport seems to have heaps of gates, with a letter/number combination. Mine was in the B series, and I went through the security screening, and it became apparent that I had to go through another guard post looking thing to get from the A series to the B series. The signage looked like it said "Police". Anyway, the guy there had so-so English, and he initially was a little unhappy that I had an Australian passport and was flying to the US and not Australia. I pointed out the US visa, and he seemed less concerned. Then he asked me to say something in Spanish. I don't know if he was trying to be conversational, or I had to be able to speak some Spanish to get past or what the story was, but by this stage I was pretty tired, and this caught me totally off guard. I think I stammered out a Buenos d as or something. He then wanted to know how many hours it took to fly from Australia to Spain. I told him I had no idea, because I'd only flown from the US to Spain. He then begrudgingly gave me an exit stamp in my passport, and I was allowed on my way. I think the whole thing was made the more harrowing by the fact I was deadly tired, the Police guy didn't speak terribly fantastic English, and I wasn't expecting a second Spanish Inquisition (let alone the first). Oh, and closer to boarding time, they chucked everyone out of the lounge area closest to the gate, and rechecked everyone's passports and boarding passes. That was fair enough, and not unlike what happens in Sydney going to the US, but they don't even let you into the lounge area in the first place. That departure process was more what I would have expected an entry process to be like, and has put me off returning to Spain a little bit. The entry process was a joke. The guy barely looked at my passport long enough to give me the entry stamp. Fortunately I slept for the bulk of the flight from Madrid to Philly, and now I'm feeling a bit more human.

I am really upset by the way the ARM build daemons are managed. The packages are not uploaded regularly, with sometimes three days between two uploads. Well it should not be a problem, if packages that have failed to build due to some packages not uploaded fast enough (see for example python-gnome, or rkward) were requeued, but that’s actually not the case. Also last week, the build daemon named “cats” stopped to upload packages, despite it continued to build them. 11 days later, nothing has changed even after a mail to arm@buildd.debian.org. And I do not speak about build daemons building nothing. All of that resulted in ARM being the slowest architecture to build packages. It looks like the ARM build daemon maintainer does not know the excellent page made by Jeroen. As arm@buildd.debian.org is everything but responsive (well if you can assign a level of responsiveness to /dev/null), I have decided to act. I have installed QEMU on an 8-way Opteron machine, and created 8 emulated ARM machines, which 256MB of RAM and 10GB of disk for each, all running buildd + sbuild. Altogether those 8 emulated ARM machines should be faster than all the Debian ARM build daemons. I have setup a wanna-build database on my server. During the day it has built around 100 packages. Yes I agree that real machines would be better, but I don’t have a stack of fast ARM machines at home. Anyway when you see random segfaults on the build daemons, or strange failures (that happen for weeks) on the build daemon named “netwinder“, you may think to that again. Unfortunately the machine I use for that is only available for a few months, and I will have to stop the emulated machine then. I just hope that the situation with respect to the build daemons will improve, so that I can stop them even before.

A few weeks ago, some spammer sent out a spam wave abusing one of my domains (fortunately one I havn't been using much). I quickly reacted by rejecting all mail to this domain. However, I'm still seeing frequent mail delivery attempts. Apparently spammers have "discovered" the email address one of them invented, and are now spamming these addresses. Great... that's like... spammer masturbation? making up your own email addresses to spam to... And worse: apparently they're now trying to bypass greylisting. Looks like we've now hit the point where greylisting will lose much of it's effectiveness we all love it for. :-( thats really bad news. Here's an excerpt from my logs (addresses removed to protect the invented):

Dec 10 14:58:54 postfix/smtpd[25738]: NOQUEUE: reject: RCPT from unknown[89.129.198.153]: 550 <agricolaapocalyptic@mydomain.tld>: Recipient address rejected: Spammers invented this address, it does not exist.; from=<random@random.tld> to=<agricolaapocalyptic@mydomain.tld> proto=ESMTP helo=<mail.001sm.com>
Dec 10 15:00:25 postfix/smtpd[15969]: NOQUEUE: reject: RCPT from unknown[89.129.198.153]: 550 <agricolaapocalyptic@mydomain.tld>: Recipient address rejected: Spammers invented this address, it does not exist.; from=<random2@random2.tld> to=<agricolaapocalyptic@mydomain.tld> proto=ESMTP helo=<mx1.cnm.cn>
Dec 10 15:02:35 postfix/smtpd[15139]: NOQUEUE: reject: RCPT from unknown[89.129.198.153]: 550 <agricolaapocalyptic@mydomain.tld>: Recipient address rejected: Spammers invented this address, it does not exist.; from=<random3@random3.tld> to=<agricolaapocalyptic@mydomain.tld> proto=ESMTP helo=<mx2.fr.clara.net>
Dec 10 15:04:40 postfix/smtpd[10646]: NOQUEUE: reject: RCPT from unknown[89.129.198.153]: 550 <agricolaapocalyptic@mydomain.tld>: Recipient address rejected: Spammers invented this address, it does not exist.; from=<random4@random4.tld> to=<agricolaapocalyptic@mydomain.tld> proto=ESMTP helo=<mail.1-shops.com>
Dec 10 15:06:46 postfix/smtpd[20414]: NOQUEUE: reject: RCPT from unknown[89.129.198.153]: 550 <agricolaapocalyptic@mydomain.tld>: Recipient address rejected: Spammers invented this address, it does not exist.; from=<hisyn@0reality.com> to=<agricolaapocalyptic@mydomain.tld> proto=ESMTP helo=<aspmx2.googlemail.com>
Dec 10 15:09:48 postfix/smtpd[20608]: NOQUEUE: reject: RCPT from efi235.internetdsl.tpnet.pl[83.14.242.235]: 550 <agricolaapocalyptic@mydomain.tld>: Recipient address rejected: Spammers invented this address, it does not exist.; from=<random5@random5.tld> to=<agricolaapocalyptic@mydomain.tld> proto=ESMTP helo=<efi235.internetdsl.tpnet.pl>

Yes, that is one host retrying for 8 minutes (usually enough to bypass a greylist), another one a few minutes later, and a third one 5 days later (not included in the log); hosts that didn't make it past the RBL are not included. All in all I count 148 email delivery attemts to this address. And all on a random email in my domain that never existed, and is not a dictionary address like sales@domain.tld; but this probably means I won't be able to enable a catchall for this domain ever again or face loads of spam. OTOH, my spam filter can probably learn that "agricolaapocalyptic" is a sure indicator for spam and just discard all of it. P.S. this effect makes it more plausible that spammers are grabbing the Outlook address books of Windows users to use for spam; it's plausible the spam-address was auto-collected by outlook and then in turn collected by the next spammer. Maybe we really need to create random addresses until they give up on having sane databases sometime? Or at least blacklist our domains for their email collectors...

Last months I’ve been busy with some projects at work, involving some Qt programming, dealing with Cisco JTAPI and other nuisances, which have prevented me from working in eBox. My work desktop is about a meter away from the now three full-time developer eBox team, so I’ve been closely following the development process and participating in some design meetings and at last, I’ve found some time to write nice stuff for it again. eBox lacked administration logging, that is, a log with every change made through the eBox administrative interface (quite useful to know when something was changed or who changed it), so I’ve added support for that in the eBox framework and have implemented the necessary stuff in two modules as an example. There is still a lot of work until every module reports every action to the module, but the core is already working:
As a nice side effect, now we can also show the changes that you are about to save or rollback:
FYI, a new eBox version (0.7.99, aka 0.8rc1) was released some days ago, you can give it a try. Check our downloads section. Obviously these changes won’t be included in 0.8, but in 0.9, which will also add a openvpn module, traffic shaping and other improvements.

Postr 0.3 is out. A few typo fixes in my code, and an update to the latest flickrapi.py to fix uploads after the Flickr servers decided to be more pedantic. This was proof that I am the only user of Postr, as it didn't work for a good week or so.

• Update flickrapi.py to version 10
• Fix references to the token

You can follow the development in the Bazaar branch, or get the Postr 0.3 tarball.

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

As anyone who follows my blog knows, I’m fond of linking to other sites with brief little quotes that either get me thinking or reinforce points I’m trying to make elsewhere. (Credit where credit is due: Dave Winer and Doc Searls both do this very effectively, and I’m just shamelessly copying them, down to the quoting style they typically use.) One of the quotes I’ve had queued up for a long time is this one from Jon Udell:

I have a confession to make. Sometimes, when I m trying out an unfamiliar open source component, I cheat. Even if the software I m working on will deploy to Linux, I ll sometimes develop it on Windows first. Why? Because on Windows, an open source component is likely to come with an installer that just works.

He’s right. Unless an application is included with your Linux distribution of choice, installing that application on Linux is a nightmare compared to Windows. Here’s an example. To install Sun’s Java Studio Creator on Windows, I just click on the .exe on Sun’s web site, which downloads the file and places it on my desktop. I double click the .exe (after, of course, checking it for viruses) and am up and running in a few minutes. In contrast, on Linux, I click on the .bin, which downloads the file and.. up pops a text editor showing me a /bin/sh script. Nice. Fortunately, I know what that is, so I save the script to a file on my desktop. I double click the file, and.. up pops a dialog box telling me the file isn’t executable. Nice. Fortunately, I know what that means, so I drop into a shell and run chmod +x ./creator-2_1-linux-ml.bin. I double click the file again, and there’s a nice graphical installer now. Finally, it looks like everything is going my way. Halfway through, though, the installation fails, telling me I need to install the RPMs for compat-libstdc++ and compat-libstdc++-dev. Nice. Assuming I even know what an “RPM” is, I then realize: I’m running Debian, and Debian doesn’t use RPM. Maybe I know about alien, but even if I do, where do I go about getting the compat-libstdc++ and compat-libstdc++-dev RPMs? At this point, I’ll probably hit Google—that is, if I haven’t already thrown up my hands in disgust and gone back to Windows. After a bit of Googling, I find this page, which tells me on Debian what I really need is libstdc++2.10-glibc2.2 and libstdc++2.10-dev. Of course! I should have known that. (Note: I’m being sarcastic.) After installing those two packages, I restart the installer (which, thankfully, knows how to deal with the fact that it’s already half installed, but that won’t always be true). The installation finishes this time, and the installer kindly offers to start the program for me. However, after poking around a bit and exiting back to the desktop, I don’t see a menu entry or a desktop icon, so I’m not sure how I’m going to find it again (and I hope I don’t have to explain why cd’ing to ~/sun/Creator2_1/bin is not an answer). Anyone who has ever installed software on Linux is familiar with this song and dance. If it’s in your distro of choice, you’re only an apt-get or a yum install away from running it. But if not, you’d better know what you’re doing, have a lot of patience, and understand how to construct effective Google search terms. (And, no, moving everything into the distribution is not a very good option. Remember that one of the key tenets of open source is decentralization, so if the only solution is to centralize everything, there’s something fundamentally wrong with this picture.) Oh, well. At least I didn’t have to check for viruses! Fortunately, some of the problems I experienced are bugs. The above was done on a pre-release Debian etch system over the summer, so it’s likely the problems have been fixed. I repeated the experiment on an Ubuntu edgy system, and it didn’t open the text editor, nor did it complain about an incompatible C++ environment. However, there were still no menu entries or desktop icons, and there was an additional problem too in that when I double clicked the file, it opened it in CrossOver Office, which I also have installed. Regardless, even if it works better on some distros than others, there’s still no usable solution until ISVs and end users alike can depend on things consistently working regardless of the distro being used. Again, fortunately, we have solutions to parts of the problem already. The LSB abstracts away the differences between the runtime environments of the various distros, so the Java Studio Creator installer could have simply said “you must install the LSB environment” rather than trying to deal with the hundreds of little variations in both the environments and the package namespaces that provide them (e.g., compat-libstdc++ vs. libstdc++2.10-glibc2.2). Better yet, on distros that provide the LSB environment in their default configuration, the installer doesn’t have to do anything. And Project Portland promises to give us a consistent interface for creating menu entries, desktop icons and such things. However, far too few applications take advantage of the LSB today (though that’s changing), and Project Portland isn’t in any of the distros yet (though we’re looking at bundling its primary deliverable, xdg-utils, with the LSB 3.2 SDK to work around that). Finally, even though the LSB provides ISVs with a consistent way to create an LSB compliant executable, there’s no consistent way to deliver an LSB compliant application that’s easy to install and that integrates well with the distribution’s package system. Yes, the LSB includes RPM today, but for a variety of reasons, ISVs don’t want to use RPM, and as already mentioned, not all distributions support RPM natively. Fortunately, once again, this isn’t just a rant. The LSB tackled these very issues at the LSB face to face and Packaging Summit last week in Berlin, Germany, and we think we have a way forward that’s acceptable to all involved: Linux distribution vendors who already have well established package systems and systems management tools built around them; ISVs who need to support multiple platforms and so don’t want to support the Linux specific RPM format or who otherwise want more control over the installation experience; and end users who want to use the software management facilities their distributions provide, whether that’s RPM or something higher level like APT and yum. More in part 2…