I don’t spend a lot of time customizing my “working” environment nowadays, like enhancing vim configuration, or tweaking the shell. But when I read MadCoder’s zsh git-enabled prompt, I though it was too convenient to not have something like that. Except I don’t work with git only (sadly, but that’s changing), and I don’t like colours in prompt (and a 2 lines prompt is too much). Anyways, since I have a bunch of directories in my $HOME that contain either svk, svn, mercurial, or git working trees, I thought it would be nice to have some information about all this on my prompt. After a few iterations, here are the sample results:

mh@namakemono:~/dd/packages$
mh@namakemono:(svn)~/dd/packages/iceape[trunk:39972]debian/patches$
mh@namakemono:(svk)~/dd/packages/libxml2[trunk:1308]include/libxml$
mh@namakemono:(hg)~/moz/cvs-trunk-mirror[default]uriloader/exthandler$
mh@namakemono:(git)~/git/webkit[debian]JavaScriptCore/wtf$


The script follows, with a bit of explanation intertwined.

_bold=$(tput bold)
_normal=$(tput sgr0)


tput is a tool I only dicovered recently, and avoids the need to know the escape codes. There are also options for cursor placement, colours, etc. It lies in the ncurses-bin package, if you want to play with it.

__vcs_dir()
  local vcs base_dir sub_dir ref
  sub_dir()
    local sub_dir
    sub_dir=$(readlink -f "$ PWD ")
    sub_dir=$ sub_dir#$1
    echo $ sub_dir#/
  


We declare as much as possible as local (even functions), so that we avoid cluttering the whole environment. sub_dir is going to be used in several places below, which is why we declare it as a function. It outputs the current directory, relative to the directory given as argument.

  git_dir()
    base_dir=$(git-rev-parse --show-cdup 2>/dev/null) return 1
    base_dir=$(readlink -f "$base_dir/..")
    sub_dir=$(git-rev-parse --show-prefix)
    sub_dir=$ sub_dir%/
    ref=$(git-symbolic-ref -q HEAD git-name-rev --name-only HEAD 2>/dev/null)
    ref=$ ref#refs/heads/
    vcs="git"
  


This is the first function to detect a working tree, for git this time. Each of these functions set the 4 variables we declared earlier: vcs, base_dir, sub_dir and ref. They are, respectively, the VCS type, the top-level directory of the working tree, the current directory, relative to base_dir, and the branch, revision or a reference in the repository, depending on the VCS in use. These functions return 1 if the current directory is not in a working tree of the currently considered VCS.
The base directory of a git working tree can be deduced from the result of git-rev-parse --show-cdup, which gives the way up to the top-level directory, relative to the current directory. readlink -f then gives the canonical top-level directory. The current directory, relative to the top-level, is simply given by git-rev-parse --show-prefix.
git-name-rev --name-only HEAD gives a nice reference for the current HEAD, especially if you’re on a detached head. But this can turn out to do a lot of work, introducing a slight lag when you cd for the first time in the git working tree, while most of the time, the HEAD is just a symbolic ref. This is why we first try git-symbolic-ref --name-only HEAD.

  svn_dir()
    [ -d ".svn" ] return 1
    base_dir="."
    while [ -d "$base_dir/../.svn" ]; do base_dir="$base_dir/.."; done
    base_dir=$(readlink -f "$base_dir")
    sub_dir=$(sub_dir "$ base_dir ")
    ref=$(svn info "$base_dir" awk '/^URL/ sub(".*/","",$0); r=$0 /^Revision/ sub("[^0-9]*","",$0); print r":"$0 ')
    vcs="svn"
  


Detecting an svn working tree is easier : it contains a .svn directory, be it top-level or sub directory. We look up the top-level directory by checking the last directory containing a .svn sub directory on the way up. This obviously doesn’t work if you checkout under another svn working tree, but I don’t do such things.
For the ref, I wanted something like the name of the directory that has been checked out at the top-level directory (usually “trunk” or a branch name), followed by the revision number.

  svk_dir()
    [ -f ~/.svk/config ] return 1
    base_dir=$(awk '/: *$/ sub(/^ */,"",$0); sub(/: *$/,"",$0); if (match("'$ PWD '", $0"(/ $)")) print $0; d=1; /depotpath/ && d == 1 sub(".*/","",$0); r=$0 /revision/ && d == 1 print r ":" $2; exit 1 ' ~/.svk/config) && return 1
    ref=$ base_dir##*

    base_dir=$ base_dir%%
*
    sub_dir=$(sub_dir "$ base_dir ")
    vcs="svk"
  


svk doesn’t have repository files in the working tree, so we would have to ask svk itself if the current directory is a working tree. Unfortunately, svk is quite slow at that (not that it takes several seconds, but that induces a noticeable delay to display the prompt), so we have to parse its config file by ourselves. We avoid running awk twice by outputing both the informations we are looking for, separated by a carriage return, and then do some tricks with bash variable expansion.

  hg_dir()
    base_dir="."
    while [ ! -d "$base_dir/.hg" ]; do base_dir="$base_dir/.."; [ $(readlink -f "$ base_dir ") = "/" ] && return 1; done
    base_dir=$(readlink -f "$base_dir")
    sub_dir=$(sub_dir "$ base_dir ")
    ref=$(< "$ base_dir /.hg/branch")
    vcs="hg"
  


I don’t use mercurial much, but I happen to have exactly one working tree (a clone of http://hg.mozilla.org/cvs-trunk-mirror/), so I got some basic information. There is no way we can ask mercurial itself for information, it is too slow for that (main culprit being the python interpreter startup), so we take the informations we can (and since I don’t know much about mercurial, that’s really basic). Note that if you’re deep in the VFS tree, but not in a mercurial working tree, the while loop may be slow. I didn’t bother much looking for a better solution.

  git_dir
  svn_dir
  svk_dir
  hg_dir
  base_dir="$PWD"


Here we just run all these functions one by one, stopping at the first that matches. Adding some more for other VCS would be easy.

  echo "$ vcs:+($vcs) $ _bold $ base_dir/$HOME/~ $ _normal $ vcs:+[$ref]$ _bold $ sub_dir $ _normal "

PS1='$ debian_chroot:+($debian_chroot) \u@\h:$(___vcs_dir)\$ '


Finally, we set up the prompt, so that it looks nice with all the gathered information. Update: made the last lines of the script a little better and factorized.

Via Eric Goldman’s recent recommendation, I decided to give Pandora another shot. The short version: Pandora is an intelligent predictive personalized Internet radio service with an arguably sustainable and protectable business model. And by “intelligent,” I mean there are real human brains at work. As Eric explains:

Pandora’s main competitive differentiator is its “Music Genome Project.” 50 trained musicians with at least a college degree in music (called “music analysts”) listen to songs all day long and rate each song on 400 different musical attributes. See the 2005 WSJ article discussing them. By profiling songs this way, the system can predict that a person who likes an artist’s song might like other songs with similar musical attributes. From listening to Pandora for many, many hours, IMO the system isn’t perfect, but it does a pretty good job, and it has definitely hooked me on music that I wouldn’t have listened to otherwise.

They have apparently cataloged approximately half a million songs and the database continues to grow apace. There is also a collaborative-filtering aspect, similar to Netflix and Amazon. I suspect this hybrid between the “wisdom of crowds” and the “wisdom of experts” will be the future of most large content projects (including wikipedia). My first few hours have returned excellent results. I created a for-working “station” called, lazily, “The Bad Plus Radio” (described as “Avant garde and angular funk/jazz, but not so dissonant that you can’t do mind-taxing work while listening”). You are welcome to listen as well. (See also my Pandora Profile.) The “artist seeds” for the channel include the following:

• The Bad Plus (of course)
• Bill Frisell
• John McLaughlin
• Medeski Martin & Wood
• Thievery Corporation
• Bred Mehldau
• Oliver Nelson
• Ornette Coleman
• Keith Jarrett

Pandora has played several tracks by these artists, but is increasingly mixing in other artists that match up on some axis of preference. I’ve thumbed-up and thumbed-down several tracks from beyond the “seed” set (and will continue to do so), thus driving the predictive engine. I look forward to creating some entirely different channels and publishing the URLs here. Although supposedly the “free” version is ad-supported, I haven’t heard any ads yet. Maybe that is still to come. In any case, it is probably worth the $36/year subscription cost. Beyond the specific content I’m enjoying here, it is nice to see a Web 2.0 (or pick your favorite version) business model that doesn’t require a leap of faith to see how it can work. Of course, they have a Facebook app as well.

Share This

The Reader monad is a simple and easy-to-use structure from the Haskell library that solves a common problem.

Very often, it's the case that you have a lot of functions that all need to use the same values. For instance, you might be laying out some text on a page, and you need to keep the details of the page size around in all your layout algorithms. Typically, you handle this situation by adding a new parameter to all your functions which represents the state. So,


layoutPage :: Text -> Page


becomes


layoutPage :: PageLayoutParams -> Text -> Page


This works just fine, but it can get really ugly. Every single function gets a new parameter, which must be threaded through to every related function that it ever calls. This causes visual clutter, particularly for functions that don't actually use the parameter themselves but just pass it on.

A function written in the Reader monad is augmented with a hidden parameter. For the hypothetical example above, we would write:


import Control.Monad.Reader
type LayoutFunc = Reader PageLayoutParams

layoutPage :: Text -> LayoutFunc Page


Note that the Reader monad is partially applied here. The result, LayoutFunc, is a new monad that adds a parameter of type PageLayoutParams to any code that runs inside it.

So, now that we have this monad, how do we use it? The "ask" operation retrieves the parameter that's hidden in the monad:


ask :: Reader a a


or, specialized to LayoutFunc:


ask :: LayoutFunc PageLayoutParams


In order to remain close to the example in question, I will provide specialized type signatures for the rest of the library functions. You can find the generic type signatures in the Haskell library documentation for Control.Monad.Reader.

Suppose that layoutPage started out like this before it was moved into the monad:


layoutPage st txt =
let width = pageWidth st
...


In the Reader monad, this becomes:


layoutPage txt =
do st - ask
let width = pageWidth st
...


As you can see, we've gone from one line of code to two. As this is clearly unacceptable for a clutter-reducing device, the Reader module provides a convenience function encapsulating the above pattern:


asks :: (PageLayoutParams -> a) -> PageLayoutFunc a


This allows us to simplify the monadic implementation to:


layoutPage txt =
do width - asks pageWidth
...


It's quite common, when multiple functions share context information, to invoke a function in an altered context. For instance, we might have a layoutSubPage routine that changes the page width:


layoutSubPage st newWidth txt =
doLayout (st pageWidth = newWidth txt)


The Reader equivalent of this idiom is the function "local":


local :: (PageLayoutParams -> PageLayoutParams) -> LayoutFunc a -> LayoutFunc a


local executes an operation in a context modified by its first parameter. For instance,


layoutSubPage newWidth txt =
local (\st -> st pageWidth = newWidth ) txt


Finally, to actually invoke a computation in the Reader monad, use runReader:


runReader :: LayoutFunc a -> PageLayoutParams -> a

main = showPage (runReader defaultPageParams someText)


For much more information on the Reader monad, see All About Monads, or the Haskell library documentation.

Last week I helped Samir Chopra and Scott Dexter kick off their book release party in New York City. The book Decoding Liberation: The Promise of Free and Open Source Software is the first academic book length piece on free software proper that among other things examines the repercussions of such elements as language use (free software vs open source) and licensing (such as non-copyleft licensing). Here are my opening remarks, which don’t give justice to the book but give a small taste of what is in there. Samir and Scott are computer scientists, philosophers, and political thinkers and bring these positions and perspectives to bear in their work. While I tend to avoid the discussion on the differences and divergences between free and open source software and licensing (just because I ask a set of questions that tend not to go into that territory), they spend a hefty about of time on this sort of engagement And what is so useful about their approach is that it is technically detailed and carefully analyzed, clarifying the stakes involved in choosing a certain set of licensing over others, or the political implications of language use. Along with this focus, there are many other threads they unpack and one of my favorites is on the aesthetics of code, which I discuss with some detail in my opening remarks with the help of one of my favorite literary writers, Susan Sontag. The conversation that followed was lively, in part because there were a number of people in the audience who are also very familiar with FOSS (Somewhat unbelievably, there were 3 anthropologists there who study free software, myself, Jelena Karanovic, and Anita Chan). And I think one of the most interesting questions was launched by Anita who asked the authors what they meant more precisely by the promise of FOSS as well as liberation. The conversation that followed was too rich to recount here, but something that I raised and I do think is important is the relationship between the buzz word of the last few years, Web 2.0 and FOSS. Web 2.0 is related to FOSS in so far as Web 2.0 refers to a suite of technologies that allow for the creation of user-generated content and collaboration. FOSS refers to a development methodology that is based on promiscuous sharing of code and collaboration. The similarities, however, end there because much of the Web 2.0 infrastructure is proprietary. FOSS by definition is non-proprietary. But I think that soon we are going to see more Web 2.0-like companies open up their infrastructure entirely or at least important components. One example of a new technology that is Web 2.0-like and is entirely free software is a activist networking tool crabgrass that is pretty impressive (I have used it to coordinate my move and am using it now to coordinate a collaborative grant). It is still under development but once released, it will be a great boon to any group that needs to collaborate and organize and coordinate:

Crabgrass also provides a public advocacy centric view of content so that people can learn more about issues and organizations through social relationships. Blog tools, voter guides, petitions, event organizing tools, and action alerts are being added to the functionality of the platform. Crabgrass integrates wikis, asset repositories, task lists, calendars, polls, and meeting schedulers into one tool which allows groups to manage their internal organizing.

The other technology that I am excited about and that I have already written about is Kaltura. As I mentioned, Kaltura is important because it lowers the bar for collaboration, providing tools to facilitate video editing. But what I find as interesting and as significant is that they are perhaps the first large-scale Web 2.0 company that is actively seeking to enter the territory of FOSS and in this respect, once they do so, they will lead the field, not simply for technical reasons, but because they choose to make and engage with open source technologies. Bringing Web 2.0 within the orbit of FOSS and brining FOSS within the orbit of Web 2.0 can only work to bolster each other, and this is where I think, at least part of the promise of FOSS lies.

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.

There are quite a few important events related to Ubuntu -- and to free software communities more generally -- in the Boston area in the next few weeks. I plan to participate in many of them. First, this coming Saturday, October 13, there will be an Ubuntu install party hosted at MIT and organized by the Ubuntu Massachusetts local community team. It promises to be a lot of fun and a great opportunity to have a gaggle of geeks install a free OS on your computer for you. If you've been thinking about installing free software but been hesitant (my guess is that this is not the majority of my readers), this is the event for you. I'll probably be doing RockBox installs as well so backup your music and bring an iPod if you're unfortunate enough to have funded Apple through the purchase of one. Next week on October 18, Ubuntu Massachusetts will be hosting a party at the Globe Bar and Cafe to celebrate the (scheduled) release of the Gutsy Gibbon. I am not thrilled about everything in this release -- like Compiz by default -- but I am happy about the progress of the distribution both technically and in reaching out to an ever-wider and ever-larger group of users. On the week of October 29-November 2, Canonical is hosting the Ubuntu Developer Summit in Cambridge. I'll definitely drop by for a least a day or two to make some strategic interjections and to participate in a few specifications that I care about. The summit is just down the street from my office at the Hotel at MIT so I have little excuse to not show up. I'll also being hanging out with friends from Ubuntu during the week. Finally, as part of the Ubuntu conference, Canonical is sponsoring FOSSCamp. It promises to be a Foocamp/Barcamp style "un-conference" with a focus on free software and open source. I'll be there and, if there's demand, will run sessions on Selectricity and a quick Making Debian/Ubuntu Packages for Sysadmins talk -- basically a more polished version of what I did at the Ubucon in New York. All events are open to the public although people who are not Ubuntu developers may be a little bored at the developer summit. I look forward to seeing both old and new faces around the project in the next month.

I've been meaning to write this for weeks. Hopefully I can still remember everything. So Sarah had a c-section the day before we were scheduled to have our c-section class. We'd both read a bit though, so it wasn't like we were going in totally uninformed and unprepared.. Firstly, Stanford Hospital's operating room area is rather mind-blowing. Sarah was transferred from Lucille Packard Children's Hospital to Stanford because they could get an operating room there sooner. The transfer was trivial, just roll the whole bed down the corridor, through the magic double doors into the operating rooms. The doors in question have a whole heap of video cameras pointing straight down, so they see everyone that gets wheeled in and out, which I found interesting. Good for records of patient movements I guess. Anyway, through those doors is a maze of corridors. There was a light-up board hanging from the ceiling in the middle of the main corridor with lights for all of the ORs. I think there were about 20. The illuminated ones were available. We went down a corridor, and past a few ORs. Outside of each one is a big stainless-steel scrub area. We got to "our" OR, and they transferred Sarah onto the operating table. Because of her heart condition, they wanted to have an arterial line in her for the duration of the procedure. This is some sort of gadget that goes into an artery and monitors your blood pressure beat by beat. The "interesting" thing with the anaesthesiologist was the New Zealand woman that we'd seen when we had an anaesthesiologist months prior, but the appointment was with a different anaesthesiologist, and this New Zealand woman was "observing". At the time, the anaesthesiologist we had the appointment with told us that she was going to be on vacation at the time of the delivery, so she wouldn't be attending. So I don't know if the Kiwi woman got promoted out of "observing" to "doing" in that period, or what, but she reintroduced herself to us in LPCH prior to moving to Stanford as being our anaesthesiologist for the delivery. Anyway, in the OR, they handed her the arterial line, in it's plastic packaging, and the first thing she asked was whether it came with anything else to put it in. At this point I figured she hadn't put one of these in before. (The answer to her question, by the way, was "no") She then proceeded to have a terrible time getting the line into Sarah's arm. Normally intravenous lines go into a vein, but this has to go into an artery. Apparently when you go poking an artery, it spasms. It then becomes very hard to get it into a moving target. She had a few goes on one arm, then gave up, and had to move over to the other arm. Sarah doesn't like needles at the best of times, and getting this honking great big thing in was no picnic. The bruising on both her wrists afterwards was phenomenal. She tends to bruise fairly spectacularly whenever they stick a needle in her. I almost stepped in and asked if it was really necessary that she have it, because they were having so much trouble getting it in, and it was clearly hurting Sarah. I think someone else ended up getting it in, not the anaesthesiologist. Not "that" one anyway. There were heaps of people in the OR. Next, came the epidural. Again, we had the inexperienced anaesthesiologist. This time she said to someone else how she was so nervous because there were "too many eyes". Not really reassuring. They gave Sarah a numbing injection first, and then proceeded to poke her in back with the epidural catheter needle thing. Sarah was flinching when they did it, and they kept yelling at her not to move. Apparently it didn't hurt, but it caused discomfort every time they tried to get it in. Eventually the associate professor of anaesthesiology stepped in and got it in. Later, they said that Sarah had a slightly curved spine or something, and that had made it a bit more complicated. I'm not begrudging the obviously inexperienced anaesthesiologist for anything. Stanford is a teaching hospital, and doctors have to get their experience somehow, but I think that when the patient is conscious, it's important to come across a little more confident. So once they got all of that sorted out, they could get her lying down on the table and get down to business. Apparently one of the side-effects of the epidural is that it can cause your body to think it's got hypothermia. Part way through the procedure, Sarah started shaking uncontrollably. I can't remember whether she complained about feeling cold or not. She also got a really itchy face. Apparently that's a side-effect of morphine. Sarah also doesn't tolerate anaesthetics very well, and started feeling nauseous part way through the procedure. Sure enough, as has happened countless times previously post-operatively, she threw up. At least we had warning and I got a kidney dish in place in time. That was about all the eventful surgical stuff. They had the usual screen up from about her neck area, so I couldn't see what they were doing. After Joshua was delivered, one of the nurses asked me if I wanted to see him, and took me around from her left shoulder where I'd been sitting to around below her right foot, to where they had him in one of those perspex portable crib things. I could see a lot of red out of the corner of my eye, and I could have seen a lot more if I'd bothered to look, but I was more interested in seeing my son at that stage. They let me bring him back around to where I'd been sitting previously, to show Sarah, but it was hard getting him up to a point where she could see him properly, and she was partially out of it by this stage. I think she dozed off for a little bit not long after that. I forget what time we got into the OR, but they started the operation in earnest at about 10:00am, and we were out of there by 10:45am if memory serves. The nurse in charge of the recovery room really didn't want me there, so I went back to LPCH with one of the nurses to spend some time with him while he was weighed and measured, and I took some photos, and held him. This was good, because I got to have a good cry on my own with him. So overall, in my "I'll never be squeezing a watermelon out of my nether regions" blokey perspective, having seen what Sarah went through, and how much discomfort that it looked like she was going through, both in the OR and afterwards, I'm not convinced c-sections are any less painful than a vaginal birth (taking the average case of both). I think you're trading some "short term" (depends on how long your labour is I guess) pain for some "long term" pain while you recover from your incision. Granted, Sarah wasn't really laid up all that badly for all that long, but it still didn't look all that pleasant. I guess really only the women who have done both delivery methods can really comment. All I know is I found it very difficult watching Sarah go through so much pain. So much so that I'm not really looking forward to that again. Maybe, hopefully, after her aorta is repaired, they'll let her delivery vaginally next time. I'm not holding much hope though. The high-risk obstetricians are fairly paranoid. There's also the possibility the baby will make the decision very easy for everyone by being breech. Sarah raised an interesting point today. Why didn't they just knock her out with a general anaesthetic? There was no need for her to be conscious for the delivery. That would have spared her the pain and suffering of getting the arterial line in, and they wouldn't have needed to bother with an epidural. One for her to ask the obstetrician at her follow-up appointment.

To follow up on yesterday’s MBTA philippic, I received a response from the T’s customer service regarding my complaints. Although it doesn’t give me hope that things will improve, it’s nice that they have at least hired someone to write personalized, polished replies. At least they can do that right:

Dear Mr. Kessel, Thank you for your email concerning service on the Needham Line. The past couple of months have been difficult for our passengers, and I want you to know we are very sorry for the inconveniences this has been causing. The causes of these delays have ranged from signal and mechanical issues to long stops boarding passengers at stations, and even track work on other lines. I know that it may seem odd that trains on other lines can impact your trains, but I assure you that is true. The Franklin, Needham, Providence, and Stoughton lines, as well as Amtrak all share the rail between Hyde Park and Boston. All it takes is one delayed train in this area to cause a cascading effect that delays other lines. There’s also the fact that trains may come in from one line to go out as another. For example, a train on the Worcester Line comes to Boston, and either the train set, or the crew (sometimes both) head out as an outbound Needham train. If the inbound is late from Worcester, then the outbound Needham will be late, which also means that its “turn,” the next inbound, will be delayed. In response to your comment about the doors not all being opened, even with a full compliment of conductors, crews are not able to staff every door, and especially at ground level stations we want to ensure that all customers are able to board and detrain safely. This is why conductors do not open all doors to the train. I contacted our Mechanical Department, asking that the PA system on train 625 be checked out to make sure everything is working properly. Please know that delays in service are not something that we take lightly, and all departments are committed to working together to ensure that our customers receive timely, safe, and reliable service. Once again, I am sorry for the inconvenience this has caused you. Thank you for writing. Sincerely, Linda Dillon
MBCR Customer Service Manager

Share This

This is a pretty good take on Tim Bray vs Erlang. However, I'd like to focus on something said at the end:

The fact is, all languages optimize for particular problem domains and I don't think that a universal programming language exists that would perform well on all tasks. Bray rapidly found out that Erlang isn't optimized for doing line-oriented I/O and it's regex library sucks. So what? While those problems could be eliminated from Erlang, the fact that Ericsson has deployed large telecom gear without having to fix those issues means that Erlang is ideally suited to its original programming domain.

The problem is that learning new languages is difficult for many people. They're not going to bother starting from 0 with a new language if what they've got is only 10/20% worse than the other guys. For companies, developing expertise (and trying to maintain it) in lots of languages is probably less productive than picking a few (Google only has four: Java, Python, Javascript and C++, and they're not exactly lacking in brainpower or cash). This is why "the right tool for the right job" works for things like saws and hammers, but not for complicated, idiomatic things like programming languages. Therefore, it's important that languages that aim to be widely used do lots of things pretty well, and try to avoid doing anything really badly. This is something I've always admired about Python, even if I don't use it anymore. It's a language that you can do a very wide variety of tasks with, and you can be sure there's probably some code out there already, and that Python will be ok for your task, even if it's not the best thing. Performance is a weak point compared to compiled languages, but even there, get the libraries right and things aren't *so* bad. In any case, my point isn't to bash Erlang (which I like), or put Python on a pillar (I prefer Ruby and Tcl), but to say that a widely used programming language doesn't need to be the best at everything, but it should aim to make people comfortable using it, safe in the knowledge that they can probably do most things *ok* if needs be. That's a far better situation than being able to do one thing realy well, and perform poorly at many other tasks, forcing its users to look elsewhere for solutions to those tasks. Personally, I think that for concurrency, Erlang is in a bit of a race right now - they're pretty far ahead in terms of concurrency (and also fault tolerance, but fewer people care about that), but behind in other areas (less library code). Other languages don't have as good a tools for concurrency, which isn't an easy problem. So, what will happen first - Erlang catches up elsewhere, other languages get "good enough" concurrency solutions, or a new language (like Scala) comes along and takes the lead?

After 6 weeks of teaching and over 2 months in my new apartment, I am making a short escape from NYC to visit my mom and sister in PR. In my Impacts of Technology class, we just finished a week on large-scale and complex technological systems, with a focus on industrial farming. We read a few sections of Micahel Pollan’s fanstastic book, The Ominvore’s Dilemma, which combines the odd qualities of being seductively alluring (thanks to his exquisite writing) and repulsive (thanks to the content, well at least the part on factory animal “farming”). I can’t recommend it enough and look forward to reading the rest, when I find the (magical) time to do so. Now that I am at the airport, I am struck at how little I know about this place, which is also a large and complex technological system and I bet revealing its technological and cultural innards would provide as fascinating (although not quite as gross) of a story as that of factory animal farming. There are many questions I would love answered: How exactly is coordination secured and what are the toughest elements to airport coordination? Where are the lines of cooperation and those of competition between airlines? What factors and values go into the design of the airport? (I know that for one thing, in American airports, there rarely seems to be enough electrical jacks; I am now sitting under the telephones, the only place with jacks in terminal 8 at JFK, and the funny thing is that there are a row of 7 unused phones and only one jack and I am sure it would be more useful to have 1 pay phone and a row of 7 jacks, instead). What sorts of airport technologies have put people out of jobs? What technologies have created new job opportunities? What sorts of social hierarchies are there in airports? Like who runs the big show? Is it a CEO? Or is something more like a university provost? What is standardized by the FAA, and what elements are more flexible, and thus different airport to airport? Is there a sense of camaraderie among airport employees, or are loyalties built primarily among employees of one airline or among the classes of workers? Given that unions are quite strong among airport employees and from the top (pilots) down (food workers), what is the political culture of airports/employees like? (I remember once overhearing a group of machinist and ground crew talking about the ugly face of globalization and NAFTA over coffee and I was dumbfounded and pretty psyched too). Are airports one of the few last remaining places in th US that provides for decent job security? Why do so many of the ground crew have such athletic, bulging calves? Is it a result of the physical demands of the job? Or is it that the type of job ( outdoors with lots of heavy lifting), attract the athletic types? Do they have to pass certain physical standards as to pilots? Was there always first class seats? Or did that come about when flying became cheaper? Are employees trained to deal with irate passengers? In what ways do pilots bitch about the long waits/delays they also have to endure? What can they do when they are waiting, as we did for an hour last night, during the massive traffic jams that are especially noxious in NYC-area airports? Do pilots have any say in the way airports are run? Why do they consistently provide less chairs than are needed in lounges, even in new terminals, as the one I was in tonight? Do air traffic controllers ever meet face-to-face with pilots or do they largely have a virtual relationship? Are programmers who patch, improve, and build traffic control systems housed in the airports, or elsewhere? Airports are not only fascinating for technological and sociological reasons but I reckon there is a lot of interesting psychological work that must happen in airports. I imagine that during those long, endless waits in the lounge, on the security lines, on the tarmac, people must often take the time to reflect, on where am I going, where am I coming from, and not in the literal sense but the metaphorical one. I know that I have spent many hours in airports letting my mind wander to places and thoughts in ways that don’t happen as easily or often elsewhere. And in many instances, I don’t think that this propensity to indulge in some reflective thinking, is a matter of time, that is waiting. For me at least, it is the fact that many times when I fly, I am moving between worlds. While I have flown hundreds of times, I never have been shed of the sense of awe I feel about planes and their ability to shrink space and time so quickly. For me, it is less the act of flying itself (that feels boring, tiring, annoying, mostly because of the insane waits and delays and I never seem to get the right amount of sleep the night before) but the visceral contrast it brings. In the morning my life is of a particular tone and rhythm, currently situated in NYC and by evening, I am back at home in PR, surrounded by thick humidity and the loud sound of coquis. Once there, my as currently configured in NYC, has little direct bearing to those around me. Planes don’t just transport, they shift and convert your inner and outer world… So, if anyone (who got this far) knows of a good social history of the airport, do tell. I would love to read it.

I got a call from one of the researchers from ABC news this evening. Apparently they are planning on doing a segment on Hans Reiser on their 20/20 show, and the researcher knew enough that there were some serious technical inaccuracies with the script (at the level of “so when Hans was creating reiser4, was that software; was he writing a program?” and “does the program run on the hard drive?”), and so they were looking for help on some technical issues on a background basis. She didn’t take any quotes from me; what she needed was help understanding the technical issues around filesystems and Linux. I tried to help explain what a filesystem was that would make sense to a lay person in 15 seconds; I have no idea whether the researcher got it, and whether she’ll be able to make changes in the script that will be vaguely coherent. We’ll see. I spent a lot of time working with Joshua Davis, providing background material for his Wired article, and he still got a bunch of the technical details wrong. The 20/20 researcher did ask me some silly questions such as “whether we were surprised when murder charges were filed against Hans?” Well, yes. What did she expect me to say? “Oh, yes, were always worried someone would get hurt…” Not! Sigh…. I might not agree with Hans’s filesystem design principles or his tactics in trying to get reiser4 accepted, but I always respected him as a fellow open source programmer. The researcher mentioned to me that Hans had done a talk at Google that was available at the Google Video site. Out of curiosity, I took a look at it. It was interesting; the last time I had seen Hans was in 1999, at the Linux Storage Management Workshop in Darmstadt, Germany that was organized by Matthew O’Keefe at Sistina Software. Compared to how he looked back then, and the picture of him in the Wired article, taken a 10-12 months after his talk at Google in February, 2006, I was struck by how much heavier (and older at least compared to my memory of him, which was much closer to this picture from his resume) in the Google Video. I also remember him as being a much more dynamic and energetic speaker, and I was struck by how slowly he spoke, with lots of long pauses and “umms” and “ahhs”. He seemed to be a much better public speaker in Darmstadt, but in the Google talk he seemed very tired as he gave the talk. One of the questions that the researcher asked me was whether I thought he was a genius or not. I told her that I thought he was quite bright in terms of raw intelligence, but that his Social IQ wasn’t as high as you might want for someone to be successful in gathering volunteers to work on an Open Source project, and in working with others in an Open Source development community. Looking at the video, I think that is very much true. He was a terrible public speaker, but some of the points he made about optimizing B-tree algorithms made sense. I might disagree with his philosophy over filesystem design and benchmarking, and I might not be terribly impressed by his social skills, but in terms of being a talented computer scientist, he was and is that. Is he guilty of the crime that he has been accused of? I have no idea. But from looking at his talk and knowing what I know of him, I have the sense of a greek tragedy. He’s been working on some of his ideas since his undergraduate days in UC Berkely in the early eighties — which he entered after finishing his 8th grade. And as research ideas, I think he might have gotten some very interesting results out of trying some of the things that he wants to do around operating system namespaces. (I think they are doomed in a production system descended from Unix, since application programmers are unlikely to rewrite their programs to take advantage of reiserfs’s performance characteristics — which would mean instead of using a Unix-like configuration file, treating a directory hierarchy containing the configuration information like a Windows registry. Still, as an academic, Plan 9-like system, I could have seen it has being a potentially very interesting Systems Research effort.) Unfortunately, his skills at public speaking and his ability to work with other people have handicapped him, and I know that has frustrated him deeply. So I have a lot of sympathy for him, and I hope that he is innocent, and will be found innocent. But only time will tell…. Anyway, according to the researcher, they are currently scheduling their segment about Hans on 20/20 on October 19th. I’m sure that schedule is subject to change, but it’ll be interesting to see how they treat Hans in their coverage. Hopefully it will be fair, and not overly sensationalistic, but unfortunately my faith in today’s TV edutainment-focused news program isn’t terribly high. My impression was that the research wanted to do a good job, but she was burdened by a very tight deadline, and in the end, the decision of what goes on the air and what doesn’t won’t be up to her. So we’ll see.

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.

I'm constantly amazed how much useful information about Debian is published daily (on web sites, blogs and mailing lists.) I'm also amazed about how much time I spend searching web pages I've seen in the past but haven't bookmarked. So bookmarks.debian.net is an attempt to improve this situation, and having all the links organised in a way so that I actually find what I'm searching for. There are only 14 links right now, and of course lots of standard “places to start” links missing (like pages from debian.org), but I'll add stuff as I use the pages and as submissions come in. I'll think about suggestions on how to organise the categories, but all in all, it's my bookmark collection, not yours, so the final decision is mine. Oh, and: please be patient if I'm not adding your submission immediately. (Btw, the number one piece of information I never remember is the name of that script to sort a list of packages by maintainer. I know it's on lists.d.o somewhere... :-)

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

To add the files, copy in your usual .bzrignore file and just add everything:

$ cp ~/bzrignore .bzrignore
$ bzr add
added foo.c
added bar.c

Check the output for mistakenly added files, adjust .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

A copy of a Bazaar branch is a different branch, you can commit to it separately. There’s a 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

As is merging (when your branches have diverged):

$ bzr merge ../myproject

One particularly nice feature is that after a merge, you see the merge as a single commit and it can be treated as such; but it also has the set of merged commits indented under it–you can examine these as individual commits as well! What’s the downside of Bazaar? Well, it’s not the fastest system (but by no means the slowest), for small to medium sized projects this is never an issue but may be for extremely large projects–fortunately the developers are improving its performance all the time! But that doesn’t matter; it is, honestly, the first revision control system that I don’t hate.

Hello World, a tape streamer of one of our customers died two days ago and we haven’t anymore warranty on this device, a new infrastructure will be realized soon anyway. So, we needed a cheap temporary solution. We bought a WD network harddisk for home use and “remote access over the internet”, even if we only need local access to it. It’s a 500 GB harddisk and you find several short GPL references in the crappy 5-pages-manual. Ok, this sounded already interesting. I read the manual and see that only Windows 2000 and Windows XP are supported and that you have to install a very proprietary Windows tool to start using the harddisk. Later there would also be a webinterface available, after the initialization. Ok, so I wanted to know if it’s possible to access the drive also with other operating systems. I connected the RJ45 port of the harddisk with my ethernet card with a cross-over cable and started to sniff with ngrep on the interface. After waiting a while I got this message some strange from a APIPA address to a Multicast address. Ok, assigned my local interface an address in the APIPA range and connected with my browser to it: T 169.254.71.58:80 -> 169.254.71.57:56819 [A]
HTTP/1.1 200 OK.
Transfer-Encoding: chunked.
Date: Thu, 30 Nov 2006 23:12:51 GMT.
0: no-cache.
Content-Type: text/html; charset=UTF-8.
Server: lighttpd/1.4.3.
Very interesting… lighttpd The device asks for a password, I went to the website of WD to read the “full manual” (as the CDROM isn’t readable with Linux as it seems), in the support part I found something about “admin” and “123456″. With this information I could login on the device and saw that it does nothing else than Samba (3.0.14) and it’s also accessible via smbclient. Without the proprietary tool, without sending personal information to Westerndigital and getting stupid newsletters. Maybe I will remove the harddisk from the case later and install it on my workstation (it isn’t reachable except port 80 and the netbios stuff) to see what exactly is on it. At least I know that it’s an ext3 filesystem. I think vendors who use embedded Linux systems for their devices and use such proprietary clients, give not more information about it are just crap. It’s something like unfair for the free-software community. (even if it works unofficially with an uncommon way) [Update] A little codesnippet from the Webinterface… very useful function moveArrow(ycord) // vert cord of layer

// ignore this function
//
// if(document.layers). //NN4+
//
// document.layers[”MenuArrow”].moveToAbsolute(xcord,ycord);
//
// else if(document.getElementById). //gecko(NN6) + IE 5+
//
// var obj = document.getElementById(”MenuArrow”);
//
obj.style.top = ycord;
//
// else if(document.all).// IE 4
//
// document.all[”MenuArrow”].style.top = ycord;
//

[Gnaaaaa, sorry Planet Debian for sending a german article to you a few hours ago. I just chose the wrong category for the article. I removed the tag already and the article disappeared from Planet Debian right now; so if you don’t know what I’m talking about just don’t care. To the german readers: it’s just the same article as my previous one, but this time in english. :-)] grml-live is a framework which lets you build a grml/Debian based Linux Live-CD with one single command. grml-live is based on FAI (Fully Automatic Installation) and uses its class based concept: In this example I built a full grml-ISO. All I did was setting the Debian-Mirror in /etc/grml/grml-live.conf to my local one (to save traffic and time) and invoking the following command:

# grml-live -t /grml/grml-live -c GRMLBASE,GRML_FULL,LATEX_CLEANUP,I386 -s sid

About 50 minutes later I have a grml-ISO inside grml_isos at directory /grml/grml-live/ (-t …). It was built using the classes (-c …) GRMLBASE (all the core, essential stuff), GRML_FULL (software selection like official grml provides), LATEX_CLEANUP (clean up some very big LaTeX directories) and I386 (x86-specific packages like kernel). Debian unstable/sid was used as the suite (-s). And that’s it. You want a smaller grml-version using Debian/stable? No problem, let’s do it in shared memory (being very fast, and with enough RAM and mountoptions rw,suid,dev no problem at all): A ‘grml-live -t /dev/shm -c GRMLBASE,I386 -s etch’ and not even 5(!) minutes later I’ve my 135MB small grml: So using grml-live you can build your own, customized Linux Live-CD without having to deal with remastering in detail. Via creating a new class (or just editing an existing one) its easy to include the software you would like to get. So, will the official grml-ISOs become obsolet? No, definitely not. The goal of grml-live is to give the grml-team a buildsystem providing exactly what we need. It should give us the possibility to concentrate on the important and interesting tasks, like: testing, bugfixing, implementing new features, working on the kernel, quality assurance, documentation,… grml-live should work on every Debian based system. If you want to give it a try just grab the Debian package from grml’s repository. The source is available (as usual) via mercurial. Find more details on the grml-live-webpage. If you have any further questions that aren’t answered by the docs yet, have feature requests, bugreports or patches: please let me know.

So, I have just installed RockBox on my iPod and I have liberated it It’s nice to see people amazed on an iPod running something that’s different from the usual firmware. Now, both my iPod and PowerBook are not running Apple software, muahaha!

---

Since we are in NYC now, and even before, we’ve been looking for interesting activities in the area. Tomorrow, the New York City Perl Mongers will handle their monthly meeting. At 6:30 PM at d.b.a, 41 First Avenue (between 2nd and 3rd Streets), map: http://tinyurl.com/2yqg4d. Tomorrow, we were supposed to go see a prospective apartment in Bushwick, Brooklyn in the afternoon; I’ll see if we can still make it. Otherwise, if you are in the area, feel free to attend!

---

Yesterday, we went to the Yankee Stadium. Actually we only went outside it, since we didn’t carry any tickets, we just wanted to see the neighborhood. It was amazing, since there was a game and we witnessed thounds of people commuting to it to watch the game. It was a nice experience only watching the people and all the buzz around the stadium. After that, we got back to Manhattan on the subway and dropped off on the 57th and Madison Ave: From there, we walked around sixty freaking blocks to get to our apartment near Essex & Delancey St. After checking on Google maps, it was a ~6 kms walk! It only took us 2:30 hrs. Heh. On the good side, we happened to see lots of nice places of Lexington and other avenues.Tonight, we’ll be walking to Little Italy and Chinatown, although we already know those neighborhoods, since Alex took us there when were here last June.

---

So, we are uploading our pics to the NYC photo set of our flickr account, raquelydavid.

This week my son Nilagriva started preschool so on Sunday we had his
vidyarambha. As an added bonus it was Rishi Panchami. As you can see from the picture, he has written four mantras in Sanskrit, the
letter &#0a85; in Gujarati, and his name in English hence the dazed look on his
face—a common Vyas reaction to formal education.

As uclibc's removal from Debian has been requested already, it is really time to push forward with this package. The technical bits of the package haven't changed in ages, and could be said to be pretty solid (I use the package daily). The problem with this package in the Debian context is that the licencing is somewhat less than clear, as no one really cared about adding their name to the list of copyright holders. I can see a few different variants how to deal with this: Number one would be the "massive audit" approach. This is the first thing I'm going to try, simply hang out on IRC for a few days and try to find people who join me (on freenode's #uclibc, mostly). If that doesn't work out, there will be lobotomized uploads, where I start a "new" package and subsequently move the functionality back in, in whatever tempo I can manage, until I get back to "pristine upstream source".