So, let’s join the postings about the currently running Debian maintainers GR. The short text of this post is I am against the proposal as it is right now and think it does more harm than good and so I did vote for Further Discussion. See below for a bit more about my reasoning, or just skip if you are already bored. :) The current proposal does look like a “yay, we have an idea thats not really thought through. And we do not want to get it into the currently existing procedures, that would involve more work and discussions. And anyway, everyone is ranting about the current procedures anyway, so lets take that bad mood against it to get this done”. (And yes, this is a bit exaggerated, so don’t take it personal, please). As you may have noticed I wrote that I am against the current proposal when it first was on vote. I was mostly on vacation back then and didnt want to read the whole thread, so I stayed mostly quiet. I am not against the DM concept itself. I am against it being seperate to the existing NM procedure. For me a proper solution has to be integrated with the existing procedures, not seperated. The main reasons why some support this proposal seem to be

1. Slow NM process.
2. Someone doesn’t want to go through NM
3. Someone doesn’t want to be in the Debian community

---

Slow NM process I am part of this, and not a small one. And yes, I feel (very) bad about it, but already think about ways this can be changed, after I got the current backlog done. Anyway, for this DM thing my backlog isn’t the main reason that people feel NM is slow. It seems to be the general “I have to wait for an application manager and then answer to a lot of questions and between that wait and wait and wait”.

---

True. People have to wait at some points, and those waiting periods can be frustrating. We should do our best to eliminate those waiting places. The other point is that of the lot of questions. Yes, we have a really big set of questions in the templates, that cover a whole lot of the possibly areas a future Developer can work in. And most of those questions got added after a large set of existing Developers showed that they completly do not know something. That way the templates are constantly growing and still intend to give the future Developers the possibility to learn about things in Debian they might never have heard about. And there is the thought that, if you read about a topic and had to answer to it in the past, you will at least remember that there is something if you encounter it in the future. But - there is also the fact that an AM is NOT forced to use the templates for their process. AMs are, and have always been, free to do the process on their own. There are some questions every AM has to ask, but thats a minority. If you look at the templates you will spot the needed ones easily. Other than those every AM can freely do whatever he wants to do with his applicant (as long as the applicant agrees to do that stuff and its legal :) ). The AM only has to keep the following in mind: Both, FrontDesk and DAM, usually do not work together with the applicant. They might have heard the applicants name at some point, in some bugreport or some packages Maintainer: field. But they usually did not interact with them. Which means that the AM has to make sure that FD and DAM are able to build up their opinion of the applicant just by reading the mailbox of the AM->NM communication. Which usually means: read between 20 - 70 mails of a communication someone else had before you decide if someone should or should not enter Debian. (Leaving alone checking packages.qa, lintian, bug lists and a bit of google).

---

Someone doesn’t want to go through NM Erm. Well. Then use sponsors for your packages. Or is it because you think NM is too hard? NM isn’t that hard, everyone that can read and write english texts (even if the english is bad) and use google is able to pass NM. (For the bad english - if you fear joining NM because of that: Well. If I go and reread my own report from back when I joined - ugh. I hate my english. And I know native people still hate my english texts, its named en_GANNEFF for a reason. :) It is not necessary for your English to be perfect; you only have to be able to make yourself understood. If an AM doesn’t understand what you wrote they can simply ask for clarification). DM also doesn’t help for people that don’t want to pass NM. They have to pass the advocate, the ID check and the same minimum set of of questions NMs have (as written a bit above). So you already have a large part of NM for the future DMs.

---

Someone doesn’t want to be in the Debian community Then they shouldn’t be able to upload on their own. They can use sponsors. After all the only thing you must do as a DD is to read debian-devel-announce. And thats something a DM also must do, or you can’t seriously consider to package anything. And then DD only adds rights for you, like taking part in votes and so expressing your opinion and getting things changed in Debian that you may not like.

---

How to integrate a concept of DM then? First - by starting in the right area - getting it into the NM system by talking to all those involved. There is FrontDesk, DAM and also the NM-Committee, the latter should be the right point for a proposal and discussion. What I can imagine that would work and do something good is a system integrated into NM that gives future Developers upload privileges after they passed a few steps with their AM. That way they can upload early in the process, which can then be part of the T&S set, and the following steps in their NM process “just” slowly add more rights to the NM until its the set of rights every DD has. Seen from the current layout of the process it would be somewhere after the ID check and the first set of P&P, ie. at the time the AM sends the second P&P part. After that point the AM could recommend to those maintaining the DM list that the applicant should be added to it, together with a list of packages where the applicant is allowed to upload them. The maintainers of that DM list could be FrontDesk + DAM + maybe someone else, but thats something to discuss. And list of packages - while one could take the current limits the GR wants to set or simply a plain list, that can be amended during the time someone is a DM. Now, one can add a turnoff for people that do not want to pass through the rest of the process at this place. Im not sure its such a good idea, but thats something one can discuss. But if so it should be attached to some rules like - must read our debian-devel-announce list, is included in regular pings of activity similar to the wat ping.

Since about two days I’m proud owner of a Lenovo X61s notebook. It will become my main and new developer box for grml, featuring all that nifty stuff like 64bit support, hardware virtualization and so on… I managed to use all the important features with a very current version of grml. I’m using kernel 2.6.22-grml on a setup with LVM, cryptsetup-luks,… everything works fine so far (including Suspend-To-RAM - even in grml live-mode when booting from USB pen - thanks for the excellent hibernate package, madduck!). As you won’t find useful and approriate information about Linux on the X61s yet (either pretty incomplete or wrong) I decided to put all relevant information on a webpage in the grml-wiki:

• Lenovo Thinkpad X61s @ grml-wiki

Short version: the X61s rocks. I’ll provide information to thinkwiki as soon I checked out all the details…

Matthew Garrett

A lot of background on the state of laptop support in Linux. It worked reasonably well in the 90s, but with the migration to ACPI, has become much more complicated and less reliable in general, especially with suspend/resume and video.

Emporer Linux and System 76 produce Linux supported laptops.

I wanted some more in-depth technical information and found Matthew later on at the Intel booth. Here's what I learned:

s2ram is little more than a wrapper around standard ACPI sleep that has options to do video mode save/restore

I asked him about all the many, many different userland laptop management tools. He recommends simple acpi-utils with the ondemand governor. laptop-mode-tools tries to do way too much, and there is little point to using a userland governor anymore.

I've been having a problem with my MacBook Pro (Core Duo) hanging on suspend about 10% of the time. I explained the symptoms and asked him how to go about debugging it. He suggested disabling console suspend and enabling PM debug in the kernel. I will give that a try and see what I get.

This release of pommed adds a couple of new features:

• Support for the nVidia GeForce 8600M GT LCD backlight, which means the support for the MacBookPro3,1 is now complete
• Automatic backlight dimming when switching from AC to battery power; the backlight level will be restored to the last “on AC” value when switching from battery to AC power again

If you are running Linux 2.6.22 on an Intel machine, you need to upgrade to this release to get the ambient light sensors working again. Jan Larres contributed an icon for gpomme, included in this release. Thanks! I am not really pleased with the code for the nVidia backlight, as it pokes I/O ports directly. It works for now, but I’ll replace that code as soon as I’ll have something better, so if you run into something that could do it before I do, please let me know. Thanks go to Steffen Schulz for pointing me to this code (bl1.c from Nicolas Boichat, modified by Felipe Alfaro Solana). Have fun! Bug reports, ideas and patches at the usual place.

I've voted in favour of the Debian Maintainers GR because, despite flaws like micro-managing the initial situation [Sven Mueller], I believe it is a useful step towards reforming the New Maintainer process. Those of you with long memories may recall that I think NM should be a modern portfolio-based qualification [-project, April 2006, but probably not the first time I explained it] instead of the current, inconsistent AM-dependent one which sees good people applying too early and sometimes being turned away, sometimes being accepted too quickly, but most often sitting in DAMnation. Despite some claims to be interested in fixing NM [Raphael Hertzog], it seems the current NM team requires throwing more people at the buggy system [Raphael Hertzog] before even considering fixing the damn bugs. Of course, I suspect any suggestion would be met with a claim that NM then wasn't performing too badly, now that it had more people. I think that's damage, so I hope the DM GR can be a first stepping stone in a new path to becoming a DD which routes around the damage.

Note: This article is part of my Testing stuff with QEMU series.

From the Debian GNU/kFreeBSD port page:

Debian GNU/kFreeBSD is a port that consists of GNU userland using the GNU C library on top of FreeBSD's kernel, coupled with the regular Debian package set.

Q: Why would anybody want to do that?
A: Why not? [1] So, after we have talked about that, let's start:

1. Install QEMU:
   apt-get install qemu
2. Download the latest Debian GNU/kFreeBSD installer ISO image (either for i386 or amd64):
   wget http://glibc-bsd.alioth.debian.org/install-cd/kfreebsd-i386/20070313/debian-20070313-kfreebsd-i386-install.iso
3. Create a QEMU image which will hold the Debian GNU/kFreeBSD (i386) installation:
   qemu-img create -f qcow2 qemu_kfreebsd_i386.img 5G
4. Boot directly from the ISO image and install Debian into the QEMU image:
   qemu -boot d -cdrom debian-20070313-kfreebsd-i386-install.iso -hda qemu_kfreebsd_i386.img
5. The FreeBSD installer will now start. For more detailed instructions see the Installing Debian GNU/kFreeBSD manual.
   First you can choose between an "Express" or "Custom" install (I used "Express").
6. Next you end up in the partitioning tool. Type "a" to use the entire (QEMU) disk for the installation (the disk is called "ad0", not "hda" as on Linux). Type "q" to quit the partitioning tool.
7. You are now asked which boot manager to use. For QEMU you should use "BootMgr", the default FreeBSD boot manager. If you install on real hardware you can also use GRUB; in that case choose "None" here (see the manual for more information), but note that the installer does not install or configure GRUB for you! You should do that beforehand!
8. Next up: The disklabel editor. Here you'll create a partition ("slice" in FreeBSD-speak) for the root filesystem and a swap partition.
   Press "c" to create a new slice (will be called "ad0s1"), enter "4GB", choose "FS" (filesystem), and enter "/" for the root filesystem. Per default the UFS2 file system will be used. To create the swap partition, press "c" again, enter "1023MB", and select "swap". The new slice is called "ad0s1b". Press "q" to quit.
9. Choose "minimal" when asked which distribution to install.
10. Installation media dialog: select "CD/DVD" and "acd0" (for QEMU's ATAPI/IDE CD-ROM drive).
11. The installation will now begin, and after a while you're asked to switch to console 3 using ALT-F3. Do it.
12. You'll have to answer a bunch of questions: geographic area + city you're in (for timezone), whether you want to participate in the Debian popularity contest, whether module-init-tools should load additional drivers (no, so press ENTER three times). The installation will soon be finished.

At the end you must select "No" as you're told to do, then reboot via "Exit Install". You can then shutdown QEMU.

1. Restart QEMU with the newly installed Debian GNU/kFreeBSD:
   qemu -hda qemu_kfreebsd_i386.img
   
2. Press enter at the FreeBSD boot manager prompt, then login as root (there's no password).
3. First things first: Set up a root password:
   passwd
4. Now let's fix networking, update the system and install a bunch of packages:
   nano /etc/network/interfaces
   Yes, there's no vi, not even a symlink to nano! Uncomment the two "ed0" lines ("ed0" is the equivalent to "eth0" on Linux, I guess).
   /etc/init.d/networking restart
apt-get update && apt-get dist-upgrade
apt-get install vim xorg icewm xterm
5. You can fix your console keymap using the kbdcontrol package (just select your keymap from the menu):
   apt-get install kbdcontrol
6. Finally, let's fix X11 and start it. But first we create a new user, as we don't want to run X11 as root:
   adduser uwe
vi /etc/X11/xorg.conf
   The mouse device is "/dev/psm0", the protocol "PS/2", and the graphics driver should be "vesa":

  Section "InputDevice"
      Option "Device" "/dev/psm0"
      Option "Protocol" "PS/2"
  [...]
  Section "Device"
      Driver "vesa"
    

That's about it. Login as "uwe" (or whatever your username is) and start X11:
startx

Wasn't all that hard, eh? Now, if you've got some spare time, head over to the Debian GNU/kFreeBSD wiki page and help improving this port ;-) You should probably start with reading the PORTING guide. Both kfrebsd-i386 and kfreebsd-amd64 seem to be reasonably stable already (and more than 70% of the whole Debian archive builds fine on these architectures, see kfreebsd-i386_stats and kfreebsd-amd64_stats). I'll quite likely install kfreebsd-amd64 on one of my boxes soonish and start using it, maybe I'll even find some time to fix/patch/port some packages... [1] More elaborate answer(s) and reasons are available in the Debian wiki.

So this is it, I've actually finished at Canonical! For most of the past week, I've been in Portland, OR at Ubuntu Live. I gave two talks (Ubuntu Technical Demonstration and Bringing your software to Ubuntu users) and one tutorial (packaging for Ubuntu and Debian derived distributions). I had a great time, and was glad to get a chance to see my former coworkers one last time. I'm happy to be leaving on great terms with my former employers, and hope to be at UbuntuLive again next year.

This conference was a whirlwind of meeting people. JP, Teri, Jim, Andy and MaryBeth are people I'm really looking forward to seeing in the bay area when I get there; I got to see Steve and Patty in the Debian booth; I managed to go for dinner with Chris and Leslie; A going away party that included many of the above plus Matt, Steve, Etienne and Torsten; I had lunch with Katie, whom I haven't seen since my wedding; I had another lunch with Mermaid, whom I thought had fallen off the face of the earth; my final lunch at Veganopolous included MaryBeth again and Rob. I did miss seeing Kamaya, which is sad, though. I got *almost* everyone I wanted to see.

It's a crazy list. Some of these people will be random business contacts. Some of these are folks that I feel like remeeting them after several years was like only missing a day. Some of these are people I miss already.

Sabrina and I are making the trek up north to Kit and Hannah's wedding. We're staying at Miriam's and had lovely Ethiopian food.

Time to sleep. 7am is going to come too early.

We've had a lot of great blog traffic about Vinismo. I thought I'd try to pull together a few of the better ones.

• vinismo! wiki wine compendium from Hugh McGuire.
• Vinismo Opens Its Doors to Wine Lovers Everywhere from the Creative Commons Weblog. Thanks, guys!
• Vinismo: Wiki + Wine from Zach Copley
• Vinismo from Wendy Copley.
• DemoCampMontreal3 report from Montreal Tech Watch
• DemoCampMontreal3 Report from Josh Nursing
• Vinismo Presentation at DemoCampMontreal3 on the SearchAnyway Blog. Probably one of my favourite pieces, although it makes Niko real mad since it cuts off just before he starts talking. Make mental note: don't say "Uh" so much.
• Bienvenue sur Vinismo, le guide des vins libre by Niko. Niko also bemoaned the difficulty of keeping our project under wraps in Mon lourd secret bient t d voil . What a drama queen.
• Vinismo : un wiki sur le vin by Olivier Niquet. He's suspicious that we are sponsored by J. Lohr, because there are so many J. Lohr wines on our front page.

All in all it's been pretty good. I hope we'll get some more, though! tags: blogs vinismo

DemoCampMontreal3 report So, it's been a couple of days and I should probably get around to posting my own DemoCampMontreal3 report.

• Niko and I started off with our own demo for Vinismo. It was a lot of fun: we talked about the reasons for starting the site, the technical, information architecture and graphics/UI design challenges, and what our future extensions are going to be. At the end of it, we took some questions, which was fun. The most interesting for me was from Roberto Rocha, whose TechnoCit is one of my favourite tech columns in Montreal. He asked, "Your typical contributor will be much older. What will you do to make your wiki more accessible to them?" It was a good question I don't have an answer to yet, but I want to think about it more.
• The second demo was by Heri Rakotomalala, who showed off his social-networking GTD tool, WorkCruncher. It's a TODO list with a twist: items that you don't get done age off the list. You have to re-commit to doing a task on an almost daily basis. I think it's a great and refreshing design; my TODO list gets depressing long and filled with unfinishable tasks, and I get too intimidated to work on ones that really matter. I think Heri might have to make some concessions to people's expectations for TODO lists -- maybe a way to automatically archive tasks, rather than deleting them entirely...?
• The third demo was by the gang from Defensio, who are providing an great anti-spam Web service similar to Akismet. They had a few examples of where they're different, but I'm not well-versed enough in comment spam issues to understand them. My guess is that since they're getting into the market after Akismet, though, they have the opportunity to make a smarter technology. Their one downside? They used slides -- which the rules of DemoCamp. They did demo the service, though.
• Fourth up was the indefatigable Simon Law. Simon's project? To turn back time. Talk about ambitious! His effort consisted of making a typical kitchen clock turn backwards. He disassembled the clock and explained how it worked to the audience. It was great, except for two things: the clock didn't work at the end of the demo (although he got it working by the end of DemoCamp), and he took a few minutes to draw a diagram of the clock; in my mind, that's just a low-tech PowerPoint slide.
• Fifth, and quite fascinating, was a tool that Jerome Paradis showed off. It was a Google-Maps mashup that filtered special emails for an informal private jet sharing network. Apparently, companies who charter private jets often have space in the jets, so they'll make that space available. People who need a last-minute charter jet can send email from their Blackberries and such, and if there's availability they get contacted by the charter companies. The interesting part? These people use a highly structured lingo ("O/W" = "one way"), and Jerome's tool scrapes these emails to make the data into a mapping app for his customers. Very interesting!

All in all, it was a good night -- probably made better by the Argentina Cabernet Sauvignon I had. There's a DemoCampMontreal4 scheduled for August 17th, but I won't be in town for it. Too bad for me! tags: democampmontreal3 defensio workcruncher simonlaw jeromeparadis vinismo

Remember when sponsoring packages was implemented in Debian? Imagine if we had felt the need to vote on whether we were allowed to do that. Instead of just doing it. I'll bet that some people would have argued against, citing reasons such as:

It appears to me that the sponsorship as sketched in the GR is mainly meant to let NMs upload earlier, i.e. it tries to fix the fact that front-desk or DAM approval take too long. I think the fix for that is just to find someone besides Joerg to also read the AM reports. Sponsees as in the GR are a workaround, not a solution.

or:

But the GR micro-manages too much and on the other hand doesn t make the current NM process any easier for Sponsees than for any non-Sponsee applicant to the NM process. Also, like some others said before, I seriously doubt that a big part of the current DD-applicants (i.e. those in the NM queue at some level) would prefer Sponsee status over DD status. What is the difference between a Sponsee and a Debian Developer? Who is interested in becoming a Sponsee and not a Debian Developer and why? Will this Sponsee class really improve the situation for New Maintainers?

or:

I suppose most of our New Maintainers will aim to become a Sponsee just to bridge the time until they re full Debian Developers. And I predict that this is also the major target audience for this new Sponsee class. Some people said on -vote that there are people actually interested in becoming a Sponsee and not a Debian Developer. Personally I find their reasons questionable, but after all I suppose there won t be many people going this route. On the other side, I don t see how this new class enhances the situation for the New Maintainers. Now they not only wait for the Application Manager, Front Desk and Debian Account Managers No, now they will also search for someone who sponsors them. So my question is: If this General Resolution mainly helps New Maintainers, why must it be so complicated? Why another class of contributers, all those complicated rules to set it up and this additional layer of bureaucracy?

or:

If you think the NM process is taking too long, then it's probably better to help out there rather than to try to create a system to bypass it in this way.

But instead, we somehow made the enormous change that sponsorship entailed in how Debian works, without voting on it. Make no mistake, it was a big change on both a technical as well as a social level. Now IMHO, the DM proposal is just fixing a bug in the current sponsorship process. The interesting thing to consider is, if this vote fails, how can the bug be fixed without another vote? I personally believe that any DD has the power to fix this without dragging the project through a vote. They may put their status as developer at stake in fixing it, if they take what seems like the obvious approach, but if one feels that this bug in sponsorship is a bad enough bug and is hurting Debian enough, that might be worth it.

Following up to Myon’s post, I also wanted to blog my honest opinion about the GR. Given my current understanding of the GR, I hope to see it fail (and will send my vote shortly after this blog entry I think). The reason is not that I think it shouldn’t be made easier to contribute to Debian (on the contrary). But the GR micro-manages too much and on the other hand doesn’t make the current NM process any easier for DM’s than for any non-DM applicant to the NM process. Also, like some others said before, I seriously doubt that a big part of the current DD-applicants (i.e. those in the NM queue at some level) would prefer DM status over DD status. And the same is true (IMHO) for other people wanting to contribute to Debian. This is a simple thing: If I contribute to something regularly in my spare time (like most contributors in the FL/OSS world do), I also would like to have some influence over its directions. And a DM is missing this influence even more than a DD is. So what should be done instead in my opinion?
I think that a DM like status is fine as part of a (possibly re-designed) NM process. Given the current NM process, I would like people been given a DM like status after they finished the T&S (tasks^IIRC and skills) part if their AM found their skills and knowledge of the policy rules sufficient to give them that status. If that is all they wanted, they can drop from the NM process at that point and stay DMs. If they want to become DDs later on, they can resume the NM process at that very step (or continue right ahead). This would do several things:

• introduce the DM status as an alternative to full DD status
• integrate the DM status closer with the existing NM process
• take some load of the friendly sponsors who upload non-DD packages now, giving them more time to help more new contributors
• give people waiting for DD status some intermediate level at which they already can do more than before their joining of the NM queue

So I really think “more discussion” is the only valid option for me in this GR. If you want to change my mind: Please leave some feedback in my blog. Or give a precise (but brief) description why the current proposal is better than integration with the current NM process in one way or the other. Abbreviations:

• DD = Debian Developer (a full Debian project member, includes voting rights)
• DM = Debian Maintainer (planned to be a somewhat restricted DD, among others without voting rights)
• NM = New Maintainer (should actually be: New Developer)
• GR = General Resolution (a way in Debian to create new rules or to ask the project leader or others in the project to do or refrain from doing something)

Update:
The GR even seems to contradict itself a bit. If the upload rules are applied in an AND fashion, one of these rules is superfluous (the first one), at least if I’m not mistaken:

• the Maintainer: field of the uploaded .changes file corresponds with the owner of the key used (ie, non-developer maintainers may not sponsor uploads)
• the most recent version of the package uploaded to unstable or experimental includes the field “DM-Upload-Allowed: yes” in the source section of its control file
• the most recent version of the package uploaded to unstable or experimental lists the uploader in the Maintainer: or Uploaders: fields (ie, non-developer maintainers cannot NMU or hijack packages)

The first rules also means that no DM could ever do an upload for packages team-maintained in the fashion cyrus-imapd-2.2 is maintained (Maintainer address is the teams mailinglist address, all uploading team members are in the Uploaders field). This is IMHO a serious flaw in the proposal. If the first rule was dumped, all would be well for team maintainers.

Share This

When voting on the current Debian Maintainers General Resolution, I think it’s worth to think about the following questions: What is the difference between a Debian Maintainer and a Debian Developer? Who is interested in becoming a Debian Maintainer and not a Debian Developer and why? Will this Debian Maintainer class really improve the situation for New Maintainers? I suppose most of our New Maintainers will aim to become a Debian Maintainer just to bridge the time until they’re full Debian Developers. And I predict that this is also the major target audience for this new Debian Maintainers class. Some people said on -vote that there are people actually interested in becoming a Debian Maintainer and not a Debian Developer. Personally I find their reasons questionable, but after all I suppose there won’t be many people going this route. On the other side, I don’t see how this new class enhances the situation for the New Maintainers. Now they not only wait for the Application Manager, Front Desk and Debian Account Managers — No, now they will also search for someone who advocates them to become a Debian Maintainer and have to wait for their key being added to the Debian Maintainers keyring. So my question is: If this General Resolution mainly helps New Maintainers, why must it be so complicated? Why another class of contributers, all those complicated rules to set it up and this additional layer of bureaucracy? Why don’t we aim for something simple, like improving our New Maintainer process. I would rather see some of those Debian Maintainer rights granted to New Maintainers after a certain point in their New Maintainer career, but not in this complicated and overengineered way the Debian Maintainer class proposes.

I haven't said anything in the DM threads yet because I still don't know which actual problem the introduction of DMs is trying to solve. IMHO the current process with sponsors reviewing and uploading packages has proven to work nicely, i.e. the amount of broken packages uploaded is not too high. Most of the perceived problems with this process stem from the fact that most of the packages offered on debian-mentors or #debian-mentors are initially crap and need lots of review cycles. Once people produce good packages asking the last sponsor for another upload should work. (And at that point NM will be a breeze.) Particularly I don't like the fact that the "initial policy for an individual to be included in the keyring" does not include any check of any technical or non-technical skills besides having a gpg key and be able to tick 3 checkboxes. I fear this will lead to people blacklisting "DM" packages because they don't want low-quality packages on their machines. At the same time, the rest of the GR text is micro-managing every other detail of the process in a way that doesn't leave much room for practical implementation decisions. It appears to me that the DM concept as sketched in the GR is mainly meant to let NMs upload earlier, i.e. it tries to fix the fact that front-desk or DAM approval take too long. I think the fix for that is just to find someone besides Joerg to also read the AM reports. DMs as in the GR are a workaround, not a solution. On a sidenote, I'm still wondering why front-desk (and afaict the DAMs) were never asked about their opinion while/after the GR was drafted. I had some chats with Anthony on IRC on the topic, but that was shortly after Debconf 6 (there was a related BoF), nothing in the past months. (not with the front-desk hat on, but having it within reach) PS: I voted "-1".

In the lands where the camel roams, the white (albino) camel is a rare and revered individual. The White Camel Awards recognize the many significant contributions made by the unsung heros of the Perl community. The efforts of these volunteers collectively make the Perl language and the Perl community better for all of us. – The Perl Foundation. 2007 Recipients

Allison Randal

Allison is at the center of the Perl community. She’s been president of The Perl Foundation, a leader and manager of various parts of the Perl 6 and Parrot efforts, as well a Perl author and editor. Her latest contribution to Perl is version 2 of the Artistic License, under which most open source Perl code, and Perl itself, is licensesd “under the terms of Perl itself”.

Tim O’Reilly

You may think of Tim as the guy who published Programming perl and Learning Perl, but he also kick-started the current form of the Perl community by giving it a place to come to together once a year. O’Reilly & Associates started The Perl Conference in 1997. Perl Mongers, the organization that helped start Perl users groups all over the world, started at that first Perl Conference. O’Reilly Media has been incredibly gracious and helpful to the Perl community.

Norbert E. Gr ner

Norbert help start the German Perl Workshop in 1999 and now is involved in several of the Perl conferences and workshops that take place in Europe. He’s the chair of the YAPC::Europe committee.

You may have noticed that my frequency of posting has increased significantly recently, and that my posts are generally at 7AM and 7PM. I am using the scheduled posting feature of Wordpress and writing my posts in advance (currently I have 8 posts in the queue including this one). Generally readers of my blog (particularly those who read Planet syndication pages) don’t want to read 5+ posts in one go. In the past I would write one post at a time and sometimes a couple of days would pass between feeling inspired to write. I had been writing text files and uploading them, but having a text file that’s 95% done is not the same as having a complete post scheduled to be released while I’m doing something else. This technique works for me, I encourage other people who have things to say but don’t seem to get around to blogging on some days to give it a go. Incidentally I chose the times 7AM and 7PM because the traffic to my site seems to peak between 7PM and 11PM local time (I haven’t analysed the logs in enough detail to determine whether this is Australians reading blogs after work or people in other countries doing it at work). To release two posts per day it seems most appropriate to space them 12 hours apart (and means that people in the same time zone as me can read a post before going to work).

Share This

Nat Torkington, program chair, started off the day. He commented that one of the most interesting trends these days is the expansion of the Open Source ideals beyond software.

Tim O'Reilly commented about the FSF's four freedoms, and asked how we maintain them. We have to think about preserving freedoms -- questions such as Free Software that relies on proprietary services, data, or business processes. It's important to remember to pay attention to freedom and not just to the success of businesses. But businesses matter and have enormous power and will always be related.

Tim really pushed expanding the boundaries of Open Source and thinking ahead: wikipedia, OpenID, etc. He also asked: does Congress need a version control system?

He suggested there are four open source success factors: frictionless software distribution, collaborative development, freedom to build/adapt/extend, freedom to fork.

Hadoop is an interesting FLOSS project to build some infrastructure like Google has. Apparently Yahoo is very interested.

Back to Nat... hardware is cheap and everyone keeps buying more of it.

James Reinders from Intel talking about multi-core parallelism. Saying that parallelism is going to be more and more important. Intel released threading building blocks, a series of templates for C++, as GPL'd software at the conference this week. I'm not all that excited about a C++ project, though, since I think languages like Haskell have more promise here anyway.

The other Intel guy mentioned Intel's open source involvement: intellinuxgraphics.org, intellinuxwireless.org, linuxpowertop.org, kernel,org, moblin.org. Linux laptops have the longest runtimes compared to other laptops.

"It's amazing how many people you can make paranoid by showing up with a tie and a suit to do a keynote at OSCON." -- James Reinders

Simon Peyton-Jones is up now, and Nat says he will "stretch your brain until only tiny bits are left."

State of the art in parallelism is really 30 years old with locks and condition variables -- like building a skyscraper out of bananas.

Locks are difficult to do right and have "diabolical error recovery".

Let's do transactions against memory instead of against a database. Implementation can even be similar to databases. The idea is transactional memory, and it sounds very, very slick.

Mark Shuttleworth and Tim for an interview...

Mark was fine, but I wish Tim had more interesting questions for him.

I went up to the front a few minutes after the event to talk to Simon PJ. He was talking to someone, who saw my nametag, and said, "Hi John, nice to meet you." He looked familiar but I couldn't quite place him, so I asked who he was. "Mark Shuttleworth." Yep, I was sitting just far enough back from the stage that I wasn't behind one of the large TV screens and couldn't make out faces real well, and I didn't recognize him. Erg..

Alex Fletcher: “The blogosphere, or at least the hemisphere which cares about such things, has been busy producing references to the latest series of events surrounding Sun Microsystems’ Project Indiana, the binary distribution of the company’s OpenSolaris operating system. For example, last week Enterprise Linux Log featured a story about the state of affairs at a recent NYC UNIX user group in Manhattan where things didn’t seem to go well. However, what I took from news of the event, including commentary from those who attended was entirely different from the way in which the article was seemingly framed.” It’s interesting how different people can take away very different things from the same presentation. If you’re at OSCON, come hear it firsthand—I’m speaking about Project Indiana today at 11:35 in room E141. And judge for yourself.

Havoc’s keynote at GUADEC was extremely interesting, especially for how it polarised the people present. Several people seemed very upset with the notion that f-spot should be replaced by flickr, but I think that was a problem with the way that Havoc presented the message, and not the underlying idea. Instead consider f-spot and flickr as sharing the same collection of data, and being two different ways to view and manage it; with changes from one appearing in the other. The mechanism isn’t important. Consider the following:

• While out and about, I take a picture with my camera phone.
• On coming home, the phone is within bluetooth range of my laptop (with both enabled).
• The laptop sees the new picture, so announces the availability of the new picture.
• f-spot is subscribed to those announcements, and causes the picture to be copied into my local f-spot library, with the meta-data adjusted to indicate the local cache (as well as the origin).
• flickr is also subscribed, so the picture is automatically uploaded to my flickr account.
• At some point in the past, a friend on Facebook changed their mobile number; this was detected and the change announced.
• e-d-s was subscribed, so automatically adjusted my contacts.
• And my phone sync service is subscribed, so now my phone is in range, its contact list is updated too.

Now, isn’t that cool?

Netflix was offline for nearly 24 hours — almost weeks in Internet time for a business whose entire existence is online. It was astonishing, at least to me, that a major Internet service could be disrupted for so long. According to my people on the ground in San Francisco, a transformer explosion was the cause. It’s a good reminder that the Net is more fragile than we might think. UPDATE: the original source in California recants. The Netflix outage remains a mystery. Explanations are welcome.

Share This

I believe that an ideal installation process for Linux would have the option of performing a Xen install. The basic functionality of installing the Xen versions of the required packages (the kernel and libc), the Xen hypervisor, and the Xen tools is already done well in Fedora and it’s an option to install them in Debian. But more than that is required. Xen has two options for networking, bridging and routing. The bridging option can be confusing to set up and changing a system from routed to bridged networking once it’s running is a risky process. I have documented the basic requirements for running bridging in a previous post, but it would be better if there was an option to have Xenbr0 as the primary device from the initial install - and there are non-Xen reasons for doing this so it would be a more generally useful feature. Another common requirement for a Xen server is to have a DVD image on the local hard drive for creating new DomU’s. If we are going to need a copy of the DVD on the local hard drive for Xen installation and we need data from the DVD for the Dom0 installation then it makes sense to have one of the early installation tasks (immediately after running mkfs) be to copy the contents of the DVD to the hard drive. Hard drives are significantly faster than DVDs - especially for random access. It would also avoid the not uncommon annoyance of getting part way through an install only to encounter a DVD or CD read error… Here are some reasons for running Xen (or an equivalent technology) when not running more than one DomU:

1. Avoid problems booting. Everyone who has spent any significant amount of time running servers has had problems where machines don’t boot. Even with a capable out of band management option such as the HP ILO it can be unreasonably inconvenient to fix such problems. Separating the base hardware management tasks of the OS from the user process management tasks makes recovery much easier. If a DomU stops booting then it’s easy to mount it on the Dom0 and chroot into it to discovere the problem.


2. Easier upgrades. Often you have users demand that you install software that only works with a newer version of the OS. You can install the new version under a different DomU, test it, and then replace the old DomU when you think it’ll work - this gives a matter of minutes of down-time instead of hours for the upgrade. If the upgrade doesn’t work then you destroy the DomU and create one for the old version. Running two versions of the OS at the same time with NFS shares for the data files is also possible.


3. Security. If a DomU gets cracked the Dom0 will not necessarily be compromised, this puts you in a good position to track down what the attackers have done. You can get a dump of the DomU’s memory to enable experts to examine what the attackers were doing. Reinstalling a DomU to replace data potentially corrupted by an attacker is much easier than reinstalling an entire machine.

Even in situations when reason #2 was the motivation for installing Xen I believe that most systems will want to have a Xen DomU running the same version as the Dom0 for the initial install. Therefore integrating the installation process would make things easier. Among other benefits if you have a server with multiple CPUs (the minimum number seems to be two CPUs on all recent machines) and hardware RAID then doing two installations at the same time is likely to give better performance overall. Also I believe that it will often be the case that the Dom0 will exist purely to support DomU’s, therefore if you only install the Dom0 then you have done less than half the installation! For a manual installation there are some reasons for not doing this all at the same time. Having the sys-admin enter configuration data for some DomU’s at the same time as the Dom0 can get confusing. However for an automated install this would be desirable. I would like to boot from a CD and have the installation process take all configuration from the network (either via NFS or HTTP) and then perform the complete installation of the Dom0 and the DomU’s automatically. Let me know what you think of these ideas, it’s just at the conceptual stage at the moment.

Share This