Version 2.6.18 of the kernel contained a small(ish) change to <linux/nbd.h>:

--- nbd.h	2006-10-17 19:53:55.000000000 +0200
+++ /usr/include/linux/nbd.h	2006-09-20 05:42:06.000000000 +0200
@@ -37,19 +37,28 @@
 /* userspace doesn't need the nbd_device structure */
 #ifdef __KERNEL__
 
+#include wait.h>
+#include mutex.h>
+
 /* values for flags field */
 #define NBD_READ_ONLY 0x0001
 #define NBD_WRITE_NOCHK 0x0002
 
+struct request;
+
 struct nbd_device  
 	int flags;
 	int harderror;		/* Code of hard error			*/
 	struct socket * sock;
 	struct file * file; 	/* If == NULL, device is not ready, yet	*/
 	int magic;
+
 	spinlock_t queue_lock;
 	struct list_head queue_head;/* Requests are added here...	*/
-	struct semaphore tx_lock;
+	struct request *active_req;
+	wait_queue_head_t active_wq;
+
+	struct mutex tx_lock;
 	struct gendisk *disk;
 	int blksize;
 	u64 bytesize;
@@ -68,11 +77,11 @@
  * server. All data are in network byte order.
  */
 struct nbd_request  
-	u32 magic;
-	u32 type;	/* == READ   == WRITE 	*/
+	__be32 magic;
+	__be32 type;	/* == READ   == WRITE 	*/
 	char handle[8];
-	u64 from;
-	u32 len;
+	__be64 from;
+	__be32 len;
  
 #ifdef __GNUC__
 	__attribute__ ((packed))
@@ -84,8 +93,8 @@
  * it has completed an I/O request (or an error occurs).
  */
 struct nbd_reply  
-	u32 magic;
-	u32 error;		/* 0 = ok, else error	*/
+	__be32 magic;
+	__be32 error;		/* 0 = ok, else error	*/
 	char handle[8];		/* handle you got from request	*/
  ;
 #endif

Which meant that the userland NBD utilities would not build against that anymore. The Debian packages are unaffected (they ship their own nbd.h since they need to build on non-Linux ports, too), but that doesn't mean we can leave it like that. The first hunk is unimportant, as it's enclosed within an #ifdef __KERNEL__. The others represent an interface change: rather than having u32 and u64, they come with __be32 and __be64. Nothing that can't be fixed with a few #define lines, but still something that had to happen. So today I released nbd versions 2.7.8 (from the outdated 2.7-branch), 2.8.7 (from the current stable and supported 2.8-branch), and 2.9.0-test3 (from the current development branch) to sourceforge, and released version 1:2.8.7-1 to Debian unstable. I'll probably also release 1:2.9.0-test3-1 to Debian experimental "some time soon", but not just yet. Apart from the obvious #define lines, the 2.9.0-test3 release also fixes some issues (in contrast to -test2 which was a bit of a crashing horror, -test3 actually works) and has revamped multi-file support. Most of the changes in -test3 (in fact, most likely all of them apart from the #define lines) were done by Phillip Hellewell, whom I owe a beer if I ever see him. Occasionally, the 2.9 line has some extra code and features that aren't available in 2.8, such as configuration file support and the ability to serve multiple block devices from one nbd-server parent process. Check it out if you have a chance and/or are interested. On top of that, the 1:2.8.7-1 release also contains some fixes in the debconf stuff, that close 3 bugs. Am I cool or what? Nah.

Simon, you have a good point, but while I am not ashamed to admit that I fall on your "rating by others" end of the scale -- happy Debian users make me happy -- much of your analysis seems a bit simplistic and not mindful of the fact that scales include points in between. If Ubuntu only enticed all of our desktop users away, I wouldn't feel very threatened by it. I'd feel disappointed that we lost those users, but I'd see all the other users we have in other areas, and I could be satisfied with that. After all, Windows still has the lion's share of the desktop users, and I don't feel threatened by it. Or by OS X. However, when significant development momentum shifts to Ubuntu, when there are lots of things happening there, I do begin to feel very threatened by it. I begin looking to see if development that's happening on Ubuntu is being contributed back to Debian. I conclude that it's largely a one-way street; any improvement I work on in Debian will get into Ubuntu with nearly 100% probability, but any improvement Ubuntu makes will only get into Debian if someone goes out, reads through a patch, and finds it. See, I'm also motivated by Debian being suitable for many different purposes -- I fall on the other end of your scale too. And I know that I don't want to be today using the software and hardware I was using 5 years ago. And 5 years from now, I won't want to be using the software and hardware I'm using today. My needs will change, things will evolve, and lots of development will be needed for Debian to still be relevant, to still be suitable for all its many purposes. And if much of the development momentum shifts to Ubuntu, and if there is not even a culture of pushing improvements back into Debian, there's a very real possibility that that won't happen. And then those of us all along this interesting Scale of Superiority you describe will have to decide between giving up and going to Ubuntu, or taking up ballroom dancing. I've personally decided that if this happens, I won't be taking the former option; Debian is the last linux distribution I intend to work on.

The weekend of the 14th-15th October saw my third BSP in as many weekends, this time in Munich. Andreas Barth was in charge of the organisation, and the LiMux development team were kind enough to host us for the weekend at their offices in the centre of the city. Andi, Zobel and I headed into the office early on Saturday morning, ready to start hitting RC bugs. Others joined us during the morning, and we got to a total of 10 people working on fixing bugs. Personally I looked through many of the bugs listed on Andreas' page. It was heartening to see that a very large number of the RC bugs were already well in hand, with patches available and in lots of cases uploads already made. I spent some time looking into #389287, #392398, #389375 and #262440. I also helped out several other developers with their own bug fixes, giving out accounts on my wide range of machines at home so that they could debug on different architectures.

We worked late into the evening, ordering in pizza and then later cooking in the offices. I moved onto some more debian-cd hacking later on, making real progress and getting almost to the point of having my multi-arch CDs working. As always, there was a lot of discussion about the general issues in Debian, especially the 4 GRs that were due to finish that evening. On Sunday morning, things started slightly later as we took breakfast at the office. There was more discussion of the GRs, and the results were generally well received by the group. We continued looking into the RC list; I investigated #389434, but struggled to make much progress. At lunchtime, we quickly(!) headed into the city to see the famous Glockenspiel at the city hall, and went for a quick tour of the historic city centre so that us non-locals could see something of the city outside of the office. We returned and picked up on the bug-killing for a couple of hours. Then the LiMux guys showed us some of their work, and gave us a demo of the project. More on that later... Unfortunately, I had to head back for my flight comparatively early this weekend so I couldn't stay around for very long after the demo. Despite the last-minute attempt by an S-Bahn ticket machine to delay my trip to the airport, I got back without incident and even landed early at Stansted. The Germans I met this weekend were very serious about getting work done, and their efforts are much appreciated. With more people helping to reduce the RC bug counts, we should have no problem releasing Etch in December. Let's keep up the good work...! As always, my meagre attempts at photography are online now.

Thjis: This is the right time to automatically search for RC bugs. So was a year ago. Although we want the RC bug count to drop, an RC bug is still an RC bug regardless of whether we know about it or not. And many RC bugs didn’t exist a year ago. Take for example #392121. A package name change in a build-dependency caused my package to FTBFS. This bug would not have existed a year ago, but needed to get fixed for etch. Incidentally, when you go through a package rename for a development package, it would be nice to check what packages build-depend on the old package. A september changelog entry for cli-common says:

- Removed transition dependency for cli-common on cli-common-dev. (7 month for a package rename transition should be more than enough)

However, at no point in that seven months did anyone email me or file a bug report to tell me that the name changed. This bug wasn’t caught until someone rebuilding the archive noticed.
Actually, this might be a good idea for an infrastructural change. Would it be possible to set up a script that notices when packages are removed and sends a notice to the maintainers of any packages build depending on them?

In a comment on a previous blog entry I was described as an active Fedora advocate, I don't think that is an accurate description. I advocate it to appropriate people, which is mostly non-programmers - but as I mentioned that means a larger proportion of the population than to whom I can advocate Debian. It's not that I'm trying to advocate Fedora, just that it fills a need for many people. I believe that the term Fedora advocate means someone has an objective of increasing the use and to use Fedora, I don't have such an objective. I am a Linux advocate, a Free Software advocate, and sometimes a Unix advocate (Unix meaning the entire family of Unix-like operating systems). Merely promoting something does not make you an advocate for it. I don't think of myself as a Debian advocate at this time, but as I am a Debian developer this may change.

It seems that the people who run the Fedora Planet think that my blog has suitable Fedora content, it's been added to that planet. Also the Fedora Planet appears to be running an older version of the Planet software as it has the same problem with my blog that Debian Planet had before the upgrade.

Now on the issue of gratis vs libre: As I am not a Red Hat employee I can't maintain a kernel-xen-nopae package and give it the same status as the kernel-xen package. Even when I was a Red Hat employee I couldn't have done that - it would require some amount of management approval. I believe that this fundamentally makes Fedora less of a libre distribution. There is no room in Fedora for someone who is an upstream developer and who just wants to maintain their own package. There is Fedora-Extras, but that has a second-class status. Only Red Hat employees can maintain packages in Fedora Core. This makes Fedora fundamentally less libre than Debian. I am not trying to suggest that Red Hat change things in this regard, I believe that Fedora is meeting all it's goals and that making Fedora as libre as Debian is not possible given the goals of making a profit on selling support of RHEL.

Chris made a good point. I also believe that MP3 codecs should not be in Debian/main. But I believe that people making mistakes about some issues is not a factor in judging the entire project. I believe that Debian is more libre although some bad decisions were made - largely due to lack of overall management. Fedora has hierarchical management, so when the legal team declares that some software can not be distributed then it gets removed without debate. I guess I could propose a GR to exclude MP3 codecs from main.

Also it should be noted that RHEL Extras has some of this software that is not in Fedora (RealPlayer for example). The Red Hat legal advice was that MP3 codecs need a license, so they ship a licensed version in their commercial distribution. This is the right thing to do for their customers (it's handy to have and I'm sure that they get a good deal by paying license fees for all their customers) and removing such things from Fedora is the right way to offer a gratis product without unreasonable legal liability.

Naturally Fedora is much more libre than any secret-source OS. Every user has the option of downloading the Fedora source and recompiling it as they wish. I could compile Fedora with a Xen kernel that runs on my hardware and with SE Linux policy that is more restrictive than that which Fedora currently has. I could build custom Fedora install CDs to install things the way I want (which I considered doing when I worked for Red Hat). But the liberty to fork a project does not compare to the liberty to join it, and the liberty to create your own packages in extras does not compare to the liberty to add your own packages that do things differently to the default package.

There are of course positive and negative aspects to this. I started work on SE Linux in Debian in 2001. In 2003 I joined Red Hat to work on SE Linux, in Red Hat I was not the only person dedicated to SE Linux work and other people spent part of their time working on it. The SE Linux work in Red Hat soon eclipsed that of Debian because there was management support. There was no possibility for a package maintainer to refuse to fix a bug that affected SE Linux simply because they didn't care for it. The positive side of this is that the SE Linux work proceeded quickly and efficiently. The negative side of this is that things which don't have management support don't appear in Fedora Core. Exim is a fine MTA but is not in Fedora Core. Some people think that AppArmor is a better option than SE Linux, they are wrong - but in Debian any developer has the option to add AppArmor support and neither I nor any other DD can prevent them. The libre nature of Debian means that as long as basic technical criteria are met DDs can add any package that they wish to the distribution.

These issues however are all related to people who are actively involved in Free Software development. For a typical Free Software user it often doesn't make much difference, until of course your favourite program doesn't get management approval to appear in Fedora Core. But the counter argument is that the quality of some of the >10,000 packages in Debian is not so high. You can install a Fedora Core package and have a reasonable expectation about how well it works, but Debian packages are sometimes rather experimental.

I also don't believe that Debian is a very functional Democracy. Some of the problems of Direct Democracy are demonstrated in Debian. In many ways it is more anarchistic, anarchy gives you liberty for good and bad. Maybe we should consider a Representative Democracy model for Debian.

I really love the idea behind that project and after some Perl people complained they now also accept submissions from Perl developers. So if you live in or around Germany and would like to do some propaganda for your favorite web framework, apply right now, as long as your favorite web framework is based on Perl. :-)

In four hours I'll be on the airplane to San Francisco via Paris. * erich puts a flower into his hair and starts singing Saturday there is the "Google Summer of Code mentor summit", where Google invited mentors from the participating organizations to Mountain View to discuss about the Summer of Code program, how it can be improved and what else Google can do for opensource. We're all very thankful to Google for offering this great program. It's meant as an opportunity to get more students interested into opensource development, and there are many success stories. Of course the program isn't perfect, and thats what the summit is for, improving it. And I'd really appreciate your feedback, your perception of the GSoC, of the students and the mentors. I've asked for feedback before, but I've received next to nothing so far. But there is quite a lot to discuss tomorrow. For example, many projects would fit to multiple organizations. I had proposed a SELinux integration project, but most of it would be reuseable by other distributions as well. There was a project which actually meant to integrate one mentoring organizations' project with an other mentoring organization. These could benefit from some "shared mentoring"; at the same time these project could server the prupose of increasing cooperation between organizations. I myself, for example, know rather little about Fedora, or the state of SELinux in Fedora. Still this is a point (well, if I still had the time to work much on SELinux that is) where I should definitely try to cooperate more with Fedora. Another proposal that came up and will be discussed is the "Summer of Content". It's not all about code. There is also documentation, graphics, sound, ... Why shouldn't a GSoC student be working on artwork or sound for a summer? The opensource/copyleft community definitely could use some support here, and we have rather few links to artists so far. So please send me your feedback. I won't be responding to mails for the next like 15+ hours since I'm travelling (maybe even 24h, if I'm busy with real life meetings), but I'm really interested in your ideas!

I've read quite a few blog posts about someone leaving Debian and whether they should remain on Debian planet. An official policy on these matters has now been posted which stated what I expected, if you feel that you belong and meet technical criteria then you are welcome.

Not that this solves much, the next debate will be about what content is suitable for Debian-planet with the expected answer being "anything which meets technical criteria and doesn't offend many people or break any laws". I've already had some comments on my blog from people who want me to change topics. I don't know if other people get this or whether doing an average of one post per day gets me more attention from the loons.

I started blogging after leaving Red Hat. I considered asking for my blog to be added to the Fedora Planet, but wasn't sure whether I would be posting much about it. I just checked and it seems that my old Advogato blog is aggregared on the Fedora Planet and there is no mailto URL on that site to allow me to get it changed. I've just put a final blog entry on Advogato to inform everyone of the change.

I'm not sure if it's worth adding my blog to the Fedora syndication. I have just decided to change my main desktop machine from Rawhide to Debian/unstable. The reason is that Fedora is mostly a Gratis distribution and Debian is more Libre. For most computer users there is no real difference as they don't have the skills to use the liberty that Debian offers. But for people who can code (note that we are in a small minority of computer users) the difference is significant.

The final issue that forced me to this decision is this bugzilla entry about Xen. In Debian there are kernels for Xen on i686, Xen on AMD K7, and Xen on i686 with vserver (doesn't Xen make vserver redundant?). In Fedora there will be one Xen kernel which won't boot on the machine that is most important to me and which ironically is the machine that was issued to me by Red Hat (and sold to me when I left).

This issue of a lack of choice is quite understandable from the Red Hat Enterprise Linux side of things. It's OK to say to a customer who wants to pay for a RHEL-AS license that they need a machine less than 3 years old if they want to use all the features. Adding new kernels adds support costs and I think that most RHEL customers want to have a smaller set of supported options with a higher level of support. I often recommend RHEL to clients and I will recommend that clients use Xen on RHEL-5 - and that they purchase recent hardware to do so.

But for home and hobby use it's a different matter. I provide all the support I need, I can compile my own kernels without much effort - but it saves time to have someone else do it. Fedora simply lacks choice here by design. I still support a bunch of Fedora and RHEL machines and will still develop RPMs for them. I will put everything I develop under http://www.coker.com.au/rpms/ for anyone who wants it.

Given that if the Fedora Planet people want to syndicate my blog I am more than happy to have them do so. I don't dislike Fedora, in fact I still recommend that people use it. It's just that Debian suits my personal needs better than Fedora does. I expect that I'll have more Debian content than Fedora content on my blog, but there will also be a lot of Linux content that's not distribution specific.

It will be interesting to see what the Fedora Planet people do.

If you search on Google for 'youtube sex', my blog comes out as #3+#4, just behind youtube itself. Sooo funny, because I never actually wrote about Sex on YouTube. Actually I don't like YouTube (which to me still sounds like a bad translation of a german insult). But there is this blog posting of mine, which lists the top tags according to technorati, when war tags had actually surpassed youtube and sex as tags. Yes, it mentions "youtube, sex". Once. But no, these are not essential, no referrer uses them, no other blog posting. Why does it show up as second site after YouTube.com itself? Oh, I'm also #3 for "youtube bush" right now, with the raw RSS feed of my blog. What is it with Google and my blog? There must be some odd effect with Googles ranking that makes my site shoot up like crazy. And it has been like that for at least one and a half year now. Back then I blogged about IBM failing to repair my laptop. This was the first time I noticed a really absurd Google ranking of my blog, when this became a top #10 result for "IBM repair". Guess I really should go into the SEO or webdesign business. If I weren't just more interested in research and software development... [Update: dropped to #14 for 'youtube sex']

I went back out to the site of Ignition 2006 today. We left the event early due to pouring rain and general bad unhappiness, with a strategic retreat to a loft in Old Town Montreal to have fun, hang out, and wear costumes that weren't covered with mud. But we left some equipment on site, and I went out to get it today, and whoooooo boy was it a mess. We tarped everything up and left up protective canopies when we left, but I guess the wind really got into this cache of stuff in the last couple of weeks, because the canopies were blown all over the place, bent, bruised, and generally indignant. Most of the tarped equipment was still tarped and dry, but there was one corner of one tarp that had come up, and everything under it was wet. Fortunately it wasn't anything important -- empty bottles, a barbecue, and some folding tables. The drive out to the site was great. It's a piece of land owned by my friend Sherman Samuel, just north of wt:Mansonville in the wt:Eastern Townships. The leaves on the trees have just about turned, so there's starting to be some bare trees and the last sharp colors of the trees. It's melancholy and beautiful -- great October weather. I was able to cram everything into the Sleek Black Tux (my just-made-up name for the Hyundai Tuscon we drive), but the drive back was pretty rough. The smell of all that camping equipment put up wet and left in the forest for a couple of weeks was... well... pretty gamy. Like really, really old towels. We call that smell "meefy", and that's pretty much what the car smells like now. Meefy. When I got home, Maj and Amita convinced me not to unload the car, but to come inside and watch the Battlestar Galactica season premiere on tape, and drink red wine and have warm split-pea soup. Allllll right. tags: meef burning man ignition eastern townships snazzy tux

Lars, you well-informed and chaste commentator I agree with Lars: Eric is doing the right thing. I understand what the Mozilla Foundation is doing, and it's more than likely the right thing for them to do. I understand what Eric is doing with Gnuzilla, and it also seems like the right thing to do. Debian and Mozilla can be friends and yet not use the same name for the software. That's OKAY. tags: lars eric dorland iceweasel firefox well-informed chaste

Freedom It sounds like, at least briefly, China has unblocked Wikipedia. It's interesting to see if this will continue, and what it will mean for future policies towards China by other Web sites. Unlike Google, Yahoo, and MSN, the Wikimedia Foundation has steadfastly refused to censor its content to meet Chinese government standards. If the WMF can stand up to China and win, what does that mean for other Web sites in the future? tags: china wikipedia unblock

Ingo J rgensmann wonders - quite rightly - when SquirrelMail 1.5 (our development branch) will become stable. Our current big project is making the entire interface templatable; that is, to separate code and layout, so it gets easy to modify the appearance. As with many open source projects, SquirrelMail started out as a small hobby project in the previous millennium, and grew and grew until it is where it's now: a giant hunk of code with stuff bolted on top, on the side and in between, and where HTML output is integrated in about every function. Work on templating had a slow start but is progressing well now; when it works acceptably we'll release 1.5.2-DEVEL, followed by perhaps a version or two more and then 2.0 Release Candidate 1 planned for the first quarter of 2007. As always, any help will make it go faster... :)

Many moons ago I thought it might be nifty for my work on Debian QA to have an easy way to see what has changes in each version of a Debian package. I wrote a little script that built a bzr branch for each package, and imported each new version in my mirror. Unfortunately, there were some problems, and I didn't have the patience then to fix them. Last weekend I finished the script (despite not doing any Debian QA work anymore), and set it running. Today it finished. There were still some problems: 88 packages failed, due to problems in bzr. I've reported them to the bzr mailing list. The run took about three full days, on an machine with a 2 GHz AMD64 cpu (in 64-bit mode), 1 GB of RAM, and two 80 gigabyte hard disks in striping mode. It would've gone faster, but I ran out of disk space a couple of times, and it took me hours to wake up and notice. Disk space usage is now about 90 gigabytes, but that's with most branches' working files removed, to save disk space (i.e., only the .bzr directory and contents in most branches). Note that the size shouldn't grow very quickly. Most new versions only change some files, and only parts of each file. Version control systems are good at keeping only the changes. I'm pretty sure 200 gigabytes would last for a long time. Bandwidth and disk I/O might be more limiting, if we wanted to have this as a service open to everyone. I don't know if bzr is the best vehicle for this; perhaps a huge Subversion repository would work better. My instinct says that a distributed version control system would work better, but I'm sure a centralized one would work, too. Whatever the system, it might be helpful for QA work, and for making changes in many packages at once, to have something like this. For QA work, it would make it easy to see what has changed in each version, or to find the version in which a certain change in a package was made. For sweeping changes, this kind of a system should, I think, make it easier to automate the build and upload of packages that are changed. I'm not, by the way, suggesting that this kind of a system would be used to do normal maintainer development. It would work by importing new uploads, not by having people commit to it directly. Or perhaps such a system wouldn't have any use for Debian, I don't know. But at least the script was useful for stress testing bzr a bit, and finding a couple of bugs in it. So it wasn't a waste of time to finish it.

Dear Lazyweb, I’m looking for a small, (easily fits on my lap on the cramped seat of a bus,) inexpensive, (around $100 CAD,) mobile text-editing device with a 90%-sized keyboard and decent battery life that runs an open source OS and Vim, and that I can sync to my desktop system. My first mobile device was a NEC PC-8201A, circa 1984. It ran on 4 AA NiCad batteries which I hardly needed to change more than once a week. At the time, it was my ideal mobile notetaking device. Its near-full-sized keyboard, Wordstar-compatible text editor, terminal program and serial interface allowed me to take notes which I would sync to my father’s Mac at home or to the VAX at the university. Today, my mobile computing needs have hardly changed: text editing is almost all I do. I don’t ask for much of a display, but as an 80 to 90 wpm touch-typist, I won’t settle for anything less than a near-full-sized keyboard. I’d prefer a system that runs Debian, and Vim is a must. Some means of easily synchronizing the device with my home system is necessary: PCMCIA wireless-B would be ideal, but is not a must-have. At the moment, I’m using an old Zaurus (not Linux-compatible) ZR-5000 which has good battery life but a very cramped keyboard, poor software, and no functional means of synchronizing the device to my PC. OK for jotting down quick notes, but frankly, I’d rather have my PC-8201A back again. I could at least type on it and sync it across the serial cable. I took a brief look at various Psion models, but they appear to be near-impossible to find. The HP Jornada 720 looks intriguing. And the NEC Mobilepro 780 appears to be another possibility. Have I overlooked anything? So, suggestions please.

Last weekend, I went to Zurich for the second leg of my own personal BSP marathon. Martin Krafft organised the BSP at the AI Lab in Zurich, arranging sponsorship and encouraging local DDs and users to turn up. Martin and I started early on Saturday morning, opening up the lab shortly before 9am and making a start on the RC bug list. Over the course of the next few hours, more people turned up and started work too - local DDs and a couple of Debian users from ETH. We worked our way through a fair number of bugs that day; personally I closed #389318 (a grotty FTBFS bug caused by IMHO a design mistake upstream - parsing header files using a simple awk script to create an m4 script to then generate C source) and spent quite some time digging into some other bugs. For our late dinner on Saturday, we headed to a local American-style bar/restaurant in Oerlikon called Cheyenne. Their speciality, it seems, is the "Big Mama", the largest burger I've ever seen! It comes on a huge serving plate, and is enough to feed up to 4 people...

I took the chance over dinner to chat with the small group of locals, especially Axel Beckert who had some interesting stories about Fedora, Opera and other groups. On Sunday, we started slightly later but probably had a more productive day in terms of the number of bugs closed. I fixed some silly FTBFS issues in ser: #384772 and #390008 were both caused by the build system assuming i386/amd64 compiler options. I adapted patches suggested by Julien Blache from his own work on openser (thanks!) and tested on my sparc and hppa systems at home. Job done... For the rest of the day, I used the time to work on remaining bugs in my own packages. Both CVS and debian-cd needed new uploads to be ready for the Etch freeze. CVS had a bucket-load of new translations following Christian Perrier's call, and debian-cd had a large number of bugs that had already been fixed in svn for a long time. Between those 2 uploads (and some other old bugs in debian-cd that needed reviewing) that made another 17 bugs fixed, although none of them were RC. Once those uploads were done, I continued on with my debian-cd multi-arch development work. On Sunday evening, we went into the middle of the old city centre in Zurich to a more traditional Swiss restaurant. Several of Martin's colleagues from the lab joined us, and we had some widely varying conversation, ranging from Debian (of course! *grin*) to gossip in the lab via lots of other topics. Due to my ridiculously early flight home on Monday morning we couldn't stay out too late nattering, but nonetheless all the people seemed to enjoy themselves. The Swiss group were a fair bit quieter then the Dutch the previous weekend, but seemed just as committed to getting work done and getting Etch out on time. It was lovely to meet and spend time with them, and I've promised to go back and visit again soon. Until then, I've put my small selection of photos online.

So it's been pointed out that since I'm no longer terribly involved in Debian, I possibly shouldn't be on Planet Debian nowadays. So unless there's any violent objections I'll ask to be removed at the end of the week - my RSS gunk is at http://mjg59.livejournal.com/data/rss for those who want to read my delightful prose in any case.

Anyway. Some token Debian-related content. Mozilla corp are unhappy with Debian providing a package called "firefox" unless every patch provided has been approved by Mozilla in advance (there's also some stuff about the logo, but that's basically a bizarre corner aspect of the same problem). I'm not going to argue against this on philosophical grounds - it's clear that that isn't going to change anybody's mind. Instead, let's compare this to some other major applications:

• Linux. Pretty much every vendor patches Linux. Part of this is for hardware support (adding out of tree drivers, and so on), but a great deal of it is feature development. A lot of patches that appear on LKML have already shipped in vendor kernels.
  
• X. Arguably one of the most forked applications shipped by any distribution - almost every X server shipped by any vendor ever is based on the reference X11 code. Without the right to fork X and maintain its name, we wouldn't have the X.org implementation[1]. No composite, no accelerated indirect 3D rendering, no input or monitor hotplugging.
  
• Gnome. Vendor patches to Gnome have largely been concentrated on branding and defaults, but in some cases we've seen major functionality changes. The new menu applet in SLED 10 is an example of this, and depending on how it's received it's likely to influence upstream development.
  

On the Mozilla side of things, the closest I can really come up with is cdrecord. There's some pretty strong parallels (upstream being unhappy about various patches, requiring a sufficiently different work to have a different name), but the end result in the cdrecord case was that we ended up with an application that was poorly integrated with the rest of the Linux environment for the sake of remaining consistent across different operating systems.

I'm not saying that that's going to happen to Mozilla. But we've seen numerous cases where allowing vendors to distribute derived versions has encouraged development and testing of new ideas, and I think in most cases that's resulted in benefits to the upstream project. The fundamental problem with refusing to allow patches that cause significant deviations from upstream behaviour is that it makes it impossible for anyone to actually get things like UI experiments into the hands of users. With Gnome, if upstream don't like your idea you have the opportunity to prove them wrong and possibly change their mind. With Mozilla, if upstream don't like your idea you're pretty much screwed. Most distributions are going to be unhappy about losing the magic Firefox branding, so you're unlikely to sell them on it. And you're not even allowed to provide binaries or source on your website unless you've renamed it away from Firefox.

I think the Mozilla corporation are missing something here. We shouldn't be prizing cross-platform consistency over integration and innovation, and we certainly shouldn't be doing our utmost to make it difficult for people to experiment with code. There's a reason that cd writing under Linux has been sucky for years, and it's not because people lacked the technical ability to make it better.

[1] Ok, the X.org case is slightly confused by the fact that they are upstream now. But without the ability to fork under the same name, they wouldn't have been.

I've been a fan of the Open Directory Project for a long time. I finally volunteered to become an editor about a month ago, and I just started editing my first category, wiki farms , today. I hope to get the category up to good shape in the next few days. I've now got an ODP profile, too. tags: odp dmoz directory editor wikifarms

Hudson Maj, Amita June and I went down to wt:Hudson (New York) over the weekend for the wedding reception of our friends Morgan and Kate. The trip down was fantastic -- the colors in the wt:Adirondacks were really amazing, just hitting their peak. Amita June had a good drive, too: she got to look around a lot, listened to some music, and had a nap of about an hour and a half. Hudson was a cute town, but not cutesy like other parts of the wt:Hudson Valley can be. The town is small -- 4-5 streets wide -- with big brick buildings lining the main street down to a promenade overlooking the Hudson River. There are a few gourmet restaurants and a disproportionate number of art galleries and antique stores, but it doesn't feel like the locals have been pushed out of their town... yet. We stayed at the St. Charles Hotel, as arranged by Kate's stepmom for most of the guests. It was functional and clean but otherwise unexceptional. There was a bar and a restaurant downstairs, and the hotel itself is just opposite a nice little park. Sunday morning we had breakfast at the Earth Kitchen organic market; I had a bowl of granola and fruit, Maj had a huge plate of huevos rancheros, and AJ ate whatever she could get off our plates. We walked around town and down to the waterfront, where we got a panoramic view for miles up and down the Hudson Valley. With the leaves nearing their height of color, it was an awe-inspiring view. We took a late lunch at Mexican Radio, a branch of a restaurant by the same name in Manhattan. It had good quality California-style Mexican food, with a few fusion dishes (like "Mexican spring rolls") that were probably overdoing it a bit. The margaritas were top-notch, and they have a tequila sampler option with three excellent tequilas for... $125! You won't normally lose that much money on three shots of tequila unless you pass out in the gutter in wt:Nuevo Laredo. The reception itself was at the Ca' Mea restaurant, right next to the historic Hudson Opera House. Kate and Morgan were in good form, playing goth-y music from their early days, and family and friends had a good time too. We all probably ate too much, and Maj and I both had hangovers the next morning. Amita June, however, had an excellent time running around the party and dancing with the bride. She was made for weddings. The drive home the next day was less than optimal. We did brunch in the St. Charles's restaurant, Bridges, and then stopped by the house of Kate's dad and stepmom for an afternoon get-together. They have a really nice Victorian house on a hill above town that overlooks the valley. We had to leave after only a few minutes, though, since we'd been lucky enough to get guest-listed for the Massive Attack show in Montreal that night. Trouble hit us as we were coming up the 87, though. First, the baby refused to sleep, getting more and more hysterical the longer she went awake. By 4:30PM, we'd had to stop so many times to soothe her that we were starting to get worried about the time. Then, we hit a detour on the interstate -- a huge accident had happened going through the mountains. We got into a sluggish line of cars wending its way along highway 9, and by the time we were back on the interstate we knew we were going to be late. We decided that luck was against our going to see MA, so we called and canceled our baby-sitter and sent email to our friend DJ Ghostbeard who'd asked us to come to the show (although we didn't get a call through... his voicemail box was full). We stopped at Geoffrey's Pub in wt:Plattsburgh for a late dinner of blackened salmon, broiled seafood and mashed potatoes, and then got back on the road. ...and straight into a 2-1/2-hour line at the Canadian border. This weekend was Canadian Thanksgiving, and apparently a lot of people took the opportunity to dip down into the states for a last bit of outdoorsmanship before the winter frosts settled in. Amita June, already a little frantic from not sleeping, went completely ballistic, and although we managed to keep her mellow most of the time, 2 hours in a line of cars with a crying baby is a little bit much for anyone. We didn't get back to Montreal until nearly midnight. It was great to get home, finally, and as usual travel's made me appreciate staying in one place. The Gazette this morning says the Massive Attack show was excellent, but I'm glad we didn't try to make it -- coming in 4 hours late is just too much. We're off to wt:Halifax next weekend for our wedding anniversary, and hopefully we'll be back into travel mode by then. tags: hudson kate morgan amitajune hudson valley adirondacks plattsburgh massive attack

Destinyland Dave Cassel has an excellent list of the 100 Greatest Internet Moments. A great compendium of Stuff What Happened over the last 10 years in cyberland. I think Dave's one of the best Internet culture observers out there. I'm glad to see he's got a new podcast, Destinyland, in which he tears apart the weird media culture we live in. Example: the crazy spiral of Dana Plato. Example: Schoolhouse Rock: Behind the music. Example: Dark side of the Hampster Dance. Good stuff. tags: destiny destinyland podcast dave cassel

Yesterday I was catching up with my magazine reading at Chapters (the Canadian equivalent of Border) when I came across an ad for a drug ad for bipolar disorder that struck me as slightly different less euphoric, more cautious to be exact compared with the ads that have been bandied loosely in all sorts of magazines in the last decade in the US. The ad was for a drug called Abilify which must be some verbal riff on Ability (no?) and there was a very clear pronouncement on that ad that admitted they had no idea how the drug even worked. It went like this: ABILIFY may work by adjusting dopmamine activity instead of completely blocking it and by adjusting serotonin activity. However, the exact way any medicine for bipolar disorder works is unknown. I find this interesting because its tone seems to depart from other ads that seem somewhat more confident (or if they were less so, it was probably kept in the fine print). But when I went to the webpage, this caveat was a little harder to find, as it was a few clicks away within a page entitlted The Brain, Bipolar I Disorder, and ABILIFY . It provides a “handy” pictoral representation of what may be going on with your brain with bipolar disorder/treatment. I found the series somewhat odd and amusing, especially the one that used a magnifying glass to see” all the neurons and nerves or whatever they are in your brain. update: so you know, the US and New Zealand are the only 2 countries that allow drug direct to consumer advertising so I am not sure what the ad was doing in this magazine. It was American magazine but in Canada. I would think they would make them get rid of ads like that. Anyone know why it can slip through the border like that?

I have been using powersave until recently, but I have gone from unhappy to fed up. I also have acpi-support and laptop-mode-tools and hell knows how they all interact. To add insult to the injury, powersave loves to crash or get stuck at times and dbus screws up at times too, which in turn screws powersave. Oh dear. So i have ditched powersave, left laptop-mode-tools and acpi-support around. And i wrote a perl script, i have called it "pm" to handle things i used powersave for. Primarily dpm (device power management) in linux, suspend to ram/disk, battery monitoring and friends. Right now it's ~250 LOC with comments, and more importantly, i know how it works. And it can do things powersave can't. So i am basically happy. It can suspend and resume pci devices (using id<->function mapping) and report their status. It has a very slim suspend wrapper, that just locks screen, syncs drives, remembers power states of pci devices and asks kernel to suspend. After resuming, it restores power states, does chvt voodoo to wake up my intel graphics and sets drive spindown timeout (something, somewhere screws this one up). I also added a "summary" output, that i run using watch on one of terminals in my screen session, that reports cpu frequency and scaling policy, system temperature, battery state (including charge/discharge rate in watts and remaining capacity in mAh), harddrive state (when spinning, also temperature and number of spinups in the drive's lifetime... if you know how to get those two without spinning up the drive, tell me). Then power states of devices (usb, ethernet, wlan, sound, modem, pcmcia, smartcard controller and isa bridge). And as a cherry on top, a list of processes and pids that have recently caused block reads from the drive (needs vm/block_dump enabled in kernel), so you can find out what caused drive spinup. That is about it, now for the catch. It works for me, it probably won't for you, at least not out of the box, unless you have same laptop as me. The pci ids of devices are hardcoded (although not hard to change near the top of the script), so is the screen lock function and probably a bunch of other things. It shouldn't be hard to make a similar script for your system using mine as a starting point though. Another thing that is missing is a nice reporter for KDE to be put on the panel or somesuch. Also, since the script is simplistic in its design, it assumes lots of things about both kernel (tested on 2.6.16 stock debian) and userspace utilities (acpi, hdparm, smartctl) and (oh, coarse-grained evilness), that you have sudo (needed for hdparm at least). Another assumption is that you have single battery and single cpu. But for all the limitations, it goes that if you are going to use a script like that, you probably know enough to extend it to multi-battery and/or multi-core situations. The script definitely needs a hacker-nature :-). So for the brave, the script is to be found on the pm page.