I've just been trying to set up a MythTV system, I've had the hardware for this for a while but until my TV broke I hadn't found the time to work on it.

My planned hardware was a P3 system for both frontend and backend. However the Debian MythTV packages take over 250M of memory for each of the frontend and backend programs (more than 500M for Myth programs alone), combine that with some memory use for MySQL, for the X server, and for the rest of a functional Linux system and a machine with 512M of RAM does not perform well. Unfortunately it seems that most (if not all) desktop P3 systems only support 512M of RAM (at least none of my collection of P3 machines does). P3 server systems support considerably more RAM (I used to have a SMP P3 server with 1G of RAM), but a server class machine is not what you want in your lounge room. P4 systems support more RAM but also take more than twice the electricity of P3 systems. The extra electricity use is a waste for a machine that will probably run 24*7, and also requires extra cooling (and therefore probably louder fans which is bad for a machine used for playing audio). Given that I desire the capabilities of a P4 in terms of RAM support and electricity use that is not excessive, my options are one of the recent Intel Core CPUs or AMD64 (both of which apparently use less electricity - not sure whether they would use as little as a P3) or a CPU designed for low power use (maybe a Via). Either option costs more than I prefer to spend (I want to use a second-hand machine valued at $129).

Of course if I could get Myth to use less memory then that would allow me to run both parts of MythTV on the one machine. Please offer any advice you can think of in regard to minimising memory use for Myth on Debian.

Given that I am unlikely to be able to optimise memory use as much as I desire it seems that I will have to go to a split model and try using an existing Pentium-D server machine as the backend and the P3 as a frontend. The up-side of this is that I can turn off the frontend machine when it's not being used (the server runs 24*7 anyway). I will need to get more RAM for the Pentium-D machine, but I had wanted to do that anyway.

The next thing I will have to do is to write SE Linux policy for MythTV and find out why /usr/lib/libmp3lame.so.0.0.0 needs both execmod and execstack (and either fix the library or write policy to permit that accss). I'm happy to have a MythTV server program running on a stand-alone machine with unrestricted access to all resources, but when it's going to run on a machine that is more important to me I need to lock it down.

Now to the design of MythTV. It's unfortunate that they don't support better multitasking options. One feature I would like to see is the ability to play MP3s in the background and then have the music pause whenever TV is selected. When I watch a live show (such as the news) I would like to listen to MP3s before it starts and then at the end of the show (and maybe during commercial breaks) have the MP3 playing resume where it left off. This is exactly the traditional lounge-room functionality we are all used to, when a commercial starts you mute the TV and un-pause the CD player! The advantage of MythTV is that you could do both with a single button - or even automatically with advert recognition!

The method of selecting MP3 files to play is also a little cumbersome and the option to add a song after the current one in the play list doesn't seem to work. Also it's a pity that there is no convenient option to sort the music list by artist, genre, or sone name - there are grouping options but they are all separate and I would like to change the sorting via a single key press.

The startup sequence of MythTV regenerates some images (which takes a few seconds), it seems that this is something that could be cached for a faster startup. Also when I add new MP3 files to the store I have to manually request a re-scan. It's a pity that it can't just check the size and time-stamp of the directories which contain MP3 files and do an automatic re-scan if they change.

Dear Lazyweb, dear Santa Claus, One thing I wish for exim is a patch for Exim Bugzilla Issue #66, which will incidentally fix Debian Bug #244724, which has become a recurring issue in various complex ISP configuration schemes. A patch solving this would add an option to an SMTP transport which allows the transport to set the authentication credentials instead of the authenticator. The transport still knows the host name given to it and can look up the right authentication credentials, while the authenticator only knows the IP address that we are connected to and thus needs to rely on reverse DNS information to look up the credentials. Which leads to numerous kinds of confusion regarding CNAMEs and broken reverse DNS on the ISP side. So, please dear Santa, give me a patch for that. It shouldn’t be too hard to do.

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.

Dear Lenny,

Since Etch is closer, i would like to see you under my tree before the 07' xmas. I know it will be hard since tanks coming from many different ways will try to stop us from work in something we like a lot. Believe in me, you still have a lot of fans with you regardless what the press is writing about us and our work lately.

They've no idea what's really going on and will do their best to spread FUD. It sells, in a world where lies told many times turns out to be the 'truth'. The real one is that hopefully in a year and some months you will raise the bar again. They will still apt-get into it, trying to understand our acts, trying to explain our community. We can't, they shouldn't.

Sincerely,
Gustavo "stratus" Franco

So, today, I finally stopped the l10n NMU campaign. It started on Sept. 25th with the "Intent to Work" on hesiod. The last package I worked on has been isync today. The goal of that campaign was closing as many longstanding l10n bug reports as possible. The main goals were decided during the i18n work meeting in Extremadura, back in September. We focused on po-debconf translations, mostly, which are an easy target for NMUs. Thomas Huriaux extracted the data from the BTS and ranked packages with regards to the number of pending l10n bugs and their age. Lucas Wall reactivated a coordination page which we already used back in early 2006 when a first version of such a campaign was run. During that campaign, I worked on 102 packages. 89 of them got all their pending l10n bugs closed, 5 of them got most of their l10n bugs closed (remaining "l10n" bugs were either not really related to localisation and strange things which I left aside), 8 packages were ignored either because their respective maintainers wanted to handle the bugs themselves or because they were tagged for removal. Meny packages have also been handled by their respective maintainers, either because the NMU announcements woke them up...or because of their natural release process. I have to point out that the level of collaboration of package maintainers has been great (except for those who are MIA, and there are quite a few) with only one very proeminent exception (just guess which one). Thijs Kinkhorst and Tobias Toedter also contributed to the campaign. Thanks to them as well. As a side effect, we also made many of these packages as lintian-clean as we could, trying to balance between too invasive NMUs and trivial fixes. IIRC, I only introduced 3 or 4 RC bugs doing so (which I fixed immediately of course). A few RC bugs were also fixed by the NMUs and even a security bug has been hunted down (for screen). Meny thanks to all package maintainers, translators and everybody who helped during that work. It has been a great time. Just look at the result. Now heading to the improvement of the next pet project of the i18n task force: the Debian i18n server.

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.

It's pretty cool to see that Technorati is going to be acting as an OpenID identity provider. That is, you can use a Technorati account as an identity on other sites (like Wikitravel). Technorati OpenID URLs look like http://technorati.com/profile/evanprodromou (say). Nice job, Technorati. tags: technorati identity openid

Encinitas Maj and I finished up our business in Los Angeles this morning, so we picked up stakes from her parents' house in Long Beach and drove down to my parents' condo in Encinitas. There was a time that a big chunk of my family lived in and around San Diego. My dad worked for a company called Peregrine Semiconductor, and my brother went to San Diego State University at the same time. Nate lived in Mission Beach, but my folks bought a condo in Encinitas, near Dad's work. Mom split her time between the house in Los Altos Hills and down here. Times have changed and everybody's drifted back up to the Bay Area (California), but my parents still own a condo on the cliffs over looking the Pacific Ocean. We all use the place for vacation time, although it's a lot easier for my brothers and parents in Northern California than it is for Maj, Amita June, and I in Montreal. Encinitas is a nice town with a really pleasant little main street on Pacific Coast Highway, great beaches, clean air and the sound of waves as you're falling asleep. We spent 4 days down here last winter, and really enjoyed it -- probably the most relaxing time of the year. We're going to spend a few more days here this week. Last year, in the late afternoon, Maj took Amita June into the pool in the condo complex. It's about 20 feet from the edge of a cliff over the Pacific, and as they were swimming around the pool, the sunset was making a red-gold luminous carpet out of the ocean below. We were close enough that we could see dolphins jumping in and out of the water. My baby and wife laughing over a dolphin-dotted sunset; jeez. Mom and Dad are selling the condo -- we're going to have to dodge realtors while we stay here -- so it's unlikely we'll get another chance to spend time in this particular condo again. Good to appreciate the time while we can. tags: encinitas san diego sunsets dolphins

Wikitravel on CNN The AP article about online travel guides made it onto CNN. The last time we had an article about Wikitravel syndicated ( Web Denizens Contribute to Do-It-Yourself 'Wikimania'), originally by Ellen Lee of the Contra Costa Times and published December 2005, it kept popping up for months. I figure this one will be out there for a while, too. tags: cnn wikitravel

Lessig Steps Aside I'm sad to see that Lawrence Lessig will be stepping down from his position as chairman for Creative Commons. As he announced in his latest "Lessig Letter", CC Changes, Joi Ito will be taking over the position. I don't think there's a better person to do the job. I hope that both of them continue to work for free culture in their own ways and through CC. tags: cc lessig joi ito

MyBlogLog TechCrunch is effusive about how great MyBlogLog is. I tried it out a bit, and I have a MyBlogLog account, but I found the user tracking script a little creepy and invasive. So I took it off. I'm not sure the value of the service outweighs the automated click-tracking. tags: mybloglog privacy cookies

Here is a graph showing the number of proposals sent in for XTech 2007 over the last two weeks. The actual deadline date is the highest bar. The Monday after, when everybody realised they'd missed the deadline, is the second highest bar. Of course, it's an open secret that tech conferences regularly extend their deadlines to account for such things. I am probably stricter than most programme chairs in this respect.
This year we got over 200 proposals. That means over three proposals to each slot, so choosing's going to be tough.This graph is one of the bits of helpful eye candy ExpectNation gives me. As the conference organization proceeds I'll publish some other interesting details about the inner workings of XTech.Meanwhile, I'm overwhelmed as usual with the quality of conference submissions, and will enjoy the task of reading each one this week. 

I've been sitting on this for a while, gradually adding more bits as I think of them. So it's a bit long and rambly, but if I don't post it now I'll never get round to it. First, the details, for anyone who cares. I got married to my partner of 11 years, Katherine, on 1st December. This was actually our 11 year anniversary. We had a civil ceremony in The Assembly House, Norwich with a wine reception afterwards, then moved on to Wolterton Hall for the main reception, with a magnificant feast provided by Brasteds. Afterwards there was a chocolate fountain courtesy of Digby's and Nero thanks to Milton. The wedding cars were provided by American Dream (we had the Excalibur Sedan and the Lincoln Town Car). The bus to/from the reception was from Dolphin Autos. Robin Phillips brought the band. Wonderful purple jacket + the other suits were from John Field Formal Hire. Next, some photos. Burly Dave Ganesh Paddy Steve Tim (Ceremony) Tim (Reception) Finally, some things I've learned. For guests (I wish someone had told me these - Katherine says I sound stroppy but I don't mean to):

• As soon as you know if you're going or not, let the couple know. Especially if you're not going. They will probably be constrained on numbers and there are very few people who can be invited at short notice if you only let them know you're not coming by the RSVP deadline.

• Don't leave buying your present until the last minute. The couple will have lots more important things on their minds in the final week or two than trying to make sure there's enough left on the gift list.

• People really do mean that they'd rather you turned up than gave a gift. I never fully appreciated this; I'd feel bad going to a wedding without having given a gift. However I know that it's not cheap to get to Norwich and (in most cases) have to spend at least one night in a hotel. I'd much rather people did that and I got to see them on the day than they sent a present.

For couples getting married:

• It costs more than you think. Really. I'd always assumed hotels dug their arm in for weddings and upped all the prices, but actually the hotels we looked at were the cheap options, both in terms of the actual cost and also the fact they'd throw extras like a honeymoon suite in for free.

• Make sure everyone in the wedding party knows the way to the ceremony venue. Really. Don't rely on them to ask you, or assume that they'll have looked at the directions you've prepared.

• People are far too generous. We received many completely unexpected gifts from relatives or friends who we hadn't invited to the wedding, or those who couldn't make it. (As well as many of the people who came to the wedding buying us far too much.) If you gave us a gift, you will get a thank you card - these are already in progress but it probably won't be until after the New Year before they're all sorted and sent.

• Don't leave booking a honeymoon until after the wedding. We had issues regarding not being sure about Katherine's holidays and we ended up not sorting anything until a couple of weeks later. This reduced our options somewhat.

• So far it doesn't seem to have changed anything much. Katherine and I have already been living together for some time which we consider a bigger step. And we haven't seen a whole lot of each other since the wedding, though we have spent the past week together. But really, we don't feel a lot different yet.

For various reasons, Software in the Public Interest (SPI) owned the domains opensource.org and opensource.net, which have been managed by the Open Source Initiative (OSI) for most of their life. This supported various SPI goals and also gave a possibility of community control of opensource.org/net just in case it was ever needed. OSI does not offer much opportunity for community control, as it is a self-appointing board. (Regular readers may remember that the principles of democratic member control, autonomy and concern for community are important to me.) I was watching as the SPI board voted in favour of giving away the opensource domains, proposal 2006-11-18.dbg.mjs.1 on the agenda. The vote happened without any discussion in the meeting. From memory (I guess logs will appear on the SPI site eventually):- David Graham ("SPI must also be involved in the promotion of and education about open source") proposed and voted for this action that stops SPI being involved in this promotion and education about open source; Michael Schultheiss ("I look forward to SPI's future expansion") (amended and?) voted for this action that reduces SPI; Neil McGovern ("achieve a greater degree of involvement [...] from the community in general") voted for this action that lessens SPI's involvement; Jimmy Kaplowitz ("It is important that it continue holding in trust the money and other legal assets belonging to its member projects [...] fulfill some more of its stated corporate purposes, involving education of the general public about free software and about computers in general") voted for this action that drops these assets and reduces involvement in education of the general public; Bdale Garbee ("would like to close this issue one way or another, once and for all") seemed willing to vote for anything which prevented further discussion - of course, only surrendering the domains could close it once and for all, as this is a one-way trapdoor topic - but had apologised for absence from the meeting; Martin "Joey" Schulze had apologised for absence from the meeting; Josh Berkus (nothing obviously relevant in his platform) abstained - consistent but disappointing; I think Branden Robinson was missing. Ian Jackson ("SPI's role is to provide a stable legal entity which can hold assets") voted against this action so that SPI would keep holding these assets. Bravo! Sources: The quotes above are the board's own promises in their election platforms, as listed on the SPI site in 2003 2006 apart from Bdale Garbee's platform which wasn't at the link given in 2004 so that quote is from the minutes of the previous meeting If some board members are willing to give away assets for no good reason, that strikes at one of SPI's core methods: holding assets for the community. What can we trust about this board? Their platforms are full of fine sentiments, but how do their actions reflect their platforms? This may be a mostly-dormant issue until the next election. If you want any of SPI's assets, just ask. If your request is rejected (as SPI rejected the opensource domain give-away before), just keep asking new sets of voters until they agree.

Many people have recently posted in Planet Debian regarding the use, usability and usefulness of having comments enabled in blogs, of using comments as the right way for following discussions, of dealing with spam, and so on.
I'm sorry I'm not linking to more of them, but I'm too lazy to look them up. This is one of the down-sides of not using comments - Ideally, if I were interested on commenting on a topic, I would just leave the comment on the blog that started it. It goes somewhat against Joey's logic of posting both the comment and the posting itself - Of course, we all want everybody and their dogs to read our comments, don't we? And, given we know that (most of) our target readers regularly follow Planet Debian, we continue ranting on our personal blogs (as I'm doing now). Besides, that will rank our page higher. We all want Google to love us, right? Of course, following discussions on a bunch of blogs is not optimal, as it's easier to miss parts of it (hey, would somebody volunteer on writing threading support for Planet? It'd have to be multidimensional, as postings often refer to different threads... Bah :) ). Besides, many of us are syndicated on different planets (and many people read our blogs as individuals as well), so many of my postings start with a stupid amount of background information so the martians understand the terrans. But still, here I am, writing a post that provides nothing but a braindump, serves no purpose, and links to your posting. So there, the world is not ideal. QED.
As always, MJR rants against captchas (and yes, thank you, you have commented on my blog that most captchas are trivially crackable by automated means). They do reduce spam, but they are REALLY not a strong barrier against it. I have thought of some ideas, or thought about implementations for other ideas I've read here and there, but I'm too lazy to implement them on my blogging software. I could switch, but I happen to like Jaws. I would like to contribute to making it better, but have had a permanent lack of time for a long time already :-/ I do get swamped by spam comments, and every now and then mass-delete whatever looks like spam (hundreds to thousands of comments, for crap's sake!), but anyway... It's not too important for me. I like having comments on my entries, but sometimes a long time must pass until I even read them (I read my own blog syndicated via the Planets, on a RSS reader).
BTW, Lucas: I used to have trackbacks enabled. The amount of spam, and the control I have over spam in my blog, makes me favor comments against trackbacks. My trackbacks used to be so wildly abused that it almost made me cry. I hope it is not your case :)

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!

Given the recent articles or blog posts that may lead some people to think that dunc bank made people work against Debian, maybe some explanations are needed. Dunc-bank is a single web page that some humourless people may find unfunny, YMMV, but that is nothing else than satirical. There was no conspiracy, undermining work, or power games. People claiming the contrary are just making complete fools of themselves. Really. The people that contributed to dunc-bank, meaning that did report most of the RC bugs in the last month are for some, even disgruntled when it comes to dunc-bank (I'm thinking e.g. of Lucas Nussbaum that did a full archive rebuild and reported many bugs). No, dunc-bank is not the evil masonery club that some depict. The sole thing I think really happened, is that people are nowadays really concerned about QA, and that there is a whole lot of issues that can be tracked automatically, at home (a good ADSL line and a GHz grade CPU is largely enough to do an archive rebuild in a week nowadays). What is really a shame in fact, is that those checks are not performed by Debian for any package, and on a regular basis. The other factor is that I think many people had concerns with etch quality, as many discussions in the past month may have let think that its quality could suffer from the announced release date. Now that this bad joke is now officially a dead-line, I think this is less and less a concern. That said, Yes, I do think some people that usually did good work in debian diminished their work considerably, and that it hurt the release. We lost some developpers (our locales + X-keyboard expert and that's a huge loss), some orphaned a lot of packages, and recent events do show that you can't improvise beeing the libpng maintainer a month before the release, and so on. Yes it's true that recent events and surroundings in Debian^[1] have led people to feel they are strangers to what Debian is becoming. And blaming them for not beeing supportive is very distateful and shocking. When you do pursue actions, that will lead to big changes in the community, then blaming the community members for those changes is a shame. So no, you can't blame the people behaviours (that have been reduced to dunc-bank supporters because that's so easy) for etch beeing late, because you can't blame the direct consequences of an action for beeing the cause of its failure.

Good morning… today I saw the RFP for “pokerth” on WNPP, had a look at upstreams website and just retitled to an ITP. Now my package is ready (and in the queue of my AM to upload )
For those who are bored or like to play poker games I already have a little preview: http://www.marioiseli.com/debian/sid/main/source/games/asciijump_0.0.6-3.dsc
http://www.marioiseli.com/debian/sid/main/binary-i386/games/pokerth_0.3-1_i386.deb Yeah I know, please don’t flame me because I write a blog article just due to one single Debian package, but I really like this game and hope you have fun with it too… Regards… (I’m not responsible when you arrive late at work tomorrow…)

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

Takatsugu had problems with his maildir and lost a bunch of mail. This reminded me of my little script that keeps my maildirs at a reasonable small size. I let run over my maildirs every night. It removes duplicate mails first and then moves all mails that are older then 30
days and not part of an active thread into a $maildirname.attic maildir.

I invoke it like this on my mail server in my user's crontab

@daily ~/src/pack_maildir.pl --maildir=~/Maildir --dir=. $(find ~/Maildir -maxdepth 1 -mindepth 1 -type d -not -name '*.attic' -not -name 'tmp' -not -name 'new' -not -name 'cur' -not -regex '.*Trash.*' -not -regex '.*Trash.*' -not -name '.SENT' -not -name '.Sent' -not -name '.DRAFTS' -not -name '.Drafts' -not -name '.virus' -not -name '.merkwurdiges' -name '.*' -printf "--dir=\%f ")

and duplicate the maildirs from there to my working machines with offlineimap.

This setup is orthogonal to spam protection, however. Apropos spam: According to my munin spamstats i get a magnitude more spam then ham nowerdays.

(This blog entry is a bit delayed because I have been on the QA meeting.) On Monday and Tuesday last week we did one important step: We sent out the release update that etch is fully frozen now. Preparing that, and then handling the incoming freeze requests took some of the time. Of course, some of the regular RC bug squashing happened as well - but that is rather a routine task now.

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.

At work, we're doing some coding to integrate our system with Ebay's system, which is kind of big and complex. Here's some PHP code to get a listed item, from eBay's developer site:

$verb = 'GetItem';
//Regulates versioning of the XML interface for the API
$compatabilityLevel = 433;
//get an array of strings containing the required headers
$headers = buildEbayHeaders($devID, $appID, $certID, $compatabilityLevel, $siteID, $verb);
///Build the request Xml string
$requestXmlBody = '<?xml version="1.0" encoding="utf-8" ?>';
$requestXmlBody .= '<GetItemRequest xmlns="urn:ebay:apis:eBLBaseComponents">';
$requestXmlBody .= "<RequesterCredentials><eBayAuthToken>$userToken</eBayAuthToken></RequesterCredentials>";
$requestXmlBody .= "<ItemID>$id</ItemID>";
$requestXmlBody .= '</GetItemRequest>';
$responseXml = sendHttpRequest($requestXmlBody, $serverUrl, $headers);
if(stristr($responseXml, 'HTTP 404')   $responseXml == '')  
    die('<P>Error sending request');
 
//Xml string is parsed and creates a DOM Document object
$responseDoc = domxml_open_mem($responseXml);
//get any error nodes
$errors = $responseDoc->get_elements_by_tagname('Errors');
//if there are rrror nodes
if(count($errors) > 0)

... and so on and so forth (it just gets more painful)... Compare with Cody Fauser's Ruby eBay API

ebay = Ebay::Api.new
begin
  response = ebay.get_item(:item_id => '110011765264')
rescue Ebay::RequestError => e
  e.errors.each do  error 
    puts error.long_message
  end
end

It's not even a contest. Best of all, most of the code that turns the XML interface into Ruby code is auto-generated. Very nice work!

At OSDC Mary Gardiner gave a talk titled The Planet Feed Reader: Better Living Through Gravity. During the course of the presentation she expressed the opinion that short dialog based blog entries are a sign of a well running planet.

Certainly if blog posts respond to each other then there is a community interaction, and if that is what you desire from a planet then it can be considered a good thing. Mary seemed focussed on planets for internal use rather than for people outside the community which makes the interaction more important.

However I believe that planets are not a direct substitute for mailing lists. On a mailing list you can reply to a message agreeing with it and expect that the same people who saw the original message will see your reply. Blogs however are each syndicated separately so a blog post in response to someone else's blog should be readable on it's own. A one line post saying "John is right" provides little value to people who don't know who John is, especially if you don't provide a link to John's post that you agree with.

On Planet Debian there have been a few contentious issues discussed where multiple people posted one-line blog entries. I believe that the effective way to communicate their opinions would either be to write a short essay (maybe 2-3 paragraphs) explaining their opinion and the reasons for it, or if they have no new insight to contribute then they should summarise the discussion.

I believe that a planet such as Planet Debian or Planet Linux Australia should not only be a forum for people who are in the community but also an introduction to the community for people who are outside. AOL posts don't help in this regard.

One final thing to note is that blogs already do have a feature for allowing "me too" responses, it's the blog comment facility...

PS Above is a picture of day 59 of the beard, it was taken on the 5th of December (I've been a little slack with beard pictures).