Philippe blogs about how one can import a GPG key into apt's GPG keyring so that it will stop complaining about unknown keys. While his method will work, it has a major flaw: Importing random keys without checking them first makes secure apt totally useless, since it allows an attacker to replace an apt repository with another one that he signed with his own key and you won't even notice because you blindly import keys anyway. So what's the right way? Depends:

• If you have a GPG key yourself, and you have built a local web of trust (with gpg's --update-trustdb command beware, this is an interactive process that can take a long time if you have a lot of keys in your local gpg keystore), you can verify that the key really is what it claims to be:

  wouter@celtic:~$ gpg --edit-key 6070D3A1
  gpg (GnuPG) 1.4.9; Copyright (C) 2008 Free Software Foundation, Inc.
  This is free software: you are free to change and redistribute it.
  There is NO WARRANTY, to the extent permitted by law.
  pub  1024D/6070D3A1  created: 2006-11-20  expires: 2009-07-01  usage: SC  
                       trust: never         validity: full
  [  full  ] (1). Debian Archive Automatic Signing Key (4.0/etch) <ftpmaster@debian.org>
  Command> quit
  

  Why --edit-key? Because --list-keys, --list-sigs, or even --check-sigs does not show you the validity information. The --list-sigs --with-colons output does, but that is meant for computer consumption, and isn't very useful for human beings. But --edit-key contains the information too, so that works. What you need to look at is the information that immediately follows 'validity:'. In my case, it says 'validity: full', meaning, "enough" people who I have indicated (using --update-trustdb) to trust that they can sign keys the proper way have signed this particular key. "Enough" is configurable, but for now, let's ignore that (there's plenty of data about that on the web if you want it). If your output says 'validity: full', then go ahead and add it to apt's trusted keyring:

  gpg --export 6070D3A1   apt-key add -
  

  Note: go ahead and ignore the 'trust: never' data in the output. This represents the fact that I told gpg not to trust the key when doing gpg --update-trustdb. This doesn't mean I won't trust data that's signed with this particular key; however, it does mean I won't trust key signatures signed with this particular key. Since this is not a personal key, but a key only used to sign data with, this is the right thing to do for this particular key.
• Alternatively, if you don't have a keyring, don't want to maintain your local web of trust, don't understand what I just said, or any combination of the preceding, just check what the maintainers of the particular repository to which this key corresponds tell you. If they're good maintainers, they should've given you a fingerprint right beside the information that contained the apt repository. Copy-and-paste that information on two command lines:

  gpg --keyserver subkeys.pgp.net --recv-key <fingerprint>
  gpg --export <fingerprint>   apt-key add -
  

  If they didn't give you that information, then send a giant cluebat mail to them. They really should've done that.
• Finally, if you don't care about all this gpg stuff and don't think anyone would be interested to break into your system, you'd be wrong scriptkiddies don't look at who's using a particular system, they just like to be stupid. If you insist, however, you should note that you can actually disable secure apt, by adding the following to a file under /etc/apt/apt.conf.d:

  APT::Get::AllowUnauthenticated "yes";
  

  Not that I'd recommend it, but if you insist...

Expectations: A little over a week ago I participated in a camp/event/conference/ that threw together 12 different networked based-groups/phenomenon/organizations. They got to do what many often can t do: spend some time working face-to-face as well as thinking about about questions of un(organizational) growth/ungrowth. Some of us spent some time learning about the nature of networked coordinations and organizations from these groups. There is a lot I could write about but, in part because I was in Amsterdam for a week, I am now playing serious catch up, but there are a few things that really struck me both of which relate to expectations, which I thought worth jotting down. Generally present were the following types of groups: open source projects (such as Blender), tech-oriented activist projects (Dyne), non-tech oriented projects (such as Free Dimensional), artistic-tech projects (such as GOTO10), artistic projects (Upgrade), academic-activist (Edu Factory) and others which are harder to classify (such as Gender Changes, and FLOSS Manuals). One thing that came out during the plenary sessions, which is when we got together as a large group to debate and discuss, is that technically oriented open source projects are at times singled out for not being inclusive. That is, people pointed out that most projects expect you to contribute technically in order to participate (and don t necessarily offer people the training/capacity so you can participate). I have heard a version of this many many and many times before and find it to be a curious (and generally unproductive) accusation, though I understand why the confusions arises. I say confusion because most of these projects are not overtly set up to be inclusive/technically pedagogical, and this is perhaps the key point they don t purport to be though many folks think this is part of their overall message/mission. Because these free software projects are open source, this, for some, somehow automatically translates into the political projects of inclusivity (that is, training folks so that they can become part of this world). And yet some other projects, such as Edu Factory and GoTo10, which are run as tight-knit of collectives, are rarely accused of not being inclusive. Why should this be? I raise this mostly because I find it interesting, pointing to the way certain terms or phrases (Freedom, Openness) combined with the visibility of FLOSS projects, automatically generate other expectations and meanings even if they don t actually exist. I also raise it because I think it is an unfair expectation to have of these communities only in so far as most of them are full of folks busy hacking up technology and this in and of itself, as I have written about before is worthwhile politically. And yet If one wants to make them more inclusive, then one can go ahead and bring into being such a project for most of them are quite open to various initiatives to enlarge the scope of participation. These projects can be internal to projects or external to them. That is, self-initiative goes a long way in this world, and has helped changed the terrain of participation and inclusivity and I am sure will continue to do so. Which brings me to my second point about expectations. Many people complain that open source is not easy to use. While this was entirely, 1000% true prior to 1998, every passing day makes this statement harder to stand by. I imagine in another 10 years, there will be many many programs that are as usable for the novice user as proprietary software. They had to play serious catch-up and I think have done a decent job. In some regards, all that was and is needed is time because time has already shown that usability has improved leaps and bounds. And yet there is still something odd about the accusations, which my friend tulpje but in the following way One would never accuse the Zapatistas for not having their military might/shit together like the US army, so why accuse open source for not being the mightiest software our there?) While I actually think that free software has already and will continue to give proprietary firms a run for their money in a way that a rag-tag guerrilla army can t do with a national army, it is nonetheless important to couch one s responses and accusations in terms of the constraints and realities of these projects. That said, I still think such expectations reflect important hopes and desires. They show us just how profoundly free software/open source has, simply by virtue of its existence, inspired many to follow suite politically, turning to FLOSS as a beacon of possibility.

Expectations: A little over a week ago I participated in a camp/event/conference/ that threw together 12 different networked based-groups/phenomenon/organizations. They got to do what many often can t do: spend some time working face-to-face as well as thinking about about questions of un(organizational) growth/ungrowth. Some of us spent some time learning about the nature of networked coordinations and organizations from these groups. There is a lot I could write about but, in part because I was in Amsterdam for a week, I am now playing serious catch up, but there are a few things that really struck me both of which relate to expectations, which I thought worth jotting down. Generally present were the following types of groups: open source projects (such as Blender), tech-oriented activist projects (Dyne), non-tech oriented projects (such as Free Dimensional), artistic-tech projects (such as GOTO10), artistic projects (Upgrade), academic-activist (Edu Factory) and others which are harder to classify (such as Gender Changes, and FLOSS Manuals). One thing that came out during the plenary sessions, which is when we got together as a large group to debate and discuss, is that technically oriented open source projects are at times singled out for not being inclusive. That is, people pointed out that most projects expect you to contribute technically in order to participate (and don t necessarily offer people the training/capacity so you can participate). I have heard a version of this many many and many times before and find it to be a curious (and generally unproductive) accusation, though I understand why the confusions arises. I say confusion because most of these projects are not overtly set up to be inclusive/technically pedagogical, and this is perhaps the key point they don t purport to be though many folks think this is part of their overall message/mission. Because these free software projects are open source, this, for some, somehow automatically translates into the political projects of inclusivity (that is, training folks so that they can become part of this world). And yet some other projects, such as Edu Factory and GoTo10, which are run as tight-knit of collectives, are rarely accused of not being inclusive. Why should this be? I raise this mostly because I find it interesting, pointing to the way certain terms or phrases (Freedom, Openness) combined with the visibility of FLOSS projects, automatically generate other expectations and meanings even if they don t actually exist. I also raise it because I think it is an unfair expectation to have of these communities only in so far as most of them are full of folks busy hacking up technology and this in and of itself, as I have written about before is worthwhile politically. And yet If one wants to make them more inclusive, then one can go ahead and bring into being such a project for most of them are quite open to various initiatives to enlarge the scope of participation. These projects can be internal to projects or external to them. That is, self-initiative goes a long way in this world, and has helped changed the terrain of participation and inclusivity and I am sure will continue to do so. Which brings me to my second point about expectations. Many people complain that open source is not easy to use. While this was entirely, 1000% true prior to 1998, every passing day makes this statement harder to stand by. I imagine in another 10 years, there will be many many programs that are as usable for the novice user as proprietary software. They had to play serious catch-up and I think have done a decent job. In some regards, all that was and is needed is time because time has already shown that usability has improved leaps and bounds. And yet there is still something odd about the accusations, which my friend tulpje but in the following way One would never accuse the Zapatistas for not having their military might/shit together like the US army, so why accuse open source for not being the mightiest software our there?) While I actually think that free software has already and will continue to give proprietary firms a run for their money in a way that a rag-tag guerrilla army can t do with a national army, it is nonetheless important to couch one s responses and accusations in terms of the constraints and realities of these projects. That said, I still think such expectations reflect important hopes and desires. They show us just how profoundly free software/open source has, simply by virtue of its existence, inspired many to follow suite politically, turning to FLOSS as a beacon of possibility.

Mark Purcell reported bug #520000 on Monday March 16th, against the gsm-utils package. Bug #510000 was reported as of Dec 28th 2008. So, it took us 2.5 months for 10,000 bugs. This is still slower than our rate of 10,000 bugs/2 months but more than the pace we had for 500000-510000. Of course, in the meantime, we released lenny on Feb 14th and, therefore, the development started again and, with development, new bugs come in. To illustrate this, one will notice that bug #515000 was reported on Feb 12th. So, it took 46 days for the first 5,000 bugs and then only 32 for the remainder 5,000. In short, we're probably back to our pace of 10,000 bugs in two months. In case someone cares, the first bug reported after the release of Lenny is #515247, reported by Robin Kluth against the gvfs package. It followed the release of lenny by 25 minutes and 14 seconds. That bug isn't fixed yet but is already reported upstream.

The book Expert Python Programming comes with subtitle Best practices for designing, coding, and distributing your Python software. Well this seems to be quite broad area to be covered by a single book, but the book really tries to cover all topics at least in some form of overview and pointing user to other documentation sources. In first chapter you can find information about installing Python on various platforms. As the book seems to be targeted to more experienced users, this chapter seems to be a bit useless, but author decided to give a chance also to users, who do not know the basics. Next chapters describe best practices for writing Python code, which was the most interesting part for me. I use Python several years, but I never really found time time to properly look at using decorators, generators and other "recently" introduced language features. Second chapter nicely covers these and I really appreciated that I got idea for what decorators can be used. Third chapter into class level and describes how to use metaclasses, attributes, constructors and other things you can face on class level. Fourth moves the topic to even more abstract way and in short summarises PEP 8 best coding practices. Here we leave solid ground of writing code and we move to more abstract areas of managing projects, testing, documenting and distributing software. It begins with description of distutils and setuptools in chapters five and six, where you will find basic information about distributing your software. Seventh chapter covers zc.buildout, which can help you with setting up and deploying applications in way Zope and Plone do. Next chapter is not really related to Python, it just describes advantages of version control. The most Python related part is using Mercurial VCS, which is written in Python, but you can of course use it for managing any project. Next tree chapters are devoted to project development in general, describing management of the project, generating documentation for project using Sphinx (what actually made me into starting documentation for python-gammu in it) and test-driven development practices. Now comes again two more interesting chapters describing optimization of Python code, giving the best advice not to optimize unless you are sure it is needed ;-). But it also goes more deeper and describes benchmarking procedures, how to debug memory usage and some basic tips for general things which might improve performance. Last chapter is some kind of extra in the book and to me it looks it was added just to use buzzwords design patters, but well it is there and it covers few design patterns which might be useful in Python like singleton or more advanced version of it called borg. In general this book covers quite wide range of topics, what can be seen as biggest advantage and disadvantage. You will get basic overview of creating Python project using modern methods (test driven development, design patters, best practices for Python code), but you can not expect it will go into much deep details. The book can extend your knowledge of development in Python, but you should carefully check examples with errata, because otherwise several of them will fail. I'm not that good at spotting problems in written English (as you can probably see in this post), but I spotted several errors in code and I think more careful editor work on the book would improve my feelings a bit. Also I personally would prefer much deeper look into some topics and skipping the others, but one book can not fit all ;-).

I went to see Fruit Fly at the Castro Theatre tonight. It was a really fun movie and very local. Oh yeah, it's a musical, I don't think I've had that much fun watching a movie since I saw Jesus Christ Vampire Hunter the first time. The opening number is a song about public transit and not needing a car in San Francisco. The previous film by H.P. Mendoza is Colma: The Musical, it's got a lot of the same cast and also look like a lot of fun. Unfortunatly, movies are behind music and I can't find a stream or download on hulu, amazon or youtube of Colma the musical.

Anyway, if anyone wants to go see Fruit Fly it is playing in Berkeley on friday. I don't think I'll make it out to that since the Castro Theatre is having a triple bill "nerds with balls" Midnites for maniacs on friday.

In other good news, I couldn't get either a Petzl size 1 or size 2 harness since my legs are size two, but my waist is size 1.

After reading the comments on my earlier post, Delayed allocation and the zero-length file problem as well as some of the comments on the Slashdot story as well as the Ubuntu bug, it s become very clear to me that there are a lot of myths and misplaced concerns about fsync() and how best to use it. I thought it would be appropriate to correct as many of these misunderstandings about fsync() in one comprehensive blog posting. As the Eat My Data presentation points out very clearly, the only safe way according that POSIX allows for requesting data written to a particular file descriptor be safely stored on stable storage is via the fsync() call. Linux s close(2) man page makes this point very clearly:

A successful close does not guarantee that the data has been successfully saved to disk, as the kernel defers writes. It is not common for a file system to flush the buffers when the stream is closed. If you need to be sure that the data is physically stored use fsync(2).

Why don t application programmers follow these sage words? These three reasons are most often given as excuses:

1. (Perceived) performance problems with fsync()
2. The application only needs atomicity, but not durability
3. The fsync() causing the hard drive to spin up unnecessarily in laptop_mode

Let s examine each of these excuses one at a time, to see how valid they really are. (Perceived) performance problems with fsync() Most of the bad publicity with fsync() originated with the now infamous problem with Firefox 3.0 that showed up about a year ago in May, 2008. What happened with Firefox 3.0 was that the primary user interface thread called the sqllite library each time the user clicked on a link to go to a new page. The sqllite library called fsync(), which in ext3 s data=ordered mode, caused a large, visible latency which was visible to the user if there was a large file copy happening by another process. Nearly all of the reported delays was a few seconds, which would be expected; normally there isn t that much dirty data that needs to be flushed out on a Linux system, even if it is even very busy. For example, consier the example of a laptop downloading an .iso image from a local file server; if the laptop has the exclusive link of a 100 megabit/second ethernet link, and the server has the .iso file in cache, or has a nice fast RAID array so it is not the bottleneck, then in the best case, the laptop will be able to download data at the rate of 10-12 MB/second. Assuming the default 5 second commit interval, that means that in the worst case, there will be at most 60 megabytes which must be written out before the commit can proceed. A reasonably modern 7200 rpm laptop drive can write between 60 and 70 MB/second. (The Seagate Momentus 7200.4 laptop drive is reported to be able to deliver 85-104 MB/second, but I can t find it for sale anywhere for love or money.) In this example, an fsync() will trigger a commit and might need to take a second while the download is going on; perhaps half a second if you have a really fast 7200 rpm drive, and maybe 2-3 seconds if you have a slow 5400 rpm drive. (Jump to Sidebar: What about those 30 second fsync reports?) Obviously, you can create workloads that aren t bottlenecked on the maximum ethernet download speed, or the speed of reading from a local disk drive; for example, dd if=/dev/zero of=big-zero-file will create a very large number of dirty pages that must be written to the hard drive at the next commit or fsync() call. It s important to remember though, fsync() doesn t create any extra I/O (although it may remove some optimization opportunities to avoid double writes); fsync() just pushes around when the I/O gets done, and whether it gets done synchronously or asynchronously. If you create a large number of pages that need to be flushed to disk, sooner or later it will have a significant and unfortunate effect on your system s performance. Fsync() might make things more visible, but if the fsync() is done off the main UI thread, the fact that fsync() triggers a commit won t actually disturb other processes doing normal I/O; in ext3 and ext4, we start a new transaction to take care of new file system operations while the committing transction completes. The final observation I ll make is that part of the problem is that Firefox as an application wants to make a huge number of updates to state files and was concerned about not losing that information even in the face of a crash. Every application writer should be asking themselves whether this sort of thing is really necessary. For example, doing some quick measurements using ext4, I determined that Firefox was responsible for 2.54 megabytes written to the disk for each web page visited by the user (and this doesn t include writes to the Firefox cache; I symlinked the cache directory to a tmpfs directory mounted on /tmp to reduce the write load to my SSD). So these 2.54 megabytes is just for Firefox s cookie cache and Places database to maintain its Awesome bar . Is that really worth it? If you visit 400 web pages in a day, that s 1GB of writes to your SSD, and if you write more than 20GB/day, the Intel SSD will enable its write endurance management feature which slows down the performance of the drive. In light of that, exactly how important is it to update those darned sqllite databases after every web click? What if Firefox saved a list of URL s that has been visited, and only updated every 30 or 60 minutes, instead? Is it really that every last web page that you browse be saved if the system crashes? An fsync() call every 15, 30, or 60 minutes, done by a thread which doesn t block the application s UI, would have never been noticed and would have not started the firestorm on Firefox s bugzilla #421482. Very often, after a little thinking, a small change in the application is all that s necessary for to really optimize the application s fsync() usage. (Skip over the sidebar if you ve already read it). Sidebar: What about those 30 second fsync reports? If you read through the Firefox s bugzilla entry, you ll find reports of fsync delays of 30 seconds or more. That tale has grown in the retelling, and I ve seen some hyperbolic claims of five minute delays. Where did that come from? Well, if you look that those claims, you ll find they were using a very read-heavy workload, and/or they were using the ionice command to set a real-time I/O priority. For example, something like ionice -c 1 -n 0 tar cvf /dev/null big-directory . This will cause some significant delays, first of all because ionice -c 1 causes the process to have a real-time I/O priority, such that any I/O requests issued by that process will be serviced before all others. Secondly, even without the real-time I/O priority, the I/O scheduler naturally prioritizes reads as higher priority than writes because normally processes are waiting for reads to complete, but writes are normally asynchronous. This is not at all realistic workload, and it is even more laughable that some people thought this might be an accurate representation of the I/O workload of a kernel compile. These folks had never tried the experiment, or measured how much I/O goes on during a kernel compile. If you try it, you ll find that a kernel compile sucks up a lot of CPU, and doesn t actually do that much I/O. (In fact, that s why an SSD only speeds up a kernel compile by about 20% or so, and that s in a completely cold cache case. If the commonly used include files are already in the system s page cache, the performance improvement of the SSD is much less.) Jump back to reading Performance problems with fsync. The atomicity not durability argument One argument that has commonly been made on the various comment streams is that when replacing a file by writing a new file and the renaming file.new to file , most applications don t need a guarantee that new contents of the file are committed to stable store at a certain point in time; only that either the new or the old contents of the file will be present on the disk. So the argument is essentially that the sequence:

• fd = open( foo.new , O_WRONLY);
• write(fd, buf, bufsize);
• fsync(fd);
• close(fd);
• rename( foo.new , foo );

is too expensive, since it provides atomicity and durability , when in fact all the application needed was atomicity (i.e., either the new or the old contents of foo should be present after a crash), but not durability (i.e., the application doesn t need to need the new version of foo now, but rather at some intermediate time in the future when it s convenient for the OS). This argument is flawed for two reasons. First of all, the squence above exactly provides desired atomicity without durability . It doesn t guarantee which version of the file will appear in the event of an unexpected crash; if the application needs a guarantee that the new version of the file will be present after a crash, it s necessary to fsync the containing directory. Secondly, as we discussed above, fsync() really isn t that expensive, even in the case of ext3 and data=ordered; remember, fsync() doesn t create extra I/O s, although it may introduce latency as the application waits for some of the pending I/O s to complete. If the application doesn t care about exactly when the new contents of the file will be committed to stable store, the simplest thing to do is to execute the above sequence (open-write-fsync-close-rename) in a separate, asynchronous thread. And if the complaint is that this is too complicated, it s not hard to put this in a library. For example, there is currently discussion on the gtk-devel-list on adding the fsync() call to g_file_set_contents(). Maybe if someone asks nicely, the glib developers will add an asynchronous version of this function which runs g_file_set_contents() in a separate thread. Voila! Avoiding hard drive spin-ups with laptop_mode Finally, as Nathaniel Smith said in Comment #111 of of my previous post:

The problem is that I don t, really, want to turn off fsync s, because I like my data. What I want to do is to spin up the drive as little as possible while maintaining data consistency. Really what I want is a knob that says I m willing to lose up to minutes of work, but no more . We even have that knob (laptop mode and all that), but it only works in simple cases.

This is a reasonable concern, and the way to fix this is to enhance laptop_mode in the Linux kernel. Bart Samwel, the author and maintainer of laptop_mode, actually discussed this idea with me last month at FOSDEM. Laptop_mode already adjusts /proc/sys/vm/dirty_expire_centisecs and /proc/sys/vm/dirty_writeback_centisecs based on the configuration parameter MAX_LOST_WORK_SECONDS, and it also adjusts the file system commit time (for ext3; it needs to be taught to do the same thing for ext4, which is a simple patch) to MAX_LOST_WORK_SECONDS as well. All that is necessary is a kernel patch to allow laptop_mode to disable fsync() calls, since the kernel knows that it is in laptop_mode, and it notices that the disk has spun up, it will sync out everything to disk, since once the energy has been spent to spin up the hard drive, we might as well write everything in memory that needs to be written out right away. Hence, a patch which allows fsync() calls to be disabled while in laptop_mode should do pretty much everything Nate has asked. I need to check to see if laptop_mode does this already, but if it doesn t force a file system commit when it detects that the hard drive has been spun up, it should obviously do this as well. (In addition to having a way to globally disable fsync() s, it may also be useful to have a way to selectively disable fsync() s on a per-process basis, or on the flip side, exempt some process from a global fsync-disable flag. This may be useful if there are some system daemons that really do want to wake up the hard drive and once the hard drive is spinning, naturally everything else that needs to pushed out to stable store should be immediately written.) With this relatively minor change to the kernel s support of laptop_mode, it should be possible to achieve the result that Nate desires, without needing force applications to worry about this issue; applications should be able to just simply use fsync() without fear. Summary As we ve seen, the reasons most people think fsync() should be avoided really don t hold water. The fsync() call really is your friend, and it s really not the villain that some have made it out to be. If used intelligently, it can provide your application with a portable way of assuring that your data has been safely written to stable store, without causing a user-visible latency in your application. The problem is getting people to not fear fsync(), understand fsync(), and then learning the techniques to use fsync() optimally. So just as there has been a Don t fear the penguin campaign, maybe we also need to have a Don t fear the fsync() campaign. All we need is a friendly mascot and logo for a Don t fear the fsync() campaign. Anybody want to propose an image? We can make some T-shirts, mugs, bumper stickers Related posts (automatically generated):

1. Delayed allocation and the zero-length file problem A recent Ubuntu bug has gotten slashdotted, and has started...

On off the biggest problems with developing servlets under a container like Tomcat is the amount of time taken to build your code, deploy it to the container and restart it to pick up any changes. Maven and the Jetty plugin allow you to cut down on this cycle considerably. The first step is to allow you to start your application in maven by running:

mvn jetty:run

We do this by configuring the jetty plugin inside our pom.xml:

<plugin>
   <groupId>org.mortbay.jetty</groupId>
   <artifactId>maven-jetty-plugin</artifactId>
   <version>6.1.10</version>
</plugin>

Now when you run mvn jetty:run your application will start up. But we can improve on this. The Jetty plugin can be configured to scan your project every so often and rebuild it and reload it if anything changes. We do this by changing our pom.xml to read:

<plugin>
   <groupId>org.mortbay.jetty</groupId>
   <artifactId>maven-jetty-plugin</artifactId>
   <version>6.1.10</version>
   <configuration>
      <scanIntervalSeconds>10</scanIntervalSeconds>
   </configuration>
</plugin>

Now when you save a file in your IDE, by the time you've switched to your web browser, Jetty is already running your updated code. Your development cycle is almost up to the same speed as Perl or PHP. You can find more information at the plugin page.

For some time ago I ve been pondering about this question. As long as GSoC 2009 is about to start and people are looking for project ideas, I m posting here a very preliminar draft of my findings and an idea for a posible software project. It s pretty written on-the-fly while I ve managed to have some minutes between work and uni. Rigurous wording isn t P1. Debian s social contract 4th item states:

Our priorities are our users and free software We will be guided by the needs of our users and the free software community. We will place their interests first in our priorities.

When we make decisions, either technical, legal and others regarding the operating system we deliver, this is one of the most referred argument. Altough that s seen as high priority often we don t have ways to properly know what our users want. While working on translations on the Spanish team we ve faced this situation. Do our users find them useful? they are able to understand them? they find that a much familiar wording would be bette than high technical details? We didn t know. Then, the question still exists. Altough Debian has ways for users to provide feedback (BTS, mailing lists, IRC, popcon, etc) none of them is designed to offer a way for the user to provide feedback on features, development roadmap and other non-bug aspects that developers and the project can tally and use for prioritize on releases. It s rather amusing to note that one of the most valuable assets free software community has is user involvement and contribution. But before we enter in details let s start on the basics. For using this information we first need to know who our users are? do we? From my findings and interaction with the community I ve identified two kinds of Debian users who can be clearly named. 1) The derivatives or pure blends, who use the Debian base and framework to build niche distributions. 2) The lead users (using E. Von Hippel s definition), who are the developers, contributors and a group of users. Debian is, if not the only, one of the projects who is best for fostering lead users. Most of them at some point involve themselves in the development process and some, later become developers. There is a more diverse group who are end-users but it s unclear to me how we can group them. Despite that they probably represent the biggest part of the pie. So, how we do please everyone? can we? In my opinion we can, at some degree. By implementing tools for first: gather user feedback, make statistical data, tally, we later can take informed decisions. In Debian decisions are voted and the set of people who votes are only developers with their own constraints. I think this would ease the constant that release-decisions-regarding-foo-tech-legal-issue represented on each release iteration, saving time, health and bits. It could be useful for knowing more about who are the ones we develop things for. I m thinking of some sort of Dell s IdeaStorm.com for software. What do you think? I m willing to co-mentor this if someone finds that is an interesting project for GSoC. Let me know!.