The Backports Team is pleased to announce the availability of a new
suite on backports: lenny-backports-sloppy. Please read carefully
before considering using or uploading to it what this entails.
The Background You might want to ask: What's that? Let me explain it. During the etch
release discussions popped up on the backports list with two clashing
groups:

• One that expected to always be able to upgrade from sarge + sarge-backports to etch without backports,
• others that wanted new versions of packages flowing in even after the release and were happy to upgrade from sarge + sarge-backports to etch + etch-backports.

The standing at that time was to accept packages that were in testing
after the release, which wasn't etch anymore but lenny. The same discussion started again before the lenny release, and given that
we are facing the upcoming squeeze release we started internally to discuss
how to noise down these long and tedious discussions, because both groups
of people had valid opinions that shouldn't get ignored. So this is where
the idea for lenny-backports-sloppy comes from.
The Change lenny-backports-sloppy will please the group that is happy to upgrade from
lenny + lenny-backports to squeeze + squeeze-backports. lenny-backports is
meant only for packages from squeeze, even after the release. Technically
that means it will get locked down for uploads after the release of squeeze
and require manual approval (for e.g. point release update versions, or
security updates that happen during the squeeze release cycle), while
lenny-backports-sloppy will accept packages from wheezy. Uploading to
lenny-backport will have to get approved by the Debian Backports Team after
the squeeze release, just like uploads to lenny are currently approved by
the Release Team. While lenny-backports-sloppy is created already and working we ask you to
NOT upload packages there without prior discussion with the Backports Team.
This is meant to ensure that the Uploader is aware about the expectations
that come along with that: The package should have a good chance to get
included in the next Debian release aka wheezy, and that the Uploader is
willing to look after the package in the upcoming squeeze-backports suite
after the release of squeeze to ensure upgradeability. In case of questions, feel free to ask either directly on the
debian-backports@lists.debian.org mailinglist, or contact
team@backports.debian.org privately. We are also pleased to annonce that the first upload to
lenny-backports-sloppy already happened. From now on you will be able
to install Postgresql 9.0 (which is not targeted at squeeze) from
lenny-backports-sloppy.
How to use If you want to use lenny-backports-sloppy you will have to add both
lenny-backports and lenny-backports-sloppy to your sources.list. Backports
from lenny-backports-sloppy may depend on packages in lenny-backports.
deb http://backports.debian.org/debian-backports lenny-backports main
deb http://backports.debian.org/debian-backports lenny-backports-sloppy main


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/

My gnucash fix from last night poses an interesting problem - there will be no new gnucash 2.2.x release. So we can fix this potential data loss bug in Debian (probably even in lenny), but what about other distributions? I'm not aware of a formal way to co-ordinate non-security patches like this across distros. (Sure, we can leave it for the vultures on the patch tracker...) Someone should whip up a whizzy web-app, or whatever.

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

I've recently returned from ICFP 2010 (International conference on functional programming). This was the second time I went there, and like last year, it was a very interesting conference. This year, I've even managed to do one keysigning with a fellow Debian Developer (hello Sylvain!) While there were many talks, I only mention a few key ones, that I have found very cool. Note: I'm a layman in this field. The text below is my own interpretation of the talks and contains many errors and wrong facts corrections are welcome! Workshop on ML I wasn't present at this workshop, but other people pointed me to this very cool talk: Mirage project The abstract, to be found at http://www.cs.rit.edu/~mtf/ml2010/program.html#Program (search for Mirage), says:

Our framework, dubbed Mirage, extends the Objective Caml language with I/O extensions and a custom runtime to emit binaries that execute as a paravirtual operating system directly under Xen. The custom run-time is significantly simpler than a general-purpose operating system, with a static single-process 64-bit address space, and "zero-copy" I/O that works directly with the OCaml garbage collector. As a result, Mirage applications exhibit significant performance speedups for I/O and memory handling versus the same code running under Linux/Xen.

It's extremely interesting, IMHO. You write your code as a more-or-less normal OCaml program, but you compile it with this special tool-chain, and you boot it directly on ton of Xen, as a domU, without the intermediate OS. The project Git repo is at http://github.com/avsm/mirage, and that links a bit older presentation (http://anil.recoil.org/papers/2010-hotcloud-lamp.pdf) which IMHO is a required read for anyone interested in cloud-related stuff. ICFP proper ICFP, the main conference, is as usual, full of math, designed to scare people away. Err, I mean, designed to tell about new developments in this field. The papers are gathered in this reddit post: http://www.reddit.com/r/haskell/comments/dji4v/papers_from_icfp_2010/. XenServer The paper http://anil.recoil.org/papers/2010-icfp-xen.pdf describes the XenServer project, and more specifically the management interface, which is written entirely in OCaml, by a team of ~10 people. They also have a bit of bin-packing code (http://xenbits.xen.org/xapi/xen-api.hg?file/95b9e4f1b9dd/ocaml/xapi/binpack.ml), but much simpler than the ganeti-htools project on which I'm working (no balancing or similar). On the other hand, it is interesting to see that they committed themselves to write the entire management suite in OCaml, as opposed to our Python plus just a few bits of Haskell. I envy them, very much so The fun tidbit was how stable they found the OCaml tool-chain. In three years, they had just one bug related to this (the tool-chain), a segfault due to wrong formatting code in the handling path of a seldom-triggered Python exception, which led to a %s to be translated as is to C code, which meant printf got the wrong specifiers. So in an OCaml project, a serious bug was due to lack of type checking in string formatting in a Python component Overall I have found interesting parallels between their experience and my own with Haskell; from is this language/tool-chain stable enough for use to concerns about using FP for a significant project (but of course, orders of magnitude difference between their case and mine). Super-compilation There were two papers on this topic; one at ICFP proper and one at the Haskell symposium. If I understood things right, super-compilation is the opposite of lazy evaluation. But let's start a bit back. First, programs written in a functional languages contain many pure function. Pure functions, being side-effect-free, exhibit many interesting properties, and one of them is that they permit decoupling of the computation of a value from the declaration of such computation. One technique derived from this is lazy computations. Lazy computation means that even though you write y = sin(x) + 1, the actual call to sin and the increment is not actually done until you need the actual value of y (not just for storing it in y, that is). Super-compilation is the opposite of this. While laziness postpones doing a computation to as late as possible, in the hope it won't be needed at all, super-compilation runs the actual computation way ahead of time, even before the program starts, that is at compile time. Since programs use input data at runtime, which is not known at compile time, the trick is to pre-compute as much as possible at this stage, given incomplete information; and the papers showed that it's possible to pre-compute much more than you'd usually believe. Optimising compilers already do some form of CAF (constant applicative form) optimisation, but the techniques presented in both papers are going beyond simple CAFs. The details are in the papers, and are complicated, but one simple example is converting this:

ones = map inc [1..]

(note that is an infinite list, and you don't want to fully compute that at any time, neither at compile nor at runtime), into:

ones = [2..]

The details on how this is done depend on the exact super-compilation implementation, and not all implementations can do the same optimisations, but in the presentations at this ICFP the idea was to split things into static/non-static parts, and build on that, or to do partial evaluation, etc. The result is that super-compilation shows significant increases in speed (in some synthetic benchmarks up to 80%), with a few benchmarks not being sped up at all, but most are. The downside is an explosion in code size, as many more things are pre-computed. Still, as a research topic, this is very interesting. My own paper Surprisingly, it seems I survived giving my talk (just an experience report, not actually fancy stuff like the rest). Either the people actually found it interesting (less likely), or they were very polite (more probably). Anyway, the paper is on the papers page (shameless self-promotion) (if you care). Haskell symposium This is co-located with ICFP, and is more practical than ICFP (which is, as I said, way too much math). The papers are again available on reddit: http://www.reddit.com/r/haskell/comments/dkzn4/papers_from_the_haskell_symposium_2010/. Orc: Concurrent Orchestration in Haskell How to easily write code for synchronising concurrent work? As an example, how complicated is to solve this problem:

[from the Orc literature] we might wish to contact two airlines simultaneously seeking price quotes. If either quote comes back below a threshold price, say $300, then let's buy a ticket immediately. On the other hand if both quotes exceed the threshold, then buy the cheapest ticket. Additionally, buy a ticket if the other airline does not give a timely quote, or notify the user if neither airline provides a timely quote.

Now, in my experience, this would require manual management and synchronisation of threads, and for example in Python the early abort of querying the price from airline B if airline A returned a good price would be non-trivial; in addition, adding two extra conditions would be again not a simple composition of rules. In Orc however, it takes all of 10 lines of code to do this, safely. I won't copy the code here, see the paper for details, or the API docs. And the best part is, this is just a cabal install orc away! I'll be very interested to see how I can use this in practice, as it is seems indeed a very powerful library. Nikola: Embedding Compiled GPU Functions in Haskell Interesting project. Using almost 100% Haskell code, and it marshalls the data to/from the GPU; in the example given, the performance is as good as hand-written CUDA code of course, this doesn't happen in all cases. It it's interesting how they manage to compile the GPU-related code to actual object code at Haskell compile time, which makes it transparent for the user. Given the prevalence of high-speed GPUs, this could be a nice way to utilise them without learning yet another language (or two, since NVidia and ATI have different stacks). They've also developed some interesting techniques (e.g. manual control of sharing, to prevent inlining) as part of their project. Scalable Event Handling for GHC This is a paper co-authored by Johan Tibell of Google Switzerland and Bryan O'Sullivan of Real World Haskell fame. Very interesting serving 20K QPS from a Haskell process while having 16K+ idle clients connected:

[ ] the performance of the epoll back end does not begin to fall off significantly until we have 50,000 idle connections open.

The talk started with the idea that we're on the path to serving 10 clients from a single machine, and how to improve Haskell's I/O manager to achieve (almost) 10 concurrent clients. The slides (which I don't have a link for) were a bit more cool on numbers than the paper. Oh, and this will come with GHC 7.0, for free An LLVM Backend For GHC The eternal fight to get better than the C backend in other words, to not have to translate Haskell to C It is interesting to see how many languages target LLVM nowadays, as opposed to plain old C via gcc. A fun trivia item was that, according to the author, there are many features in LLVM that are not actually used by 90% of the languages targeting it (e.g. the garbage collector) (if I heard correctly in the talk). The results are interesting, although not too much overall speedup is gained; this seems to be due to the hard-to-optimise Cmm intermediate language inside GHC. In any case, a few benchmarks get more than 10% speedup, even in the current form. This will also come in GHC 7.0, although not enabled by default; probably needs to mature some more Conclusion I've enjoyed this conference a lot, and I've learned a lot from it. Given that many of the talks are about research topics, it's harder to apply them in day-to-day work, but I think the pay-offs will be long term rather than immediate.

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?

• There is no Plan B: why the IPv4-to-IPv6 transition will be ugly
• Scanner looking under clothes has already been misused at Heathrow.
• Landell Webcasting - interesting alternative for <ahref>DVSwitch with simple setup.

I travel pretty regularly, about 35% so far in 2010. When it goes wrong, travel can be exhausting, frustrating, complicated, stressful and even debilitating. I m always looking for ways to make my trips run more smoothly. On a recent flight to Taipei, I wrote down a few of the techniques which I ve successfully put into practice and found helpful. This is not an exhaustive list; I ve omitted a lot of the common and obvious tips I ve seen elsewhere.

1. Make a packing list. This one may be obvious, but a lot of people neglect it. Perhaps they think making lists is boring and fussy, but really, it isn t. Without a packing list, it s easy to forget to do the things which will make your trip better. Use it every time, and bring a copy with you (or store it online) so you can add the things you wish you had brought or done. A simple, ever-improving packing list is the most effective technique I have found for making travel less stressful and more enjoyable.
2. Carry a water bottle with a tight-fitting lid. I use a 32oz Nalgene bottle, which fits nicely into the seat next to me or under an armrest, and gives me enough water for even the longest flights. I fill it up after passing through security, at a cafe, bar or lounge, and generally decline the beverages offered by the cabin crew. Staying hydrated helps me feel better during the flight, and leaves me with less malaise when I arrive. I don t need to manage a tray table or armrest full of cups and other debris, so I can sit more comfortably, with the tray table folded away.
3. Consolidate essential items using multipurpose equipment. For example, invest in a power adapter which has USB sockets onboard, and carry USB cables instead of wall chargers. Versatile items like this save on space and weight. I can charge two devices this way, but the equipment is smaller and lighter than even a single wall charger.
4. Learn how to sleep on an airplane. Getting some sleep on a long flight really helps to offset the effects of traveling. There are several resources out there with practical advice on how to do it. One thing which really helped me was to buy a high quality eye mask which blocks out all of the light in the cabin. The one I use looks a little funny and is not cheap, but is very comfortable and effective. It s made of memory foam with a soft, washable cover and works much better than the ones the airlines give away for free. I no longer bother with a neck pillow, and use the flaps built into the seat to lean my head against. I m surprised at how many people don t know about this common aricraft feature: virtually every long-haul seat has something like this, even in economy, though it may not be obvious how to use it.
5. Buy duplicates of things like toiletries, and keep them in your travel kit so you don t need to pack your everyday items (and risk forgetting them) each time. The less packing you need to do, the less time it will take, and the less opportunity there is for mistakes. This also saves time unpacking when you get home, and lets you buy a smaller size of the item where available.
6. Optimize border crossings Carry the forms you ll need for customs, immigration, etc. in your carry-on. They don t always provide them at the counter or on board the plane, and it s a hassle to rush to fill in the form at the last minute. If you have a few of them with you, you can fill them out early (perhaps even before you fly) and then hustle to the front of the queue. For countries you enter frequently (especially your home country), programs like Global Entry (US) and IRIS (UK) will save you a lot of time by allowing you to use an automated kiosk to cross the border.

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.

shapado.debian.net Since a few hours, a Shapado instance for Debian is available at: Shapado is a Question and Answer (QA) website, meant to provide user support to the community, by the community. Another way of seeing it is as a skill exchange website: users can ask questions about stuff they don't know and other users, possiby more expert on that topic, can answer those questions; everyone can then use peer review to evaluate and sort answers. Several proprietary web applications are based on the above notions and have proven useful for user support in several contexts, including other Free Software distributions. Shapado on the other hand is Free Software released under AGPL; as such it's the best match to give a try to something similar in the context of Debian. Shapado has also a couple of other niceties, e.g. offers login via OpenID and supports questions/answers in multiple languages. Will it work for us?
Will it not?
It's up to the community. This kind of user support works when it reaches a critical mass of both "newbie" users in need of help and of "expert" users willing to help them. No matter your category, give it a try: go to the website and look around, you'll probably find a question to ask, a question to answer, or an answer to evaluate. Acknowledgements

• the Shapado developers
• Patrick Aljord for hosting support
• Fernando C. Estrada and Luis Uribe for admin / moderation work (by the way, they are looking for help)
• Jorge Castro for pinging me about this idea

---

Update: add mention of multi-language support

For some time, I've had this idea brewing for how the 'net would work without DNS. Initially I was mostly thinking of how to get rid of the dark side of the registrar business, but it appears that maybe it could help with security in general too. It may not be feasible at all, or I may have forgotten extremely crucial points. I'm not a DNS guru, so bear with me and consider this as a thought experiment. This is, however, a proposal for how the Internet could be made truly decentralized, or acentric. Made so, because it currently is very centralized on at least two counts: the DNS is an inherently hierarchical structure of authority; and so is the situation with the SSL certificates used for securing websites. Let's start with DNS, if you will. Basically, the idea is to replace the current Domain Name System, which is centralised in nature (even if subdomains can be delegated) with a fully decentralised system with no central authority. The point of current DNS is to map names to IP addresses in a unique way. It currently works by registering a this name is managed by such-and-such server, ask for details at such-and-such IP address message. Of course, since there's only one namespace (or a limited number thereof, if you consider that TLDs are different namespaces), there needs to be a central authority to resolve conflicts, because some names will be more popular than others. I propose to start with a cryptographic key pair (think GPG key). Anyone can create their key pair; we assume that it's extremely unlikely for two people to generate the same keys, and that it's also very hard for two people to generate keys with the same fingerprint. By (being the only one) knowing the secret part of a key, I am the authority on what can be signed with it. I could for instance sign records that say that www points to this set of IP addresses, and smtp points to that other address. Within my area of authority, which is to say within my domain. Which is identified by the fingerprint of my key pair. What do we have so far? A mechanism that allows in a decentralised way to verify who's authoritative on the F5566852EB92BD779CF137190EA756B5144843F5 domain . In DNS terms, more probably F55...3F5.some-tld. Now let's publish the signed records on a decentralised peer-to-peer network. I'm not up to date with the latest trends in that domain, but I think something like Gnutella or Freenet would qualify, since it doesn't need central hubs but only an initial list of nodes, and it does automatic discovery of new nodes. Projects such as the FreedomBox (name likely to be changed) will probably help with that. Anyway, when looking up www.F55...3F5.some-tld, the resolver gets the signed record (and the public part of the key) from the P2P network, checks the signature, and uses the contents of the record to determine the IP address. No central or delegated registry involved at any point. Lesser risk of a single point of failure, which means better resilience against outages. Also, a better resilience against DNS-based censorship, be it promoted by non-democratic states or by greedy corporations. Of course, F5566852EB92BD779CF137190EA756B5144843F5 isn't a terribly easy name to remember or transmit. But the string of hex could be presented to the user in some other form easier to recognize for people without geek super-powers. My favourite would be the bibi-binary representation, but I'm told that the bubble-babble method works equally well. It would still be unreasonable to expect people to remember such names, and especially to type them into their web browsers or e-mail agents. A possible solution to that would be to use a short form, such as 144843F5 (or its bibi-binary equivalent), complemented by a visual representation of the full fingerprint such as the one SSH does. That pair could be displayed on business cards, email signatures, glossy brochures, advertisements and so on, and allow users to just type the strange word or flash the 2D barcode, check that the funny picture matches (in case the strange word returns several results), and get the website they want. Which they can of course bookmark under a name they can remember, probably even the same name that everyone else uses to bookmark that website. And nothing precludes convenient directories mapping names to full URLs (like search engines currently do) as long as users check that the visual representation of the site they go to matches what they've seen elsewhere. That elsewhere could, of course, take advantage of the natural web of trust that emerges in of GPG-using communities. If I'm directed at a website whose key I don't immediately recognize, then I can see who trusts that key to be legitimate (by checking the signatures), and who trusts them, and so on. Ultimately, the decision is mine to make, and mine only. In any case, once I know what URL I want to visit, I can be sure this DNS replacement will give me the right IP address (or addresses). DNS servers replying with advertisement sites instead of correct ones, and DNS-based filtering, will be things of the past. Of course, having the right IP address only solves the attacks on the DNS part. Eavesdropping can also happen by diverting traffic at the IP level. But we have a trustable way to know information related to a domain, so let's use it: the signed record can also contain the fingerprint of cryptographic keys (SSL or SSH or whatever). So we can be sure we're actually talking to the correct server, rather than to some man-in-the-middle spy. With the same guarantees of correctness as the ones for the DNS, backed by the web of trust and out-of-band validation. Again, we get rid of the hierarchy of certification authorities , some of which have been known for helping organizations get at the (supposedly secret) data people exchange over the net. To summarize: with this scheme, if I know the site I want to access is F55...3F5, then I can be certain that a) I get the right IP address for it and b) I'm actually talking to it. And nobody in-between can intercept the traffic, if the site is properly administrated and its private key is kept secure. And from the site admin's point of view, there's no need to trust DNS registrars and SSL certification authorities not to fool around with the data, or blackmail me into paying increasing fees for keeping my URL working or my SSL key certified. There's still the problem of the allocation for the IP addresses themselves, but two major parts of the centralized and hierarchical net can be gotten rid of. There are proposals attempting to fix part of the problems already, but they're incomplete. DNSSEC only solves the authentication of DNS records, not the centralisation problem. 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). This is of course only a rough draft, full of technical considerations yet certainly not exhaustive. I've thought about it though, and I believe there are no theoretical problems with the implementation of such a scheme (apart for the handling of expiration and revocations, probably). The main obstacle to mass-adoption I can envision is the UI part, and the entrenched habit of just typing a keyword into a search engine and implicitly trusting its results, then blindly trusting the website itself; but even if mass-adoption isn't reached, I can't see anything wrong with giving those who want to be careful a more secure Internet.

Prospective Debian contributors typically follow this process:

1. Read the New Maintainers' Guide.
2. Find something they want to package.
3. Create a package.
4. Email the debian-mentors mailing list asking for someone to review the package, and if it passes review, upload it.
5. Feel increasingly lonely and sad, as the days pass without a reply on the list.
6. (Optional) Blame themselves when no one seems to care, when in fact they submitted a perfectly fine package.

Okay, so I'm exaggerating that last point. But I'm very interested in improving the culture of Debian, like I promised as follow-ups for that Debian for Shy People talk. I was talking about the email list on the #debian-mentors IRC channel. I got this vote of confidence from andrewsh:

<andrewsh> silence is bad

When there are humans involved, silence isn't always golden. So now I have a plan: Niels and I promised that any email to debian-mentors will be answered within four days. Maybe we'll say, "Sorry, we all seem to be busy!" Or maybe we'll say, "I'll try to review that next Thursday." The goal is to replace self-doubt and worry among contributors with feedback and clear expectations. (Thanks to Karen Rustad for help with editing.)

I recently spent a little time adding support for isohybrid images to d-i. isohybrid is a tricksy boot sector hack that allows copying a CD image direct to a USB stick and booting it. I used it in anger for the first time yesterday, and it worked so well compared with the old method of booting d-i from USB sticks that I feel I need to blog about it so others can enjoy the fun.. The documentation on the web site has not caught up yet, but this is already usable with current d-i daily builds. For now only in the netboot mini.iso. That can be written directly to a USB stick or USB disk to make it boot d-i.

cat mini.iso > /dev/sdX

The netboot mini.iso is so named because it's functionally identical to netbooting d-i. Except without the need to set up a tftp server. Besides being a 16mb download that will fit on even your oldest USB stick, another advantage to using the mini.iso is that you don't even need to use a separate USB stick to boot the installer. You can write the mini.iso directly to the same disk that d-i will be installing to! (Particularly handy for installing debian to USB disks.) (This is also very handy for d-i development and testing, since a mini.iso can be written out to a USB key about as fast as a test machine will post..) adding firmware I also arranged for there to be a second partition on the mini.iso. The firmware partition is most easily accessed by unplugging and replugging the drive after writing the mini.iso to it -- then it will show up as /dev/sdX2 (or "Firmware" in a GUI). If you need to add firmware to d-i, you can just mount it and extract the firmware tarball into it. d-i will then automatically find, use, and install the firmware. isohybrid with other Debian CD images All this will also work with other larger Debian CD images, but we're not yet building the larger images with isohybrid, due to issues with jidgo. However, you can just run isohybrid yourself (from the syslinux package) on the CD image you download, and if it's got a recent version of d-i on it, d-i will be able to find and use the hybrid CD image after booting. That doesn't add the firmware partition to the image. If you need to do that, you could use this script.

Thanks to the efforts made by Steffen, and recently the great work from Daniel(Boinc s Ubuntu maintainer, and now member of pkg-boinc team) Squeeze will have boinc 6.10.58 \o/. If you are curious you can see all changes since 6.2.14(Current version on lenny) http://packages.debian.org/changelogs/pool/main/b/boinc/current/changelog The main feature for this release is that now nvidia and ATI users can use their GPU with boinc(they need to download the non-free libs and apply some workarounds). And if you read trough here, and you are a boinc user and want to help us, please send an email to pkg-boinc-devel@lists.alioth.debian.org, we need freshblood there

A month or so ago, I published a paper with Leah Buechley that is mostly an analysis of how the LilyPad Arduino has been used. I read an earlier draft last year and loved it so, when the opportunity arose, I was honored to help out as the paper evolved. LilyPad is a microcontroller platform that Leah created a few years back and that is specifically designed to be more useful than other microcontroller platforms (like normal Arduino) in the context of crafting practices like textiles or painting. Leah's design goal with LilyPad was to create a sewable microcontroller that could be useful for making things that were qualitatively different from what most people made with microcontrollers and that, she hoped, would be of interest to women and girls. Our paper tries to measure the breadth of LilyPad's appeal and the degree to which it accomplished her goals. We used sales data from SparkFun (the largest retail source for both Arduino and LilyPad in the US) and a crowd-sourced dataset of high-visibility microcontroller projects. Our goal was to get a better sense of who it is that is using the two platforms and how these groups and their projects differ. We found evidence to support the suggestion that LilyPad is disproportionally appealing to women, as compared to Arduino (we estimated that about 9% of Arduino purchasers were female while 35% of LilyPad purchasers were). We found evidence that suggests that a very large proportion of people making high-visibility projects using LilyPad are female as compared to Arduino (65% for LilyPad, versus 2% for Arduino). Digging deeper, qualitative evidence suggests a reason. LilyPad users aren't just different. The projects they are making are different too. Although LilyPad and Arduino are the same chips and the same code, we suggest that LilyPad's design, and the way the platform is framed, leads to different types of projects that appeal to different types of people. For example, Arduino seems likely to find its way into an interaction design project or a fighting robot. LilyPad seems more likely to find its way into a smart and responsive textile. Very often, different types of people want to make these projects. Leah and I believe that there's a more general lesson to be learned about designing technologies for communities underrepresented in science, technology, engineering, and mathematics (STEM) -- and for women in particular. The dominant metaphor in the discussion on women in computer science is Margolis and Fisher's idea of "unlocking the clubhouse." The phrase provides a good description of the path that most projects aimed at broadening participation of women in computing projects seem to take. The metaphor is based around the idea that computing culture is a boys' club that is unfriendly to women. The solution is finding ways to make this club more accessible to those locked outside. It should go without saying that we share Margolis and Fisher's goal of increasing participation of women in STEM. That's LilyPad's point, after all. It it hopefully also clear that we're supportive of, and involved in, projects working to remove systematic barriers to participation by women and other groups. That work must continue. But I also think that Leah's work with LilyPad suggests another way forward based on addressing issues of self-selection that will affect even the most welcoming technological communities. Here's what we say in our paper:

Our experience suggests a different approach, one we call Building New Clubhouses. Instead of trying to fit people into existing engineering cultures, it may be more constructive to try to spark and support new cultures, to build new clubhouses. Our experiences have led us to believe that the problem is not so much that communities are prejudiced or exclusive but that they're limited in breadth--both intellectually and culturally. Some of the most revealing research in diversity in STEM found that women and other minorities don't join STEM communities not because they are intimidated or unqualified but rather because they're simply uninterested in these disciplines. One of our current research goals is thus to question traditional disciplinary boundaries and to expand disciplines to make room for more diverse interests and passions. To show, for example, that it is possible to build complex, innovative, technological artifacts that are colorful, soft, and beautiful. We want to provide alternative pathways to the rich intellectual possibilities of computation and engineering. We hope that our research shows that disciplines can grow both technically and culturally when we re-envision and re-contextualize them. When we build new clubhouses, new, surprising, and valuable things happen. As our findings on shared LilyPad projects seem to support, a new female-dominated electrical engineering/computer science community may emerge.

I have a strong belief that computing can be an empowering tool and that expanding users' control over technology is a critically important issue. Our paper argues that we should attempt to expand participation in computing by broadening the possibilities of computing, rather than only by broadening participation in extant, computing organizations, projects, and genres. Even if computing and electrical engineering communities were perfectly welcoming (which they are not) most people (both male and female, but disproportionately female) will choose not to participate. Building new clubhouses requires creativity of its proponents and risks charges of reinforcing stereotypes and existing status hierarchies. But, executed carefully and well (as I believe LilyPad has been), it suggests ways to reach the majority of people that no "unlocking" project will ever seem relevant to.

A new month has just begun, it s again time for a few suggestions of free software projects to flattr. This is Flattr FOSS in action. Enough said, let s start with my suggestions:

1. The battle for Wesnoth is a great turn-based tactical strategy game (I spent countless hours on it a few years ago). It s been a long time I have not played on my computer, but opensource games should be encouraged. Lack of good games is one of the few recurring complaints that come back from people trying out Linux for the first time. And The battle for Wesnoth is a very active project, so there s no reason to not support them.
2. Shutter is the next-generation tool to take screenshots, it s quite popular at least in Ubuntu and it can easily replace the default gnome-screenshot application. You can apply various effects on the fly, and upload the resulting pictures directly on image hosting sites (Flickr, Picasa, etc.).
3. Awesome is a highly configurable window-manager for X. I use it as a tiling window manager (windows are arranged to always fill the entire screen). Its configuration file consists of LUA code so it s for power-users mainly Julien Danjou started Awesome but he has also written many other small nifty tools, discover them in his Flattr profile.
4. Sparkleshare is a new collaboration tool that will transparently synchronize a folder between several computers/persons and inform you in real-time of changes. Under the hood, it uses public Git hosting sites (like Github or Gitorious) to store and exchange the data. In some aspects, it s like Dropbox s shared folders. You can also read Linux Weekly News review of it.
5. My last suggestion is to support Harald Welte and his projects. Click here to see his Flattr profile. He is someone in the free software world. First of all he s a famous kernel hacker, he wrote much of the firewalling code (known as netfilter). He also initiated gpl-violations.org and ensured that the GNU General Public License was respected when he found out companies that failed to meet the terms of the license. Lately he has been reverse-engineering the whole GSM stack pointing out security problems as he discovers them with the goal to provide a free implementation of everything (first results are in projects OsmocomBB and OpenBSC). Isn t that impressive?

That s it for this month. By the way, did you tell your friends how easy it is to support free software with Flattr? Share this article with them and let them join Flattr FOSS too. No comment Support my work

There was a lot of news coverage like Credit card fees being imposed by councils, says Which? earlier this week. People seemed outraged that councils were making a small surplus over the year in total. Interviewees suggested that councils should just include the cost of taking payments in the amount charged. Of course, councils are sort-of not-for-profit, so they ll just set prices to include the credit card fees and make a small surplus on other cheaper forms of payment over the year in total. So everyone who uses bank transfers will pay more because credit card fees are high! Will that be next year s scandal? Presumably that s what happens in France, Germany and other countries where sellers can t charge more for credit card payment. That, or you just don t accept credit cards, like many German retailers never used to. What else can they do? It s a bit odd of Visa to claim it costs more to accept other forms of payment. Cheques are horrendously expensive if you only get a few, but seem to get cheaper if handled in bulk. Domestic bank transfers and cash also seem cheaper than Visa to me. Sellers seem to be asked explicitly to assume much more fraud risk in order to accept credit cards, too. Mind you, with the amazingly slack approach of most US retailers to cards (no chip-and-PIN and they usually don t bother to even check the signature I cut up the card I used in the USA when I arrived home), I m surprised there s not more card fraud. I m also a bit surprised Bath and North East Somerset (which neighbours my home district) is paying 2% on credit card transactions. Our co-op has been offered deals about as good as that and we don t do anything like as many transactions. We ve not yet taken one up because the setup paperwork is a pain and the setup and maintenance fees usually suck. It feels like it doesn t matter what you do with money, bankers still get rich. Even though I keep looking (like in 2007), it ll probably happen: we need to act again, because some overseas customers seem unwilling or unable to register with a site to pay (and some payment sites have ethical questions too), while international bank transfers are even more expensive and an even bigger pain. Besides card payments, we re considering opening a currency trading account and a Euro bank account. Anyone done these and do you think they re worth it or not? And do any Eurozone banks allow a UK company to open an account without a member visiting in person? I ve found few possibilities, after looking at banks in seven countries so far.

After being noticed in blog comment about another theme for phpMyAdmin, I started to look for other hidden contributions for phpMyAdmin and I was surprised how many people did not even try to submit their code upstream. Have you ever considered trying to contact upstream? Quick search on SourceForge.net revealed: VisualMCD for phpMyAdmin

An Add-on for phpMyAdmin which enables user to create PDF Schema and Relation with a simple click and mouse moves. No more fastidious typing of table coords needed to create the PDF Schema.

Even though the SF.net history says it was released 440 days ago, it is actually dated back to 2003 and it obviously is not compatible with current code base. Also we have similar feature for few years now, so it was just duplicated effort. phpMyAdmin theme: Paradice

Paradice is a Theme for the popular web-based database administration tool phpMyAdmin. You will find the development version here. All official releases will be made by the phpMyAdmin project.

This theme is just developed externally, but you can get it from our themes page phpMyAdmin persian project

phpMyAdmin persian project

Something what seems to be dead from beginning. Anyway if you want to translate, please use our translation server. MySQL Form Generator pour PHPMyAdmin

C'est un outil pour crr un site autour d'une base. Un gnrateur de formulaire. Sur base d'une DB Mysql.Projet prvu pour tre intgr PhpMyAdmin.mysql -> formulaire HTML+javascript avec le code PHP pour trater les soumissions de donnes.

Something we still don't have in phpMyAdmin, however the project is inactive for more than year. pmahomme

Clean, modern and easy to use phpMyAdmin theme.

Theme which started this search, however it seems to fail for me right now. phpMyDesigner

Plugin for phpMyAdmin. PhpMyDesigner is a tool written in PHP and Ajax. This CASE with WEB interface. ( MySQL )

This actually does not fit into this blog, because it is one of projects that got merged and are now part of our code base. phpMySchema

phpMySchema is a tool written in PHP for generating an ERD or otherwise graphical view of your MySQL databse over the web. It is being developed to be used as a standalone script and as a module for phpMyAdmin.

Generally it looks like an interesting addition, however we can quite well compete with this after this year's GSoC, which added ability to export schema in various formats.

Filed under: Phpmyadmin 0 comments

For once, not using that journal entry title to talk about my own. Someone posted a pointer to an opinion piece looking at productivity differences between the US and Germany to a private hierarchy I read. I know productivity numbers like this are somewhat disputed, but I don't want to get into that. What I'm more interested in is the analysis. Whether or not the US does significantly better or worse than other countries in this regard is hotly debated, but what isn't is that the length of typical work weeks for employees, particularly in IT, is not going down. Fifty or a hundred years ago, it was common to expect that the growth of automation would mean more leisure for humanity. There was, at the time, some argument over whether that would be a good thing, but it seemed to be a trend. This didn't happen here. The above article argues that the amount of vacation that US employees take is going down over time. And in IT it's common to hear about 50 hour weeks (or 80 hour weeks in startups). Little of that promise of increased leisure from modern technology seems to have happened in the US, although it seems to have happened somewhat in Europe; about all we managed was to get down to a 40-hour work week, which is now honored in the breech for a lot of exempt employees. And that was seventy years ago. Most of the scientific research that we have available is quite clear that working longer hours causes diminished productivity. Standard time management advice is to focus more and work in shorter intervals. Hours of unfocused work are considerably less effective than much shorter periods of focused work, recovery time is vital, and forcing oneself to work long hours leads to bad decision-making. Even in less cerebral and more repetitive work, such as some assembly line work, we've known for many decades that working longer hours leads to more accidents and more bad decisions, and there the costs of an accident are often much higher. So, why are we so dead-set on doing the exact opposite of what available evidence says is the best way to work? I think this is to some extent a Rorschach blot question: you're going to see the answer in this that fits your pre-conceived notions about what's dysfunctional about US workplaces. I rambled elsewhere about my own pet peeve: the overwhelming focus on money and short-term profit and cutting cost, which I think leads to a lot of the nasty employment abuses in the US. But here I want to raise a different point: as the article says, we work long hours because that's what we're measured on and rewarded for. We work unproductively for many of those hours partly because it's impossible to be productive for that many hours. We get used to feeling intermittantly unproductive at work; it becomes normal. And in many jobs, particularly in IT, we don't measure ourselves by results because we have no idea what a reasonable level of results actually is. Management gets a lot of blame for failure to manage by results rather than by artificial measures like attendance and time worked (or tickets closed, or hours logged against customer requests, or similar trivially manipulatable and artifical measures). But I think this goes deeper than management. I think even we ourselves, with as good of knowledge as anyone could possibly have of what our jobs are and what good results look like, don't have a clear idea of how much to expect from ourselves on a daily basis. I know from time management exercises that I wildly mis-estimate tasks and don't have a good feedback loop to get better at estimates. I also tend to plan towards maximums rather than the average. If I have a very good day, I try to work at that level and hold myself to that level of work, rather than trying to find a long-term average. And my perceptions about what results constitute good results vary wildly based on the most recent events and surrounding context (such as whether a project is late), even though I know that my basic work capacity is not going to change significantly because a project is late. If we want to change how we measure work, I think this may be the place to start. We can't ask managers to measure us by results if we don't even know what that measurement would look like. I'm going to start asking myself some new questions: What is the average amount of work I can get done in a day? What's the standard deviation? Is there some way that I can measure this over time so that I'm not fooling myself based on circumstances or temporary surges of productivity, since my day-to-day productivity seems to have a lot of "noise"? What realistically constitutes finishing a week's worth of work? When am I "working" but not accomplishing something, and more importantly, why am I doing that? What broke when that happens? I'm firmly convinced that one of my personal breakthroughs in time management will happen when I can stop "working" when I'm not being productive. Whenever I manage this (rarely, right now), I both find I needed the break and find that I can return far more productive than I was before I took the break. But usually I continue to "work" unproductively, clocking hours without creating results, and feel both guilty about the lack of results and even less productive. That's the trap that I think this article is pointing at.