If you re using Debian, you know that this distribution is built entirely by volunteers that form a very diverse community. And you could be part of it. But why should you do that? I can t tell for you but I can share my own experience. It s been 12 years since I joined Debian and I m going to tell you what keeps me on board. 1. Technical excellence When facing a new challenge, Debian will strive to do the right thing. This pays off in the long term. In many cases, it means that we will take more time to implement our solution compared to other distributions out there, but this is also the reason why our packaging infrastructure allows us to offer painless upgrades and consistency across all packages. Debian is committed to quality and builds up on his experience thanks to the Debian Policy. My time is precious, I like to spend it on something useful in the long term. 2. Inspiring goals In its social contract, Debian has set out to create a 100% free as in freedom operating system. The criteria defining what constitutes a free work are listed in the Debian Free Software Guidelines (DFSG). While the above is relatively ambitious in itself, it doesn t inspire me much. What makes the difference to me is the emphasis given by the social contract on our users and free software. We don t build a free operating system in the void, we build it for people. Debian s motto the universal operating system can also be interpreted in multiple ways: universal as in for everybody on the world , on all kinds of computers , or for every possible usage . 3. High impact work Knowing that my work is useful to people is important, but it s even better when I know that it will benefit to lots of people. With Ubuntu and the hundreds of other derivatives, there are nowadays literally millions of users impacted by my work. Even an insignificant one second improvement experienced by 10 millions of people represent 115 days of time saved for something else, you get the idea 4. Working with great people Debian has the chance to have lots of smart people on board. There s always someone sharing valuable advice when you read Debian s mailing lists. When I joined in 1998, I was a real newbie and I learned a lot of things by reading and interacting with people more knowledgeable than me. You can still experience the same thing nowadays but there s one caveat: you must cope with various kinds of mailing list contributors including the smart but uncivilized (don t be offended too quickly!) and the occasional troll (best ignore it, don t feed it!). 5. Recognition of work When you contribute to Debian, people get to know you through your contributions. It s very rewarding to be thanked by your peers and by Debian s users. Check out thanks.debian.net to convince you that many people are grateful for the work we put into Debian. So that s it for me. But what about you? What motivates you to contribute year after year, or to start contributing if you re a prospective contributor?

Subscribe to this blog (it s free!) by RSS, by email, or on Facebook.

21 comments Support my work

This essay is a summary of my presentation at the workshop Inlaws and Outlaws, held on August 19-20, 2010 in Split, Croatia. The workshop brought together advocates of piracy with participants in the free culture and free software movements.

In Why Software Should Not Have Owners, Richard Stallman explains that, if a friend asks you for a piece of software and the license of the software bars you from sharing, you will have to choose between being a bad friend or violating the license of the software. Stallman suggests that users will have to choose between the lesser of two evils and will choose to violate the license. He emphasizes that it's unfair to ask a user to make such a choice. Over the past few years, pirate parties have grown across much of the developed world. Of course, piracy remains the primary means of distributing media across most of the rest. Advocates of access to information have gathered and organized under the "pirate" banner, representing the choice of sharing with friends over compliance with license terms. The free/libre and open source software (FLOSS) and free culture movements seem to have a confused and conflicted reaction to all this. On one hand, major proponents of several pirate parties are FLOSS and free culture stalwarts and several pirate parties have made FLOSS advocacy a component of their political platforms. Pirate Parties' clear opposition to software patents and DRM resonates with both FLOSS and free culture communities. On the other hand, FLOSS leaders, including Stallman, have warned us about "pirate" anti-copyright policies. Free culture leaders, like Lawrence Lessig, have repeatedly and vociferously denounced piracy, treated even the intimation of an association with piracy as an affront, and systematically distanced themselves and their work from piracy. Should FLOSS and free culture advocates embrace pirates as comrades in arms or condemn them? Must we choose between being either with the pirates or against them? Our communities seem to have no clearly and consistently articulated consensus. I believe that, unintuitively, if you take a strong principled position in favor of information freedom and distinguish between principles and tactics, a more nuanced "middle ground" response to piracy is possible. In light of a principled belief that users should be able to share information, we can conclude there is nothing ethically wrong with piracy. Licenses have the power of the law but they are protected by unjust "intellectual property" laws. That said, principles are not the only reason activists choose to do things. Many political stunts are bad ideas not because they are wrong, but because they won't work and have negative side effects. Tactics matter too. Even though there might not be anything ethically wrong with piracy from the perspective of free software or free culture, it might still be a bad idea. There are at least three such tactical reasons that might motivate free software and culture to not support piracy or participate in pro-piracy movements and politics. First, a systematic disrespect for copyright undermines respect for all licenses which have been of a huge tactical benefit to free software and a increasingly important factor in the success of free culture. Copyleft licenses like the GPL or CC BY-SA have power only because copyright does. As Stallman has suggested, anti-copyright actions are anti-copyleft. That needn't be an argument against attempts to limit copyright. Indeed, I think we must limit and reduce copyright. But we must tread carefully. In the current copyright climate, I believe that copyleft offers a net advantage. Why should others respect our licenses if we don't respect theirs? Looking at the long term, we must weigh the benefits of promoting the systematic violation of proprietary licenses with the benefits of adherence to free software and free culture. Second, piracy is fundamentally reactionary. Part of its resonance as a political symbol comes from the fact that the piracy represents a way that consumers of media can fight back against a set of companies which have attacked them -- with lawsuits, DRM systems, and demonization in propaganda -- for sharing in ways that most consumers think are natural and socially positive. But piracy focuses on reaction rather the fundamental importance of sharing that drives it. As a result, most pirates do not support, or are even familiar with, a principled approach to access to information. As a result, many piracy advocates who speak out against DRM on DVDs will be as happy to use NetFlix to stream DRMed movies for $5 a month as they were to download for free. The best rallying cries do not always translate into be the most robust movements. Third, through its focus on a reaction, a dialog about piracy avoids engagement with the tough questions of what we will replace the current broken copyright system with. A principled position suggests that it is our ethical prerogative to create alternative models. The free software movement has succeeded because it created such a prerogative and then, slowly over time, provided examples of workable alternatives. A principled position on free software did not require that one provide working new systems immediately, but it makes the development of creative, sustainable approaches a priority. Attacking the system without even trying to speak about alternative modes of production is unsustainable. Free software and free culture call for a revolution. Piracy only calls for a riot. Piracy, in these three senses, can be seen as tactically unwise, without necessarily being unethical. By taking a principled position, one can go build on, and go beyond, RMS's comment. On free culture and free software's terms, we can suggest that piracy is not ethically wrong, but that it is an unwise way to try to promote sharing. Without being hypocritical, we can say: "I don't think piracy is unethical. But I also do not support it."

a rather active week, although most of my uploads were (again!) either packages prepared by others or packages where I just applied existing patches from the BTS.

• #524102 libsubtitleeditor0: "libsubtitleeditor0: missing Replaces: subtitleeditor"
  add missing Breaks/Replaces and upload to DELAYED/2
• #591976 src:libjifty-plugin-chart-perl: "libjifty-plugin-chart-perl: does not build swf files from source"
  upload repackaged package prepared by bremner (pkg-perl)
• #593014 src:libpoe-api-peek-perl: "FTBFS: test t/03-event.t fails with libpoe-perl (2:1.2920-1)"
  upload new upstream release prepared by periapt (pkg-perl)
• #593027 src:solr: "solr: FTBFS: lib/lucene-core-2.9.2.jar Missing"
  untag squeeze
• #597180 valgrind: "valgrind: Man page misbuilt on i386"
  add missing build dependency and upload to DELAYED/2
• #598070 src:libdevel-cover-perl: "libdevel-cover-perl: FTBFS (powerpc): Test 37 fails"
  manual versioned close, the new version builds again (pkg-perl)
• #598249 pacemaker: "unable to install pacemaker heartbeat"
  close: affects backports and not reproducible
• #599251 liblatex-driver-perl: "FTBFS: waits for user input at "latex path [/usr/bin/latex]""
  uploaded fixed package prepared by carnil (pkg-perl)

in case you haven't seen it yet: there will be a BSP at the Mini DebConf Paris at the end of october. .

I should probably have researched the batteries in this old solar-powered house before I installed a charge controller. I had assumed that the 24 6-volt batteries in the house's battery bay were standard lead-acid deep cycle batteries. It wasn't until I stumbled over a receipt from 1997 that I learned that the batteries are really NiCads. Specifically Saft model STM5-180. Thirty of these were purchased in 1997 from TVA in Chatanooga, for $350 total. An amazing price, since a single deep cycle battery is in that ballpark, new. These batteries were used, they had been in a "bus" -- perhaps it was a 1995 Chrysler TEVan, or maybe one of the pilot electric buses running there in the late 90's. They were probably not in this '79 VW TVA Bus. All mentions of these batteries I can find involve electric vehicles -- it's unusual for them to be used to power a house. Being vented NiCads probably accounts for these batteries' long useful life -- surely at least 15 years. Still, with only twenty-four good ones left, they are probably toward the end of their lifespan and need to be taken care of in order to last. Once I realized they were NiCads, I knew the charge controller was charging them wrong. NiCads like to be charged at a higher voltage than the 13 or so volts used for lead acid. I would have liked to charge them at 16 volts, but that would feed back through the house wiring, and could fry 12 volt stuff. Checking ratings, 15 volts seemed the highest voltage I could risk. Coming back a week later, I found the batteries charged up to 13.4 volts. And they are now working great. Through several cloudy days, we had all the power we needed. And when the sun was out fully, I sometimes saw the solar panels charging the batteries at 125 watts -- fully half of the panels' rated capacity, and much better than before. The batteries start each evening at 13.4 volts, and only drop to 13.3 by morning. We started using electric lights more, and then just leaving them on all evening, and the nslu2 online all night, and the batteries remained at the magic 13.3 in the morning. This is because NiCad batteries have a near-constant voltage until they are perhaps 30% discharged. In other words, I had been charging them less than half full before. I have figured out how to combine the two banks the batteries are in into one large bank, and once I get the cables to do that, I hope to have battery capacity to get through up to a week of solid clouds in midwinter.

battery box and solar panel

The bug webinterface of the Universal Debian Database currently knows about the following release critical bugs:

In Total:	744
Affecting Squeeze:	358
Squeeze only:	76
Remaining to be fixed in Squeeze:	282

Of these 282 bugs, the following tags are set:

Pending in Squeeze:	19
Patched in Squeeze:	44
Duplicates in Squeeze:	28
Can be fixed in a security Update:	28
Contrib or non-free in Squeeze:	11
Otherwise fixed in Squeeze:	29

Ignoring all the above (multiple tags possible), 161 bugs need to be fixed by Debian Contributors to get Debian 6.0 Squeeze released. However, with the view of the Release Managers, 218 need to be dealt with for the release to happen. Please see Interpreting the release critical bug statistics for an explanation of the different numbers.

BSP Paris 2010, during mini-DebConf The first mini-DebConf in Paris, France is just a few weeks away and about 150 persons have signed up as attendees (wow!). The days of the conference (October 30th-31st, 2010) will most likely see the Debian Squeeze release in its deepest possible freeze, fighting with the very very very few remaining RC bugs (right? right!). What's the most useful thing that a crowd of Debian hackers can do that close to a release?
A Bug Squashing Party, of course! Therefore please welcome: We now need to arrange a room for the BSP, in parallel with the talk rooms of the conference. Hence please sign-up on the wiki page if you plan to attend the BSP. Please do so even if you're already signed up as a conference attendee, as the rooms will be different.

I've been mostly working on GnuCash the past few evenings. I added more info and a test case to Bug #593856, so that should fall into place soon. I turned my attention to ettercap this evening, and Bug #521857 - another easy one, just applying the updated patch. Except when I ran "lintian -F", I got:

lintian -F /var/cache/pbuilder/result/ettercap_0.7.3-2.1_amd64.changes 
E: ettercap: binary-or-shlib-defines-rpath ./usr/sbin/ettercap /usr/lib
E: ettercap-gtk: binary-or-shlib-defines-rpath ./usr/sbin/ettercap /usr/lib

This led me to a Jan 2008 email from Raphael Geissert about packages defining RPATH on amd64. For now, I've rebuilt in an i386 chroot - I'd need some help making a full lintian run on amd64 if I were going to propose a mass bug-filing.

Roland Mas writes an interesting article about decentralized naming, in which he says:

Monkeysphere aims at adding a web of trust to the SSL certificates system, but the CA chain problem seems to persist (although I must admit I'm not up to speed with the actual details).

Since i'm one of the Monkeysphere developers, i figure i should respond! Let me clarify that Monkeysphere doesn't just work in places where X.509 (the SSL certificate system) works. It works in other places too (like SSH connections). And I don't think that the CA chain problem that remains in Monkeysphere is anything like the dangerous mess that common X.509 usage has given us. I do think that at some level, people need to think about who is introducing them to other people -- visual or human-comprehensible representations of public key material are notoriously difficult to make unspoofable. On the subject of distributed naming: OpenPGP already allows distributed naming: every participant in the WoT is allowed to assert that any given key maps to any given identity. Duplicates and disagreements can exist just fine. How an entity decides to certify another entity's ID without a consensus global namespace is a tough one, though. If i've always been known as "John Smith" to my friends, and someone else has also been known as "John Smith" to his friends, our friends aren't actually disagreeing or in conflict -- it's just that neither of us has a unique name. The trouble comes when someone new wants to find "John Smith" -- which of us should they treat as the "correct" one? I think the right answer probably has to do with who they're actually looking for, which has to do with why they're looking for someone named "John Smith". If they're looking for John Smith because the word on the street is that John Smith is a good knitter and they need a pair of socks, they can just examine what information we each publish about ourselves, and decide on a sock-by-sock basis which of us best suits their needs. But if they're looking for "John Smith" because their cousin said "hey, i know this guy John Smith. I think you would like to argue politics over a beer with him", then what matters is the introduction. And OpenPGP handles that just fine -- if their cousin has only ever met a single John Smith, that's the right one. If their cousin has met several John Smiths, then the searcher would do well to ask their cousin some variant of "hey, do you mean John Smith or John Smith ", or even "do you mean the John Smith who Molly has met, or the one who Charles has met?" (assuming that Molly and Charles have each only certified one John Smith in common with the cousin, and not the same one as each other), or to get a real-time introduction to a particular John Smith, where his specific key is somehow recordable by the searcher for future conversations (or beer drinking). This is what we do in the real world anyway. We currently lack good UIs for doing this over the network, but the certification infrastructure is in place already. What we're lacking in infrastructure, though, is a way to have a distributed addressing. Roland's proposal was to publish addresses corresponding to cryptographic identities within some DNS zone, or in freenet or gnutella. Another approach (piggybacking on existing infrastructure) would be to include IP address information in the OpenPGP self-certification, so the holder of the name could claim exactly their own IP address. This could be distributed through the keyserver network, just like other updates are today, and it could be done simply and immediately with a well-defined OpenPGP notation. I'd be happy to talk to interested people about how to specify such a notation, and what possible corner cases we might run into. Drop a note here, or mail the Monkeysphere mailing list or hop onto #monkeysphere on irc.oftc.netTags: authentication, distributed naming, identity, monkeysphere

What's the best way to run PHP in Debian in a shared environment? Years ago May First/People Link switched from the old reliable modphp to suPHP because modphp ran all php scripts as the same user, meaning (among other things) that any site could access the database configurations of any other site. suPHP was great, however, after several years we've decided to replace it because:

• As our members increasingly use Drupal and Drupal sites grow increasingly more complex, suPHP's performance has become a problem.
• suPHP executes with the permissions of the owner of the file it is executing. From a zero-conf perspective, this features makes suPHP very easy to setup. However, from a security perspective, it forces you to run your php script with the permission to delete itself. Not optimal.

We first turned to fcgid. We tried it out on a couple individual web sites (fcgid can run alongside suPHP), and, after a week without much problems, we implemented it on an entire server. Out of the box, on a shared server with several dozen web sites, the most notable resource utilization difference between fcgid and suPHP is the increase in memory usage. Unlike suPHP which dies after each requests, fcgid gains a performance boost by sticking around (with either 2 or 3 processes living on) to server future requests. If you have several dozen web sites that aren't high traffic sites, it means they may each have up to the three processes staking out memory that would otherwise be free with suPHP. We addressed the memory problem by adding the following to /etc/apache2/mods-available/fcgid.conf:

DefaultMinClassProcessCount 0
IdleTimeout 60
IdleScanInterval 60

These directions tell fcgid to kill processes that have been idle for more than 60 seconds. That means we still get the performance gain from a site getting more than one page view per minute, but otherwise we re-claim the memory. Before switching our remaining servers we decided to do more extensive testing to ensure we would be getting the performance and resource gains we were hoping. Also, we decided to consider mpm-itk, which is a variation of mpm-prefork that runs each virtual host with a per-vhost configured user and group (like suexec, but for the entire virtual host). Since it's a variation of mpm-prefork, it's safe to run it with the more resource friendly mod_php. We used the apache benchmarking tool ab. And we tested on a virtual machine (running on my laptop) with 1GB of RAM. The test web site we used was a copy of the May First/People Link site (we used the home page for the test), which is running Drupal 6. It's a relatively simple Drupal site, however, we turned Drupal caching off to better simulate PHP processing usage likely to be found on our members' sites. We ran tests against the following configurations:

• Plain mpm-prefork with mod_php and apc (as a standard to strive for)
• Both mpm-worker with suPHP and mpm-prefork with suPHP (how much of a difference does worker vs prefork make with a Drupal site?)
• mpm-worker/fcgid/suexec
• mpm-itk with mod_php

The tests were run with:

• 1 request (in the results, this test is labelled 1:1)
• 20 requests, 5 concurrent (20:5)
• 50 requests, 10 concurrent (50:10)
• 70 requests, 10 concurrent (70:10)

We originally tried, for the last test, 100 requests/25 concurrent but it caused ab to time out on the mpm-worker/fcgid/suexec configuration. We then lowered it to 75/15. Still timed out (load on our test server went way up). The tests paused 120 seconds between testing each environment to give the server load a chance to settle down. And we paused 30 seconds between each test (not enough time for the fcgid processes to be killed, but enough time for all the processes to hopefully complete their requests). The tests are scripted and the full results are available. You can also see the various vhost configurations (test.mouse, test.mouse.itk, test.mouse.suexec.fcgid), and the fcgid.conf. To summarize the report ... if you are running one web site on a server, there's little argument for using anything other than mod_php and mpm-prefork - the performance of this combination far exceeds any other combination. I'm scratching my head over the the vastly different conclusions reached by 2bits. They didn't publish their tests so I'm not sure exactly how to compare. Maybe they have a lot more static content? Or - maybe there's a mistake in our tests? Open to ideas. suPHP seems to be left in the dust compared with either fcgid/suexec or mpm-itk. Given that it's also less flexible, there's not much going for it. And lastly... fcgid/suexec and mpm-itk seem comparable. That was a surprise. We were expecting mpm-itk to perform better because it's running mod_php. Given the similarity in performance, fcgid/mpm-worker seems like a much more well-tested and well-supported approach for a shared server. One side note... originally, out of laziness, we tested against the default Drupal install.php page. Less static content and much less PHP processing. In these tests, with low loads, the results provide different numbers, but the comparisons between environment were similar ... except with the last test. With the 70 requests/10 concurrent test, fcgid/suexec dramatically out-performed everyone (by a factor or more than 2). That's probably because no new cgi processes had to be spawned and the effect of mod_php using APC was reduced because there was very little php code to process.

Review: Thinking in Java, by Bruce Eckel

Publisher:	Prentice Hall
Copyright:	2006
Printing:	October 2009
ISBN:	0-13-187248-6
Format:	Trade paperback
Pages:	1461

Thinking in Java has gone through multiple editions. This review is of the 4th edition, which is targetted at Java 5 (with some minor updates for Java 6, released as it was going to press). Prior to reading this book, I'd never written code from scratch in Java and had never learned anything about Java in a structured fashion. My CS degrees come before the era of ubiquitous Java; the most I'd ever done with the language was look over and make some minor fixes to code other people had written, using general programming knowledge. I choose this book as my introduction because I was looking for a ground-up introduction with good reviews and was avoiding books that contained a printed version of the Java library documentation. I can get that myself on-line. I kept a set of notes on my impressions of the Java language itself separately and will not get into that here. This is, instead, a review of Thinking in Java as a book and as a training tool for someone who wants to pick up the language. First off, this is a remarkably well-titled book, much more so than the typical programming language book. Eckel is not just teaching Java as one programming language among many. He tries hard to teach the reader to think in Java, with a lot of attention to idiomatic use of the language and natural ways to use its expressiveness. This is exactly what I was looking for I don't want to just write C or Perl in Java syntax and I was very satisfied with the result. The book is also very heavy on source code examples; this is much of the reason why it's 1,461 pages. Eckel illustrates everything with Java code, generally complete functioning short programs. Even exploratory musings and experiments are implemented as Java code. I don't think there's any significant thought in this book that isn't shown in both text and in explained Java code. Eckel has also clearly put significant effort into choosing good examples and designing his sample programs. I have some past (mild) experience with object-oriented design, and a lot of experience with higher-level system design, and I was satisfied and occasionally intrigued by the object structures and design tips that Eckel provides. He uses design pattern language heavily, but not in a confusing way, and he takes some time to explain typical design patterns and illustrate them repeatedly. This is a solid introduction to good object-oriented program design as well as an introduction to Java. One oddity of this book, though, is that Eckel introduces the language from the ground up, starting with syntax and basic types, and is very careful not to use any concepts before he introduces them. The result is a very thorough introduction to the Java language, but it means that it takes 900 pages (!) before Eckel introduces I/O and the possibility of writing a useful program based on just the information in the book. This is for entirely sound conceptual reasons: I/O in Java relies on lots of concepts, like exceptions and generics, that require extensive introduction and discussion. However, it does mean that through well more than half of a monumental tome the reader is learning the language through rather artificial programs. I have extensive prior programming background and a high tolerance for more abstract examples (I have a master's degree in software theory), so I could deal with this, but even with that background I was starting to feel like my head was getting too full and too crowded with concepts without being able to make them concrete. It probably would have helped to work through some of the exercises, but I dislike exercises that aren't grounded in some problem I personally want to solve. If you're someone who only learns languages through practical application, this approach to teaching the language may drive you nuts, and you may want to look for another book that compromises conceptual progression to get you started faster. Related to this, Thinking in Java is not about the standard library. It's about the language, and the vast majority of this book is focused directly on the language level: inheritance, information hiding, generics, exceptions, introspection, concurrency, annotations, serialization, and so forth. The only parts of the standard library that Eckel covers in depth are the container classes, I/O, and a somewhat odd and misplaced final chapter on Swing. There is nothing about databases, essentially nothing about web applications or containers, no network programming, and very little in the way of practical, applied problems. As you might guess from the combination of that limitation of scope and the length of this book, that means it is extremely comprehensive; I doubt there are many corners of the basic language semantics, including around generics, that Eckel leaves unexplored. This is exactly what I wanted (I know how to read library documentation myself and all language core libraries start looking mostly the same after you've programmed in five or six languages), but it's very different from the typical approach of a programming language book. Don't be surprised. This biggest problem with Thinking in Java from my perspective is that it defers many interesting topics to Eckel's web pages and to free companion books and material that is supposedly found there, to the point of advertising that on the cover. This is a good way to allow the reader to explore extra topics that are of specific interest while skipping others, provided that one actually delivers on that promise. However, Eckel's web site is dire. The first time I looked at it earlier this year I was unable to find most of the supplemental material the book promises is there, and now www.mindview.net doesn't resolve in DNS. I've found copies of some of that material hosted elsewhere in Google searches, but this is a rather frustrating experience if one was relying on that supplemental material to fill in the gaps. And the book is clearly written expecting people to go look at the web materials; Eckel refers to them probably a hundred times over the course of the book. Less of a serious problem, and more of a quirk, is the closing chapter on Swing. This chapter really doesn't fit much with the book. I suppose Eckel felt obligated to put in at least one chapter on some concrete applied topic (I personally would have preferred databases be that topic, but oh well), and it does serve a useful purpose in showing how concurrency, inner classes, inheritance, and introspection all work together in a significant Java library. But it's not presented as just an example, and it fits in oddly with the rest of the book. It also has an inexplicable middle section about Flash programming. I ended up mostly skimming this. But this isn't much of a flaw in the book; if one ignores 100 pages out of 1,450, that's not much of a loss. Eckel comes from a C++ background (he was a founding member of the C++ standardization committee), which shows up most prominantly in the generics chapter. It's a solid, thorough introduction to Java generics, but it also has an extensive exploration of all the problems with the Java erasure model and many, many examples of the things that one would find intuitive from C++ that don't work the same way in Java. If you come from a C++ background, this is quite possibly useful; if, like me, you don't care about C++, it's at best mildly interesting and gets a touch tedious. There are a few other places where Eckel pokes surprisingly sharp sticks at the Java designers, but taken in context I think this is a quirk of the book's conversational style (which is otherwise a feature). Eckel's love of Python is also somewhat entertaining (particularly the long advertisement for Python in the introductory chapters of a book on Java), but has little impact on the book. I think the largest drawback of it is that all the examples in this book are tested using a Python framework, which isn't so much a problem with them as a lost opportunity. They're annotated with metadata used by Eckel's Python test framework, and in a Java book I would have been much more interested in a good Java test framework built on top of something like JUnit. Oh well. Overall, this is a very solid book which, despite being enormous, does not feel pointlessly padded. It's thorough and exhaustive on its topic, but there's a point to nearly everything in here. It was also exactly the Java book I wanted: an introduction to the language, built on a firm foundation of object-oriented program design, with discussion and pointers on how to think idiomatically in the language and use it to its fullest potential, and without mindlessly reproducing the standard library documentation. If that's also what you're looking for in a Java book, I recommend it highly. Just know going in what sort of book you're getting, since its pacing and order of presentation may frustrate some learning styles. Rating: 8 out of 10

I've just uploaded git-dpm 0.3.0-1 packages to experimental. Apart from many bugfixes (which I will also take a look if I can make an 0.2.1 version targeting squeeze, though the freeze requirements tend to get tighter and tighter, so I may already be too late), the biggest improvement is the newly added git-dpm dch command to spawn dch and then extracts something to be used for the git commit message (I prefer to have more control over debian/changelog, so I prefer this way over the other direction).

Proposed timeline of the Release Team

We hope to have sorted out all the details and resolved the remaining blockers by the end of October, with the focus during November being on translation updates, testing and coordination with different teams to prepare the new release.
This means that it s possible to have a release out in time for Christmas, but to do this we need YOUR help. Please, squash bugs, write release notes, squash bugs, support our translators and squash some bugs.

Has anyone experience with using Google Apps?The server I'm currently using for my private email will be shut down soon, so I need to decide upon a future way of handling my personal email. I have low requirements, they key feature I need is a good spam filter; Google Apps can certainly provide this. Since I'm the single user, the free "standard" edition should be easily good enough.Obviously, since I don't have a reachable mail server myself anymore, I'd either have to rent a server just for my personal email, or use some hosted solution like Gmail, even if it is not open source.So, did you try it? Did you return to a different solution?

• Privacy issues of using Google
• Free service limitations (50 acounts, sufficient for me)
• Good spam filter
• Good Webmail
• High availability
• IMAP support (at least to some extend
• Android support - my next phone likely will be an Android device

Any points I'm missing? Email me: erich (a) debian orgUpdate: I have received a lot of feedback, much of which is very positive on Gmail/Google Apps for personal use.

Richard Baraniuk gave an interesting TED talk about Open Source Learning [1]. His project named Connexions which is dedicated to the purpose of creating Creative Commons free textbooks is a leader in this space [2]. He spoke about Catherine Schmidt-Jones who wrote 197 modules and 12 courses on music [3], that s a very significant amount of work! He also mentioned the translation of the work into other languages. I wonder how well the changes get merged back across the language divide. We have ongoing disputes in the free software community about whether various organisations do enough work to send patches back upstream, this seems likely to be more of a problem in situations where most of the upstream authors can t even understand the language in which the changes are written and when the changes involve something a lot more subtle than an change to an algorithm. This would be particularly difficult for Chinese and Japanese as those languages seem to lack quality automatic translation. He mentioned Teachers Without Borders [4] in passing. Obviously an organisation that wants to bring education to some of the poorer parts of the world can t have a curriculum that involves $250 of text books per year for a high school student (which was about what my parents paid when I was in year 12) or $500 of text books per year for a university student (which might be a low estimate for some courses as a single text can cost more than $120). Free content and on-demand printing (or viewing PDF files on a OLPC system) can dramatically lower the cost of education. It s widely believed that free content without the ability to remix is cultural imperialism. This is apparently one of the reasons that the connexions project is based on the Creative Commons Attribution license [5]. So anyone anywhere can translate it, make a derivative work, or collate parts of it with other work. I expect that another factor is the great lack of success of all the various schemes that involve people contributing content for a share of the profits, the profits just don t match the amount of work involved. Philanthropy and reputation seem to be the only suitable motivating factors for contributing to such projects. One of the stated benefits of the project is to have computer based content with live examples of equations. Sometimes it is possible to just look at an equation and know what it means, but often more explanation is required. The ability to click on an equation, plug in different values and have them automatically calculated and possibly graphed if appropriate can make things a lot easier. Even if the result is merely what would be provided by reading a text book and spending a few minutes with a scientific calculator the result should be a lot better in terms of learning as the time required to operate a calculator can break the student s concentration. Even better it s possible to have dynamic explanations tailored to the user s demand. To try this out I searched on Ohm s Law (something that seems to be unknown by many people on the Internet who claim to understand electricity). I was directed to an off-site page which used Flash to display a tutorial on Ohm s Law, the tutorial was quite good but it does seem to depart from the free content mission of the project to direct people off-site to proprietary content which uses a proprietary delivery system. I think that the Connexions project could do without links to sites such as college-cram.com. One of the most important features of the project is peer review lenses . The High Performance Computing Lens [6] has some good content and will be of interest to many people in the free software community but again it requires Flash. One final nit is the search engine which is slow and not very useful. A search for engine returned lots of hits about engineering which isn t useful if you want to learn about how engines work. But generally this is a great project, it seems to be doing a lot of good and it s got enough content to encourage other people and organisations to get involved. It would be good to get some text books about free software on there!

• [1] http://www.ted.com/talks/lang/eng/richard_baraniuk_on_open_source_learning.html
• [2] http://cnx.org/
• [3] http://cnx.org/member_profile/Catherine
• [4] http://www.teacherswithoutborders.org/
• [5] http://creativecommons.org/licenses/by/2.0/

Debian s testing distribution is where Debian developers prepare the next stable distribution. While this is still its main purpose, many users have adopted this version of Debian because it offers them a good trade-off between stability and freshness. But there are downsides to using this distribution and the Constantly Usable Testing (CUT) project aims to resolve those. This article will present the project and the challenges involved to make it happen. About Debian unstable & testing Debian unstable is the distribution where developers upload new versions of their packages. It happens frequently that some packages are not installable due to changes in other packages or due to transitions not yet completed. Debian testing, on the contrary, is managed by a tool that ensures the consistency of the whole distribution: it picks updates from unstable only if the package has been enough tested (10 days usually), if it s free of new release-critical bugs, if it s available on all supported architectures, and if it doesn t break any other package already present in testing. The Release Team (RT) controls this tool and provide hints to help it find a set of packages that can flow from unstable to testing. Those rules also ensure that the packages that flow into testing are reasonably free of show-stopper bugs (like a system that doesn t boot, or X that doesn t work at all). This makes it very attractive to users who like to regularly get new upstream versions of their software without dealing with the biggest problems associated to them. This is all very attractive, yet several Debian developers advise people to not use testing. Why is that? Known problems with testing Disappearing software The release team use this distribution to prepare the next stable release and from time to time they remove packages from it. Either because it s needed to ensure that other packages can migrate from unstable to testing, or because they have long-standing release-critical bugs without progress towards a resolution. It also happens that they remove packages on request of the maintainers because they believe that the current version of the software cannot be supported (security-wise) for 2 years or more. The security team also regularly issues such requests. Long delays for security and important fixes Despite the 10-day delay in unstable, there are always some annoying bugs (and security bugs are no exceptions) that are only discovered when the package already has migrated to testing. The maintainer might be quick to upload a fixed package in unstable, and might even raise the urgency to allow the package to migrate sooner, but if the packages gets entangled in a large ongoing transition, it will not migrate before the transition is completed. Sometimes it can take weeks for that to happen. This delay can be avoided by doing direct uploads to testing (through testing-proposed-updates) but this is almost never used, except during a freeze, where targeted bugfixes are the norm. Not always installable With testing evolving daily, updates sometimes break the last installation images available (in particular netboot images that get everything from the network). The debian-installer (d-i) packages are usually quickly fixed but they don t move to testing automatically because the new combination of d-i packages has not necessarily been validated yet. Colin Watson sums up the problem:

Getting new installer code into testing takes too long, and problems remain unfixed in testing for too long. [...] The problem with d-i development at the moment is more that we re very slow at producing new d-i *releases*. [...] Your choices right now are to work with stable (too old), testing (would be nice except for the way sometimes it breaks and then it tends to take a week to fix anything), unstable (breaks all the time).

CUT s history CUT finds its root in an old proposal by Joey Hess: it introduces the idea that the stable release is not Debian s sole product and that testing could become with some work a suitable choice for end-users. Nobody took on that work and there was no visible progress in the last 3 years. But recently Joey brought up CUT again on the debian-devel mailing list and Stefano Zacchiroli (the Debian project leader) challenged him to setup a BoF on CUT for Debconf10. It turned out to be one of the most heavily attended BoF (video recording is here), there is clearly a lot of interest in the topic. There s now a dedicated wiki and an Alioth project with a mailing list. The rest of this article tries to summarize the various options discussed and how they re supposed to address the problems identified. The ideas behind CUT Among all the ideas, there are two main approaches that have been discussed. The first is to regularly snapshot testing at points where it is known to work reasonably well (those snapshots would be named cut ). The second is to build an improved testing distribution tailored to the needs of users who want a working distribution with daily updates, its name would be rolling . Regular snapshots of testing There s general agreement that regular snapshots of testing are required: it s the only way to ensure that the generated installation media will continue to work until the next snapshot. If tests of the snapshot do not reveal any major problem, then it becomes the latest cut . For clarity, the official codename would be date based: e.g. cut-2010-09 would be the cut taken during September 2010. While the frequency has not been fixed yet, the goal is clearly to be on the aggressive side: at the very least every 6 months, but every month has been suggested as well. In order to reach a decision, many aspects have to be balanced. One of them (and possibly the most important) is the security support. Given that the security team is already overworked, it s difficult to put more work on their shoulders by declaring that cuts will be supported like any stable release. No official security support sounds bad but it s not necessarily so problematic as one might imagine. Testing s security record is generally better than stable s one (see the security tracker) because fixes flow in naturally with new upstream versions. Stable still get fixes for very important security issues sooner than testing, but on the whole there are less known security-related problems in testing than in stable. Since it s only a question of time until the fixed version comes naturally from upstream, more frequent cut releases means that users get security fixes sooner. But Stefan Fritsch, who used to be involved in the Debian testing security team, has also experienced the downside for anyone who tries to contribute security updates:

The updates to testing-security usually stay useful only for a few weeks, until a fixed version migrates from unstable. In stable, the updates stay around for a few years, which gives a higher motivation to spend time on preparing them.

So if it s difficult to form a dedicated security team, the work of providing security updates comes back to the package maintainer. They are usually quite quick to upload fixed packages in unstable but tend to not monitor whether the packages migrate to testing. They can t be blamed because testing was created to prepare the next stable release and there is thus no urgency to get the fix in as long as it makes it before the release. CUT can help in this regard precisely because it changes this assumption: there will be users of the testing packages and they deserve to get security fixes much like the stable users. Another aspect to consider when picking a release frequency is the amount of associated work that comes with any official release: testing upgrades from the previous version, writing release notes and preparing installation images. It seems difficult to do this every month. With this frequency it s also impossible to have a new major kernel release for each cut (since they tend to come out only every 2 to 3 months) and the new hardware support that it brings is something worthwhile to many users. In summary, regular snapshots address the not always installable problem and changes the perception of maintainers towards testing, so that hopefully they care more of security updates in that distribution (and in cuts). But they do not solve the problem of disappearing packages. Something else is needed to fix that problem. A new rolling distribution? Lucas Nussbaum pointed out that regular snapshots of Debian is not really a new concept:

How would this differentiate from other distributions doing 6-month release cycles, and in particular Ubuntu, which can already be seen as Debian snapshots (+ added value)?

In Lucas s eyes, CUT becomes interesting if it can provide a rolling distribution (like testing) with a constant flux of new upstream releases . For him, that would be something quite unique in the Free Software world . The snapshots would be used as starting point for the initial installation, but the installed system would point to the rolling distribution and users would then upgrade as often as they want. In this scenario, security support for the snapshots is not so important, what matters is the state of the rolling distribution. If testing were used as the rolling distribution, the problem of disappearing packages would not be fixed. That s why there have been discussions of introducing a new distribution named rolling that would work like testing but with adapted rules, and the cuts would then be snapshots of rolling instead of testing. The basic proposal is to make a copy of testing and to re-add the packages which have been removed because they are not suited for a long term release while they are perfectly acceptable for a constantly updated release (the most recent example being Chromium). Then it s possible to go one step further: during freeze, testing is no longer automatically updated which makes it inappropriate to feed the rolling distribution. That s why rolling would be reconfigured to grab updates from unstable (but using the same rules than testing). Given the frequent releases, it s likely that only a subset of architectures would be officially supported. This is not a real problem because the users who want bleeding edge software tends to be desktop users on mainly i386/amd64 (and maybe armel for tablets and similar mobile products). This choice if made opens up the door to even more possibilities: if rolling is configured exactly like testing but with only a subset of the architectures, it s likely that some packages migrate to rolling before testing when non-mainstream architectures are lagging in terms of auto-building (or have toolchain problems). While being ahead of testing can be positive for the users, it s also problematic on several levels. First, managing rolling becomes much more complicated because the transition management work done by the release team can t be reused as-is. Then it introduces competition between both distributions which can make it more difficult to get a stable release out, for example if maintainers stop caring of the migration to testing once the migration to rolling has been completed. The rolling distribution is certainly a good idea but the rules governing it must be designed to avoid any conflict with the process of releasing a stable distribution. Lastly, the mere existence of rolling would finally fix the marketing problem plaguing testing: the name rolling does not suggest that the software is not yet ready for prime time. Conclusion Whether CUT will be implemented remains to be seen, but it s off for a good start: ftpmaster Joerg Jaspert said that the new archive server can cope with a new distribution, and there s now a proposal shaping up. The project might start quickly: there is already an implementation plan for the snapshot side of the project. The rolling distribution can always be introduced later, once it is ready. Both approaches can complement each other and provide something useful to different kind of users. The global proposal is certainly appealing: it would address the concerns of obsolescence of Debian s stable release by making intermediary releases. Anyone needing something more recent for hardware support can start by installing a cut and follow the subsequent releases until the next stable version. And users who always want the latest version of every software could use rolling after having installed a cut. From a user point of view, there are similarities with the mix of usual and long term releases of Ubuntu. But from the development side, the process followed would be quite different, and the constraints imposed by having a constantly usable distribution are stronger: any wide-scale change must be designed in a way that it can happen progressively in a transparent manner for the user.

This article was first published in Linux Weekly News. If you want to see more articles like this, join Flattr and click on the flattr button below every article that you like.

21 comments Support my work

diocles' blog post reminds me that it's time again for some more RCBW propaganda. so here are the RC bugs I've worked on in the last two weeks:

• #574624 dibbler-client: "dibbler-client: after removing package with dselect impossible to purge it."
  apply patch to init script, upload to DELAYED/2
• #578403 mysql-proxy: "DAEMON=".." in initscripts points to"
  fix init script (patch from BTS), upload to DELAYED/2
• #589582 eucalyptus: "eucalyptus: FTBFS with upcoming Hibernate 3.5"
  add a comment to the bug report
• #595839 verilog-mode: "verilog-mode: FTBFS in squeeze: Nonexistent build-dependency: 'emacs22'"
  add emacs23 as first alternative in B-D-I, upload to DELAYED/2. later cancelled
• #595876 multiboot: "multiboot: FTBFS in squeeze: rm: cannot remove debian/multiboot/usr/share/info/dir': No such file or directory"
  remove potentially created file unconditionally, upload to DELAYED/2
• #597409 tk707: "tk707: install-info installed leads to /usr/share/info/dir.gz in built package"
  rm /usr/share/info/dir.gz in debian/rules, upload to DELAYED/2
• #597411 ssed: "ssed: install-info installed leads to /usr/share/info/sdir.gz in built package"
  rm /usr/share/info/sdir.gz in debian/rules, upload to DELAYED/2

which RC bug are you going to tackle today?

Recently, Google started changing the web in some interesting ways. A lot by contributing code. It started with projects such as the Chrome web browser, which quickly achieved a market shares over 10%, which is more than Apple Safari and Opera together.And the good side, Chrome did not actually add "yet another incompatible platform", but by being closely related to Safari (or more precisely WebKit), it is not that different.Other stuff that belongs into this category is the Google Web Toolkit and the closure compiler (which essentially is a JavaScript code checker and optimizer).But recently, Google goes a step further. They started tackling internet file formats. First they proposed a new Video codec known as WebM or VP8. Now they extracted an image format out of this codec, known as WebP.There is some serious doubt on the quality, the images do appear to be a bit blurry and lose details. I concur with JPEG even being a bit better, despite the block artefacts. The blurry results of WebP are not really convincing.The h.264 based image looks best to me, but H.264 is patent-encumbered for all I know, so we might not see this new format in wide use until 2028. This already ruled out other image formats such as JBIG or FIF. Or look at audio formats: we're still using MP3 everywhere, because everyone tries to push another patent-encumbered audio format that the others are not going to adopt. So MP3 remains the only thing widely accepted (Ogg Vorbis is nice, but it looks as if companies such as Apple are not going to adopt it, probably because they have interest in other formats. Maybe the Ogg Vorbis support in Chrome will help here on the long run).In particular, why would you pay royalties for a tiny bit of image quality, given the constantly sinking prices of bandwidth? The H.264 patents may make a difference on video data, they probably won't pay of for still images.Given that WebM is sometimes claimed to be a simplified H.264 (minus the patent issues?), WebP probably is as good as we can get to the H.264 based quality without running into the same patent issues?But enough on the image data. There is one thing, I'd really like to see Google change on the web. The worst thing about the web is called JavaScript (or more accurately, ECMAScript). There is just so much wrong with this language that we really need to replace it ASAP.Some things that are wrong with JavaScript:

• The syntax is about as crazy as Perl, anything could be valid code.
• There a lot of syntax quirks and oddities. Try to test for a variable storing an Array ...
• It lacks any reasonable Standard Library - which is a key strength of modern languages such as Java, Python, C# - and which is why everbody is using one of the thousand JavaScript frameworks such as Dojo, Mojikit, Google Closure Library, Prototype, jQuery, MooTools, Yahoo UI Library, ...
• Due to the lack of standard functionality, the JavaScript development cost is a lot higher than needed, development time is bad for the triviality of most JavaScript tasks, and the file size is even worse than JPEG vs. WebP ...

So my biggest wishlist item of Google to contribute to the Web via Chrome and Firefox is a new web scripting language. As much as I love python, the whitespace syntax of Python doesn't work for the web (we need to be able to store complex statements in HTML attributes without newlines), so we'll have to look for something else. Maybe Ruby will work?

Steve Jobs is a name that comes up a lot when talking to businesspeople, especially in the technology industry. His ideas, his background, his companies, their products, and his personal style are intertwined in the folklore of tech. I have no idea whether most of it is fiction or not, and I write this with apologies to Mr. Jobs for using him as shorthand. I have never met him, and my point here has nothing to do with him personally. What I want to discuss is the behavior of people who invoke the myth of Steve Jobs. In my (entirely subjective) experience, it seems to me that there is a pattern which comes up again and again: People seem to want to discuss and emulate the worst of his alleged qualities. Jobs has been characterized as abusive to his employees, dismissive of his business partners, harshly critical of mistakes, punishingly secretive, and otherwise extremely difficult to work with. Somehow, it is these qualities which are put forward as worthy of discussion, inspiration and emulation. Is this a simple case of confusing correlation with causation? Do people believe that Steve Jobs is successful because of these traits? Perhaps it is a way of coping with one s own character flaws: if Jobs can get away with such misbehavior, then perhaps we can be excused from trying to improve ourselves. Or is there something more subtle going on here? Maybe this observation is an effect of my own cognitive biases, as it is only anecdotal. As with any successful person, Jobs surely has qualities and techniques which are worthy of study, and perhaps even emulation. Although direct comparison can be problematic, luminaries like Jobs can provide valuable inspiration. I d just like to hear more about what they re doing right. Perhaps this is an argument for drawing inspiration from people you know personally, rather than from second-hand or fictitious accounts of someone else s life. I ve been fortunate to be able to work with many different people, each with their own strengths, weaknesses and style. I ve seen those characteristics first-hand, so I also have the context to understand why they were successful in particular situations. If there s one thing I ve learned about leadership, it s that it s highly context-sensitive: what worked well in one situation can be disastrous in another. Is your company really that much like Apple? Probably not.

German RIAA-Equivalent GEMA still has not reached an agreement with YouTube. As a consequence, about half of the YouTube videos I get links for are not accessible because they contain a song that is managed by GEMA.Sorry, I will not buy a song that I can't preview this way.International music companies such as Universal Music Group, EMI and Sony Music definitely should rethink their cooperation with GEMA, they are harming their business.