Search Results: "evo"

4 November 2007

Manoj Srivastava: Manoj: The White Company

I had somehow managed to miss out on The White Company while I was growing up and devouring all of Sherlock Holmes stories and The Lost World. This is a pity, since I would have like this bit of the hundred years war much better when I was young and uncritical. Oh, I do like the book. The pacing is fast, if somewhat predictable. The book is well researched, and leads you from one historic event to the other, and is peppered with all kinds of historical figures, and I believe it to be quite authentic in it s period settings. Unfortunately, there is very little character development, and though the characters are deftly sketched, they all lack depth, which would not have bothered the young me. Also, Sir John Hawkwood, of the white company, is mentioned only briefly in passing. This compares less favourably than Walter Scott s Quentin Durward, set in a period less than 80 years in the future. but then, I ve always have had a weakness for Scott. As for Conan Doyle, the lost world was far more gripping. I am now looking for books about Hawkwood, a mercenary captain mentioned in this book, as well as Dickson s Childe Cycle books. The only books I have found so far on the golden age of the Condottieri are so darned expensive.

Daniel Burrows: Lessig at the University of Washington

On Friday 2007-11-02, I watched Larry Lessig give a presentation at the University of Washington entitled Is Google (2008) Microsoft (1998)? Since it was Lessig, the talk was articulate and thought-provoking, and he used his slides very well (unlike many presenters who just read bullet points).

The argument he made is that Google is like Microsoft in some ways (and so are other companies like Facebook). In his analysis, the problem with Microsoft was that so many companies made themselves Microsoft-dependent, which both forced other companies to follow suit (due to network effects) and gave Microsoft leverage they could use against everyone in their ecosystem (e.g., Netscape). According to Lessig, Microsoft was not evil to use this leverage, but you have to recognize that Microsoft will do what is best for Microsoft, and this may not be what is best for you. He then suggested that we should be aware of the potential for the same thing to happen; in support of this point, he quoted excerpts from the terms of service from the APIs of Google and Facebook, which contain typical statements like we reserve the right to terminate your use of this service for any reason or for no reason, and asked: What if Microsoft had written this license agreement?

But it seemed to me that this wasn't his main point. He was using this observation as a springboard to talk about issues revolving around competition and public policy. Specifically, he feels that we should work towards a more just model of interaction between companies and users whose work makes the company more valuable (by contributing to a software ecosystem, by posting content on the Web site, etc). But the correct way to do this (he says) is not via competition, after-the-fact litigation, or voluntary codes of conduct: competition may not be around to enforce good behavior (as we've seen with Microsoft), litigation may be too late and ineffective (again, see Microsoft), and voluntary codes of conduct will disappear as soon as they get in the way of the bottom line. The correct approach, he argued, is across-the-board regulation so that all the companies have to play by the same rules.

From there he went on to talk about governmental corruption. He said (quoting Robert Reich's book Supercapitalism) that the reason we consistently look for solutions in the market and in voluntary compliance is that our governmental system is broken and does not effectively regulate corporations in the public interest. But Lessig is optimistic that we can change things (he joked that his publisher was unhappy with this point of view, because his brand has been built on pessimism). In his view, the politicians in Washington, by and large, want to be honest and do good, but they aren't able to within the current political system. For instance, on the few occassions that he managed to get access to lawmakers to discuss copyright issues, it was often the first time they had heard that there was more than one side to the argument. He thinks we need a national political movement that will shame politicians into being less corrupt.

This is all a simplification of what he said, of course; unfortunately, I wasn't able to find a recording of this talk on Lessig's Web site, or I'd point you at primary source material. I don't know if this is because he chose not to post it, or because it just hasn't been made available yet.

My view

In general, I thought that the speech was very interesting and well thought out. But as much as I'd like to buy into his optimism that we can fix our system, I don't think it's well-founded, for two reasons.

First, he argued that competition will resolve some of these problems (that was before and after he said we can't rely on competition, which I found confusing and may indicate that I misunderstood something). His evidence for this seemed to be that when Microsoft was dominating the world, users responded by reducing their dependence on Microsoft products and by switching to alternatives such as Linux. But, in fact, although more people may be using Linux than in the past, virtually everyone is still only using Windows, it's still almost impossible to find a programming job that isn't Windows-only, and Microsoft is still raking in money hand over fist; indeed, they're doing so well that they're planning to expand their workforce by a third. To take just one data point of many: I ride the bus to Seattle and back, and I regularly see other people using laptops as they commute. Virtually all the laptops run Windows. Occasionally I'll see a Mac, and every few months I'll see a guy running Linux on his laptop; I say "a guy" because it's the same guy every single time. So by my estimation, use of Linux on laptops in buses on the 545 route from Redmond to Seattle is way below 1%, with Macintoshes somewhere around 5%.

To broaden my point, I think Lessig has fallen into a trap that highly intelligent people, particularly those in academia, tend to fall into. In academia, you are surrounded by people who value learning and thinking deeply about the world. These are people who will give serious and unbiased consideration to questions like what is the social effect of my acceptance of the Facebook Terms of Service? and If I become dependent on this service, will that possibly affect me in five years if the company decides to act against my interests? The problem with this is that these people are not representative of the population at large. The population at large thinks why is this check-box getting in the way of me sending pictures to my friends? And I have no doubt that any kid who, e.g., refuses to sign up for Facebook as a protest against their TOS will be roundly mocked in their social circles for being a weird antisocial nonconformist. (of course, this may not apply to the small minority of people like myself whose social circles consist of weird antisocial nonconformists)

Second, Lessig's optimism about the political system seemed to be based on his observation that the people in government are, by and large, not venally corrupt: they want to do good, but the system is constructed in a way that makes this impossible. To me, that's a tremendously disheartening statement. If our problem were simply a few, or even many, corrupt politicians, this would be a solvable problem: even nowadays, Americans have some ability to choose who gets elected, and I believe that a sufficiently well-coordinated campaign could replace bad politicians with good ones.

But if the problem is that the system is corrupt even when the individuals are honest, it's a much deeper problem and frankly one that I don't know how to solve. While individuals have some direct control over who gets elected, we have no way to directly change the system that produces the corruption; the levers to do this are in the hands of the politicians elected through that broken system. It's unlikely that the politicians themselves will fix the problem, because they've benefited deeply from it: if the system is left as it is, well over 90% of Congress members will keep
their jobs
in the next election cycle, and any effective change seems likely (by definition) to disrupt this cushy arrangement.

On the other hand, running new candidates for office will not fix the problem. After all, if the problem is that the system is corrupt even when the participants are honest, then putting more honest people into government will have no effect. In order to get elected, these new politicians will have to become just as corrupt as the old ones, because that's how the system is set up. So we might change the faces, but we'll have the same old problems.

I recall two specific concrete proposals that Lessig made to make the system more responsive. First, he suggested shaming politicians who engage in corrupt behavior -- presumably taking large donations from interested parties. I don't see how this will help. Americans generally have a very low regard for the political class as it is; will pointing out particular examples of politicians taking money really make a difference when it comes to votes? And if it doesn't, will it really produce any change in their behavior? Politicians are motivated by votes the same way corporations are motivated by money; unless they stand a chance of losing their job (which is virtually impossible in any event), there's no reason for them to change how they behave.

His second proposal was for a system of contributions where it's impossible for any individual to prove they had donated a particular amount of money to a particular candidate. Even assuming it could be implemented perfectly, I don't think this will really solve the problem, for two reasons. First, it's not generally a secret what moneyed interests want. Politicians who want to attract large donations can just take positions that they know will appeal to donors of that sort. The donors themselves can make this easier on the candidates by, e.g., posting public position statements on issues of the day. Secondly, and this is far more insidious, even if politicians honestly represent their positions, then because success in running for office is so tied to the amount of money the candidate can raise, only candidates who hold opinions favorable to large corporations and wealthy individuals will be able to get elected. In fact, for all I know this is what happens already!

But with all that said, it was a really interesting talk and Lessig tied together some things you might not think would go together. If a video or Flash presentation becomes available, I would recommend watching through it. And hopefully my pessimistic predictions will be wrong; it's certainly happened before.

28 October 2007

Tore S. Bekkedal: Play! - A Video Game Symphony

I recently attended the Play! concert in Oslo, with a friend who was visiting Oslo from Bergen. The concert took place in an expo hall just outside Oslo, which was being used for the Electroworld electronics exposition. Wow, has that ever changed! I was there the first time, three-odd years ago, when it was arranged in Oslo Spektrum, and I was bitterly disappointed! It was nothing but a slightly larger Expert Electronics store. I was angry that I had actually been conned into paying for this. This year, it was completely different. They had a gigantic venue, with lots of interesting booths. Yamaha showed off some truly gorgeous digital pianos, and electronic drum sets, NRK was there, to show off their beautiful HD-1 HDTV production bus, and all kinds of interesting things. Even so, it was very clear that Expert was trying to get you to buy stuff. Something just doesn’t sit right with me about paying money to enter a store which is marketed as an expo. My previous experience with Electroworld meant I was not at all interested in repeating it. I wanted to catch the concert which was being held there. But they wouldn’t let me in unless I bought a ticket for the expo. Having already paid 70 EUR for a concert ticket, I was not enthusiastic about paying 15 more EUR to be allowed to enter the venue. But I relented, and was duly fleeced. I only got around 30 minutes of time before the concert started, so I didn’t get all that much time to look around. The first part of the concert started. The orchestra was the wonderful KORK (AKA Kringkastingsorkesteret, AKA “The Norwegian Radio Orchestra”). They started off with a beautiful fanfare by Nobuo Uematsu. However, their choice of music frustrates me deeply. They played some of the obvious classics, like Mario, Sonic The Hedgehog, some Zelda, but most of the time was wasted on some really lame music. It seems that their repertoire was not chosen based on the musical merit of the games, but on the current popularity. Why else would they be devoting time to some dull, insipid incidental music from WoW, Halo, and Silent Hill, without even an identifiable motif, as opposed to more of Koji Kondo’s wonderful Mario or Zelda tunes, or - damnit - Nobuo Uematsu’s Final Fantasy music? This is the thing that has left me the most disappointed. They practically ignored the elephant in the room of game music, Nobuo Uematsu. His compositions are absolutely beautiful, and they really shine when performed by a classical orchestra. You can practically tell that they’re meant to be performed by them, rather than some dinky Super Nintendo synthesizer chip. The Final Fantasy VI Opera, most of the Final Fantasy VII soundtrack… They then proceed to play One by Metallica. …WTF, you ask? WTF, indeed. Their justification was that it’s in the soundtrack from Guitar Hero. That’s absurd. And it wasn’t even a very good performance. It was still pretty funny that this very serious-looking classically trained vocalist slowly walked up on stage and gave a really good performance - he really did sound like the Metallica vocalist. Almost as an afterthought, at the very last, they play One-Winged Angel, one of the most dramatic and beautiful pieces from Final Fantasy VII. The audience breaks into absolutely wild applause. But - what - they bring in a METAL BAND on stage. A GODDAMNED METAL BAND! And they proceed to absolutely slaughter the whole piece! The choir and orchestra are drowned out by loud electric guitars with riffs that don’t make sense, and a drummer that can’t even keep the damned beat - the bass drum was all over the place! Seemingly not content with simply omitting his music, they have to absolutely demolish the performance of it. I actually have to say that this is by far the most disappointing concert I have ever gone to. Granted, my expectations were high, but just to witness a live performance by this wonderful orchestra of the Prelude, Anxious Heart, Tifa’s Theme, Eyes On Me, Fighting!, Still More Fighting! or Aerith’s Theme would’ve made the 85 EUR worth it. Judging from the audience’s applause when he first mentioned the Final Fantasy series, I think they agreed with me.

23 October 2007

Isaac Clerencia: Open aLANtejo 2007

Last weekend I had the chance to attend the Open aLANtejo conference, in beautiful vora, Portugal. I went there to give a presentation about Open Source Game Development and had the chance to meet interesting people that I knew through somebody else or just from the community lore :P To be honest I had a really better time than I expected :) Some of the speakers were the Bitrock people, Jono Bacon (Ubuntu Community Manager) and Juanjo from Igalia. I’m really looking forward to meet up again. The organisation team was also really helpful and passionate about the event, so if you get invited, don’t think twice about going :)

19 October 2007

Jose Luis Rivas Contreras: So cheap!!

I found in my dad's office a Macworld of october 90' and saw this 2 page ad:
This is when you think how that people could live? If you need 2G right now for nice working that would make $138.000!! Thanks tech evolution!

17 October 2007

Martin F. Krafft: Mexican salsa on Pizza?

I am a purist when it comes to food. A huge purist. And yesterday I ended up at Miller's Pizza on Upper Baggot Street, Ballsbridge, Dublin, Ireland, and I enjoyed a Thai Prawn Green Curry Pizza, while colleagues of mine were devouring Mexican Salsa on Pizza Dough and similarly "perverse-sounding" foods. Unfortunately, their menu behind the above link is out of date (someone should let them know ), but that should not stop anyone with an appreciation for eclectic food and an adventurous vein from stopping to eat at this place the next time you're in Dublin. NP: Devin Townsend: Ziltoid the Omniscient

Chris Lamb: Missing notes in the Mozart s Dissonance quartet K. 465?

The second movement of Mozart’s String Quartet in C «Dissonance», K. 465 has an interesting two bars where it appears that the violin theme is accidentally missing. As highlighted in red on the score, the violin part is devoid of the crotchet/four quavers that the other parts present - the other “missing” bar is at this section’s mirror in the sub-dominant, bar 75. Some printed editions have added the missing notes, claiming that Mozart made a mistake (or overruling him on musical grounds!), but it seems bizarre that Mozart—who even likened the composition of the “Haydn” quartets to a long, labourious fatigue (”lungha e laboriosa fatica“)—would make such an error. The preface to the Neue Mozart Ausgabe claims:
It is unthinkable that Mozart [could] have made a mistake or from absent-mindedness made a slip of the pen no less than four times in such an obvious and important detail.
(The preparation of the original first edition, which Mozart himself presided over, presumably accounts for the other two.) At least one scholar has claimed that the notes aren’t missing at all; they are simply contained within the cello’s notes. I don’t find this explanation particulary satisfying. The NMA goes further by stressing its wish that the original version should be used in performances, which seems to suggest that adding the notes is (or at least, was) a common practice, but I cannot find many recordings with the added notes: my Leipziger, Emerson, Alban Berg, Ysa e, Italiano and Amadeus Quartet interpretations all omit the notes, whilst only the Hagen Quartet add them.

16 October 2007

Russell Coker: War is Bad for the Environment

I just read a nutty post claiming that Neo-Conservatism is good for the environment [1]. The first bogus claim is that Saddam had WMD and war was required because he was a despot. The fact is that the Iraqi government was always repressive, there are many factions in Iraq that don’t like each other and a repressive government is the only way to keep such groups in a united country. The current civil war in Iraq and the effective secession of Kurdistan (which currently seems to be involved in an undeclared border war with Turkey) demonstrates this. Saddam was always a despot, but he did improve the living conditions of most Iraqis - the best way to avoid a revolution is to convince the majority of the population that things will get worse if there is change. I suggest reading the Wikipedia page about Saddam Hussein [2]. The best information on Fourth Generation Warfare (4GW) seems to be on the conservative military analysis site Defense and the National Interest [7]. It covers all the issues related to invading other countries from a conservative point of view. Note that Neo-Conservatives are not Conservatives, the real Conservatives hate the Neo-Cons more than anyone else does. The amusing statement is made that “apologists claim it was one of the most advanced Arab nations” and then a link is provided to information on Saudi Arabian censorship. It’s worth reading the wikipedia page about the history of Saudi Arabia [3], among other interesting facts “the U.S. Army Corps of Engineers built the country’s television and broadcast facilities and oversaw the development of its defense industry” (does the US army share responsibility for the censorship?). It’s widely regarded that if the US military support was removed then the Saudi government would be overthrown. Referring to Saudi Arabia hardly seems like something you want to do if trying to justify occupying other middle-eastern states. An unsubstantiated claim is made that under-developed countries produce excess pollution due to inefficient technology. Unlike some people I try to get some facts before posting so I looked up the wikipedia page on CO2 emissions per capita [4]. It seems that the highest ranking first-world country is Luxembourg at #4, the next is the US at #10. The countries on the list that rank higher than the US have a combined population of about 11,000,000 while the US population is 302,000,000 - some quite mental arithmetic suggests that the US produces about 20 times more CO2 than the top 9 countries on the list combined! It doesn’t seem that having the highest technology is helping the US protect the environment, I guess that they just use it to build bigger cars. The next thing I noticed is the countries that are at the bottom of the list - they are the world’s poorest countries. It seems that countries without much money just can’t afford to burn lots of oil, while countries with lots of money can. No real surprises there. The lowest ranking on the list for a country that is unlikely to be regarded as being in abject poverty is India at position #133. The next lowest is Turkey at position #98 followed by China at #91. As a final point of reference Switzerland is at position #69 a produces just under 27% the CO2 that the US does (on a per-capita basis). According to the CIA World Fact Book Switzerland has an infant mortality rate of 4.28/1000 and a life expectancy of 80.62 [5], while the US has an infant mortality rate of 6.37/1000 and a life expectancy of 78 [6]. I believe that the infant mortality rate and the life expectancy are the two factors that are most representative of quality of life as they are the easiest factors for measuring the overall health of the population. Being healthy is one of the most important factors in quality of life. It seems to me that by all objective measures the Swiss are doing better than the people of the US, yet they produce less pollution and never invade other countries. Probably the most ridiculous statement in the post is “see rapidly dwindling resources wasted on jihad and revolution“. A revolution (locals using force to create a new government) takes little resources and most actions that a more simple-minded analysis might call “jihad” takes almost none. Sending an invasion force to the other side of the world and supporting an occupying army for years does however use significant resources, consider that the Hummvee is the least fuel-efficient vehicle on American roads in terms of work done (trucks and buses use more fuel but carry large amounts of cargo or many people), but it’s also the most fuel-efficient vehicle used by the US army in Iraq. There is the possibility that Jaldhar was attempting satire. If so then I suggest that satire be kept separate from serious web content to avoid confusion about where the satire ends. But if you want some satire about oil then I suggest consulting theonion.com. Before someone accuses me of being impolite, over a year ago the best estimate for the death toll from the occupation of Iraq was 655,000 [8]. Current extrapolations from the previous medical research suggest that the death toll has now exceeded 1,000,000. Regardless of whether the original post was intended as satire or not, I’m not laughing and I don’t feel the need to be polite to someone who makes excuses for such loss of life. Finally as a positive suggestion towards the environment (and any other issue that you may want to discuss), I suggest analysing the issues before writing about them and not blindly trusting other people. When you write a post make objective claims with references to back them up. When you read a post consider the points that are made and the references that are cited. Do the references support the claims? Are there other interpretations of the evidence? Are the reference sites reputable?

Biella Coleman: Topics in Digital Media

Next semester I am teaching one (yay one) course and it is a graduate course on digital media. This is the description I have so far and I will post the tentative syllabus in the next few week.
Computers, especially in their networked dimension, have sparked a series of ethical, political, and social debates that often revolve around a series of stark and connected dualities: control and freedom; pleasure and exploitation; creativity and constraint. In this course we will approach topics in digital media via an historical angle that squarely addresses these dualities. To this end, we will often cross-cut readings on similar topics and material whose conclusion about the nature of computing will often vary considerably. The goal, however, is not to determine the correct or right side of these dualities but have students come away with a firm understanding of the following: 1) the history of computing and networking in light of the ways the authors as well as technologists/inventors construct or understand these dualities; 2) the various sources technological, social, and political that may shape or drive any of these elements; 3) unpack the political and social relationships, if any, between them and the stakes involved in how these authors represent the nature of computing and networking. The course primarily concentrates on computers and networks and is roughly chronological, starting with the first digital computers and ending with our digital present. Particular topics we address are: cybernetics and liberalism; networks and the cold war; personal computers and online communities; hackers, the free software movement and intellectual property; labor, development, and computers; peer-to-peer knowledge production; computer gaming; and counter-globalization and computer networking.

Jaldhar Vyas: Neoconservatism Is Good For The Environment

One of the common criticisms of the war in Iraq is that it was just an excuse to plunder that nations' oil. Of course that wasn't the reason however on Blog Action Day I urge environmentalists to think about why that might have actually been a better reason than the ones the politicians gave. The world supply of oil will probably run out in my lifetime. While alternative sources of energy are being researched, they have yet to be viable on a large enough scale to keep the world economy running at its present rate of progress. For the time being we must depend on oil and it is of vital importance that this precious resource is managed carefully. The problem is that it is not. Whereas civilized countries use energy for good purposes most of the oil is produced in countries which can only be described as evil. Take Saddams Iraq for instance; apologists claim it was one of the most advanced Arab nations, but that isn't setting a very high bar is it? Oil wealth was not used to better the lives of citizens but to prop up a savage and despotic regime. It is the poor and desperate deprived of the ability to take part in free markets who despoil the environment in a struggle to survive. Look at the other major oil producers and there too you will see a veritable rogues gallery. Some of these villains may be motivated by fundamentalism, some by socialism but the effect is the same. The common man in their countries does not get to enjoy the fruits of progress They are forced to muddle along with old, energy-inefficient, pollution-causing tech and their large numbers and vast geographical range undermine any modest environmental gains made by a few middle-class Westerners. How could anyone who cares about the fate of our mother Earth stand by and watch her bounty being squandered by dictators? See rapidly dwindling resources wasted on jihad and revolution? The next time there is talk of war, be environmentally responsible and ask your representatives to make securing oil and spreading capitalism priorities. You owe it to your planet.

13 October 2007

Biella Coleman: On Networks and Experimental Writing

One of my dissertation thesis advisors, Christopher Kelty, is teaching a superb looking course at Harvard this fall on networks. The only thing I would add to that syllabus right now is a book by a department colleague, Alexander Galloway, who just published a book with Eugene Thacker The Exploit. And while I have not read more than a chapter, what I like about it is its experimental style. They open this book with the following orientation:
It is our intention in this book to avoid the limits of academic writing in favor of a more experimental, speculative approach. To that end, we adopt a two-tier format. Throughout Part I, “Nodes,” you will find a number of condensed, italicized header that are glued together with more standard prose. For quick immersion, we suggest skikking Part I by reading the italicized sections only…. In this sense, we hope you will experience the book not as the step-by-step propositional evolution of a complete theory but as a series of marginal claims, disconnected in a living environment of many thoughts, distributed across as many pages.
The good thing is while the form is experimental, at the sentence level, things are quite clear. I have often had the experience of reading experimental work whose content was the experiment but not the form, and basically I did not understand a thing. In this case, it is the form that achieves their desire to explore and present their marginal claims. Annemarie Mol in The Body Multiple also uses a two-tiered experimental approach that is just fantastic, especially since her writing is especially accessible.

10 October 2007

Martin F. Krafft: Packaging with Git

Introduction I gave a joint presentation with Manoj at Debconf7 about using distributed version control for Debian packaging, and I volunteered to do an on-line workshop about using Git for the task, so it's about time that I should know how to use Git for Debian packaging, but it turns out that I don't. Or well, didn't. After I made a pretty good mess out of the mdadm packaging repository (which is not a big problem as it's just ugly history up to the point when I start to get it right), I decided to get down with the topic and figure it out once and for all. I am writing this post as I put the pieces together. It's been cooking for a week, simply so I could gather enough feedback. I am aware that Git is not exactly a showcase of usability, so I took some extra care to not add to the confusion. It may be the first post in a series, because this time, I am just covering the case of mdadm, for which upstream also uses Git and where I am the only maintainer, and I shall pretend that I am importing mdadm to version control for the first time, so there won't be any history juggling. Future posts could well include tracking Subversion repositories with git-svn, and importing packages previously tracked therewith, but this ain't no promise! (well, that last post is already being drafted, but far from finished; you have been warned!) I realise that git-buildpackage exists, but imposes a rather strict branch layout and tagging scheme, which I don't want to adhere to. And gitpkg (Romain blogged about it recently), deserves another look since, according to its author, it does not impose anything on its user. But in any case, before using such tools (and possibly extending them to allow for other layouts), I'd really rather have done it by hand a couple of times to get the hang of it and find out where the culprits lie. Now, enough of the talking, just one last thing: I expect this blog post to change quite a bit as I get feedback. Changes shall be highlighted in bold typeface.
Setting up the infrastructure First, we prepare a shared repository on git.debian.org for later use (using collab-maint for illustration purposes), download the Debian source package we want to import (version 2.6.3+200709292116+4450e59-3 at time of writing, but I pretend it's -2 because we shall create -3 further down ), set up a local repository, and link it to the remote repository. Note that there are other ways to set up the infrastructure, but this happens to be the one I prefer, even though it's slightly more complicated:
$ ssh alioth
$ cd /git/collab-maint
$ ./setup-repository pkg-mdadm mdadm Debian packaging
$ exit
$ apt-get source --download-only mdadm
$ mkdir mdadm && cd mdadm
$ git init
$ git remote add origin ssh://git.debian.org/git/collab-maint/pkg-mdadm
$ git config branch.master.merge refs/heads/master
Now we can use git-pull and git-push, except the remote repository is empty and we can't pull from there yet. We'll save that for later. Instead, we tell the repository about upstream's Git repository. I am giving you the git.debian.org URL though, simply because I don't want upstream repository (which lives on an ADSL line) hammered in response to this blog post:
$ git remote add upstream-repo git://git.debian.org/git/pkg-mdadm/mdadm
Since we're using the upstream branch of the pkg-mdadm repository as source (and don't want all the other mess I created in that repository), we'll first limit the set of branches to be fetched (I could have used the -t option in the above git-remote command, but I prefer to make it explicit that we're doing things slightly differently to protect upstream's ADSL line).
$ git config remote.upstream-repo.fetch \
    +refs/heads/upstream:refs/remotes/upstream-repo/upstream
And now we can pull down upstream's history and create a local branch off it. The "no common commits" warning can be safely ignored since we don't have any commits at all at that point (so there can't be any in common between the local and remote repository), but we know what we're doing, even to the point that we can forcefully give birth to a branch, which is because we do not have a HEAD commit yet (our repository is still empty):
$ git fetch upstream-repo
warning: no common commits
[ ]
  # in the real world, we'd be branching off upstream-repo/master
$ git checkout -b upstream upstream-repo/upstream
warning: You appear to be on a branch yet to be born.
warning: Forcing checkout of upstream-repo/upstream.
Branch upstream set up to track remote branch
  refs/remotes/upstream-repo/upstream.
$ git branch
* upstream
$ ls   wc -l
77
Importing the Debian package Now it's time to import Debian's diff.gz remember how I pretend to use version control for package maintenance for the first time. Oh, and sorry about the messy file names, but I decided it's best to stick with real data in case you are playing along: Since we're applying the diff against version 2.6.3+200709292116+4450e59, we ought to make sure to have the repository at the same state. Upstream never "released" that version, but I encoded the commit ID of the tip when I snapshotted it: 4450e59, so we branch off there. Since we are actually tracking the git.debian.org pkg-mdadm repository instead of upstream, you can use the tag I made. Otherwise you could consider tagging yourself:
$ #git tag -s mdadm-2.6.3+200709292116+4450e59 4450e59
$ git checkout -b master mdadm-2.6.3+200709292116+4450e59
$ zcat ../mdadm_2.6.3+200709292116+4450e59-2.diff.gz   git apply
The local tree is now "debianised", but Git does not know about the new and changed files, which you can verify with git-status. We will split the changes made by Debian's diff.gz across several branches.
The idea of feature branches We could just create a debian branch, commit all changes made by the diff.gz there, and be done with it. However, we might want to keep certain aspects of Debianisation separate, and the way to do that is with feature branches (also known as "topic" branches). For the sake of this demonstration, let's create the following four branches in addition to the master branch, which holds the standard Debian files, such as debian/changelog, debian/control, and debian/rules:
  • upstream-patches will includes patches against the upstream code, which I submit for upstream inclusion.
  • deb/conffile-location makes /etc/mdadm/mdadm.conf the default over /etc/mdadm.conf and is Debian-specific (thus the deb/ prefix).
  • deb/initramfs includes the initramfs hook and script, which I want to treat separately but not submit upstream.
  • deb/docs similarly includes Debian-only documentation I add to the package as a service to Debian users.
If you're importing a Debian package using dpatch, you might want to convert every dpatch into a single branch, or at least collect logical units into separate branches. Up to you. For now, our simple example suffices. Keep in mind that it's easy to merge two branch and less trivial to split one into two. Why? Well, good question. As you will see further down, the separation between master and deb/initramfs actually makes things more complicated when you are working on an issue spanning across both. However, feature branches also bring a whole lot of flexibility. For instance, with the above separation, I could easily create mdadm packages without initramfs integration (see #434934), a disk-space-conscious distribution like grml might prefer to leave out the extra documentation, and maybe another derivative doesn't like the fact that the configuration file is in a different place from upstream. With feature branches, all these issues could be easily addressed by leaving out unwanted branches from the merge into the integration/build branch (see further down). Whether you use feature branches, and how many, or whether you'd like to only separate upstream and Debian stuff is entirely up to you. For the purpose of demonstration, I'll go the more complicated way.
Setting up feature branches So let's commit the individual files to the branches. The output of the git-checkout command shows modified files that have not been committed yet (which I trim after the first example); Git keeps these across checkouts/branch changes. Note that the ./debian/ directory does not show up as Git does not know about it yet (git-status will tell you that it's untracked, or rather: contains untracked files since Git does not track directories at all):
$ git checkout -b upstream-patches mdadm-2.6.3+200709292116+4450e59
M Makefile
M ReadMe.c
M mdadm.8
M mdadm.conf.5
M mdassemble.8
M super1.c
$ git add super1.c     #444682
$ git commit -s
  # i now branch off master, but that's the same as 4450e59 actually
  # i just do it so i can make this point 
$ git checkout -b deb/conffile-location master
$ git add Makefile ReadMe.c mdadm.8 mdadm.conf.5 mdassemble.8
$ git commit -s
$ git checkout -b deb/initramfs master
$ git add debian/initramfs/*
$ git commit -s
$ git checkout -b deb/docs master
$ git add RAID5_versus_RAID10.txt md.txt rootraiddoc.97.html
$ git commit -s
  # and finally, the ./debian/ directory:
$ git checkout master
$ chmod +x debian/rules
$ git add debian
$ git commit -s
$ git branch
  deb/conffile-location
  deb/docs
* master
  upstream
  upstream-patches
At this time, we push our work so it won't get lost if, at this moment, aliens land on the house, or any other completely plausible event of apocalypse descends upon you. We'll push our work to git.debian.org (the origin, which is the default destination and thus needs not be specified) by using git-push --all, which conveniently pushes all local branches, thus including the upstream code; you may not want to push the upstream code, but I prefer it since it makes it easier to work with the repository, and since most of the objects are needed for the other branches anyway after all, we branched off the upstream branch. Specifying --tags instead of --all pushes tags instead of heads (branches); you couldn't have guessed that! See this thread if you (rightfully) think that one should be able to do this in a single command (which is not git push refs/heads/* refs/tags/*)
$ git push --all
$ git push --tags
Done. Well, almost
Building the package (theory) Let's build the package. There seem to be two (sensible) ways we could do this, considering that we have to integrate (merge) the branches we just created, before we fire off the building scripts:
  1. by using a temporary (or "throw-away") branch off upstream, where we integrate all the branches we have just created, build the package, tag our master branch (it contains debian/changelog), and remove the temporary branch. When a new package needs to be built, we repeat the process.
  2. by using a long-living integration branch off upstream, into which we merge all our branches, tag the branch, and build the package off the tag. When a new package comes around, we re-merge our branches, tag, and build.
Both approaches have a certain appeal to me, but I settled for the second, for two reasons, the first of which leads to the second:
  1. When I upload a package to the Debian archive, I want to create a tag which captures the exact state of the tree from which the package was built, for posterity (I will return to this point later). Since the throw-away branches are not designed to persist and are not uploaded to the archive, tagging the merging commit makes no sense. Thus, the only way to properly identify a source tree across all involved branches would be to run git-tag $branch/$tagname $branch for each branch, which is purely semantic and will get messy sooner or later.
  2. As a result of the above: when Debian makes a new stable release, I would like to create a branch corresponding to the package in the stable archive at the time, for security and other proposed updates. I could rename my throw-away branch, if it still existed, or I could create a new branch and merge all other branches, using the (semantic) tags, but that seems rather unfavourable.
So instead, I use a long-living integration branch, notoriously tag the merge commits which produced the tree from which I built the package I uploaded, and when a certain version ends up in a stable Debian release, I create a maintenance branch off the one, single tag which corresponds to the very version of the package distributed as part of the Debian release. So much for the theory. Let's build, already!
Building the package (practise) So we need a long-living integration branch, and that's easier done than said:
$ git checkout -b build mdadm-2.6.3+200709292116+4450e59
Now we're ready to build, and the following procedure should really be automated. I thus write it like a script, called poor-mans-gitbuild, which takes as optional argument the name of the (upstream) tag to use, defaulting to upstream (the tip):
#!/bin/sh
set -eu
git checkout master
debver=$(dpkg-parsechangelog   sed -ne 's,Version: ,,p')
git checkout build
git merge $ 1:-upstream 
git merge upstream-patches
git merge master
for b in $(git for-each-ref --format='%(refname)' refs/heads/deb/*); do
  git merge -- $b
done
git tag -s debian/$debver
debuild   # will ignore .git automatically
git checkout master
Note how we are merging each branch in turn, instead of using the octopus merge strategy (which would create a commit with more than two parents) for reasons outlined in this post. An octopus-merge would actually work in our situation, but it will not always work, so better safe than sorry (although you could still achieve the same result). If you discover during the build that you forgot something, or the build script failed to run, just remove the tag, undo the merges, checkout the branch to which you need to commit to fix the issue, and then repeat the above build process:
$ git tag -d debian/$debver
$ git checkout build
$ git reset --hard upstream
$ git checkout master
$ editor debian/rules    # or whatever
$ git add debian/rules
$ git commit -s
$ poor-mans-gitbuild
Before you upload, it's a good idea to invoke gitk --all and verify that all goes according to plan:
screenshot of gitk after the above steps
When you're done and the package has been uploaded, push your work to git.debian.org, as before. Instead of using --all and --tags, I now specify exactly which refs to push. This is probably a good habit to get into to prevent publishing unwanted refs:
$ git push origin build tag debian/2.6.3+200709292116+4450e59-3
Now take your dog for a walk, or play outside, or do something else not involving a computer or entertainment device.
Uploading a new Debian version If you are as lucky as I am, the package you uploaded still has a bug in the upstream code and someone else fixes it before upstream releases a new version, then you might be in the position to release a new Debian version. Or maybe you just need to make some Debian-specific changes against the same upstream version. I'll let the commands speak for themselves:
$ git checkout upstream-patches
$ git-apply < patch-from-lunar.diff   #444682 again
$ git commit --author 'J r my Bobbio <lunar@debian.org>' -s
  # this should also be automated, see below
$ git checkout master
$ dch -i
$ dpkg-parsechangelog   sed -ne 's,Version: ,,p'
2.6.3+200709292116+4450e59-3
$ git commit -s debian/changelog
$ poor-mans-gitbuild
$ git push
$ git push origin tag debian/2.6.3+200709292116+4450e59-3
That first git-push may require a short explanation: without any arguments, git-push updates only the intersection of local and remote branches, so it would never push a new local branch (such as build above), but it updates all existing ones; thus, you cannot inadvertedly publish a local branch. Tags still need to be published explicitly.
Hacking on the software Imagine: on a rainy Saturday afternoon you get bored and decide to implement a better way to tell mdadm when to start which array. Since you're a genius, it'll take you only a day, but you do make mistakes here and there, so what could be better than to use version control? However, rather than having a branch that will live forever, you are just creating a local branch, which you will not publish. When you are done, you'll feed your work back into the existing branches. Git makes branching really easy and as you may have spotted, the poor-mans-gitbuild script reserves an entire branch namespace for people like you:
$ git checkout -b tmp/start-arrays-rework master
Unfortunately (or fortunately), fixing this issue will require work on two branches, since the initramfs script and hook are maintained in a separate branch. There are (again) two ways in which we can (sensibly) approach this:
  • create two separate, temporary branches, and switch between them as you work.
  • merge both into the temporary branch and later cherry-pick the commits into the appropriate branches.
I am undecided on this, but maybe the best would be a combination: merge both into a temporary branch and later cherry-pick the commits into two additional, temporary branches until you got it right, and then fast-forward the official branches to their tips:
$ git merge master deb/initramfs
$ editor debian/mdadm-raid                     #  
$ git commit -s debian/mdadm-raid
$ editor debian/initramfs/script.local-top     #  
$ git commit -s debian/initramfs/script.local-top
[many hours of iteration pass ]
[  until you are done]
$ git checkout -b tmp/start-arrays-rework-init master
  # for each commit $c in tmp/start-arrays-rework
  # applicable to the master branch:
$ git cherry-pick $c
$ git checkout -b tmp/start-arrays-rework-initramfs deb/initramfs
  # for each commit $c in tmp/start-arrays-rework
  # applicable to the deb/initramfs branch:
$ git cherry-pick $c
This is assuming that all your commits are logical units. If you find several commits which would better be bundled together into a single commit, this is the time to do it:
$ git cherry-pick --no-commit <commit7>
$ git cherry-pick --no-commit <commit4>
$ git cherry-pick --no-commit <commit5>
$ git commit -s
Before we now merge this into the official branches, let me briefly intervene and introduce the concept of a fast-forward. Git will "fast-forward" a branch to a new tip if it decides that no merge is needed. In the above example, we branched a temporary branch (T) off the tip of an official branch (O) and then worked on the temporary one. If we now merge the temporary one into the official one, Git determines that it can actually squash the ancestry into a single line and push the official branch tip to the same ref as the temporary branch tip. In cheap (poor man's), ASCII notation:
- - - O             >> merge T >>     - - - = - - OT
         - - T      >>  into O >>
This works because no new commits have been made on top of O (if there would be any, we might be able to rebase, but let's not go there quite yet; rebasing is how you shoot yourself in the foot with Git). Thus we can simply do the following:
$ git checkout deb/initramfs
$ git merge tmp/start-arrays-rework-initramfs
$ git checkout master
$ git merge tmp/start-arrays-rework-init
and test/build/push the result. Or well, since you are not an mdadm maintainer (We^W I have open job positions! Applications welcome!), you'll want to submit your work as patches via email:
$ git format-patch -s -M origin/master
This will create a number of files in the current directory, one corresponding for each commit you made since origin/master. Assuming each commit is a logical unit, you can now submit these to an email address. The --compose option lets you write an introductory message, which is optional:
$ git send-email --compose --to your@email.address <file1> <file2> < >
Once you've verified that everything is alright, swap your email address for the bug number (or the pkg-mdadm-devel list address). Thanks (in advance) for your contribution! Of course, you may also be working on a feature that you want to go upstream, in which case you'd probably branch off upstream-patches (if it depends on a patch not yet in upstream's repository), or upstream (if it does not):
$ git checkout -b tmp/cool-feature upstream
[ ]
when a new upstream version comes around After a while, upstream may have integrated your patches, in addition to various other changes, to give birth to mdadm-2.6.4. We thus first fetch all the new refs and merge them into our upstream branch:
$ git fetch upstream-repo
$ git checkout upstream
$ git merge upstream-repo/master
we could just as well have executed git-pull, which with the default configuration would have done the same; however, I prefer to separate the process into fetching and merging. Now comes the point when many Git people think about rebasing. And in fact, rebasing is exactly what you should be doing, iff you're still working on an unpublished branch, such as the previous tmp/cool-feature off upstream. By rebasing your branch onto the updated upstream branch, you are making sure that your patch will apply cleanly when upstream tries it, because potential merge conflicts would be handled by you as part of the rebase, rather than by upstream:
$ git checkout tmp/cool-feature
$ git rebase upstream
What rebasing does is quite simple actually: it takes every commit you made since you branched off the parent branch and records the diff and commit message. Then, for each diff/commit_message pair, it creates a new commit on top of the new parent branch tip, thus rewrites history, and orphans all your original commits. Thus, you should only do this if your branch has never been published or else you would leave people who cloned from your published branch with orphans.
If this still does not make sense, try it out: create a (source) repository, make a commit (with a meaningful commit message), branch B off the tip, make a commit on top of B (with a meaningful message), clone that repository and return to the source repository. There, checkout the master, make a commit (with a ), checkout B, rebase it onto the tip of master, make a commit (with a ), and now git-pull from the clone; use gitk to figure out what's going on.
So you should almost never rebase a published branch, and since all your branches outside of the tmp/* namespace are published on git.debian.org, you should not rebase those. But then again, Pierre actually rebases a published branch in his workflow, and he does so with reason: his patches branch is just a collection of branches to go upstream, from which upstream cherry-picks or which upstream merges, but which no one tracks (or should be tracking). But we can't (or at least will not at this point) do this for our feature branches (though we could treat upstream-patches that way), so we have to merge. At first, it suffices to merge the new upstream into the long-living build branch, and to call poor-mans-gitbuild, but if you run into merge conflicts or find that upstream's changes affect the functionality contained in your feature branches, you need to actually fix those. For instance, let's say that upstream started providing md.txt (which I previously provided in the deb/docs branch), then I need to fix that branch:
$ git checkout deb/docs
$ git rm md.txt
$ git commit -s
That was easy, since I could evade the conflict. But what if upstream made a change to Makefile, which got in the way with my configuration file location change? Then I'd have to merge upstream into deb/conffile-location, resolve the conflicts, and commit the change:
$ git checkout deb/conffile-location
$ git merge upstream
CONFLICT!
$ git-mergetool
$ git commit -s
When all conflicts have been resolved, I can prepare a new release, as before:
$ git checkout master
$ dch -i
$ dpkg-parsechangelog   sed -ne 's,Version: ,,p'
2.6.3+200709292116+4450e59-3
# git commit -s debian/changelog
$ poor-mans-gitbuild
# git push
$ git push origin tag debian/2.6.3+200709292116+4450e59-3
Note that Git often appears smart about commits that percolated upstream: since upstream included the two commits in upstream-patches in his 2.6.4 release, my upstream-patches branch got effectively annihilated, and Git was smart enough to figure that out without a conflict. But before you rejoice, let it be told that this does not always work.
Creating and using a maintenance branch Let's say Debian "lenny" is released with mdadm 2.7.6-1, then:
$ git checkout -b maint/lenny debian/2.7.6-1
You might do this to celebrate the release, or you may wait until the need arises. We've already left the domain of reality ("lenny" is not yet released), so the following is just theory. Now, assume that a security bug is found in mdadm 2.7.6 after "lenny" was released. Upstream is already on mdadm 2.7.8 and commits deadbeef and c0ffee fix the security issue, then you'd cherry-pick them into the maint/lenny branch:
$ git checkout upstream
$ git pull
$ git checkout maint/lenny
$ git cherry-pick deadbeef
$ git cherry-pick c0ffee
If there are no merge conflicts (which you'd resolve with git-mergetool), we can just go ahead to prepare the new package:
$ dch -i
$ dpkg-parsechangelog   sed -ne 's,Version: ,,p'
2.7.6-1lenny1
$ git commit -s debian/changelog
$ poor-mans-gitbuild
$ git push origin maint/lenny
$ git push origin tag debian/2.7.6-1lenny1
Future directions It should be trivial to create the Debian source package directly from the repository, and in fact, in response to a recent blog post of mine on the dispensability of pristine upstream tarballs, two people showed me their scripts to do it. My post also caused Joey Hess to clarify his position on pristine tarballs, before he went out to implement dpkg-source v3. This looks very promising. Yet, as Romain argues, there are benefits with simple patch management systems. Exciting times ahead! In addition to creating source packages from version control, a couple of other ideas have been around for a while:
  • create debian/changelog from commit log summaries when you merge into the build branch.
  • integrate version control with the BTS, bidirectionally:
    • given a bug report, create a temporary branch and apply any patches found in the bug report.
    • upon merging the temporary branch back into the feature branch it modifies, generate a patch, send it to the BTS and tag the bug report + pending patch.
And I am sure there are more. If you have any, I'd be interested to hear about them!
Wrapping up I hope this post was useful. Thank you for reading to the end, this was probably my longest blog post ever. I want to thank Pierre Habouzit, Johannes Schindelin, and all the others on the #git/freenode IRC channel for their tutelage. Thanks also to Manoj Srivastava, whose pioneering work on packaging with GNU arch got me started on most of the concepts I use in the above. And of course, the members of the the vcs-pkg mailing list for the various discussions on this subject, especially those who participated in the thread leading up to this post. Finally, thanks to Linus and Junio for Git and the continuously outstanding high level of support they give. If you are interested in the topic of using version control for distro packaging, I invite you to join the vcs-pkg mailing list and/or the #vcs-pkg/irc.oftc.net IRC channel. NP: Aphex Twin: Selected Ambient Works, Volume 2 (at least when I started writing )

9 October 2007

Ross Burton: Experiments with GUPnP

Now that through black magic, voodoo, and a working network driver I have Avahi working on my NAS and UPnP working on my SoundBridge, I can get back to the task of learning a bit about GUPnP, a GObject-based library for UPnP. My first hack is a simple tool that pops up notification bubbles when the currently playing track changes, and it was surprisingly easy. First, wecreate a Control Point for the service we want to control. This object will emit signals when devices on the network are discovered which provide this service, so by connecting to that signal all of the discovery is handled for us.
GUPnPContext *context = gupnp_context_new (NULL, NULL, 0, &error);
GUPnPControlPoint *cp = gupnp_control_point_new (context, "urn:schemas-upnp-org:service:AVTransport:1");
g_signal_connect (cp, "service-proxy-available",
                  G_CALLBACK (service_proxy_available_cb), NULL);
gssdp_resource_browser_set_active (GSSDP_RESOURCE_BROWSER (cp), TRUE);
Now in service_proxy_available_cb we are passed a Service Proxy object to which represents a device providing the service we asked for. Service proxies can have actions invoked on them, or we can be notified when a State Variable change. There is a state variable in AVTransport called CurrentTrackMetaData but don't let that fool you: for reasons too boring to detail that doesn't cause notifications. The only interesting state variable in AVTransport is LastChange, which is basically a meta-variable which contains the name and value of the last variable which changed. Madness, I agree. This is where we come to the problem with GUPnP: it makes the protocol seem so clean and simple that when warts like this become obvious, they stand out. Anyway, we want to listen for changes to the LastChange state variable. This involves adding a notify and then subscribing to the proxy. Luckily state variables emit their current value when we subscribe to them, so we never need to fetch the current value.
static void
service_proxy_available_cb (GUPnPControlPoint *cp, GUPnPServiceProxy *proxy)
 
    gupnp_service_proxy_add_notify (proxy, "LastChange",
                                    G_TYPE_STRING, notify_cb, NULL);
    gupnp_service_proxy_set_subscribed (proxy, TRUE);
 
Believe it or not, we're actually nearly finished. Now to implement notify_cb. This is passed the variable name and a GValue containing the new value. A basic implementation is pretty simple.
static void
notify_cb (GUPnPServiceProxy *proxy,
           const char        *variable,
           GValue            *value,
           gpointer           user_data)
 
    g_print ("%s changed to %s\n", variable, g_value_get_string (value));
 
And we're done! When the program starts it discovers any devices on the network, creates proxies and watches the variables, printing them as they change. Devices can come and go, GUPnP handles that automatically. Easy as pie. Well, sort of. The string is an XML document which could contain any variable, so we need to parse it looking for a CurrentTrackMetaData node. On that node the val attribute contains an escaped XML document describing the metadata in the (and I kid you not) DIDL-Lite format. The saving grace here is that at least its partially Dublin Core, but that needs to be parsed for the title and artist information. This is all standard XML mojo, and quite boring. The end result is that my first hack application is 150 lines long, the first 100 of which are entirely devoted to XML parsing. The next step is to write a convenience library around DIDL to avoid having to parse it manually. It's not exactly a complicated task, but quite tiresome. For the curious, the full source is in this Bazaar branch. NP: Directions EP, Variou (from Acroplane I think)

6 October 2007

Joey Hess: an evolutionary change to the Debian source package format

Back around 1999, I was really interested in getting all of Debian imported into CVS (ugh!) so we could have all the benefits of pervasive version control. I've always been sad it didn't happen, especially since ubuntu did it. Although they seem to get less benefits from it than I would have thought at the time, go figure. I actually feel though that the model Debian has developed with alioth and now with VCS- fields, in which packages use version control, and debian integrates support for it without mandating it, or mandating which version control system is used, is has better legs than ubuntu's model. Ubuntu's model potentially leaves you where freebsd is now, nursing a cvs equivilant along as the world has moved on. Except, well, Debian actually picked a different version control system, and has been stuck with it for years. I refer to the diff, which is great for passing patches around by email, but not so great as a mechanism for recording the history of changes needed to debianise a package. So we have this whole set of things piled on top of the diff, like the loathsome dbs. We also have this whole set of problems in the source package format that cannot be expressed by diff and have to be messily worked around, like not being able to add/modify binary files, and not being able to (re)move files. (Wig and Pen addresses some of the worst limitations of the current format, but AFAIK noone is working on implementing support for generating Wig and Pen format packages, since doing so is unavoidably complicated.) Once I started looking at the diff in .diff.gz as a version control system, the natural thing was to think about adding support to other revision control systems, following down our path of debian supporting maintainers who choose to use a different one. So I arrived at the idea of a .git.tar.gz. Let a debian source package consist of just a .dsc and package_version.git.tar.gz, which contains only package/.git/*. Making changes to the source becomes very pleasant, since you can commit any change you like and not have to worry about how it will be repesented in the .diff.gz. And of course there's all kinds of benefits of having the history and branches and tagged upstream source available in there. Far too many benefits to list here, and only a few downsides. I look at this as very much of an evolutionary change, not a revolutionary change, to the debian source format. Most packages will continue to use .diff.gz for a long while, but packages whose maintainers chafe under that format will have another one to choose from. So, well, I implemented it. A dpkg-source that understands this format is available in the sourcev3 branch at git://kitenet.net/dpkg. I'll be posting some technical details and the patches to debian-dpkg, and I've put a FAQ about it in the wiki. A sample dpkg source package built using this is temporarily here. This demo package includes only the last 200 commits to the dpkg git repo, so it's more than 1 mb smaller than dpkg's normal .tar.gz!

3 October 2007

Thijs Kinkhorst: Welcome back red pencil

This Monday, state secretary Bijlevelt of interior affairs finally decided that any current type of voting computer is not safe enough for elections. This decision is not a surprise for anyone who's followed along with the wedonttrustvotingcomputers.nl action group, but it's the first time the government has acknowledged the full problem. This means that on the next "election" at October 10th here in Utrecht, already the red pencils will be recovered from their long time storage. Most interesting about this whole discussion is the question I only see asked sparingly:
What problem are voting computers trying to solve?
As a data point: on the last general elections, the Amsterdam district finished their counts of pen-and-paper voting before midnight on election day.

1 October 2007

Nico Golde: Archlinux leader steps back

Just read that after 6 years the leader(Judd Vinet) of the ArchLinux distribution will step down from his role.
he reason for this is that I do not have the time to devote towards a leadership role in a project the size of Arch Linux, and Arch deserves someone who does.

Referring to his post the new leader will be Aaron Griffin.

[via archlinux.org]

28 September 2007

Martin F. Krafft: Counting developers

For my research I wanted to know how to obtain the exact number of Debian developers. Thanks to help from Andreas Barth and Manoj Srivastava, I can now document the procedure:
$ ldapsearch -xLLLH ldap://db.debian.org -b ou=users,dc=debian,dc=org \
  gidNumber=800 keyFingerPrint \
    sed -rne ':s;/^dn:/bl;n;bs;:l;n;/^keyFingerPrint:/ p;bs ' \
    wc -l
1049
This actually seems enough as I do not recall any new maintainers being added since the last call for votes, which gives 1049 as well. Andreas told me to count the number of entries in LDAP with GID 800 and an associated key in the Debian keyring. Manoj's dvt-quorum script also takes the Debian keyrings (GPG and PGP) into account, so I did the same:
$ ldapsearch -xLLLH ldap://db.debian.org -b ou=users,dc=debian,dc=org \
  gidNumber=800 keyFingerPrint \
    sed -rne ':s;/^dn:/bl;n;bs;
              :l;n;/^keyFingerPrint:/ s,keyFingerPrint: ,,p;bs ' \
    sort -u > ldapfprs
$ rsync -az --progress \
  keyring.debian.org::keyrings/keyrings/debian-keyring.gpg \
  ./debian-keyring.gpg
$ gpg --homedir . --no-default-keyring --keyring debian-keyring.gpg \
  --no-options --always-trust --no-permission-warning \
  --no-auto-check-trustdb --armor --rfc1991 --fingerprint \
  --fast-list-mode --fixed-list-mode --with-colons --list-keys \
    sed -rne 's,^fpr:::::::::([[:xdigit:]]+):,\1,p' \
    sort -u > gpgfprs
$ rsync -az --progress \
  keyring.debian.org::keyrings/keyrings/debian-keyring.pgp \
  ./debian-keyring.pgp
$ gpg --homedir . --no-default-keyring --keyring debian-keyring.pgp \
  --no-options --always-trust --no-permission-warning \
  --no-auto-check-trustdb --armor --rfc1991 --fingerprint \
  --fast-list-mode --fixed-list-mode --list-keys \
    sed -rne 's,^[[:space:]]+Key fingerprint = ,,;T;s,[[:space:]]+,,gp' \
    sort -u > pgpfprs
$ sort ldapfprs pgpfprs gpgfprs   uniq -c \
    egrep -c '^[[:space:]]+2[[:space:]]'
1048
MAN OVER BOARD! Who's the black sheep? Update: In the initial post, I forgot the option --fixed-list-mode and hit a minor bug in gnupg. I have since updated the above commands. Thus, there is no more black sheep and the rest of this post only lingers here for posterity.
while read i; do
  grep "^$ i $" pgpfprs gpgfprs   echo $i >&2
done < ldapfprs >/dev/null
which returns 9BF093BC475BABF8B6AEA5F6D7C3F131AB2A91F5
$ gpg --list-keys 9BF093BC475BABF8B6AEA5F6D7C3F131AB2A91F5
pub   4096R/AB2A91F5 2004-08-20
uid                  James Troup <james@nocrew.org>
our very own keyring master James Troup. So has James subverted the project? Is he actually not a Debian developer? Given the position(s) he holds, does that mean that the project is doomed? Ha! I am so tempted to end right here, but since my readers are used to getting all the facts, here's the deal: James is so special that he gets to be the only one to have a key in our GPG keyring which can be used for encryption, or so I found out as I was researching this. Now this bug in gnupg actually causes his fingerprint not to be printed. Until this is fixed (if ever), simply leave out --fast-list-mode in the above commands. NP: Oceansize: Effloresce

27 September 2007

Russell Coker: Eating Corpses

Davyd Madeley writes about vegetarianism for the environment [1] which is listed in Wikipedia as Environmental Vegetarianism [2]. He links to an article on the Huffington Post [3]. The Huffington Post article in turn links to an article on GoVeg.com about global warming [4]. Mass-produced meat is not only bad for the environment but there are also health issues related to meat consumption (due to bad practices in mass farming, combining the meat of thousands of animals into mince thus increasing the spread of bad meat, and the fact that most people in first-world countries consume significantly more meat than anyone did at any time in history). One thing that doesn’t get mentioned in these posts is the fact that farming is not required to produce meat. In fact the meat that is most healthy (due to lack of carcinogenic chemicals and free-range feeding) and has the strongest flavour (which may be a good or bad thing depending on whether you actually like the flavour of meat) is from wild animals. If you don’t like the taste of meat (which seems to be the case when people don’t like game meat) then why eat it at all? In Australia large numbers of kangaroos are killed because they eat grass more efficiently than cattle (they have evolved over tens of thousands of years to survive in Australian conditions unlike cattle). There are also a number of foreign animals that have run wild in Australia and are considered vermin, this includes rabbit, pig, buffalo, deer and camel (all of which are tasty). Even among native animals there are often times when a cull is needed. If some good seasons allow the population to increase then when there is a bad season the population has to reduce and it’s often better for them to be culled (thus providing plenty of food for the surviving animals) than for all of them to starve. There is a game meat wholesaler I’ve visited a few times that sells buffalo, rabbit, pig, camel, crocodile, possum, emu, kangaroo, and some other animals. All of the meat is from wild animals (apart from rabbit and pig none of those animals can be domesticated). I’m sure that every region has such a wholesaler that will sell to interested individuals if you know where to look (it seems impossible to buy any game meat other than kangaroo retail in Australia). Finally one thing that offends me is people who eat meat but are not prepared to kill the animal. If you aren’t prepared to kill it then you shouldn’t pay someone else to do so on your behalf! Claiming that “the animal was going to be killed anyway” is a pitiful excuse that is only suitable for children. It’s acceptable for children to eat meat without thinking about where it came from. But adults should be able to deal with the fact that eating meat means killing animals - or become vegetarian if they can’t cope with it. The book 3001 The Final Odyssey pioneered the term “corpse food” for eating meat. I believe that the term is accurate and should be used. If you can’t stomach eating corpses then there are many good vegetarian options available. There are many vegetarians in the Linux community. As these issues are getting discussed a lot recently maybe it would be good to have the vegetarians choose some good vegetarian restaurants to have Linux meetings on occasion. Davyd got a bit of negative feedback on his post, maybe if he invited a bunch of his local Linux people to have dinner at a vegetarian restaurant and they enjoyed the food then the reaction to such ideas would be more positive.

26 September 2007

Lucas Nussbaum: Compiz interest

From time to time, I try Compiz, to see if how it has evolved. The last time was yesterday (I also switched to the xserver-xorg-driver-ati from experimental). But as usual, after using it for a few minutes, I can’t help switching back to metacity. I don’t think that Compiz’s visual effects bring anything on the usability POV, and I just find them annoying after the initial “WOW”. Of course, it’s nice to show off, but to do actual work? Are there people really using it all the time?

25 September 2007

MJ Ray: What is needed to start Open Social Networking?

Since the closure of SoFlow and adding myself to LinkedIn, I've been thinking a bit about Professional Associations and using Social Networks (SNs) for business. I've not worked out my answers, so this is a "dear lazyweb, what pieces of this jigsaw am I missing?" post. Much of the recent mainstream news has been about the legal problems of SNs - for example, see BBC: Web networkers 'at risk of fraud' (which was also in items on a recent Click show on BBC World and News24) and BBC: Facebook site faces fraud claim - or about how they could Save The World, like BBC: Social net offers new perspective I think there's a bigger problem which will stop SNs making a deep-change to online activity. Each time a SN like SoFlow closes, it wastes some resources of its members. I'm starting to side with other developers in being tired of seeing my input turn to bitrot, through buggy software or buggy business models. I'm not alone: see Gunnar Wolf: On social networks for example. A good idea seems to be on Slashdot: It's Time for Social Networks to Open Up but how? Each SN seems to guard its dark corners as vital elements of its business model. Should we look to our Professional Associations to create new Open Social Networks (OSNs)? After all, SNs aren't the core money-makers for professional associations. But, the biggest problem with Professional Associations is picking a trustworthy one - one which will do what it says on the tin, instead of taking your subscription, then undermining you. Consider the British Computer Society and its OSSG License: how many of its members really wanted another software copyright licence? Fortunately, it was spotted - Volunteer brickbat thrower needed in London (Tuesday 24th 6pm) - and the Report from BCS OSSG meeting on a new FS license suggests the negative feedback was loud and clear, so hopefully we won't see that again. If I was a BCS member, I'd probably not renew after helping to fund that harmful activity. librarian.net: choosing your battles and choosing your professional associations talks a little about some library associations as a sort of case study which many will recognise as familiar, but there's an interesting comment from Blake there:
"I think there's an association out there for everyone."
Is there? What association is out there for liberal hackers and webmasters? I don't think I've found it yet. So, should we be looking at ourselves, rather than existing professional associations? Can we do Open Social Networks peer-to-peer in a meaningful way? Are we already doing it with blog feeds? How should we expand on that? Although I disagree with the conclusion that using another Social Network site with an uncertain business model is How to succeed with social networking, the article also mentions that
"social networking is in its infancy and that it will not really get underway until we have portable profiles and interconnectivity"
In other words, it's our revolution - let's steal it back. (Update: 2007-09-27: 1 comment)

Next.

Previous.