I spent the day working with Daniel. He has been trying to get the correct runes for a GCC build in a strange environment. Turns out all he needed was me to throw stupid ideas at him until one caused him to examine some of the generated intermediate symbol maps...

I don't know if anyone else has been tracking this recently, but a while back I got curious about the relative proportions of dh(1) and CDBS in the archive, and started running some daily analysis on the Lintian lab. Apologies for my poor graphing abilities, but the graph is here (occasionally updated): Although dh is still a bit behind CDBS, the steady upward trend is quite striking - it looks set to break 20% soon, up from under 13% in September - compared with CDBS which has been sitting within half a percentage point of 25% the whole time. Incidentally, was that an ftpmaster trying to sign his name in the graph over Christmas or something? :-)

Nathanael Boehm wrote a nice essay last month called The Future of Employment?, about a disconnect between workers' and employers' views of social networks. (This post is based partly on my comment in the ensuing Hacker News thread.) Boehm wrote:

When I need help with a challenge at work or need to run some ideas past people I don t turn to my co-workers, I look to my network of colleagues beyond the walls of my workplace. Whilst my co-workers might be competent at their job they can t hope to compete with the hundreds of people I have access to through my social networks...

The late Sun Microsystems taught us that the network is the computer. It's true: we still use non-networked computers for specialized tasks, but nobody wants one on their desk it's just so useless compared to one that talks to the entire world. Boehm could have titled his essay The Network is the Employee. There are still tasks that people do in isolation, but the ability to contact a network of peers and experts makes the difference in my job, and many others. Alone together The lone computer programmer in a small business has thousands of colleagues on Stack Overflow, Reddit, and so on. It's a chaotic and messy way to find answers, but it's better than the days when your only choice was to call tech support or smack the box with your fist, whichever seemed more useful. I can't begin to list all the problems I've solved and things I've learned by Googling for others with relevant experiences, and getting help from a different expert for every problem. Decades before the web, computer geeks had virtual communities for on mailing lists, Usenet, and IRC. Now any job in the world has an online forum. Even the night clerk at the gas station has Not Always Right. Teaching has long been a solitary profession. Despite working in a crowded classroom, teachers are isolated; they rarely have colleagues observing or participating directly in their work. This has such an impact that teacher education sometimes includes training in meditation or reflection, to compensate for lack of external feedback. So I'm really curious what happens when teachers start to work together remotely the way programmers do. You will be assimilated Boehm's essay reminded me of a vague sci-fi-like idea I've been kicking around: the first group minds will evolve from the intersection of Mechanical Turk, virtual assistants, social networking, and augmented reality. Starting around the 1990s, it was possible to instantly "know" any fact that was published online. Since then, we've increased the amount of content online, our tools for searching it, and ways of connecting to the network. Today we have instant access to almost any published knowledge, anywhere. The number of people on the net has grown too, and the number of ways to find and talk to them. Most of us can contact dozens of friends at any given moment, plus friends-of-friends, co-workers, fellow members of communites like Hacker News or MetaFilter, and also complete strangers. Along with raw facts, we now have access to vast amounts of human judgement, experience, and skill. One result of this is the "virtual assistant," who provides a service that was once available only to high-powered executives. The new personal assistant can work remotely (often overseas), spread costs by serving many masters, and leverage the internet superpowers listed above. Today their services are targeted at small business owners and the Tim Ferriss crowd, but I'm sure someone soon will start marketing virtual personal assistance to all sorts of other creative workers, teachers, even stay-at-home parents. So, how long before I can simply touch a button to let a remote assistant see what I'm seeing in real-time and help me make transportation plans, translate foreign signs and speech, look up emails related to whatever I'm doing or thinking, or even advise me on what to say? Some of these queries will go to my circle of friends, others to the general public, and some to a personal assistant who is paid well to keep up with my specific needs. And that assistant of course will sub-contract out portions of each job as needed to computer programs, legions of cheap anonymous Turkers, or to his or her own network of assistants. At that point, I'm augmenting my own perception, memory, and judgement with a whole network of brains that I carry around ready to engage with any situation I meet. If nothing else, I hope someone writes a good sci-fi thriller story in which a rogue virtual assistant subtly manipulates the actions of unknowing clients, leading them to some unseen end.

Update March 1st, 24 UTC: Reynaldo Verdejo is ok, the list is complete! Update March 1st, 16 UTC: Alejandro Vald s, Fabi n Arias, Carlos R os Vera and Germ n P o-Caama o have been in contact with others in Chile. Probably by now some of you know or are worried about the situation in Chile. I m not chilean nor in Chile but I ve been following closely due to the considerable number of good friends I have there, most of them related to GNOME.
From The Big Picture (AP Photo/Roberto Candia) Juan Carlos Inostroza (blog down) suggested I publish the list of GNOME/Free Software people in Chile that has reported since the earthquake and are fine, here it goes: Known, found and good:

• Andrea Orellana Palma
• lvaro Olivares
• Alejandro Vald s (updated 20100301 @16 UTC, via Felipe Besoa n)
• Adrien Bustany (updated 20100301 @16 UTC, via pvanhoof)
• Cristian Barahona G.
• Carlos R os Vera (updated 20100301 @16 UTC, via his sister on fb)
• Fernando Ruiz Altamirano
• Joo Anfossi Mardones
• Jorge Bustos
• Juan Carlos Inostroza
• Fabio Dur n
• Fabi n Arias (updated 20100301 @16 UTC, via Andrea Orellana)
• Felipe Andres Besoa n Pino
• Fernando San Mart n Woerner
• Germ n P o-Caama o (updated 20100301 @16 UTC, via Pablo Estef )
• Mario Gonz les
• Miguel Angel Ruiz Manzano
• Pablo Estef
• Pedro Villavicencio Garrido
• Ricardo Fuentes
• Reynaldo Verdejo (updated 20100301 @24 UTC, via Claudio Saavedra, Juan Carlos Inostroza)
• Sven von Brand
• Sebasti n Lara

Not know, nor found, we presume good but without cellphones:

• None

If you have been in contact with any of them, leave a comment, send a DM in twitter (@diegoe) and etc. List is not complete, I probably forgot someone, please remind me. Will update if I get news from anyone.

This post is about an upcoming feature in Zeitgeist 0.3.3 and is so far only available in checkouts from trunk or our PPA. It is expected to be released within the next weeks. Some weeks ago I implemented a new feature in Zeitgeist and I figured I d drop some lines about it. I m talking about a data-source registry. You may be wondering, what the hell is that even, a data-source? . So Zeitgeist is a database, a global event log, but it doesn t do any magic indexing or monitoring by itself; the information it logs needs to come from somewhere be it applications sending it to Zeitgeist themselves, daemons, plugins for applications, etc. Any such entity is called a data-source . Having a register of all data-sources interacting with Zeitgeist provides some benefits, like for example:

• Having a list of them. Lists are nice :).
• Being able to disable data-sources from a centralized place instead of requiring each to write its own preferences dialogue.
• Being able to set up a blacklist rule considering which data-source the information comes from as a condition (not implemented yet).

More details When they register, data-sources will need to provide the following information: an unique ID, a name (may be localized), a description (may be localized) and optionally a template specifying what sort of events it logs. Additionally, the last timestamp the data-source was seen by Zeitgeist, whether it is running right now and whether it is enabled will also be available. It is important to note that registration is not compulsory; while it is highly encouraged for data-sources to use it, is it still possible to anonymously insert information into Zeitgeist (for example from a shell script). The event template is also only informational, and will not be enforced by Zeitgeist at this time. Avoiding duplicates from GTK Recently Used You may know that zeitgeist-datahub provides basic support for applications which have no direct Zeitgeist support but do use GTK s RecentManager, which is not as detailed as we would like, but it is better than nothing. However, until now we had a problem: when applications had support for both, GTK s Recently Used and Zeitgeist (be it native or as an extension), it was possible for duplicate events to be inserted or other sorts of conflicts between both data-sources. Now that we have the information from the registry available, we ve been able to solve this modifying our Recently Used data-source to ignore any events concerning applications which already have another data-source logging the same types of events.

---

In case you don t care at all about what I m talking here and you just want to see fancy interfaces, go check this out. Related posts:

1. Zeitgeist is out!
2. Introduction to Zeitgeist 0.2 s API
3. Zeitgeist Hackfest (II)

---

No comments
Siegfried-Angel Gevatter Pujals, 2010. Permalink License Post tags: gnome, Programari lliure, zeitgeist

DebConf 11 will be held in Banja Luka, Bosnia and Herzegovina. Munich, Germany arrived on a close second and our bid, Quito, Ecuador, arrived last, allegedly because some points flipped over since DC 11 was meant to happen in Europe. So, after having three DebConfs hosted in America in the last four years, DebConf 11 will travel to Europe in 2011! Good news for all our fellow DDs and contributors over there. The Banja Luka team managed to get an important support from their Government. They even met with the Prime Minister and got him to sign an offer of full support. I think this becomes dangerous for a DebConf, given that I ve worked and have had mishaps while funding conferences with at least three governments (Ecuador, Venezuela and Brazil) with stronger levels of support (Law-like level) for free software and I know that at least other two governments in the World have unfortunately done this in the past. So we need backup plans and lots of follow-up activities with the stakeholders. However, this agreement sets an important milestone in government support for free and open source software as well as Debian. I ll use it in my Debian slides, and congratulations! IMO, Munich would have made a great host for DC11 in terms of air travel connectivity, at a bigger hit on local costs, but nothing that would differ that much from DC7, though! I don t think I ll be able to make it at this moment to Bosnia (struggling for NYC) and at this point it s premature to think on supporting Quito s again for DC12. People and sponsors get gradually tired, even with spiritual commitment. The DC10 decision meeting was long and lots of things needed to be improved. At that moment I thought the Project learnt useful lessons for future meetings, but we re repeating ourselves now on the DC11 decision meeting. And now, I m just hoping for the best, for the sake of the time and sanity of all us here. Ditch the priority list altogether, increase the stakeholders on the global team, filter bids early in the process and use more technology to improve the information flow before the decision!

Debconf11 This evening, the final decision on which city will host Debconf11 next year will be taken. For the last half year, mostly Andreas Barth, Jan-Marek Glogowski and I have been working hard to make the Munich bid as good as possible. One thing we wanted to make clear from the beginning was that we would go for a conference in the city center - not some conference center in some nearby village or in an industrial area far away from where the city life happens. It was not easy, since the german-wide decision, we had to reshuffle venue plans a couple of times. In the end, thanks to Jan-Marek, we managed to get an excellent venue offer. Our bid consits mostly of:

• Venue: Computer Science building (recently built) of Munich University for Applied Science, we can get as much as we need, for free. The only thing we would have to pay for is additional security personell during the night.
• Network: Leibniz Rechenzentrum is the operator of the Munich Research Network (MWN), the venue is connected with at least 1 GBits fibre optics, and the MWN is connected to X-Win at the same speed. This will be free as well.
• Food: We can either take up the offer from the Studentenwerk, the organisation operating the university restaurants. Of course, the quality is not like in a Michelin-star restaurant, but I have eaten there for several years during my studies and it is on par with previous Debconf offerings. Alternatively, we could look into food catering.
• Accomodation: We tend to go for hostels, similar to Edinburgh, probably 4-6 bed dorms. Munich is pretty expensive for lodging, so this is something we decided early on to keep the costs reasonable. Again, I think this is in line with previous Debconfs. Of course, hotels at a broad price range are available.

The biggest strong points about Munich are, in my opintion:

• Our local team has lots of experience with Debian and Debconfs, as well as organizing conferences
• We have government support via the LiMux-project, and the city mayor of Munich, Christian Ude, has agreed to be the patron of the conference
• Munich is very easy to get to, both for european (via train or car) or american/asian attendees (via plane). The airport is one of the biggest in europe and has direct connections to e.g. Atlanta, New York, Boston, San Fransisco, Los Angeles, Sao Paulo and Tokio.
• Network connection via LRZ/MWN/X-WIN should be superb, especially to Debian machines hosted at euro

It the end, it seems Banja Luka seems to have the stronger bid, especially due to their 150000 EUR governemnt sponsorship. We will see who wins, I believe we did the best we could.

With 9cdcabb0a7f7a38b8cd2292a48a98eb4eb5e458d, we are one step closer to having Lua dpkg bindings in the archive.

Until two years or so ago I used VMware Workstation intensively for development and testing of Debian Installer, using one of the licenses generously made available to the D-I team by VMware. It was much faster than Qemu and thus very welcome. But due to increasing problems keeping it working with new kernels on a desktop system running unstable, I switched to VirtualBox (the OSE version), which has the huge advantage of being packaged for Debian and thus automatically follows the Debian kernel packages. That advantage has disappeared somewhat as I'm currently compiling my own kernels I'm currently running 2.6.33 on a Lenny desktop. So far I've been able without too much trouble to find patches for the VirtualBox modules to keep them compatible with new upstream kernels. This week I had reason to try VMware again. The Server edition this time as that has free licenses. The Server concept, where you connect to the management system and virtual machines via a web browser, is quite nice. It means I could install it on a server and keep my laptop nice and responsive. To keep VMware separate from the rest of the system and not mix it with software installed cleanly from Debian packages, I decided to install it in /opt. And that works beautifully. There are only a few bits installed in /etc, but that's OK. I have /etc managed by etckeeper anyway [1]. More challenging was building WMware modules to match my kernel. VMware wants you to run their vmware-config.pl script every time you switch kernels and build the kernel modules on the system where it runs (which requires the kernel headers). I wanted to build the modules as part of my kernel build process, on a totally different machine. The same as I already do for VirtualBox. I save the custom modules in a tarball that has the same uname and package version as the kernel package I build and have a simple script that installs them correctly. I succeeded by hacking the Makefiles (deleting most of their content) and then integrating them in my kernel build wrapper script. The module source provided by VMware built fine with a Debian 2.6.26 kernel, but not with the 2.6.32.9 kernel on my server (of course). But luckily others had already run into the same problems and solved them, so with some searching I found the required patches (first a full updated source for 2.6.29, then patches needed for .31 and for .32). Isn't open source just wonderful? So with that the VMware server started beautifully (well, the init script needed to be told that module names have changed from *.o to *.ko), but I could not connect to it from my laptop using SSL. Connecting without SSL (using an instance of iceweasel running on the server but started remotely from my laptop using X forwarding SSH) worked fine. That turned out to be a known issue too. After applying all the suggested workarounds in my iceweasel configuration (disable TLS 1.0; set cache size to zero; explicitly disable use of proxy for the server) I can now connect reliably to the VMware Server management system. Phew. [1] I had to exclude a fair number of VMware files for etckeeper as they are updated by VMware itself and thus really belong in /var. Example are DCHP status files...

The most common criticism of the Anti-Counterfeiting Trade Agreement (ACTA) is the lack of transparency. Before the nations disclose the terms of the agreement under negotiation, we are unable to gain an idea of the big picture, let alone voice our opinions and push for changes. Our politicians don t want us to know. We rely on leaked documents for our information. This is backwards in a world where a state should represent its people. This smells foul to me. There are undoubtedly some good reasons for the treaty, and if we can contain worldwide, large-scale trade of counterfeited goods and medicine, then that would be a net benefit to us all. However, we must not allow certain governments to succomb to the pressure of (commercially-motivated) lobbyists, to extend that pressure onto other nations using trade as a means of pressure, and to slash our freedom as if it were an inconvenient obstacle in their way. Only if the terms under negotiation become publicly available, and the public is given a voice, then we can help our governments in entering an agreement that is in the interest of its people, rather than a threat to us. It is hardly surprising that total capitalist nation USA are the strongest opponents of transparency, because the public might delay or even prevent the treaty. I was also not surprised to see South Korea and Germany in the list of supporters of secrecy either. It is interesting to see that the leaders of Singapore, Belgium, Portugal, and Denmark also seem to believe that these negotiations should be withheld from the public. Does anyone know about Switzerland? I tip my hat to New Zealand, Canada, Australia, Netherlands, Sweden, Finland, Ireland, Hungary, Poland, Estonia, and Austria for their support of transparency.

After a whole bunch of drastic changes, lots of bugfixes, rewriting and refactoring, I released DAViCal 0.9.8 on Christmas day last year. I didn't release it very publicly, because I knew it sucked significantly. In an increasingly fast turnaround I've subsequently released 0.9.8.1 to a somewhat wider audience while I was at the recent Calendaring and Scheduling Consortium meeting in Costa Mesa at the beginning of the month. Earlier this week I released 0.9.8.2 to the more interested of the DAViCal userbase. So finally, yesterday, I released DAViCal 0.9.8.3 to fix the few significant problems that were left with that, and this is the release that I'm telling everyone about, because I believe it should be a good stable platform to people who want to upgrade their production DAViCal servers, or who have been hanging back from using DAViCal until the platform was a little more stable.
<!--break-->
This release marks some significant departures from previous DAViCal. I've decided to walk away from some of the more ancient legacy software I tried to work with in the past (PHP4 & PostgreSQL 7.x), to move to support the most ancient-but-not-superseded legacy Linux release I know of, which is CentOS / RHEL, so DAViCal now has a minimum requirement of PHP 5.1 & PostgreSQL 8.1. The biggest changes to DAViCal are under the covers. It is server software, after all, so the largest changes often are not visible on the surface. What has changed is that the architecture for constructing responses as been refactored into a core object which is used to access any DAV resource in the system. This greatly simplifies the general coding and reduces a fair bit of code duplication which had been happening. Another long overdue change is to get rid of the old arcane & obtuse permissions model, replacing it with something which will be radically faster in installations with more than a few hundred users, as well as being more consistent, easier for people to control, and directly in alignment with the DAV ACL specification. Some of the work here was assisted by NZ Registry Services who gave me a Macbook to help with my compatibility testing. Not all of the changes are under the covers though. The new DAViCal also has a thoroughly revised administrative interface, and over the last couple of releases I've gone through the system trying to uncover all the places which were not properly localisable, too, so if you see DAViCal displaying strings in a language you didn't configure it for, it should be a fixable thing. I'd like to particularly thank Masahiro Mikami for turning around some Japanese translations very quickly which enabled me to quickly and visually see what was not properly translatable. There's still more work to do (there's always more work to do) but a fully translated DAViCal should, I hope, be quite usable by non-English speakers now. The new DAViCal also supports some rather significant extra functionality beyond the CalDAV standard, in particular we can thank Rob 'Cave' Ostensen for providing an implementation of pub/sub event change notifications. This version also supports draft 2 of the proposed WebDAV synchronisation standard - that's still under development, but we expect to track pretty close to released versions of that. Of course with all of this work there are some areas that didn't get changed. I didn't manage to finish an implementation of the scheduling extensions draft, much as I would have liked, but that is going to become very much a focus in the coming couple of months, and I'll be calling it "1.0" when things settle down after we get that done. Other things I will be working on include a ticketing system for providing targeted, controlled access to a specific collection or event, and making a start on CardDAV support for addressbook storage. DAViCal seems to be fitting a need for people, and I know there are several thousand installations around the world, even if I'm not sure where they all are. I know some people are running DAViCal on their 8-way server, where I've no doubt it gurgles along pretty happily, and that there are some people running it on their OpenWRT installation, with some tiny amount of resources - just enough for a family calendar. Traffic on the wiki has increased to several hundred thousand hits per month, perhaps three times what it was a year ago, and I hope that I can continue to provide a valuable and useful piece of infrastructure for that little calendaring corner of your organisation. What heartens me the most in this ongoing experience is the nascent community that appears to be forming around my software, with people writing 'tip sheets' and helping to answer questions on the IRC channel and mailing list. These small contributions made by many people - people whom I have never met, for the most part - are enabling me to put more time into feature development and expansion, and that's what I really love.

Christian Robert blogged about a particularly heavy-handed solution to last Sunday's Sudoku puzzle in Le Monde. That had my symapthy as I like evolutionary computing methods, and his chart is rather pretty. From there, this spread on to the REvolutions blogs where David Smith riffed on it, and showed the acual puzzle. That didn't stop things as Christian blogged once more about it, this time welcoming his post-doc Robin Ryder who posts a heavy analysis on all this that is a little much for me at this time of day. But what everybody seems to be forgetting is that R has had a Sudoku solver for years, thanks to the sudoku package by David Brahm and Greg Snow which was first posted four years ago. What comes around, goes around. With that, and about one minute of Emacs editing to get the Le Monde puzzle into the required ascii-art form, all we need to do is this:

R> library(sudoku)
R> s <- readSudoku("/tmp/sudoku.txt")
R> s
      [,1] [,2] [,3] [,4] [,5] [,6] [,7] [,8] [,9]
 [1,]    8    0    0    0    0    1    2    0    0
 [2,]    0    7    5    0    0    0    0    0    0
 [3,]    0    0    0    0    5    0    0    6    4
 [4,]    0    0    7    0    0    0    0    0    6
 [5,]    9    0    0    7    0    0    0    0    0
 [6,]    5    2    0    0    0    9    0    4    7
 [7,]    2    3    1    0    0    0    0    0    0
 [8,]    0    0    6    0    2    0    1    0    9
 [9,]    0    0    0    0    0    0    0    0    0
R> system.time(solveSudoku(s))
      [,1] [,2] [,3] [,4] [,5] [,6] [,7] [,8] [,9]
 [1,]    8    4    9    6    7    1    2    5    3
 [2,]    6    7    5    2    4    3    9    1    8
 [3,]    3    1    2    9    5    8    7    6    4
 [4,]    1    8    7    4    3    2    5    9    6
 [5,]    9    6    4    7    8    5    3    2    1
 [6,]    5    2    3    1    6    9    8    4    7
 [7,]    2    3    1    8    9    4    6    7    5
 [8,]    4    5    6    3    2    7    1    8    9
 [9,]    7    9    8    5    1    6    4    3    2
   user  system elapsed
  5.288   0.004   5.951
R>

That took all of five seconds while my computer was also compiling a particularly resource-hungry C++ package.... Just in case we needed another illustration that it is hard to navigate the riches and wonders that is CRAN...

In the past, several of my Puppet modules have been tightly coupled. A perfect example is Apache and Munin. When I install Apache, I want munin graphs set up. As a result my apache class has the following snippet in it:

munin::plugin   "apache_accesses":  
munin::plugin   "apache_processes":  
munin::plugin   "apache_volume":  

This should make sure that these three plugins are installed and that munin-node is restarted to pick them up. The define was implemented like this:

define munin::plugin (
      $enable = true,
      $plugin_name = false,
      )  
   include munin::node
   file   "/etc/munin/plugins/$name":
      ensure => $enable ?  
         true => $plugin_name ?  
            false => "/usr/share/munin/plugins/$name",
            default => "/usr/share/munin/plugins/$plugin_name"
          ,
         default => absent
       ,
      links => manage,
      require => Package["munin-node"],
      notify => Service["munin-node"],
    
 

(Note: this is a slight simplification of the define). As you can see, the define includes munin::node, as it needs the definition of the munin-node service and package. As a result of this, installing Apache drags in munin-node on your server too. It would be much nicer if the apache class only installed the munin plugins if you also install munin on the server. It turns out that is is possible, using virtual resources. Virtual resources allow you to define resources in one place, but not make them happen unless you realise them. Using this, we can make the file resource in the munin::plugin virtual and realise it in our munin::node class. Our new munin::plugin looks like:

define munin::plugin (
      $enable = true,
      $plugin_name = false,
      )  
   # removed "include munin::node"
   # Added @ in front of the resource to declare it as virtual
   @file   "/etc/munin/plugins/$name":
      ensure => $enable ?  
         true => $plugin_name ?  
            false => "/usr/share/munin/plugins/$name",
            default => "/usr/share/munin/plugins/$plugin_name"
          ,
         default => absent
       ,
      links => manage,
      require => Package["munin-node"],
      notify => Service["munin-node"],
      tag => munin-plugin,
    
 

We add the following line to our munin::node class:

File<  tag == munin-plugin  >

The odd syntax in the munin::node class realises all the virtual resources that match the filter, in this case, any that is tagged munin-plugin. We've had to define this tag ourself, as the auto-generated tags don't seem to work. You'll also notice that we've removed the munin::node include from the munin::plugin define, which means that we no longer install munin-node just by using the plugin define. I've used a similar technique for logcheck, so additional rules are not installed unless I've installed logcheck. I'm sure there are several other places where I can use it to reduce such tight coupling between classes.

Canada responds to historic Olympic hockey game loss to US: (source)

Past Sins Sam Varghese wrote an article about Matthew Garrett s LCA talk The Linux community: what is it and how to be a part of it [1]. In page 2 Sam quotes Martin Krafft as asking about how Matthew s behavior had changed between 2004 and the present, Sam cites some references for Matthew s actions in 2005 to demonstrate. I think that this raises the issue of how far back it is reasonable to go in search of evidence of past behavior, something that I think is far more important than the specific details of what Matthew said on mailing lists many years ago and whether he now regrets such email. If someone did something that you consider to be wrong yesterday and did the same thing five years ago you might consider it to be evidence of a pattern of behavior. If someone s statements today don t match their actions yesterday then you should consider it to be evidence of hypocrisy. But if someone did something five years ago which doesn t match their current statements then in many situations it seems more reasonable to consider it as evidence that they have changed their mind. Then of course there is the significance of what was done. Flaming some people excessively on some mailing lists is something that can be easily forgiven and forgotten if Google doesn t keep bringing it up. But as a counter-example I don t think that Hans Reiser will be welcome in any part of the Linux community when he gets out of jail. For the development of the Linux community (and society in general) I think it s best to not tie people to their past minor mistakes. While it is nice when someone apologises for their past actions, the practical benefits of someone just quietly improving their behavior are almost identical. A particular corner case in this regard is the actions of young people, anyone who was born after about 1980 will have had great access to electronic media for their entire life and will have left a trail. Most people do a variety of silly things when they were young, the older members of the Linux community were fortunate enough not to have electronic records remaining where Google could find them. Back to Matthew, I think that if he is to be criticised about such things then evidence that is much more recent than 2005 needs to be used. Cultural Differences Sam quotes Matthew as claiming that the Linux community was largely a Western, English-speaking one, those who participated in it necessarily had to adapt to the norms of this group . I don t believe that there is a single Linux community. There are a number of different communities that are formed around free software, which have significant amounts of overlap. I don t believe that there s any reason why a Chinese or Indian Linux mailing list should conform to the same standards as those of an American list. But there will be a trend towards meme propagation through people who are associated with the Linux communities in multiple countries every time you meet Linux people in another country you are helping to reduce the cultural differences in the Linux community. Someone from China or India who joins a LUG in Australia will have to adapt to some of the norms of Australian behavior in the same way as an Australian who migrates to China or India would have to adapt to some local norms. On page 4 of the discussion Matthew disagrees with Sam s interpretation [2], maybe Matthew s opinions on this matter are closer to mine than the way Sam describes them. Is Division Inherently Bad? I believe that the word divisive is overused. The only way to avoid division is to have everyone agree with the majority, but sometimes the minority will be right. Note that I am using the word minority to refer to any group of people who happen to disagree with the majority, among other things that includes people who vote for a political party that isn t one of the two biggest ones. An entirely separate issue is that of the treatment of minority groups , one of the most divisive events in history was the US civil war it s good that slavery is outlawed but unfortunate that a war was required to gain that result. On page 4 of the discussion Matthew says to Sam Your writing is influenced by members of the Linux community, and in turn it influences the Linux community. The tone of it is entirely relevant to the behavioural standards of the community [2]. If a community can be easily divided then the real problem probably isn t the person who triggered a particular division. Also there is the issue that even if you could get a general agreement that certain issues shouldn t be discussed in certain ways then with the wide range of cultural attitudes and ages of participants you have to expect someone to raise the issue you don t want raised. Of course it s impossible to objectively determine whether a division is productive or not, so it doesn t seem at all viable to have any expectations regarding outsiders not being divisive. Sometimes you just have to deal with the fact that the Internet contains people who disagree with you. It seems to me that the most divisive issues we face involve people who mostly agree on contentious issues. If someone entirely disagrees with you then it s easy to ignore them (if you even have a conversation with them), but if they are someone that you communicate with and they are almost right in your opinion then there s the potential for a big argument. Probably the best way to minimise division in the community is to have the first people who get involved in a dispute take a Rogerian approach [3]. Failing that a good approach is to respond by writing an essay. When an issue is made popular by services such as Twitter that give little explanation then everyone rushes to the barricades. It seems to me that the unreliability of some blogging platforms is part of the cause of the problem in this regard. I ve just given up on writing comments on Blogger, I m not going to write a good comment only to have it eaten by blogger. There are lots of blogs that have problems which discourage the population from writing anything other than a one-sentence response. The Good that can come from Disputes On page 5 of the discussion there is a comment from Anirudh the Indian student who was criticised by Sam (which ended up inspiring part of Matthew s talk and leading to more disputes) [4]. Here is the start: I am the person who wrote the ill thought-out post that drew criticism eight months ago. There has been some discussion about that, so I wish to say something.

I am very grateful to Sam Varghese. I say this with utmost sincerity. Read the rest, it s educational. I m sure that there are others who have had similar learning experiences but who don t want to write about them. I m sure that there have been many disputes which would appear to the casual observer to have resulted in no good at all, but which would actually have resulted in people learning things and amending their behavior. The issue of Age Car rental companies generally don t do business with men who are less than 25 years old. Life insurance policies don t offer reasonable rates to males between the ages of about 16 and 25. This is because the insurance companies have good statistical data on the results of the typical actions of people at various ages and know that young men tend to be at a high risk of earning a Darwin Award. The same combination of hormones and life experience that makes a young man a danger on the road will also tend to make him get involved in flame-wars on the net. If we could figure out how to influence teenagers into being less anti-social then it would be a great achievement. The current young people will become older and more sensible soon enough but will be replaced by a larger number of young people who will do the same things. As things stand I don t expect the next cohort of young people to learn from Anirudh.

• [1] http://www.itwire.com/opinion-and-analysis/open-sauce/36850
• [2] http://discuss.itwire.com/viewtopic.php?f=8&t=18319&start=28
• [3] http://en.wikipedia.org/wiki/Rogerian_argument
• [4] http://discuss.itwire.com/viewtopic.php?f=8&t=18319&start=28

RCBW - #22 With a mini-rush in the week-end, I'm now back on track to the weekly schedule of RCBW; here are this week's squashes:

• bug #565274 - tex4ht - test and close bug fixed by recent binNMU
• bug #553553 - phpsysinfo - fix dir-or-file-in-var-www, based on a patch by Mats Erik Andersson
• bug #553496 - doc-central - fix dir-or-file-in-var-www, sponsor NMU by Mats Erik Andersson
• bug #559821 - libtunepimp - fix libltdl CVE (bonus fix bug #476378), patches by Yavor Doganov
• bug #568982 - sqldeveloper-package - port from dos2unix to fromdos, patch by Michael Musenbrock
• bug #534721 - libhpricot-ruby1.8 - error in printing tags to stdout (fixed upstream in a version already in Debian)
• bug #564680 - gnugk - rebuild against firebird 2.1, as requested by Damyan Ivanov (important bug blocking RC bug #549062)

About this week highlights:

• In his latest RC-bug statistics, Tolimar has pointed to the RCBW description as inspiring. That's good, I hope more and more people can find it inspiring (in fact, that's why I wrote it). A handful of people doing RCBW is pointless, unless as a side-effect we manage to change the culture of our project in order to be more collaborative on how we reach a release.
• I've been amazed by how many RC bugs are "stuck" just because no one took care of establishing communication among the appropriate people. That of course happens when the maintainer of the bug has been unresponsive, but some investigations of the bug is usually enough to make the appropriate people (upstream, porters, related package maintainers, ...) aware of it ... and then the bug will "mature" all alone.
• Josselin has announced the Debian/GNOME bug weekend for the next weekend (27-28/02/2010): an initiative to collaboratively triage GNOME-related bugs in Debian. For large-enough packages (and GNOME fits that definition for quite some different notions of "large"), such efforts are as badly needed as RC squashing: if you liked RCBW, you can't miss the GNOME bug weekend

Martin Krafft advocates a model of Internet access where advertisers pay for the Internet connection [1]. The first problem with this idea is the base cost of providing net access which in most cases is wires to the premises. Every service that involves a cable to someone s house (Cable TV, Cable/DSL net access, or phone service) has a base minimum monthly fee associated with the expense of installing and maintaining the cable and whatever hardware is at the other end of the cable. For DSL and basic phone service the pair of wires ends at an exchange and takes a share of the DSLAM or a telephone exchange. It seems that the minimum monthly cost for any wire that goes to the house in Australia is about $20. So if an advertiser makes $0.20 per click (which I believe to be higher than the average price for Google Adsense clicks) then the user would have to be clicking on adverts more than 3 times a day. This might be viable if an ISP runs a proxy that inserts adverts into all content (which technically shouldn t be that difficult). But modifying content in-transit to introduce adverts is something that the net-discrimination crowd can only dream about. 3G net access has the lowest per-user costs. Based on current data costs it seems possible for an ISP to run a 3G service with bills for users as low as $15 per annum if they don t transfer much data. Recouping $15 might be easy but it s also a small enough amount of money that most users won t mind paying it. What we really need is to have more competition in the 3G ISP business. When I investigated this issue last month I found that there are few 3G Internet providers in Australia and the cheapest is Dodo at $139 per annum with a 15G limit [2]. With a bit more competition I m sure that someone would offer a really cheap plan for 1G or 2G of data access in a year. Martin complains about users paying twice as users pay to access the network (which is like paying a taxi to get to the market), so that they can visit sites where advertisers make money showing ads to the visitor . But if the advertisers were to pay then there would be a lot of inefficiency in determining how much each advertiser should pay which would result in extra expenses and therefore providing the service would cost more. I don t think that paying for a taxi to get to the market is a bad thing, personally I prefer to save money and use a bus or tram. I think that the best analogy for this is comparing using your own choice of a bus, tram, taxi, etc to get to the market or having the market operator provide taxis for everyone and then make everything really expensive to cover the significant costs of doing so. Finally there is the issue of video transfer which uses up a lot of bandwidth. According to both industry rumor and traceroute there is a significant mirror of youtube content in Australia. This means that youtube downloads will be cheap local transfers not expensive international transfers. I expect that most multi-national CDNs have nodes in Australia. So for Australia at least video transfer would not be as expensive as many people expect. I think that to a large extent the concept of having content providers pay to host the content has been tried and found to fail. The Internet model of you pay for your net access, I pay for mine, and then we transfer data between our computers without limit has killed off all the closed services. Not only do I think that net-discrimination is a bad idea, I think that it would also turn out to be bad for business.

• [1] http://madduck.net/blog/2010.02.20:charge-advertisers-for-the-last-mile/
• [2] http://etbe.coker.com.au/2010/01/15/cheap-net-access-australia/

I don't talk about SPAM publicly these days, for reasons that are probably self-explanatory. However this is just insane:

• Saturday 20th February 2010: Registered a new domain.
• Sunday 21st February 2010: Received first spam.

Currently at 40+ SPAM mails and rising; all mails addressed to "postmaster@", rather than any past users of the domain. (I can see from http://archive.org that the domain was last active in 2008.) ObSubject: The Goonies

ISPs fight a raging war over net neutrality because their infrastructure cannot keep up with the increasing demand (or rather supply) of content. Therefore, ISPs want to charge the users premiums if they wish to use certain services on the Net. For instance, since videos are usually large in size, one would have to purchase e.g. the platinum package to be able to access video hosting sites. It would be a serious loss of freedom if they won, and the Internet would never be the same. Let s turn that idea around: since sites that use advertising make money off every visitor, they are really the ones that should pay the ISPs so that they can improve their infrastructure. The same applies to sites that make money off visitors in other ways. At the moment, users pay to access the network (which is like paying a taxi to get to the market), so that they can visit sites where advertisers make money showing ads to the visitor, which might actually let them to pay a manufacturer for a product the end user pays twice, and the advertisers take in money, leeching off the ISPs investing into their infrastructure. I think that the advertiser and not the consumer should pay the ISP to keep the infrastructure afloat improve it even. The manufacturer should then pay the advertisers for displaying the ad, and the user consumes if s/he chooses to and everyone only pays once, for services they want. This will help improve competition among providers, which should always be the goal. If my ISP would start to record the volume of HTTP traffic I produce for each target site, charge the targets appropriately (they could start with a couple at first), and I d get free connectivity in turn, I d be quite happy. The ISP wouldn t have to look at the contents at all for that. I don t yet know what to do if the target sites choose not to pay up. ISPs could block them, or throttle or deprioritise traffic, but either of those might simply lead to an exodus of users, just like premiums would. As usual, this just needs to be done by many ISPs in concert. Are you listening?

Note: Please see RC-Bug statistics for Squeeze, calendar week 7 for an explanation of the numbers.

Total:	699	+49
Affecting Squeeze:	559	+41
Squeeze-only:	117	+23
Unfixed bugs remaining in Squeeze:	442	+18

Of these 442 bugs...

... are pending	36	+4
... are patched:	65	+1
... are duplicates:	47	+-0
... are in Non-free or contrib:	10	+10
... are claimed by someone:	14	-3
... are fixed in the delayed queue:	5	-1
... are somehow marked as fixed:	53	+14

Or in other words:
Release critical bugs left in squeeze, when ignoring all these:
262 (+2 compared to previous week). With this release managers views, 472 (+48 compared to previous week) bugs remain to be fixed somehow before we can release. Some notes:

• Lucas Nussbaum did another archive wide rebuild of all packages to detect some FTBFS bugs. Apparently he found some, so the number increased ;)
• Stefano Zack Zacchiroli wrote some very interesting (or should I say inspiring?) notes about his RCBW initiative running under the motto let's fix one Debian RC bug per-day.
• To the best of my knowledge, the problems with the mips* machines haven't been solved yet. So we are still looking for mips* porters. Please see this small problem description as well as the mails on our mips mailing list.

So much for this week. Let's see, how the numbers evolve in the coming seven days...