Election TomorrowOn Saturday we will have a Victorian state election. As usual for state elections most people will vote on issues related to the federal government, the mainstream media has little coverage of state politics and people seem to vote on what they see on TV. Presumably that means we have a good chance of having a similar situation to the last Federal Election where the Labor and Liberal parties each won 72 seats in the lower house and Labor formed a coalition with the Greens MP and three independents.The independent MPs didn t give much explanation of the reasons for their choices. But it seems that a large motivating factor was the Greens success in the senate, as Labor was more willing to work with the Greens that meant that if a Liberal based coalition had won in the lower house there was a good chance of a Double Dissolution.The Liberal party can t make dealsIn a world where sanity prevailed the result of this would be the Liberal party firstly adjusting their policies to appeal to Greens voters and secondly trying to make some deals with the Greens at a high level to allow the possibility of a Liberal/Green coalition government. While there are substantial policy conflicts between the Liberal and Green parties it does seem possible to get a coalition working if both sides accept that they won t get everything that they want. Forming government and getting only some of your policy implemented seems like a better option than being in the opposition and getting almost none of your policy implemented. Also there is no reason why we couldn t have a Liberal/Labor coalition government in the next decade it seems unlikely that any election will deliver a result that doesn t have Liberal + Labor comprising more than 50% of the seats in both houses.But it seems that sanity doesn t prevail. The Liberal party have put the Greens below Labor on their preferences for the upper house and on their How To Vote cards for the lower house [1]. This greatly increases the probability of Labor scoring an outright win. It also seems likely to drive a wedge against the conservative voters who want to conserve the environment.The Sad State of the Liberal PartyKevin Andrews (Liberal MP and former minister) wrote a strange and amusing diatribe titled The ideological drive behind the Greens [2]. Here is what I regard as the best part:First, those who vote Green as their primary vote: This is the Don s Party group that used to be in the ALP in the 60s and 70s: young university students or graduates, frequently working or still studying in academia, no kids, often gay, arts and drama type degrees or architecture where they specialise is designing environmentally friendly suburbs, agnostic or atheist, often US or Canadian refugees from capitalism, but well paid in professional consulting or media jobs. According to the CIA World Factbook [3] the median age of Australians is 37.5, the majority of the population were born in 1972 or later. The film Don's_Party was released in 1976 and was about the 1969 election. While Kevin Andrews was old enough to remember the 1969 election clearly the majority of the Australian population weren t even born before that election and isn t old enough to have watched the movie when it was in the cinemas. Kevin is making it quite clear that he and his party represent a time that is past. The rest of that paragraph is filled with strangeness that is a good sample of the rest of his article.The sad thing is that he seems to think that this appeal to the minority of people who are old enough to remember the 1969 election, bigoted enough to appreciate the discrimination against homosexuals (which is a long standing Liberal policy), and politically clueless enough to support McCarthyist policies against alleged communists.We need a decent and sane conservative party to represent the decent and sane Australian citizens who are politically conservative. I am beginning to doubt that the Liberal party could ever be reformed enough to become such a party.

• [1] http://www.abc.net.au/7.30/content/2010/s3074524.htm
• [2] http://www.abc.net.au/unleashed/41010.html
• [3] https://www.cia.gov/library/publications/the-world-factbook/geos/as.html

Colin Watson is not a high-profile Debian figure, you rarely see him on mailing lists but he cares a lot about Debian and you will see him on Debconf videos sharing many thoughtful comments. I have the pleasure to work with him on dpkg as he maintains the package in Ubuntu, but he does a lot of more interesting things. I also took the opportunity to ask some Ubuntu specific questions since he s worked for Canonical since the start. Read on. My questions are in bold, the rest is by Colin. Who are you? Hi. I m 32 years old, grew up in Belfast in Northern Ireland, but have been living in Cambridge, England, since I was 18. I m married with a stepson and a daughter. I became interested in Debian due to the critical mass of Debian work happening in Cambridge at the time (and perhaps more immediately because my roommate was running Debian: hey, what s that? ), started doing random bits of development in 2000, and joined as a developer in 2001 (a really exciting time, with lots of new people joining who became integral parts of the project). I d only really been intending to do QA work and various bits of packaging around the edges, and maybe some work on the BTS, but then Fabrizio Polacco died and I took over man-db from him, and it sort of snowballed from there. I graduated from university shortly before becoming a Debian developer. I worked for a web server company (Zeus), then a hardware cryptography company (nCipher), before moving to work for Canonical in 2004, since when I ve been working full-time on Ubuntu. By this point, I suspect that going back to work in an office every day would be pretty tough. What s your biggest achievement within Debian or Ubuntu? One thing I should say: I rarely start projects. Firstly I don t think I m very good at it, and secondly I much prefer coming on to an existing project and worrying away at all the broken bits, often after other people have got bored and wandered off to the next new and shiny thing. That s probably why I ended up in the GNU/Linux distribution world in the first place, rather than doing lots of upstream development from the start I like being able to polish things into a finished product that we can give to end users. So, I ve had my fingers in a lot of pies over the years, doing ongoing maintenance and fixing lots of bugs. I think the single project I m most proud of would have to be my work on the Debian installer. I joined that team in early 2004 (a few months before Canonical started up) partly because I was a release assistant at the time and it was an obvious hot-spot, and partly because I thought it d be a good idea to make sure it worked well on the shiny new G4 PowerBook I d just treated myself to. I ended up as one of the powerpc d-i port maintainers for a while (no longer, as that machine is dead), but I ve done a lot of core work as well: much of the work to put progress bars in front of absolutely everything that used to have piles of text output, rescue mode, the current kernel selection framework, a good deal of udev support, several significant debconf extensions, lots of os-prober work, and I think I can claim to be one of the few people who understands the partitioner almost top to bottom. d-i is the very first thing many of our users see, and has a huge range of uses, from simple desktop installs to massive corporate deployments; it s unspeakably important that it works well, and it s a testament to its design that it s been able to trundle along without actually very much serious refactoring for the best part of five years now. I have a soft spot for man-db too. It was my first major project in Debian, starting out from an embarrassingly broken state, and is now nice and stable to the point where I recently had time to spawn a useful generic library out of it (libpipeline). What are your plans for Debian Wheezy? d-i has a lot of code to deal with disks and partitions. Of course a lot of it is in the partitioner, and for that we use libparted so we don t have to worry very much about the minutiae of device naming. But there are several other cases where we do need to care about naming, mainly before the partitioner when detecting disks, and after the partitioner when installing the boot loader. Back in etch, we introduced list-devices , which abstracted away the disk naming assumptions involved in hardware detection. In wheezy, I would like to take all the messy, duplicated, and error-prone code that handles disk naming in the boot loader installers, and design a simple interface to cover all of them. This has only got more important following the addition of the kFreeBSD and Hurd d-i ports in squeeze, but it bites us every time we notice that, say, CCISS arrays aren t handled consistently, and it s a pain to test all that duplicated code. I d also like to spread the use of libpipeline through C programs in the archive, which I think has potential to eliminate a class of security vulnerabilities in a much simpler way than was previously available. If you could spend all your time on Debian, what would you work on? I would love to systematically reduce the need for the current mass of boot loaders. There s a significant cost to having so much variation across architectures here: it s work that needs to be done in N different places, the wildly differing configuration means that d-i has to have huge piles of code to manage them all differently, and there are a bunch of strange arbitrary limitations on what you can do. The reason I m working on GRUB 2 is that, in my view, it s the project with the best chance of centralising all this duplicated work into a single place, and making it easier to bring up new hardware in future (in a way that doesn t compromise software freedom, as many proprietary boot loaders of the kind often found on phones do). Of course, with flexibility tends to come complexity, and some people have a natural objection to that and prefer something simpler. The things I don t quite have time to do here are to figure out a coherent way to address the specific over-complexity problems people have with the configuration framework while still keeping the flexibility we need, and to do enough QA and porting work to be able to roll out GRUB 2 at installation time to all the Debian architectures it theoretically supports. What s the biggest problem of Debian? Backbiting, and too much playing the man rather than the ball. With one or two honourable exceptions, I ve largely stopped reading most Debian mailing lists since it just never seems a productive way to spend time compared to writing code and fixing bugs; and yet I m conscious that they re one of the primary means of communication for the project and I m derelict in not taking part in them. I do find it a bit frustrating that people are seen primarily in terms of their affiliations. I suppose it s natural for people to see me as an Ubuntu guy , but I don t really see myself that way: I ve been working on Debian for nearly twice as long as I ve been working on Ubuntu, and, while I care a great deal about both projects, I ve put far more of my own personal time into Debian and I try to make sure that a decent number of the things I m involved with there aren t to do with work. Work/life separation is a good thing, not that I m very good at it. Generally speaking, when I m working on Debian, I m doing so as a Debian developer, because I want Debian to be better. When that s not the case, if it matters, I try to indicate it explicitly. You re working for Canonical since Ubuntu s inception. If you were Mark Shuttleworth, is there something that you would have done differently? We had many good intentions when we founded Ubuntu. We also had a huge amount of work to deliver, to the point where it wasn t at all clear whether it would be possible (the warty release was named based on the expectations of it, after all, and came out much more usable than we d dared to hope). In hindsight, it might have helped to be quieter about our good intentions, so that we could exceed expectations rather than in some cases failing to meet them. That might have set a very different tone early on. (Personally, I m happy I m not Mark. The decisions in my office are much easier to take.) It seems to me that the community part of Ubuntu is much more eager to cooperate with Debian than the corporate part. It s probably just that more and more Canonical employees are not former Debian contributors. Do you also have this feeling? Are there processes in place to ensure everybody at Canonical is trying to do the right thing towards Debian cooperation? Just to be clear, I m wearing my own hat here which, ironically, is a fedora rather than a company hat. It makes sense for Canonical to be taking on more non-Debian folks; after all, we can t simply hire from the Debian community forever, and a variety of backgrounds is healthy. As you say, it may well be natural that Ubuntu developers who don t work for Canonical are more likely to have a Debianish background, as it tends to take something significant to get people to switch to a very different family of GNU/Linux distributions, and changing jobs is one of the most obvious of those things. Certainly, there was a definite sense among the early developers that we were all part of the Debian family and cared about the success of Debian as well. As Ubuntu has developed its own identity, people involved in it now tend to care primarily about the success of Ubuntu. At the same time, pragmatically, it s still true that getting code changes into Debian is one of the most economical ways to land them; changes made in Debian or upstream land once and tend to stay in place, while changes made only in Ubuntu incur an ongoing merge overhead, which is not at all trivial. In many ways it s human nature to try to fulfil your immediate goals in the most direct way possible. If your goal is to deliver changes to Ubuntu users, then it s natural to concentrate on that rather than looking at the bigger picture (which takes experience). Debian developers often fail to send changes upstream for much the same reason, although there s more variation there because they re normally working on Debian of their own volition and thus tend to have wider goals; the economics are more or less parallel though. Thus, I think the best way to improve things is to make it the path of least resistance for Ubuntu developers to send changes to Debian. We re already seeing how this works with the Ubuntu MOTU group; if you send a patch for review, or work on merging a package from Debian, very often the response includes have you sent these changes to Debian? . We re working on both streamlining our code review through a regular patch pilot programme and requiring more code review for changes in general, so I think this will be a good opportunity to ask more people to work with Debian when they propose changes to Ubuntu. For myself, this may be obvious, but I notice that I m much better at getting changes into Debian when I already have commit access to the Debian package in question. All the work on improving collaborative maintenance in Debian can only help, for Ubuntu as well as for everyone else. It doesn t make so much difference for large changes that require extensive discussion, but there are lots of small changes too. Canonical is upstream of many software projects (unity, indicators infrastructure, etc.). Why aren t those software immediately packaged in Debian? Do you think we can get this to change? I m not sure what the right approach is here, particularly as I haven t been involved with much of that on the Ubuntu side. I suspect it would be helpful to look at this in a similar way to Ubuntu changes in general. It s understandable that those developers have getting changes into Ubuntu as their first goal. And yet, having code in Debian offers a wider, and often technically adept, audience, and most developers like having their code reach a wider audience even if it s not their first priority, particularly if that audience is likely to be able to help with finding problems and fixing bugs. It should be seen as something beneficial to both distributions. The hardest problems will be with things that aren t merely optional add-ons (which should generally be fairly non-controversial in Debian, given the breadth of the archive in general the existence of things like bzr and germinate as Debian packages was never a hard question), but which require changes in established packages. For example, gnome-power-manager in Ubuntu is built with application indicator support, and that s an important part of having a good indicator-based panel: a lot of the point of indicators is consistency. Since I do very little desktop work myself, I don t know exactly what would be involved in making it possible to choose this system based on a Debian desktop, but I think it s probably a bit more complicated than just making sure all the new packages exist in Debian too. Obviously you have to start somewhere. Is there someone in Debian that you admire for his contributions? Christian Perrier is absolutely tireless and has done superb things for the state of translations in Debian. And Russ Allbery, even aside from his fine ongoing work on policy, Lintian, and Kerberos, is a constant voice of sanity and calmness. Release management is incredibly hard work, as I know from my own experience, and anyone who can sustain involvement in it for a long period is somebody pretty special. Steve Langasek and I got involved at about the same time but he outlasted me by quite a few years. He deserves some kind of medal for everything he s done there.

---

Thank you to Colin for the time spent answering my questions. I hope you enjoyed reading his answers as I did. Subscribe to my newsletter to get my monthly summary of the Debian/Ubuntu news and to not miss further interviews. You can also follow along on Identi.ca, Twitter and Facebook.

11 comments Liked this article? Click here. My blog is Flattr-enabled.

My trusty somewhat-old laptop has been under the weather lately. It will not boot when it's cold, and it's fairly picky. ~20 C seems too cold already; so I have to heat it up at little.
Now that winter is coming, this needs to be done almost every morning, and that is extremely annoying. Does anybody have an idea of what could be wrong? It seems that the problem is not just a loose connection, as the laptop goes up in stages:

1) when the power button is pressed the power LED will blink for a split-second and nothing will happen,
2) the LED will light up for slightly longer, but the laptop still will not boot,
3) the laptop starts booting but shuts off spontaneously after while on the BIOS screen,
4) the laptop goes through the BIOS screen, but shuts down before showing the boot menu.
Past that, apparently the CPU generates enough heat for stable operation.
This is fairly complicated behaviour for a hardware problem. I wonder, maybe the power supply is at fault? Any ideas, anyone? This is a good excuse to buy a new laptop, but I would rather not splurge right before Christmas season.

Yesterday and today I attended Ruxcon the leading technical security conference in Australia [1]. The first lecture I attended was Breaking Linux Security Protections by Andrew Griffiths. This included a good overview of many current issues with Linux security. One thing that was particularly noteworthy was his mention of SE Linux policy, he cited the policy for the FTP server as an example of policy that can be regarded as too lax but also noted the fact that to get SE Linux used the policies had to be more liberal than we might desire. There is probably scope for someone to give a good lecture about how we are forced to make uncomfortable choices between making security features stronger and making them more usable.The next lecture I attended was Breaking Virtualisation by Endrazine. It makes me wonder how long it will be before someone cracks one of the major cloud hosting services such as EC2 it s not an appealing thought.Billy Rios gave a really interesting lecture titled Will it Blend? about blended exploits. The idea is to try and find a few programs which do things that are slightly undesired (arguably not even bugs) but which when combined can result in totally cracking a system. One example was a way of tricking IE into loading a DLL from the desktop and a way of tricking Safari into saving arbitrary files to the desktop, combine them and you can push a DLL to a victim and make them load it. Learning about these things can really change the way you think about misbehaving programs!Ben Nagy gave an interesting lecture about Prospecting for Rootite . His systematic way of finding test cases that cover a large portion of the code of a large application such as MS-Word seems quite effective. Once you have test cases that cover a lot of code then you can use fuzzing to find flaws.Edward Farrell gave an informative lecture about RFID Security , I didn t really learn that much though, he confirmed my suspicions that RFID implementations generally suck.Mark Goudie gave a very informative lecture titled We ve been Hacked! What Went Wrong and Why . Mark works for Verizon and often with the US Secret Service in investigating security breaches. He presented a lot of information that I have not seen before and made some good arguments in support of companies being more proactive in protecting their systems from attack.Stephen Glass and Mark Robert gave a lecture titled Security in Public Safety Radio Systems which mainly focussed on digital radios used by the Australian police. It would be good if the police got people like them to test out new kit before ordering it in bulk, it seems that they will be using defective radios for a long time (it s not easy or cheap to replace them once they are deployed).Edward Farrell gave an interesting lecture titled Hooray for Reading: The Kindle & You about hacking the Kindle. Unfortunately they haven t worked out how to get GUI code going on a hacked Kindle yet so there are some limitations as to what can be done.I think that the most interesting lecture of the conference was This Job Makes you Paranoid by Alex Tilley of the Australian Federal Police. He gave some interesting anecdotes about real cases to illustrate his points and he advocated the police position really well. I ve attended several lectures by employees of law enforcement agencies, but none of them demonstrated anywhere near the understanding of their audience that Alex did.The last lecture I attended was Virtualisation Security State of the Union by David Jorn of Red Hat. He gave an interesting summary of some of the issues including mentioning how SE Linux is being used for confining KVM virtual machines.Ruxcon was a great conference and I definitely recommend attending it. I have to note that even though there are police attending and lecturing it s not entirely a white-hat affair. One thing that I hope they do next year is to get a bigger venue. The foyer was rather crowded and because it had a hard floor was really noisy between lectures. Space and carpet are two really important things when you have lots of people in one room!

• [1] http://www.ruxcon.org.au/

About this time last year, I spent a while talking about how Barnes and Noble were failing in their GPL obligations. It took them about two months to release some source code that didn't actually correspond to the hardware - they finally provided it in March, more than three months after shipping the device.

The Nook Color is now shipping. Guess what Barnes and Noble aren't providing yet?

The flood of generic Chinese Android devices with no source code makes it very easy to think that GPL adherence is something that's only problematic with devices sourced from countries with poor records in IP enforcement. In reality, it's a problem everywhere. Barnes and Noble are a US company and the contractors for the Nook were based in Canada. They're aware enough to include the GPL notice in their documentation, but not concerned enough to make sure that they actually posses the source code that they're legally obliged to provide.

I'm glad to see that the Linux Foundation are providing resources to ensure compliance, but it's likely that this is going to continue being a problem until we start engaging in more visible efforts to educate companies about their legal obligations. The idea that a company like Barnes and Noble would ship copies of Windows without paying the appropriate license fees is pretty implausible, but they seem perfectly happy to engage in for-profit copyright violation if nobody's going to chase them down. It'll be interesting to see if this trend continues, or if we start making a sincere effort to remind vendors of their obligations.

In other GPL violation news - Fusion Garage have promised me that they'll provide the source code to their GPLed components on Monday. Given that the device has been end of lifed this is obviously pretty inept. Investors should realise that they're putting money into a company that has knowingly been engaging in criminal behaviour for over 6 months. We'll see how they manage compliance for their Android devices.

Most Debian packages are managed with a version control system (VCS) like git, subversion, bazaar or mercurial. The particularities of the 3.0 (quilt) source format are not without consequences in terms of integration with the VCS. I ll give you some tips to have a smoother experience. All the samples given in the article assume that you use git as version control system. 1. Add .pc to the VCS ignore list .pc is the directory used by quilt to store its internal data (list of applied patches, backup of modified files). It s also created by dpkg-source so that quilt knows that the patches are in debian/patches (and not in patches which is the default directory used by quilt). For that reason, the directory is kept even if you unapply all the patches. However you don t want to store this directory in your repository, so it s best to put it in the VCS ignore list. With git you simply do:

$ echo ".pc" >>.gitignore
$ git add .gitignore
$ git commit -m "Ignore quilt dir"

The .gitignore file is ignored by dpkg-source, so you re not adding any noise to the generated source package. 2. Unapply patches after the build If you store upstream sources with non-applied patches (most people do), and if you don t build packages in a temporary build directory, then you probably want to unapply the patches after the build so that your repository is again in a clean status. You can do this by adding unapply-patches to debian/source/local-options:

$ echo "unapply-patches" >>debian/source/local-options
$ git add debian/source/local-options
$ git commit -m "Unapply patches after build"

svn-buildpackage always builds in a temporary directory so the repository is left exactly like it was before the build, this option is thus useless. git-buildpackage can also be told to build in a temporary directory with --git-export-dir=../build-area/ (the directory ../build-area/ is the one used by svn-buildpackage, so this option makes git-buildpackage behave like svn-buildpackage in that respect). 3. Manage your quilt patches as a git branch Instead of using quilt to manage the Debian-specific patches, it s possible to use git itself. git-buildpackage comes with gbp-pq ( Git-BuildPackage Patch Queue ): it can export the quilt serie in a git branch that you can manipulate like you want. Each commit represents a patch, so you want to rebase that branch to edit intermediary commits. Check out the upstream documentation of this tool to learn how to work with it. There s an alternative tool as well: git-dpm. Its website explains the principle very well. It s a more complicated than gbp-pq but it has the advantage of keeping the history of all branches used to generate the quilt series of all Debian releases. You might want to read a review made by Sam Hartman, it explains the limits of this tool. 4. Document how to review the changes One of the main benefit of this new source format is that it s easy to review changes because upstream changes are kept as separate patches properly documented (ideally using the DEP-3 format). With the tools above, the commit message becomes the patch header. Thus it s important to write meaningful commit messages. This works well as long as your workflow considers the Debian patches as a branch that you rebase on top of the upstream sources at each release. Some maintainers don t like this workflow and prefer to have the Debian changes applied directly in the packaging branch. They switch to a new upstream version by merging it in their packaging branch. In that case, it s difficult to generate a quilt serie out of the VCS. Instead, you should instruct dpkg-source to store all the changes in a single patch (which is then similar to the good old .diff.gz) and document in the header of that patch how the changes can be better reviewed, for example in the VCS web interface. You do the former with the --single-debian-patch option and the latter by writing the header in debian/source/patch-header:

$ echo "single-debian-patch" >> debian/source/local-options
$ cat >debian/source/patch-header <<END
This patch contains all the Debian-specific
changes mixed together. To review them
separately, please inspect the VCS history
at http://git.debian.org/?=collab-maint/foo.git
<put details="details" here="here" more="more">
END

Subscribe to this blog by RSS, by email or on Facebook.

11 comments Liked this article? Click here. My blog is Flattr-enabled.

I have long been in Bruce Schneier s camp, thinking that the TSA is a joke: nothing but security theater. A few recent examples come to mind:

• In the famous recent event, a man refuses to go through the backscatter machine, and then refuses to be groped. They tell him he can t board the plane, take a report, and say he is free to leave. Then they say he has to go back to the screening area and be screened before leaving the airport, despite his wishes. Obviously they don t believe he really had a bomb, because if he did, would they really want him in a cramped area surrounded by hundreds of civilians? So why make him go back?
• Reading about these screenings, one of my thoughts was, I sure wouldn t want to have my kids have to go through that, or a millimeter wave machine whose health effects are completely unknown! Then I read the TSA s bulletin, intended to calm people like me: don t worry, kids under 13 will never be patted down. OK TSA, so either your patdowns are completely ineffective or you are so naive that you think that nobody under 13 could ever be an attacker. If the latter, why fuss with making them go through security in the first place?

I don t get it. They have been completely reactionary since they began. They have a complete failure of institutional imagination. Something happens, and then a new rule comes out to prevent the thing that everybody is now expecting. And what happens about the thing that people aren t expecting yet? Nothing. So we now have to take off our shoes because one guy tried to use them for something nefarious. OK, fine, but the next guy is probably going to try something other than shoes. Which is why, I m sure, many people are pointing out that the TSA is over-reliant on technology and device detection and completely underemphasizing evildoer detection as, we are repeatedly reminded, the Israelis excel at. The TSA s attempt to remedy that was foolish at best, and, according to a recent report, not grounded in science. Which is why I am heartened that, almost a decade after 9/11, Americans are starting to let go of their fear and be ready to reclaim some sense of intelligence at the security line. The fact that politicians think there is something to be gained by being tough on TSA s invasive screening procedures, rather than risk looking soft on terrorism, is evidence of this. So, what I haven t yet worked out is this: What gives, TSA? Are they:

• Stupid or incompetent? Do they really, deep down, actually believe it when they say this is excellent, best in the world security? Do they really not see how stupid it is?
• Afraid? Are they afraid that if they don t deploy every possible technological solution, and then there is an attack, that they will be fired? (This surely doesn t explain the botched behavioral screening program though)
• Pressured? Are the vendors of security technology getting at them directly or indirectly via politicians forcing them to deploy this stuff?
• Apathetic? They simply have a job, don t really care about it at all, and are just doing the minimum necessary to bring home a paycheck?
• Stuck in a culture of rigidity? Unable to come up with any sort of process that gives screeners the ability to use discretion, they insist that everyone be treated equally and that those that aren t are treated differently on a completely random basis. Some bureaucrats probably spent years on the plan, which is totally useless.

(Note: this criticism is directed mostly at the upper levels of TSA management; I do not believe the people most of us see have the ability to change the system, even if they wanted to.) One final word: I also get annoyed at all the people that grouse at the TSA checking 80-year-olds as thoroughly as everyone else. An 80-year-old could be wearing a hidden device just as much as anyone else could, and if we don t check them, then someday they probably will. The key is to be smart about who we check carefully. Use data, behavioral analysis, simple questioning, etc it works, and is a lot better than exempting people under 13 and over 80 from screening on arbitrary grounds. Also, it might help anyone with a blurry groin. And it might just save a bunch of us from getting cancer.

You probably all know du from GNU Coreutils. But there s more than just du around in Debian. du xdu First there is xdu, which displays du output piped into it graphically, even if du is running on some other box with the output coming over an ssh connection:

$ du   xdu
$ ssh server-without-xlibs du some-directory   xdu

Clicking on any directory except the topmost zooms into that directory. Pressing n sorts by size and s toggles the display of sizes in numbers. xdiskusage xdiskusage seems to be a fork of xdu or at least shares some GUI code with it as it looks and behaves quite similar. But the GUI looks nicer, more modern and you don t need to pipe the output of du into it. It collects the disk usage of a given directory itself. ncdu And then there is ncdu, the ncurses du . (It has nothing to do with the German party CDU . You can easily remember that as Not CDU . ;-) It shows you the disk usage of files and subdirectories in the given directory already sorted by size, optionally displaying also ascii art bars and/or percentage (by pressing g one or more times) for better comparision between file and directory sizes. And all easily and intuitively to navigate in an ncurses text-mode user interface.

ncdu 1.3 ~ Use the arrow keys to navigate, press ? for help
--- /home/abe/debian/webwml ------------------------------------
                             /..
   70.2MB [20.0% ##########] /english
   40.9MB [11.7% #####     ] /french
   35.0MB [10.0% ####      ] /german
   30.2MB [ 8.6% ####      ] /swedish
   26.6MB [ 7.6% ###       ] /japanese
   23.2MB [ 6.6% ###       ] /spanish
   21.5MB [ 6.1% ###       ] /portuguese
   19.8MB [ 5.6% ##        ] /danish
   15.2MB [ 4.3% ##        ] /italian
    9.8MB [ 2.8% #         ] /russian
    8.8MB [ 2.5% #         ] /polish
    6.5MB [ 1.8%           ] /finnish
    5.8MB [ 1.6%           ] /chinese
    4.4MB [ 1.3%           ] /catalan
    4.3MB [ 1.2%           ] /dutch
    3.7MB [ 1.0%           ] /korean
    3.4MB [ 1.0%           ] /ukrainian
    3.0MB [ 0.9%           ] /czech
    2.6MB [ 0.7%           ] /croatian
    2.6MB [ 0.7%           ] /bulgarian
    2.4MB [ 0.7%           ] /norwegian
    1.7MB [ 0.5%           ] /hungarian
    1.6MB [ 0.4%           ] /romanian
    1.2MB [ 0.3%           ] /greek
    1.2MB [ 0.3%           ] /turkish
    1.1MB [ 0.3%           ] /slovak
  576.0kB [ 0.2%           ] /Perl
  556.0kB [ 0.2%           ] /arabic
  428.0kB [ 0.1%           ] /lithuanian
 Total disk usage: 351.1MB  Apparent size: 351.1MB  Items: 70653                                                      

And yes, I uploaded the two screenshots shown above also to screenshots.debian.net as both tools had no screenshots available yet.

This brief announcement was published in the debian-devel-announce mailing list and I repeat it here for your information.
Hi! Since there has been a lot happening in the Debian Multimedia world during the Squeeze release, so we figured we should give you an update on that. Who are we? In the dark old ages, there were two teams involved in multimedia: the Debian Multimedia and Debian Multimedia Packages teams. Please note that neither of them is related to debian-multimedia.org (which is maintained by Christian Marillat, and is known to break current ffmpeg-based applications like mplayer and vlc in Debian Squeeze.). During late 2008, both teams were merged into one, the Debian Multimedia Maintainers team, to avoid effort fragmentation. Since then, there has been a lot of work done: Consumer Multimedia in Debian Consumer Multimedia is about playing and, well, consuming multimedia. Squeeze will feature:

• FFmpeg 0.5.2, finally uncrippled thanks to zack! No mp3/h264 encoder, though. (still in NEW).
• mplayer 1.0rc3, finally with mencoder enabled.
• VLC 1.1.3
• VDPAU hardware acceleration in ffmpeg/mplayer (but feedback is welcome!)
• Guayadeque 0.2.5
• gmusicbrowser 1.0.2

Squeeze will not feature:

• FFmpeg 0.6 (But already available in experimental)
• Hardware acceleration with VA-API (packages also in experimental, for support on Intel hardware).

Producer Multimedia in Debian Producer multimedia is software for producing multimedia. Squeeze will
feature: End user applications:

• Ardour 2.8.11
• Audacity 1.3.12
• Composite 0.006
• Csound 5.12. The QuteCsound frontend is also available.
• FluidSynth 1.1.1
• Hydrogen 0.9.4.1
• Internet DJ Console 0.8.3
• Jokosher 0.11.5
• LiVES 1.3.4
• mhWaveEdit 1.4.20
• morituri 0.1.1
• QTractor 0.4.6
• Rosegarden 10.04.2
• SooperLooper 1.6.14
• Traverso 0.49.1
• X Jack Video Monitor 0.4.13
• Yoshimi 0.058.1

Platforms and technologies:

• JACK versions 0.118 and 1.9.6 (aka, jackd1 and jackd2). You can choose to install any of them (but only one at a time).
• LV2 plugins are supported. Ardour has support for them, and there are a bunch of them provided in Debian.
• LADSPA plugins are still supported.
• DSSI updated to 1.0.0, many plugins are available.
• FireWire sound devices are supported with libffado, and is supported by JACK.

Squeeze will not feature:

• JACK session support.
• Ardour 3 (it s not out yet, so it did not make it in time for squeeze).
• SuperCollider. There is a package in the works, but did not make it to Squeeze.
• Toonloop: This live stop-motion animation editor has been packaged only recently.
• NASPRO: Convenient library to implement LV2 dynamic manifest plugins. It s available in Sid.
• Mixxx: 1.7 series had RC bugs, and 1.8 was too late for squeeze.

Debian Multimedia Blend There is also an effort to start a Debian Multimedia Blend to give a better overview about what multimedia applications are available in Debian. There is a short list for a quick overview as well as a long package list separated in sections to give a more detailed overview (including translations, screenshots, popularity of package etc). You are invited to help improving the tasks either directly in SVN or by sending patches to Andreas Tille <tille@debian.org> or debian-multimedia@lists.debian.org (see below). Note that not all of the packages listed in the tasks pages are maintained by the Debian Multimedia team, since they are aimed at producing useful package sets instead of showing only our own packages. For those who want to squash some bugs in multimedia packages there is also the bugs page generated by the Blends tools, or our team bug page. Other activity The team has seen a lot of growth since the merger. Of the current 52 members of the Alioth team, 20 were added during 2009 and 18 in 2010, many of whom are involved in upstream development as well as the debian packaging. The number of packages has also grown, with 112 of the current 205 git repositories in our team area having its first commit during 2010. Where to reach us The Debian Multimedia Maintainers can be reached at pkg-multimedia-maintainers@lists.alioth.debian.org, should you have any questions. We have also decided to repurpose the old debian-multimedia@lists.debian.org address for user and more general discussion. We would like to invite everyone interested in multimedia to join us there. Interested developers/packagers can also join us at the first address. Some of the team members are also in the #debian-multimedia channel on OFTC.

Regards,

Alessio Treglia on behalf of the Debian Multimedia Maintainers

In my professional role as Ubuntu CTO, I take on a number of different perspectives, which sometimes compete for my attention, including:

• Inward supporting the people in my department, alignment with other departments in Canonical and reporting upward
• Outward connecting with customers, partners and the free software community, including Debian
• Forward considering the future of the Ubuntu platform and products, based on the needs of their users, our customers and business stakeholders within Canonical
• Outside-in taking off my Canonical hat and putting on an Ubuntu hat, and looking at what we re doing from an outside perspective

My recent work, as Canonical has gone through a period of organizational growth and change, has prioritized the inward perspective. I took on a six-month project which was inwardly focused, temporarily handing off many of my day-to-day responsibilities (well done, Robbie!). I ve grappled with an assortment of growing pains as many new people joined Canonical over the past year. With that work behind me, it s time to rebalance myself and focus more outside of Canonical again. It s good to be back! In my outward facing capacity, I ll shortly be attending Web 2.0 Summit in San Francisco. I attend several free software conferences each year, but this is a different crowd. I hope to renew some old ties, form some new ones, and generally derive inspiration from the people and organizations represented there. Being in the San Francisco Bay area will also give me an opportunity to meet with some of Canonical s partners there, as well as friends and acquaintances from the free software community. With my head down, working hard to make things happen, it s easy to lose perspective on how that work fits into the outside world. Spending more time with people outside of Canonical and Ubuntu is an important way of balancing that effect. Looking forward, I ll be thinking about the longer term direction for the Ubuntu platform. The platform is the layer of Ubuntu which makes everything else possible: it s how we weave together products like Desktop Edition and Server Edition, and it s what developers target when they write applications. Behind the user interfaces and applications, there is a rich platform of tools and services which link it all together. It s in this aspect of Ubuntu that I ll be investing my time in research, experimentation and imagination. This includes considering how we package and distribute software, how we adapt to technological shifts, and highlighting opportunities to cooperate with other open source projects. My primary outside-in role is as chair of the Ubuntu Technical Board. In this capacity, I m accountable to the Ubuntu project, the interests of its members, and the people who use the software we provide. Originally, the TB was closely involved with a range of front-line technical decisions in Ubuntu, but today, there are strong, autonomous teams in place for the most active parts of the project, so we only get involved when there is a problem, or if a technical question comes up which doesn t fit the charter of an established team. It s something of a catch-all. I d like to re-establish the TB in a more central role in Ubuntu, looking after concerns which affect the project as a whole, such as transparency and development processes. I m also re-joining Debian as a non-uploading contributor, to work on stimulating and coordinating cooperation between Debian and Ubuntu. I m looking forward to working more with Zack on joint projects in this area. This change will help me to support Canonical and Ubuntu more effectively as they continue to grow and change. I look forward to exercising some mental muscles I haven t used very much lately, and facing some new challenges as well.

I decided recently to publish interviews from Debian contributors and I picked Joey Hess as my first target. He s one of the few who have heavily influenced Debian by creating software that have become building blocks of the project, like the debian-installer (Joey uses the shorthand d-i to refer to it). My questions are in bold, the rest is by Joey (except for the additional information that I inserted in italics). Who are you? Hello, I m Joey Hess. I m one of the oldtimers in Debian. Actually, I just checked, and there are still up to nineteen active Debian Developers who joined the project before I did, in 1996. I got started fairly young, and am just 34 years old. I spend part of my time working with Lars Wirzenius, another Debian oldtimer, on Branchable. It makes it dead-easy for anyone to make a website that is built from Git, using my Ikiwiki engine to do wiki and blog style things. These days I spend the rest of my time working on free software, when I should really be looking for work to pay the bills. What s your biggest achievement within Debian or Ubuntu? I guess I m mostly known by Debian developers for writing debhelper and perhaps debconf. Probably founding the Debian Installer project has been a bigger impact for users. I m fairly equally proud of all three projects. But while it might sound corny, I am more proud of the accumulation of all the smaller things done in the context of Debian. It s more of a deep connection to the project. All the bugs fixed, and filed, and packages uploaded, and late night discussions, and just being a part of the larger project. What are your plans for Debian Wheezy? Hmm, I stopped thinking of Debian releases by code names back around Slink. So, few specific plans for Wheezy. The main thing I would like to help make happen in Debian next is Constantly Usable Testing, and it transcends releases anyway. The only specific plans I have for Wheezy are that there will probably be a new debhelper compat level, and I hope d-i will finally switch to using git. RH: You can learn more about Constantly Usable Testing in my article Can Debian offer a Constantly Usable Testing distribution?. If you could spend all your time on Debian, what would you work on? Getting Debian on all these computers that we carry around in our pockets and can t easily run apt-get on and hack on. Phones that is. It s a bigger problem than just Debian, but I think Debian needs to find a way to be part of the eventual solution. The FreedomBox concept at least hints at a way around the current situation with embedded computers in general. What s the biggest problem of Debian? I believe that the biggest problem is institutional, social and technological inertia. Every specific case of something that frustrates me about Debian today can be traced back to that. You contribute regularly to Debian mailing lists, yet I don t remember any aggressive/frustrated mail of you. How do you manage that? Are you avoiding heated discussions? Rats, sounds like all my wonderful flames of years past have been forgotten! Seriously though, after I noticed thread patterns, I started trying to avoid participating in the bad patterns myself. Now I limit myself to one expression of an opinion, and I don t care who gets the last word. If people can t be convinced, it s time to find another approach to the problem. Also, code talks. Most of the programs you wrote for Debian are in Perl. Do you regret this choice? I love that question! No, no regrets. My only concern is whether the language limits contributors or users. I have not seen Perl significantly limiting the use of anything except for debconf (we had to rewrite it in C for d-i). And I do not notice fewer contributions to my Perl-based code than to other code. I do sometimes regret when someone tells me they had to learn or re-learn Perl to work on something I wrote. But while I m enjoying writing new things in Haskell now, and while I hope it will mean less maintenance burden later, I don t think using Haskell will make it easier for others to contribute to my programs. Anyway, for me the interesting thing about writing a program is the problem it solves and the decisions made doing it. Choice of language is one of the less interesting decisions. Is there someone in Debian that you admire for his contributions? Well, lots. You re tempting me to throw a dart at a map. So arbitrarily, I ll say Anthony Towns. We could all learn something from how he s approached making big, fundamental changes, like introducing Testing, and making Debian Maintainers happen.

---

Thank you to Joey for the time spent answering my questions. I hope you enjoyed reading his answers as I did. Subscribe to my newsletter and don t miss further interviews. You can also follow along on Identi.ca, Twitter and Facebook. PS: If you want to suggest me someone to interview, leave a comment or mail me.

3 comments Liked this article? Click here. My blog is Flattr-enabled.

I would tell you about the phone call I had with a company where the CEO acknowledged that they were behaving in criminal activity in multiple jurisdictions but promised that they'd probably stop in a few weeks and so I shouldn't worry, but it seems that in the modern Internet I'm not allowed to because there were no independent witnesses and I haven't called the police, and also if I wanted people to respect my copyright I shouldn't have put my software on the internet where I'm just begging for it to be taken advantage of. Also, in future I won't be fixing any bugs unless they happen to me because you might just be making them up make my code look bad, and also you shouldn't accept any patches from me because I might by lying about things just to inflate my patch count and make myself look better at the expense of competing companies.

(for anyone missing the point: THIS IS A SERIES OF ANALOGIES INTENDED TO INDICATE THAT THIS ARGUMENT IS FACILE)

You re probably manipulating Debian packages everyday, but do you know what those files are? This article will show you their bowels Surely they are more than file archives otherwise we would just use TAR archives (you know those files ending with .tar.gz). Let s have a look! 1. It s two TAR file archives in an AR file archive! A .deb file is actually an archive using the AR format, you can manipulate it with the ar command. This archive contains 3 files, you can check it yourself, download any .deb file and run ar t on it:

$ ar t gwibber_2.31.91-1_all.deb
debian-binary
control.tar.gz
data.tar.gz

debian-binary is a text file indicating the version of the format of the .deb file, the current version is 2.0 .

$ ar p gwibber_2.31.91-1_all.deb debian-binary
2.0

data.tar.gz contains the real files of the package, the content of that archive gets installed in your root directory when you run dpkg --unpack . But the most interesting part which truly makes .deb files more than a file archive is the last file. control.tar.gz contains meta-information used by the package manager. What are they?

$ ar p gwibber_2.31.91-1_all.deb control.tar.gz   tar tzf -
./
./postinst
./prerm
./preinst
./postrm
./conffiles
./md5sums
./control

2. It contains meta-information defining the package and its relationships The control file within the control.tar.gz archive is the most fundamental file. It contains basic information about the package like its name, its version, its description, the architecture it runs on, who is maintaining it and so on. It also contains dependency fields so that the package manager can ensure that everything needed by the package is installed before-hand. If you want to learn more about those fields, you can check Binary control files in the Debian Policy. Those information end up in /var/lib/dpkg/status once the package is installed. 3. It contains maintainer scripts so that everything can just work out of the box At various steps of the installation/upgrade/removal process, dpkg is executing the maintainer scripts provided by the package:

• postinst: after installation
• preinst: before installation
• postrm: after removal
• prerm: before removal

Note that this description is largely simplified. In fact the scripts are executed on many other occasions with different parameters. There s an entire chapter of the Debian Policy dedicated to this topic. But you might find this wiki page easier to grasp: http://wiki.debian.org/MaintainerScripts. While this looks scary, it s a very important feature. It s required to cope with non-backwards compatible upgrades, to provide automatic configuration, to create system users on the fly, etc. 4. Configuration files are special files Unpacking a file archive overwrites the previous version of the files. This is the desired behavior when you upgrade a package, except for configuration files. You prefer not to loose your customizations, don t you? That s why packages can list configuration files in the conffiles file provided by control.tar.gz. That way dpkg will deal with them in a special way. 5. You can always add new meta-information And in fact many tools already exploit the possibility to provide supplementary files in control.tar.gz:

• debsums use the md5sums file to ensure no files were accidentally modified
• dpkg-shlibdeps uses shlibs and symbols files to generate dependencies on libraries
• debconf uses config scripts to collect configuration information from the user

Once installed, those files are kept by dpkg in /var/lib/dpkg/info/package.* along with maintainer scripts.

If you want to read more articles like this one, click here to subscribe to my free newsletter. You can also follow me on Identi.ca, Twitter and Facebook.

19 comments Liked this article? Click here. My blog is Flattr-enabled.

Tomorrow I won't have to deal with it getting dark at a soul-crushing 5:30 pm. Nor will I have to wake up blearily an hour early in the spring. Instead I will be enjoying my new, custom time zone. It's "JEST", for "Joey's Eastern (non)Standard Time", and in JEST, there is no spring forward or fall back stress. The folly of daylight savings time (Ben Franlin's best prank ever) really becomes apparent when you have solar power. It's bad enough that the sun is setting at 6:30 without compounding that by an hour. By keeping my clock set so the sun sets in midwinter at 6 pm, I will maximise what little light there is, and minimise time spent using batteries in the dark. Of course, it helps that I'm my own boss, and that most of the people I work with are probably not in a nearby timezone anyway, and that most things are done asynchronously. Since JEST is an hour ahead of local time here in the winter, I will, at worst, tend to be running early. So I only have to change my clocks one time -- and by "change", I mean create a custom timezone in Linux. Here's how to do that.

1. Make a custom timezone file. The standard one for North America is a bewildering 3000 lines of special cases, conflicting legistlation, and historical weirdness, but I only need one: echo "Zone JEST -4:00 - JEST" > JEST.zone
2. Compile and install it to somewhere; I put it in ~/.zoneinfo zic JEST.zone -d ~/.zoneinfo
3. Set TZ to use it. Also TZDIR if it's not in the system directory. export TZDIR=~/.zoneinfo TZ=JEST

Update: Turns out it was easier than I thought, just setting TZ=FOO+4 will make date display a timezone "FOO" that is 4 hours behind GMT. So all I need is to set TZ=JEST+4 Result:

date: Sat Oct 30 21:43:39 JEST 2010
date -R: Sat, 30 Oct 2010 21:43:39 -0400

Previously:

• daylight savings time idiocy
• DST: no power saved
• daylight savings crime
• fall back day

My wife has been pestering me for months to get a replacement for our dead Epson inkjet printer (which didn t last long, mind you). To avoid the nightmare of printer support, which, unless you buy a high-end professional printer which does everything plus the coffee, is usually somewhere between disaster and works sometimes , we spent a long time on manufacturers websites to choose wisely the model. We chose the HP Laserjet P1102, which, according to HP, has a full support level and is even part of their recommended models. Yet, after plugging it in, it took me quite some time to understand why it would behave as a brick instead of a printer. First, I thought it was a bug in hplip. Then, I soon discovered that the printer advertised itself as a storage device instead of a printer. What, a buggy firmware? Thanks to a random question on Launchpad I discovered it s not a bug, it s a feature. It s named HP Smart Install and it turns out it s yet another stupid idea to support OSes that are too dumb to detect your printers automatically: the printer advertises itself as a CD drive, until you install the driver that will make it switch back to being a printer. What happens to those who don t want this feature that turns your printer into a 10 kg, read-only USB drive? Well, HP has a solution in the Smart Install FAQ:

25. Can I turn HP Smart Install off or on?
Yes. You can use the HP Smart Install utility to disable/enable HP Smart Install. The utility is stored on the software CD, in the UTIL folder. SIUtility.exe is for 32-bit operating systems and SIUtility64.exe is for 64-bit operating systems.

Bunch of idiots. If I buy a 100 printer, it s not so that I have to buy a 100 operating system just to activate it.

In the comments of the article explaining how to generate different dependencies on Debian and Ubuntu with a common source package, I got asked if it was possible to apply a patch only in some distribution. And indeed it is. The source package format 3.0 (quilt) has a neat feature for this. Instead of unconditionally using debian/patches/series to look up patches, dpkg-source first tries to use debian/patches/vendor.series (where vendor is ubuntu, debian, etc.). Note that dpkg-source does not stack patches from multiple series file, it uses a single series file, the first that exists. So what s the best way to use this? Debian should always provide debian/patches/series, they are supposed to provide the default set of patches to use. Any derivative cooperating with Debian can maintain their own series files within the common VCS repository used for package maintenance. They can drop Debian-specific patches (say branding patches for example), and they can add their own on top of the remaining Debian patches. It s worth noting that it s the job of the maintainers to keep both series files in sync when needed. dpkg-source offers no way to have stacked series files (or dependencies between them). If you want to use quilt to edit an alternate series file, you can temporarily set the QUILT_SERIES environment variable to vendor.series . Just make sure to start from a clean state, i.e. no patches applied. Otherwise quilt will be confused by the sudden mismatch between the series file and its internal data (stored in the .pc directory).

Found it useful? Click here to see how you can encourage me to provide more articles like this one.

No comment Support my work

About a month ago, at the end of August, I finished a 10-day Vipassana meditation course. This was probably one of the more extreme activities I have ever participated in, and it's well worth a blog post. I found out about the course in a ridiculously trivial way, by following a link in a Reddit comment (I wonder if I could track down that comment...). The website referenced by the comment contained (almost) no new-agey mumbo-jumbo and looked legit in general. I also appreciated the fact that this was a relatively serious and intensive course, which should be enough to form a reasonably founded opinion on meditation in general. When learning sporadically, in small bits, it is hard to say whether the material itself is no good, or you just do not understand it yet and need to study more; I was quite skeptical towards the practice, but wanted to give it fair trial. I was quite impressed that there was a course available in Lithuania, a few hours by train from where I live. Finally, the course was free (by tradition Vipassana is taught without monetary compensation). I went ahead and signed up for a standard introductory 10-day course. Vipassana (also called insight meditation) is a meditation technique allegedly coming back from Gautama Buddha himself (well, all the traditions like to claim that origin...). It has been experiencing a renaissance, partly due to an organization set up by a meditation teacher S. N. Goenka which has founded meditation centers all over the world. The essence of Vipassana is a method of teaching your mind to act instead of merely reacting to outside stimuli such as pain, anger of other people or hardships. The technique provided is to monitor your sensations, watch them with equanimity and suspend any reaction, and slowly it sinks in that all things are temporary and you can choose what to react to and how. That's the basic idea; I don't want to go deep into exposition of Vipassana as there is plenty of information about that (also at the same time the information is almost useless because you have to experience it to really understand it). Instead, I will sure some of the more personal remarks and experiences. The course took place in an cottage near Kretinga, housing around 50 people. The living conditions were absolutely great, and this would have been a true holiday if not for the regime and the rules. The day would start very early, at 4 AM (ending at around 9:30 PM), and we'd do about 12 hours of meditation in total inbetween, with occasional breaks, but the most gruesome part is that no communication at all was allowed with anyone except the manager of the camp (and the teacher during a specified time). That gets to you after a few days, but still, there are people around you, so it's bearable; on the other side, the senses (touch, smell) become very acute. The food was taken care of by volunteers (students who have finished the course), and I could say it was quite good actually. The goal, of course, was to keep the environment from interfering with meditation, and I think it was done very well. The presentation of the actual technique also did not disappoint. Each day a new step would be introduced, with the whole day to practice before moving on. Looking back, the pacing worked well. Every day in the evening there were lectures on theory. They were somewhat informative, but also sometimes annoyingly primitive and verbose. The little mistakes, holes in logic and slight doses of mumbo-jumbo almost drove me nuts by the middle of the course, until I learned not to react to them. Despite the shortcomings of presentation, the simplicity and lucidity of the practice and lightness of theoretical baggage really appealed to me. The whole organisation in general gave the impression of complete transparency, with no strings attached, no financial interests in play and no agitation for further involvement. While there are many meditation techniques, I am happy that I've gone with Vipassana in particular for one reason: Vipassana meditation uses no artificial tools to help you concentrate, such as mantras, visualisations, counting, etc. Such methods make concentration much easier, but they also create a dependence on the methods themselves. I appreciate the purity of Vipassana in this regard. Not everything in the practice is roses though. First, a particular worldview supported by Vipassana is presented as "scientific" and supposedly "the right way to live", and if even if you don't agree, "the truth" of Vipassana will become obvious to you with time. This is a distinctive mark of ideologies. The thing that makes everything break is the reincarnation, which is generally assumed as true, even if it's not shoved down the student's throat. Every rationalization of a world view has a "white lie" (usually related to the concept of eternity somehow) at the core, and in this context reincarnation is it. Given what we know now about the relationship between the mind and the body, reincarnation is absolutely ridiculous and completely untenable, and that breaks all "moral" reasoning for practicing meditation as opposed to doing something else. I'm not the first to bring up this problem, there's plenty of material about it online. The second slippery idea is that the concept of "negative happiness" is central in Vipassana, that is: happiness is defined as lack of suffering. This point is not that unreasonable actually, from personal experience I could indeed call the state of non-suffering happiness, but there is definitely something missing when compared to the state of mind when I'm truly, positively happy. Whether you consider that something important or not, it's definitely there. Third, Vipassana suggests that it is only you who is at fault when your inner state is disturbed; the world affects you as much as you let it, and in order to find happiness you should learn to control the "interface" rather than the outside world, which will usually not behave as you want. This may be correct, but sometimes it could just be easier to fix the world rather than change yourself, and I have the suspicion that it this is much more frequently the case in the modern world compared to the pre-modern environment. (This is one of the points which break when reincarnation is rejected, as with reincarnation you have the whole eternity to fix yourself.) While the complaints are serious, they do not mean complete rejection of Vipassana but rather integration among the various other techniques available. The actual meditation technique is still great for gaining and maintaining mental composure, reducing anxiety and improving well-being. Now, if I could only get used to meditating regularly... If you have the chance, I highly recommend you try out an introductory 10-day course. There is little to lose and a lot to gain. And if you do go ahead, I have two hints. First, do not even think about leaving the course before it's over. Any hardships are temporary and will be overcome quickly. Second, use the time with the teacher, those interactions were very helpful to me. Also, given the "noble silence", talking to someone once in a while will not hurt.

Dato pointed out on my post yesterday that I had omitted to link to the Ikea catalogue. And then it hit me - I am completely failing to monetize this blog! (Sadly, Ikea aren't in a position to give me any kickbacks right now.) Since my money would be spent on innovative Swedish design in any case, I present a new microdonations system: Flattr-pack. I'll add a "Flattr-pack this!" button to everything I write, and then you can send me furniture with one easy click. Unlike other systems, this has the advantage that no one will be taking a 10% cut of your donations. Awesome! Or maybe not. For those who don't know what I'm on about, Flattr is a website that lets you donate small amounts of money to other websites. It has been proposed to use this site to support free and open source software (FOSS). Now a quick modern anthropology lesson: in a 1998 essay titled "Homesteading the Noosphere", Eric Raymond conjectured that FOSS society is a gift economy; your reputation is proportional to how much you give away. At first sight, microdonations drop neatly into this system; after all, the users are giving money away, right? And yet somehow, I don't think those users are gaining much in terms of reputation. Not in the same way as if they reported bugs, say; joined a localization team; or even just turned up to conferences and volunteered to sit on the front desk. Both types of activity could be described as "donations" - but in one case, the donation benefits the whole community around the project, and in the other it goes to just a few top developers. It's a plain old exchange economy in disguise. I do hope that those users are not dissuaded from making the more generous donations just because it's more convenient to whip out a credit card. That would not be in their long-term interests, or those of the community as a whole. I fear this scheme could also incentivize some oddly inefficient behaviour; writing blog entries purely for their donation potential, say, or even content-free search-engine optimization posts. Speaking entirely personally, I do not plan to join in.

Today I forgetfully left my USB drive at home when I took off for a night at the yurt. This has happened before and generally involves staring at an scp for rather too long, probably getting low on battery power in the process, and is followed by not quite having files in the places I expect and forgetting to delete them from my small laptop SSD later. With git-annex those annoyances can go away. So I wanted a couple of gigabytes of files that were left at home behind a slightly slow link. Rather than scp them to my laptop for several hours, I just did a quick ssh into a server, and browsed through my stuff there, running git annex get $foo & on files and directories I wanted. Then went to eat dinner and play board games while the content was scped across the slow link from home. Now I can quickly download it all to my laptop from that fast server (named "finch"), like this:

git pull
git annex move . --from finch

That removes the data from the server too, freeing its space back up for next time. And the files are in their regular places on my laptop, automatically. And I can simply git annex drop . when I need that space back without worrying about losing any data. (Hmm, this feels a little bit like it did to switch from doing everything by hand with dpkg to using apt-get..)