So, you might have heard about Blackle. It's Google with a black
background. Apparently, it's a misguided attempt to save
electricity.
A little searching around shows that there's also a Greenle. And a
Pinkle. All seem to be have been built independently. We need a
Purple.
Update: Also, Bluegle and the the confusing similarly named, but
fundementally different Graygle and Greygle.
Update: And Browngle.
Apparently Scott James Remnant in his article on version
control systems confuses arch and git. One can only speculate that his short git
usage stems from the pre 1.0 days, where you had to use higher level tools
(called porcelain) to happily work on git. A funny anecdote is that Scott
back in his dpkg hacking year promoted arch heavily.
Ubuntu^Wbzr propaganda spreads speed gains as big bonus of the last major
releases. In order to be able to do that you have to start with a terrible
baseline. Testing bzr on middle sized repos is no fun at all. The bzr pain
inside launchpad must be beyond imagination.
Nowadays it is much easier to hack on mdadm than on lvm2. The reason is that
later project uses rusty cvs. With git it is really easy to contribute back.
Either you mail the patches or publish your repository. git will help you
along on each way.
The other very big bonus of git is the big community around git. It is a
community excited around building and delivering the best version control system. The git
development does regular surveys on git usages and incorporates back the
wishlists.
The most "funny" way to use git is to run it as cvsserver. You may believe
me or not i have seen git cvsserver emulation usage in the wild.
Usage: arismom [OPTION]... [FILE]...
Do it Jersey style.
-a, --all do all those things
-b bubble
--bounce bonuce
--CoC=STYLE adhere to STYLE code of conduct
-d, --debian=PACKAGE dedicate actions to Debian PACKAGE
-e, --ensqualm=USER ensqualm USER first
-t, --tempdir=DIRECTORY spew temporary files into DIRECTORY
So let's cut to the quick. Create a file called _arismom somewhere
in your function search path. This is described by the array $fpath.
You can view its contents by typing print -l $fpath, and you
can add a a directory to the beginning with fpath=(~/.zsh/scratch $fpath)
or to the end with fpath+=(~/.zsh/scritch). For the purposes
of this blog entry, we'll pretend you have a ~/.michaelbolton/squatch
directory in your $fpath and that you are now editing
~/.michaelbolton/squatch/_arismom. The first line of the file,
at the very tippy top, should read
#compdef arismomThis ensures that when the completion system boots up and finds your file, it will associate your function with the command arismom and complete options and arguments for it accordingly. Speaking of arguments, skip a line for aesthetic equilibrium, and invoke the _arguments utility function.
_arguments \_arguments is sort of the cdbs of the zsh completion fleet. By the end of this blog entry, you'll have no idea how it works, and if you want to do anything particularly complex with it, you might encounter some resistance. For those of you unfamiliar with Z-Shell syntax or shell syntax in general, the trailing backslash means I'm a-gonna feed you a ton of information about the command-line interface to arismom. So tell it about the first option already.
'(-a --all)' -a,--all '[do all those things]' \To oversimplify, this declares that -a and --all are options which produce the identical behavior of do all those things . Specifically, the part in parentheses says to not complete either -a or --all when either -a or --all is already on the command-line. The part in braces is merely brace expansion; for that reason it is outside of the single quotes. If you're unfamiliar with brace expansion, try print '(alice)' bob,carnie '[wilson]' to see how it expands. Finally, the phrase in brackets is an explanation of the option, which may or may not be displayed depending on your configuration. Next, do a short option that has no long option equivalent.
'-b[bubble]' \A long option with no short option equivalent looks similar. Don't feel limited by upstream's inadequate descriptions, misspellings, or poor grammar.
'--bounce[amplify bounce level according to X-la algorithm]' \Some options take arguments. Now we use colons.
'--CoC=[adhere to CoC]:CoC style:(mjg59 buxy ubuntu)' \The first column is the same optspec by which you've been so excited thus far, and the part between the colons is the message or description of that which will be matched. The part after the last colon is the action; in this case you are specifying a list of possibilities within single parentheses. In most cases, you'll want to be more dynamic than a pre-defined list, and there are many helper functions all ready to serve you.
'(-d --debian)' -d,--debian= '[dedicate actions to Debian package]:package:_deb_packages avail' \_deb_packages is a function that completes Debian packages; it can take avail, installed, or uninstalled to restrict which set of packages it offers. In this case we want it to complete any package available from your sources.
'(-e --ensqualm)' -e,--ensqualm= '[ensqualm user first]:user to ensqualm:_users' \Here the _users function will complete usernames.
'(-t --tempdir)' -t,--tempdir= '[spew]:temp dir:_files -/' \Normally the _files function will complete files, but you can tell it that you only want directories with the -/ option. Finally, we want to cover all the remaining arguments (which according to the fictitious usage information is a list of files). In this case, you happen to believe that files with the .nj extension are to be completed.
'*:NJ files:_files -g "*.nj"'The -g option specifies a glob pattern to match files. Now the entire file should look like this.
#compdef arismom _arguments \ '(-a --all)' -a,--all '[do all those things]' \ '-b[bubble]' \ '--bounce[amplify bounce level according to X-la algorithm]' \ '--CoC=[adhere to CoC]:CoC style:(mjg59 buxy ubuntu)' \ '(-d --debian)' -d,--debian= '[dedicate actions to Debian package]:package:_deb_packages avail' \ '(-e --ensqualm)' -e,--ensqualm= '[ensqualm user first]:user to ensqualm:_users' \ '(-t --tempdir)' -t,--tempdir= '[spew]:temp dir:_files -/' \ '*:NJ files:_files -g "*.nj"'There you have it. Restart zsh and try tab-completing various things after arismom. P.S. I expect bug reports containing functions for dpatch-edit-patch, pkill, and pgrep by tomorrow morning. P.P.S. Why is Scott James Remnant still on Planet?
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/nullwhich 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
Like any sensible software developer, I have a close relationship with revision control systems. In my previous job, I was an SCM Engineer (see Software configuration management) which meant I had an even closer relationship than most, since we were running the CVS servers and actively using them to track changes and deployments.
We all know, deep down, that revision control systems shouldn’t exist. This kind of thing should be inherent in the design of the operating system, through standard file and filesystem formats. The OLPC interface is making some headway towards that, but for the rest of us, it means using a revision control tool throughout the development process.
Unfortunately, even though the tool is expected to be the most-used command on your system, very few of them are particularly easy to use. Thus there’s a large learning curve, and people become religious about their choice since they have invested significant time in using it.
Just to spice the mix up, not only will people religiously defend their choice of revision control system, but they’ll do so while actively hating it.
In the beginning there was CVS and we all thought that it was pretty good. It was based on the simpler RCS and shared a file-format with it, but introduced control of directory trees and remote operation.
Actually, in reality, CVS wasn’t that good. Its command set could be a little strange and inconsistent (e.g. it’s not possible to diff between two dates on a branch); the support for branching assumed that all branches would be merged into the mainline, and only once; and nobody ever really knew how to create a new project in a repository (tip. cvs import is wrong).
But we all used it anyway, and we muddled through. It did have some good features; it was simple, fast and pretty reliable–when it did break, you could usually fix the repository yourself. And most importantly of all, we understood how to drive it.
And so it was for many years, until Subversion (SVN) came along. Subversion intended to be “a better CVS”, perhaps this goal should have made us suspicious at the time since CVS was already being a pretty good CVS by itself; unfortunately we hated CVS so much we flocked to the new system in hope.
In hindsight, Subversion didn’t really improve on CVS much at all. In fact, arguably, the only real improvement was the addition of atomic commits (in CVS, each commit is per-file, so it’s manual labour to work out which change was made to two files at the same time).
(Its support for branching, tagging, copying, renaming, etc. were no better than CVS’s when done in the repository by hand.)
The cost of this single new feature was a much more complicated interface (with two separate commands), a backend that tended to break down weekly and a lethargic slowness to its operation.
Most people I know now justify their use of Subversion instead of CVS by “Subversion is maintained, CVS isn’t” which is a somewhat self-fulfilling justification.
While the mass conversion to Subversion, and ensuing disappointment and frustration, was going on; something new appeared on the horizon: Arch.
Arch was different, it broke one of the core assumptions of revision control, that of the repository as a cathedral. In CVS, and Subversion like it, if somebody wants to modify your code (even if on a branch) you need to give them access to your own repository. In some cases (especially with CVS), vast access control and permission structures would be in place to ensure proper behaviour.
With Arch, you don’t; all you need to give to anyone is read access. Anybody can make their own branch by copying yours and committing to their own copy.
This model also necessitated fixing a long standing problem that CVS had; Arch has repeatable (smart) merging. If you merge from a branch, you can merge again later, and again, and again.
Arch made this possible through each commit (changeset) having a globally unique identifier; made from the branch’s own globally unique identifier and the changeset number in the branch.
Unfortunately while this was a massive step in a new direction, Arch had an absolutely terrible user interface. Its command list was terrifying with over 100 commands, many of which had multiple word names (tla set-tree-version). It exposed too many of its own innards, and expected you to learn them. It also forced baroque file naming semantics on its users and strange policy (though shalt not commit without first running “make clean”).
Efforts were made to improve Arch’s user interface through projects such as baz, but they were always to be doomed from the start.
We’ve since seen an explosion of new revision control systems; Monotone, Darcs, Git and Bazaar.
What’s especially interesting is the commonality between these systems. They are all “distributed” like Arch, though they also all discard the strange “unique branch identifier” convention and instead simply assign a unique identifier to each file or commit.
This means that they all support personal branches, and by necessity all support repeatable (smart) merging.
So how do they differ, what are their killer features and killer problems?
Monotone is all about repository integrity, ensuring that every commit is both authorised and intact. It pays for this with a severe lack of speed.
Darcs is based around a “theory of patches”, a branch is not made up of its history but by the collection of patches in it. Unfortunately this often breaks down, and darcs frequently gets stuck calculating even trial and commonplace branch models.
Git is very strange to me; its killer feature appears to be the speed at which it can handle very large trees, but the interface is as insane as Arch’s was. It is heavily optimised for the “I only apply patches” development model, at the expense of ordinary development models (it shares an issue with Arch where calculating annotations on an individual file is an expensive operation).
What about Bazaar? Its killer feature is that it is designed to work the way you do. The command set is relatively small, and each of them works in the most obvious manner. It also supports plugins so that you can always implement your own workflow.
Of all the revision control systems, it’s the only one (that I’m aware of) that supports both distributed and centralised workflows (and lets you go distributed when you need to, e.g. when you’re on a plane).
Here’s a few examples of how Bazaar’s command set works the way you do. To start managing some code in bzr:
$ cd myproject
$ bzr init
.bzrignore file and just add everything:
$ cp ~/bzrignore .bzrignore
$ bzr add
added foo.c
added bar.c
.bzrignore and remove the file with bzr rm.
A common operation is realising that the commit you’re about to make should really go on a new branch for now:
$ cd ..
$ cp -a myproject myproject-foo
$ cd myproject-foo
$ bzr commit
bzr branch command for it too (which deals with issues such as bound branches, checkouts, etc.) but it’s nice to demonstrate that Bazaar does what you’d expect even when you don’t use its own commands.
Pulling changes from another branch (where you haven’t made any modifications yet) is easy:
$ bzr pull ../myproject
$ bzr merge ../myproject
Seriously. Now that we have been using the request tracker for quite some time, it’s even more obvious that the DSA team is not up to its task.
Use login “guest” and password “readonly” if you want to check the RT tickets linked in this article.
The facts
I have an intense, unexplainable, uneasiness around lamp stores. Perhaps
it's even a fear.
Something about so many lamps, so close together. It seems unnatural.
Very Wrong.
Due to the fact that my favorite Window manager is now licensed
non-freely (and then some), I award Tuomo Valkonen the J rg
Schilling award for free software project management.
Tuomo can console himself with his award while I console myself with
Tritium. With the new dock feature announced today, I think it
just turned into something I can switch to.
Inspired by Mitchell Charity's printable paper rulers and Steve
Pomeroy's CSS ruler, I wrote a little python script to generate an
on-screen ruler for the OLPC XO-1. The XO-1 screens are super high
resolution (200dpi) and are each identical. This makes for a very
accurate ruler. It's one of a few project I've done or am working on
that tries to take advantage of the physical qualities (and physical
consistencies) of the XOs. Also, a ruler is just a really useful thing
for a school child -- or anyone else for that matter.
Of course, different screens have different pixel sizes so the ruler for
the XO won't work on another screen. This made some of my friends
jealous. To appease them, I spent a couple hours and hacked up a little
web frontend to my ruler generator which allows anyone to create custom
on-screen rulers and to save them and share them with others who might
have the same screen. I've called it YouRule. Please check it
out or download the source and send me improvements.
http://projects.mako.cc/yourule
This Saturday, September 15, is Software Freedom Day 2007. With more
than 300 teams registered, there's a good chance that there's something
going on near you.
I'll be helping at the Software Freedom Day event in downtown Boston
where I'll be giving a talk on a still undetermined topic. I'll also be
helping out with GNU/Linux and RockBox installs and letting folks play
with my XO and OpenMoko.
If you are into free software, open source, or GNU/Linux, please show up
to your local SFD event. Go ahead and bring your friends who are not yet
familiar with free software -- this event is primarily for them.
In Boston, there will be refreshments, talks, demonstrations, and
installs. Bring your laptop, desktop, iPod, or other DAP -- or just
bring yourself and a friend.
I think I’ve just invented a new sport…
Everyone knows the game of Googling your own name, and finding out all sorts of fascinating things that you have forgotten or didn’t realise had made it onto the Interwobble.
Here’s a new twist, use the Internet Archive Wayback Machine instead and read through things like old versions of your homepage.
I’m honestly shocked at just how much incriminating material I’ve found, both from my own website and segfault.org
This comment on my site from Leonard Richardson and my reply especially amused:
What percentage of the time are you drunk? This is to settle a bet. Okay, well on an average week I guess I go out for 3 nights. Friday night starts at 5:30 and ends 12 hours later, the other two days would be probably from 9:30 to 2:30am, so 5 hours. So we can say I spend 22 hours innebriated. Just under a day, or 13% of the week. Some weeks that might be as much as 25% to 30% I guess tho. Who was the bet with, and more importantly, who won?This explains a lot …
Perhaps you want to both reflect on 9/11 and help demonstrate that
limericks can be serious by writing some serious limericks about
9/11?
Several months ago, I announced that I'd received a grant from mtvU
and Cisco to work on a cool voting technology research project called
Selectricity. A project in quotidian democracy, Selectricity attempts
to apply some of the best voting technology and election methods
research towards every-day decision-making. It takes research I did at
the MIT Media Lab and packages it into a real, useful, application.
I spent probably half of my time over the last several months managing
a team of competent hackers and designers as we've built out the
project. Last week, press releases and news stories went out as
we launched our first production batch of features and a new design. You
can check it out online at:
http://selectricity.orgThere is a whole line-up of a groups and organizations, some high profile, that will be using the software in the coming months. There's also half a dozen killer new features that are built and waiting in the wings for a little polish and fanfare. We'll be testing and releasing those in the next couple months. No doubt, I'll be mentioning bits and pieces of my work on the project on my blog here. However, if you want to follow development, you should subscribe to the Selectricity News Blog where more full coverage will take place. You can leave feedback, suggestions, and bugs as comments on the blog or email it to team@selectricity.org. The election method code is already published and we'll be releasing the rest of the code under the AGPLv3 when the license is released by the FSF in the next few weeks.
Last week, Rapha l Hertzog mentioned a transition in progress that
was going to change the way that Planet Debian updates. As part of
the plan to deprecate cvs.debian.org, Rapha l helped me move Planet
Debian away from the old CVS repository and to a new Subversion
repository in Alioth.
Readers of Planet Debian should not notice any differences.
When it comes time to change or disable a feed, contributors to planet
Debian will have to update their feed slightly differently.
Documentation on how the new method is now in the wiki and at
gluck:/org/planet.debian.org/README.
As Rapha l mentioned, all Debian Developers have write access to the
configuration file in the Subversion repository through their Alioth
accounts. Unlike the old setup, non-DD's who have blogs in Planet can
have write access to it as well, but they'll need to have an Alioth
account and they'll need to be added to the ACL by me. As before, it's
only OK to modify one's one feed and anyone who violates this in bad
faith will have their privileges to the repository removed.
The old CVS repository remains crudely broken. Please help update any
references to the old CVS-based method or alert me to documentation
that's public and out of date that you don't have access to change
yourself.
Continuing my mission to put together a kick-ass team to develop the Ubuntu Desktop, the following position is now up on the website:
Posting Date & ID: September 2007 UDD
Earlier this year I blogged about using the twitter bot for Remember the Milk. I still use it fairly well, even though the SMS messages from the RTM come late a bit. It's working for me in order to get a good chain going for the thesis proposal. There are a couple other bots that I'm using which are on twitter as well. Next.