Last weekend, Jeroen van Wolffelaar and Thijs Kinkhorst organised a BSP at Utrecht University. I went along for a couple of reasons:

• to help reduce the number of RC bugs in the run-up to the Etch release
• to meet some of the Dutch developers and users, and to encourage them to work their best for Etch

I met up with Hanna Ollila at Schiphol Airport late on Friday evening, and we took the train down to Utrecht together. We found Jeroen and some others at the station and went straight on to a party in the middle of town for a few hours. Then after just a few hours' sleep we headed into the University to get breakfast and start squashing bugs. A group of about a dozen people turned up that day - mainly a mixture of Dutch DDs and other locals.

I took a look at a couple of bugs initially on Saturday: #387419 and #387498. Unfortunately, the first (kdepim FTBFS on alpha) was difficult to reproduce - the alpha machine I had available for testing was too short on memory and took a very long time to build kdepim, long enough that after 2 days I gave up. I couldn't reproduce the latter (system() hanging when running on mips) on any machine I had access to - it looks like more work is needed there... In parallel with those two RC bugs (found on Andreas' great summary page at http://bts.turmzimmer.net/details.php), I also had a very productive session working in parallel with Christian Perrier, fixing translation/i18n bugs in one of my own packages, CVS. Thanks Christian, you're a pleasure to work with! On Saturday evening, the gang of us headed into the centre of Utrecht for a nice meal, some beer and some spirited conversation at a Greek restaurant. I took the opportunity to talk with Frans Pop about some of the remaining work needed for d-i and debian-cd. On Sunday, the work continued. I was still waiting on feedback on #387498 and my build of #387419, so I decided to make the most of the uninterrupted time to get some debian-cd development work done. I'm still hoping to get multi-arch CDs working before we release etch, so this was a great help. In fact, I got so engrossed in this that I managed to work straight through dinner...! In terms of bugs, I must admit that I didn't do much in terms of reducing absolute numbers. This weekend, there were a lot of bugs in categories that don't really work well for Bug Squashing: licensing/legal bugs (which really need discussion with the maintainer), newly-opened bugs (IMHO it's a little rude to NMU a package when a bug has only just been opened - give the maintainer at least a couple of days to respond!) and deep bugs where intimate knowledge of the package is needed. I expect there will be more to work on next weekend in Zurich, if nothing else some of those "new" bugs will have aged. Early on Monday morning I caught the bus from near Jeroen's apartment to start the journey home. Thanks to the nice reliable public transport, I got all the way to Schiphol well in time. Then my flight back to Stansted was delayed... :-( It was great to meet up with a bunch of enthusiastic people. Some I'd met before (Frans, Jeroen, Hanna). Some I met for the first time (Thijs, Bas, Moritz and others). But all of them were working hard, wanting to help get Etch out on time. Let's keep up the good work! I have a small number of photos online.

I've chosen debian because it fulfills an ideal. For me Debian is about to build an Universal OS , and when decisions has to be taken, it's based:

• on the technical quality for the technical ones,
• the consensus of the community for the others.

To live decently, I do work also in a start-up company that also happen to write closed-source software. That gives me enough money to eat and live well, and beeing able to dedicate my free time on Debian and free software. That means I've done the choice on purpose not to mix my paid work with Debian, because I don't want to balance the decisions I take in Debian I against my well-beeing. That said, I'm completely OK with people having paid works intimately related to their DD work. And if their work is intimately related to etch beeing released in time, then well, I wish them a lot of courrage. I wouldn't have the guts. I'm OK with this because we are talking about people that are not able to impose decisions to me that I judge irealist or bad. And still, I can dismiss such decision thanks to the CTTE if needed. Though, when it comes to delegates, it's a full different story, because I do have to interact with those guys in my allday Debian work, and that undoing their decisions needs a GR as per constitution. It's way less easy than going in front of the CTTE. And if Delegates are paid whichever the entity that pays them is, they will have to balance technical choices against beeing able to eat tonight (or reimburse their house, or ). Obviously, one will say that it's OK here, it's not a salary, and that the currently discussed^[1] contract is not about doing the RM releasing Debian in time, but helping toward that goal, or trying to release in time not sacrificing the release quality. I answer bullshit! to that. Our RM have at least I happen to hope so more higher standards than that. If they accept that mission it's to see it completed. I'm already fearing for them getting down if they can't achieve that.
I also know that at least one of the dunc-tank board member^[2] would like to see a structure able to fund DD's to work on Debian, and be able to live from that. I'm sorry, but that's an option I don't want the project to take. And if dunc-tank is a prelude to that, so please don't even think of starting it. When there is money in the game, the donator,employer,boss, and the guy accepting that money have at least a moral contract if not a legally binding one of results. And I see no investor that would happen to be interessed into a contract where the due in line is undefined. Thinking otherwise looks like complete naivety to me. So either it won't work, either people will have to take into account other parameters than technical quality when the will have to make choices. I see in my paid work what such things mean, and I do consider me lucky, I'm in a company where people do know what quality means. Though the company also has to live, and that sometimes makes us take choices that I don't like at all. I never want have to even consider such choices in Debian. I'm sorry, but putting such considerations in the project is jeopardizing what the project means and represent to me. The sole structure that would maybe fit would be some bounty board, with the following things done:

• any person (at least for DD's) can come with his project, with absolutely no censorship;
• the proposer that comes with his idea chooses the price for it, with again no censorship;
• anyone is free to do the job for free, obsoleting the bounty^[3], so that a bounty cannot become blocking.

And even with that some kind of checking that the job has been done correctly has to be done somewhere, and I don't see clearly who could do that, but I suppose that's doable to find some fair reviewers plus the donator(s) for that.
That said dunc-tank does not meet any of the previous requirements, is driven by delegates, and works around the thorny problem of finding a consensus among the DD's in the worst possible way. Those are the reasons^[4] why I think dunc-tank is a bad idea.
And to the people offended that I seconded the recall, this is about the fact that I found the way dunc-tank has been imposed to us after having asked for our opinion, and heard the acute opposition of some of us hideous, and about the fact that beeing the DPL, or even a delegate and in dunc-tank at the same time is a conflict of interests. It's not a matter of beeing pro or against dunc-tank, matter against which there is no course of action for me anyway, as it has been on purpose and artificially kept outside of Debian.

More than one month ago, when back from holidays (without a real break in my Debian activities, thanks to hotels in Mexico with Wifi), I decided to focus on technical work. No more sterile discussions, no more arguing in political Debian mailing lists, no more lessons given to the entire world (something that we(fr_FR) are so well known for). Just technical stuff and one goal: the i18n Extremadura meeting. That meeting went so well that I still have tons of work to do, combined to new organization and duties at work. This left nearly no room for tentations to react to the various events that shaked out little world recently et C'est Tres Bien, mes petits amis. I will certainly continue with that good resolution. After all, we have to release in December, don't we? :-). And we have an interesting l10n NMU campaign running as well as a running jihad against many boring and useless debconf notes.

Today is the day against DRM. Thousands of people around the world are spreading the word about Digital Restriction Management technologies. The interesting thing about the people building DRM systems is that they're doing evil. They may not think they're doing evil, after all they're generally good people, doing their jobs, feeding their families, and protecting their interests. It's not a big evil, but it is a subtle one. And that's why you shouldn't support them. For decades, the music industry has been making money by selling records and tapes. This was a good business, because it was difficult to produce records, and it was difficult to get tapes into the hands of consumers. They made quite a tidy sum over production and distribution of art, which is a pretty decent living. But then came the Internet. And the Internet got big. Big enough that you're reading what I'm writing, even though we come from completely different backgrounds and are probably miles apart. The interesting thing about the Internet is that copying a song and sending it to someone else costs almost nothing. Zip, zero, zilch. Now traditional media distribution houses are upset. The service they performed was valuable and the goods they sold were scarce. Nowadays, neither or those are true. People can record music in their garages, edit it on their computers, and publish it online. The digital medium has turned art from a scarce resource into an abundance. So what do companies do? They feel that they have to protect their existing business models so they try to push through legislation that would make it illegal to provide abundance. That's like arresting farmers for plant seeds they've harvested from their own wheat. But this is wrong. People are now using the Internet to make and distribute art like we've never seen before. The proliferation of new songs, new pictures, new videos is just enormous. The creative community has exploded through sharing, some of it illegal, and we can all see what a vibe this has caused. DRM is meant to put a stop to that. It's designed to have two components: one is the technology that monitors and restricts what you can do with the art that you've bought, the second is the legislation that makes it illegal to circumvent this technology. So only criminals will be able to give music to their friends. But criminals will do that anyway, laws won't prevent DVD duplication in Asia. They will, however, stop you from listening to music in ways some corporation doesn't want you to. What can you do about it? Make it known that you're against DRM. Make it known that you're against proprietary systems that stifle the creative spirit. And only purchase open systems. Not just because it's the right thing to do, but also because they won't hold you hostage.

At the moment I estimate a 50% chance that etch will ship with a debhelper that I don't loathe. The NMUed up version for the python transition is not something I'll be at all happy with etch shipping with. Thanks to several Debian pythoneers, we have a plan to fix this, but getting it into testing in time for the freeze is looking increasingly tricky. The plan is:

1. Revert dh_python to the pre-NMU version.
2. Make dhpython detect debian/pycompat or Python-Version and become a no-op in those cases. Generally deprecate dhpython.
3. Make dhpysupport do everything dhpython used to do.
4. Make dhpycentral do everything dhpython used to do.
5. Test everything. (Ideally, all python packages.)

Steps 1 2 and 3 are done in the 3-day delayed upload queue. Step 4 still needs to be done, and some initial tries at it have failed. Step 5 has so far been limited to building a half-dozen or so packages. The details are in #381389.

Today I started reading High Fidelity and am having trouble putting it down. So far I have read three other of Hornby’s novels: About a Boy, How to Be Good and A Long Way Down (in that order). And to be honest after the insightful intrigue of the former I found the other two lacking in anything of any interest. A Long Way Down was massively predictable and a tad morbidly bland and How to Be Good failed to say anything interesting, at all. Ever. A couple of weekends ago I was visited by some close friends from Cambridge, Steve and Noirin, and we did the usual Berlin things. Sunday Fr hst ck, shopping, eating ice cream and a helluvalot of walking. We did however see Thankyou For Smoking at the Original Version cinema at the Sony Center. It was witty and clever and all the things a good film should be. Noirin commented afterwards that in the whole film that you don’t see anybody smoking in the whole thing. I’m looking forward to Starter for Ten. I doubt anyone outside the UK will really grok a film about a cult television series (if Countdown is cult, University Challenge must be up there with the Today Programme.) (Pardon the cheesy pun on the name of a chain of book shops long since subsumed into the now ubiquitous Borders.)

For most of this year I've been working mainly on a Macbook Pro, having deserted my Ubuntu desktop.  Somebody wrote to me recently, kindly enquiring how this life was going, and asking some questions in particular.

Although of limited interest to some, I decided to answer the mail here, if for nothing else to record my views for future reference.

Q: How is developing on a Mac? Is TextMate really that good?

Developing Rails applications on a Mac is sweet, and yes, TextMate really is that good. My jilted .emacs languishes in lonely misery.

Developing other (non-Mac) stuff on a Mac is a real pain however, because nothing's where you'd expect it after years of Linux use.  Like several other developers I've seen, I run Ubuntu Linux in a virtual machine under Parallels for such work.

It's not just that Macs lack apt-get (as you can get it with fink), it's that they lack the reliability of Debian or Ubuntu's package repositories to underpin it. Running Linux in a virtual machine is far easier.

On the subject of TextMate,  perhaps the best compliment I can pay it is that using it reminds me of the last text editors I really felt at home in, CygnusEd and then FrexxEd on the Amiga. TextMate's most serious flaw is the inability to create split views, however. It seems to me that's a key programmers' feature, to be able to read from one source file at the same time as editing another.

Q: Is the hype about Ruby on Rails true?

I still think so. I resisted it for 6 months because I tend to be averse to anything that gets such a large amount of publicity, but then stepped aboard the train around the time of Rails 0.13.

I've not really looked back after my initial experiments seemed to bear out the claim of developing "ten times faster than PHP". I'll admit I find it hard to keep up with all the extra developments that get added at the Rails cutting edge, but then again I don't really need them.  Most of those additions are refinements, rather than core changes. Constraints on my time mean I tend to write in a common Rails subset, as opposed to flexing my muscles with the obscure but clever bits.Even if your taste isn't for Rails, then the trend that Rails, Django and friends have started is improving the web development playing field for all.

Q: What makes you happy and sad about the Mac?

The things that the Mac still scores on are:

• Fonts, fonts, fonts. Despite all my many efforts at getting good letterforms on Linux, I still couldn't make it as good as OS X.
• Productivity applications. I love my OmniGraffle and OmniOutliner. I'm salivating over the prospect of OmniFocus, and Quicksilver rocks my world.
• Hardware. Suspend/resume without worry, video conferencing that works.

The interesting thing to me is that none of these are very difficult to surmount, for want of a little resource.  The day of the Linux desktop, so perennially around the corner, will yet come.

As a balancing postscript, I will mention that there are some things that are Mac irritants to a sensible Linux person, which include filesystem case sensitivity, lack of decent SSH agent (yes, I've tried them all), not knowing what to kill -9 when things go pear-shaped, Apple's arrogance, crippled nature of some default apps (iChat won't put multiple accounts in the same window, Safari doesn't support keyboard navigation at all well, Quicktime player won't play movies fullscreen).

I have received some requests (as comments) to publish the info i have about the USB key. I will do that soon, when I manage to get my home ADSL working again…

Martin 'Joey' Schulze is still aggressively writing against Dunc tank. I don't agree with his posting at all. I don't think dunc-tank is doing any serious damage to the project; so far all the damage comes from a few people (especially you, Joey), that play some "politics" game here I don't really get or like. And just count the number of people who have expressed discomfort with your postings. I remember having seen the word "blackmail" attributed to some of your mails. [Update: and it also sucks that people have to point out that they didn't reduce their Debian involvement because of Dunc tank, but just because they don't use the software anymore, have too little time or are annoyed by your behaviour; otherwise you'd probably cite them as dunc-tank enemies.] I'm also convinced that your assessment - that only the release in december counts - is false. You know, the people working on Debian were NOT replaced by the announcement of the dunc tank experiment. We still want to make Debian the "Universal OS", and are still dedicated to the projects goals. But some of us still remember the bad press debian has been receiving because of the delays with sarge release, and the users we have lost back then because of pushing back the release again and again. You know, many people still act like "yeah, debian releases in december, sure, when hell freezes over". One of Debians strengths was security support. But security support doesn't work as well, when half of the software you're running are unsupported backports. If Debian wants to remain a good base choice (i.e. universal OS), it needs to provide a reliable combination of secure but not too-out-of-date software to become useless again. Therefore I consider frequent-enough, somewhat-on-time releases important for the universal OS idea; this will also cut down on our work (at least for those doing backports, too, since we need to do less of them). It's not a primary goal, but a consequence of the well-established goals. Now why I accept the experiment of 'hiring' the release managers for one month full-time: I've always had the impression that donating to Debian is somewhat pointless, because I don't see any concrete results, or where the money is going. To me it always felt like it ends up in an unused saving account with the SPI treasurer, until someone finds a way to spend it. Here the money is used in a transparent way, on well-respected people and with a very concrete result. And remember, it's an experiment. It's a one time thing so far. Oh, and to actually counter all your blah-blah: I've actually recently increased my Debian efforts again. Because of the dunc-tank thing, and despite your end-of-the-world-claims. Namely because it gave me back the feeling that someone actually cares about making Debian useful to everbody (and not just us freaks running unstable and experimental). That there is some interest in getting the new release out of the door on time, of supporting our users out there such as the city of munich (which is also running backports AFAIK). To me Debian is still mostly about the users, not about the ego of developers. Be a nice guy and do a good job, and you'll get lots of thank yous, a couple of friends, a couple of patches, some free beer or tshirts in return. Does this corrupt as well, getting a free coke? Yes, I got a free Jolt coke four years ago at Systems. Does this make you demotivated, that you didn't get one, too?

Strange comments from Release Manager Andreas Barth predicting that this resolution would mean:

'The debian-installer has to be changed prior to release of Etch. This change alone would delay by at least 6 months, according to Joey's estimations.'

The resolution does not specify how it should be implemented technically. I'm pretty sure other options (such as dropping some hardware support from the official release) have been mentioned and there are probably suggestions that I'm unaware of. If the release managers choose to delay the release until debian-installer is changed, then that is their choice.

'Even fonts and videos would fall into the category where we would need source - but what is the source of a font? or a video stream? (and yes, fonts are "works that are executed by other means", i.e. displayed on the screen) That is a great new place for lots of new discussions that don't really help our users, but will definitly waste lots of time.'

The source of a font is what you used to make that font. Similarly for other work. It's pretty obvious in most cases. As far as I understand the concept of streaming video, we don't have it in the release, so that one seems a strange argument to me.

'We would be in a very bad situation e.g. with the debian-keyring (and all other sort of crypthographic stuff) - I definitly don't plan to distribute the sources for my public key (as the sources can also be used to generate the private key).'

I think this is the only interesting point: but is the debian-keyring made up of programs, rather than data that is input to a program? Do the private keys contain instructions which are executed by GnuPG? If not, note that source provision is only "strongly recommended" not required and there is a pretty strong reason for it not to be included in this small case.

'In summary, this proposal would delay the release of Etch by at least 6 months, probably even one year. Of course, any of the pending GRs can still overrule the result of this GR, but - that is not something we should be proud about, or even plan.'

In summary, I think we should remember that predictions can be wrong as well as right, even from a release manager, whether or not they are being paid for their time by an external organisation. Of course, the release manager could try to make those predictions true, but that would be pretty cynical. Vote to reaffirm DFSG 2! Update: shortly after publication of the above, someone at TU Wien wrote "yay for debian-legal fuckheads". Good argument(!) I can see why you are at university(!) Also, Andreas Barth's last blog post keeps changing the date, so it sits in the top place on planet for ages. I didn't think it was so weak as to need that sort of help. This update suggests it might be a software bug, though. Update 2: Hoho, guess I found part of the problem!

Joey:

I reduced my involvement in Debian because of, well, posts like this and this. When given the choice between working on something where technical issues matter and one where people will spend most of their time trying to score political points using inaccurate or misleading information[1] or just making assertions about people's motivations[2], the one where I don't bleed out of my eyes is going to win.

For what it's worth, one of the reasons I got a previous job was that I was a Debian developer and part of my job involved ensuring that our product was packaged and maintained in Debian. Had I lost the ability to do that, it's entirely likely that I wouldn't have had my contract renewed. I'll await my retroactive internment in the reeducation camps.

OH GOD WASN'T I SUPPOSED TO HAVE STOPPED CARING ABOUT THIS STUFF?

[1] Joss: compiz is dual GPL/MIT. The maintainer is well within his rights to chose to distribute the package purely under the GPL, and could easily argue that the Debian modifications to the package are GPL only. NEW has never been a FIFO, and sexy packages have often passed through more quickly. New upload in FTBFS shock? FILM AT GODDAMNED 11.

[2] Not sure if this is true, but Joey hates on AJ because he was abused by an Australian circus clown when he was 20. I've no evidence whatsoever to justify that statement, but it suits my argument to make it anyway.

General freeze is getting closer, so it was time for me to push things a little forward. I have uploaded a NMU of kexec-tools yesterday to delayed/5 which add support of init scripts. That means that you will just have to edit /etc/default/kexec, change USE_KEXEC=0 to 1 and reboot will use kexec. :-) Furthermore, this upload was acknowledged by the maintainer of kexec-tools, Khalid Aziz, so this is really good, thanks to him.

"Debian developer Eric Dorland confirmed to internetnews.com that Debian will re-name Firefox and that the re-naming process could be completed as soon as next week." (in Firefox Not Really Free? [Sean Michael Kerner], tip to /Jonas) Another hat-tip to /Jonas for this thought-provoking suggestion: are MozCorp deliberately trying to mimic X-Oz's role in the XFree86 farce?

Two of our good friends here in Montreal are Kate and Morgan. She's a Ph.D. student in philosophy at Rutgers, working on her dissertation here, and he's a game designer. They're from Australia originally, and they just got married Down Under about 4 weeks ago. Her dad and stepmom live in North America, though, so they're thoughtfully holding a wedding party next weekend for Kate and Morgan's American friends and family at their home in wt:Hudson (New York). We've driven through the area a few times in the past, but we haven't really stopped for long. From what Kate says, Hudson's a pretty town and early October means lots of leaf-peeping opportunities. Not that Montreal's any slouch in that respect right now, but it will be nice to see other people's leaves, I guess. There's also a Firefighter Museum and a Shaker Museum. I also just finished The Island at the Center of the World, a historical book about the 17th-century Dutch colony of New Netherlands (now New York). The main settlements were in the Hudson Valley between Manhattan and Albany (New York), so I'd like to find a nice one to stop at and look around. The drive down is about 4-1/2 hours, and I think we'll be OK doing it in one hop, even with the baby strapped down in the back seat. We're heading out on Friday evening, spending Saturday checking out the sights, then parties on Sunday and Monday (a holiday, Columbus Day, in the US). Monday night Maj got us tickets to see Massive Attack here in Montreal, so we'll be zooming back up highway 87 Monday afternoon and if we can avoid problems at the border in wt:Plattsburgh we'll be rockin' out (a bit) that evening. tags: kate morgan wedding party hudson massive attack leaf peeping

Parallel distrihoozit The discussions on the cc-licenses list over the last week have gotten increasingly heated. At heart is the very emotional issue of DRM (AKA TPM) technology, and to what extent its use is compatible with Open Source and Open Content. It's been a real shame -- several pages-long posts that really try to hammer a point into the head of someone who's just not listening since they're busy writing their own 10-page-long email. It's become impossible to read and some wiser heads have asked for a cooling-off period. Thankfully so. There is very little time left to continue this discussion. I really sincerely hope that people who are interested in seeing Commons licenses that are compatible with Debian and other Free Software pop in and say something to that effect. Cool heads who can state things in simple English are particularly welcome. The list allows posting to subscribers only -- kind of a damper on one-time posts -- but subscription only takes a second, and you can disable your subscription immediately after you're done. tags: cc debian cc-licenses public review cc3.0

Busy Wednesday Ahead 2007 is going to be the year of wiki in Montreal. We're having two of the main wiki conferences -- RecentChangesCamp and Wikisym -- here in Montreal next year. And I guess it's time for the local wiki, open source, open content and "open other" community to start getting ready. At least in the wiki world we're taking the first steps. Wednesday 4 October (uhh... I mean, Duodi 12 Vend miaire) we're having Montreal Wiki Wednesday at 8655 rue St-Denis (metro Cremazie). Alain Desilets and Sunir Shah, who are both working on Wikisym, will be coming, as well as Anne Goldberg (principal organizer of RCC) and the inimitable Seb Paquet, who runs everything in this town. 15h-18h, fun times ahead. tags: wiki wiki wednesday wikisym montreal rococo

CC Salon Montreal But wait there's more! On top of WW, we're going to have a big Creative Commons Salon Montreal on Wednesday night, too. This will be the second time we've had a get-together in Montreal for CC so far, and I think it's going to be a good one. Maj and I are going to give an informal talk about Wikitravel and its CC license which has worked so well for us. I'm really gung-ho on the CC Salon idea. It's a great way to engage the interesting, fun part of CC -- and it's all about the fun, right? CC Salon Montreal is happening 4 Oct at 18:30h at L'am re boire, 2049 rue St. Denis (a mere 66-block walk from Wiki Wednesday!). Should be a good time. (On top of all this, I'll probably stop at YULblog on the way home, just to make the Web maven's trifecta for the night. tags: cc cc salon montreal salon

I was thinking late last night and it became clear to me that over the past 9 or 10 years, I had fallen into a nomadic outlook, even when I wasn't being particularly nomadic in my way of life all the time. Between moving around the Bay Area 1.5 times a year, shipping everything cross-country by UPS, hauling all my worldly goods back in a pickup, and then falling into a longterm already-established-but-clearly-not-permanent place at the farm, dashing off to places like Honduras and Brazil for months at a time, and going around with a camper, I experienced the kind of pressure that selects for keeping posessions limited, appreciating things that pack a lot of different uses into a small space (like a laptop with gigs and gigs of carefully organised information). The things I aquired, valued, and kept were either very portable and useful -- tools, laptop, tents, vehicles, cookware -- or portable and luxurious -- comforters, good sheets, a rug. (I had my pick of nearly anything in my Grandmother's house, and I chose a rug.) The real luxury items were put up with only grudgingly and spent a lot of time in storage. Mostly books, and this is why unlike most people, I prefer my books on the computer. For lots of other categories of stuff, I tended to assume that I wasn't going to keep it long, and bought/borrowed accordingly -- and ended up giving away couches on Craigslist. Recently I saw some stuff about Mongolian nomads in the Gobi packing their yurts onto their camels, and I can relate to that, there's a real beauty to it. So it's been weird over the past week to put together all the large furniture that I need in my house, like a fridge, etc. A bit hard to accept it. Only with time will I find out how long this stop along the way will last..

Slashdot had a post this evening about the update to the O'Reilly IPv6 book.

I took a scan of the comments, and got the usual bits - why would someone bother? What's the killer app? We're not running out of oil^Waddresses! While I don't claim to be an expert on the topic, where I have used IPv6 succesfully is on my home network. Where NAT is really annoying for geeks is that our ISPs give us one IP address, make it move around occasionally, and tell us we can't run servers on it. Add an IPv6 tunnel to this, and it doesn't really matter what my ISP thinks. My machines remain trivially addressable. Scanning the address space to try and hammer on the boxes is a non-trivial task and by-and-large, Windows zombies aren't usually talking on IPv6.

This isn't a permanent nirvana, but if general attitudes about v6 are the same as the drones on /., then my little workaround hack will persist for a while.

Whee, that was fun. I orphaned three packages (liwc, piuparts, and publib), and asked for the removal of two more (python-licosmamo and lodju). The removed ones have no users (mostly not even myself), and the orphaned ones don't either, except piuparts. I'm hoping someone will adopt piuparts. See #390754 before you do, though. The reason for this evening's activities: I have more responsibilities than I have time for, so I'm trying to fix that by shedding everything I can. I'm not leaving Debian (I will even maintain a package), but I'm not expecting to put in a lot of effort into Debian development in the near future. Next year we'll see if I can't arrange for more time for this again.

Tag clouds are usually done by scaling font sizes according to some weight. Actually this is not very precise. For a representative representation (lol, I should get this domain name. representative-representation.com), the tag size - that is the surface area! - should be a representation of the tags weight. The suface however doesn't directly depend on the font size, but is more like font size * length of word (length being appropriate for the font used). So when displaying tags with very different font sizes, "egg" and "Technorati" shouldn't just be scaled by their weight, but also by their word length. OTOH, few users will actually be able to "grasp" the actual difference in size. IMHO it's just about "popular" vs. "obscure" and about making the tool more intersting to use.