Configuring Gitweb for Apache on Debian

[git.ithinksw.org](http://git.ithinksw.org/) is a pretty nifty site: in addition to providing Gitweb when you access it via a web browser, it also allows cloning of repositories in the same namespace. So, for example, you can visit [http://git.ithinksw.org/ITFoundation.git](http://git.ithinksw.org/ITFoundation.git), and receive a Gitweb-generated interface to the repository, but you can also run `git clone http://git.ithinksw.org/ITFoundation.git` to clone the repository. [tycho](http://tychoish.com/) is also a fan of Git, and was interested in setting a similar site up for his own repositories, so I've decided to share my configuration here.

iThink Software goes open source

Beginning in January, I'd been working to move much of the code we wrote at [iThink Software](http://ithinksw.com/) to open source. I'm happy to say that I am now satisfied with the result: [a redmine installation](http://ithinksw.org/), and [git repositories](http://git.ithinksw.org/).

Haven Fundamentals Part Two

Haven consists of a daemon (referred to as havend) and a library for communicating with that daemon (referred to as libhaven). Individual computers will run a single instance of havend, and any other software (referred to as client software) running on those computers which requires access to the database utilizes the libhaven library to communicate with the local instance of havend.

Haven Fundamentals Part One

At the lowest level, Haven utilizes a document-oriented, schema-less database. I'll use the term "object" where other systems would use "document", to avoid connotations of "document" that are not appropriate at such a low level. Objects have a UUID to define their identity, and an arbitrary number of key/value pairs as content. Key names are informally standardized using reverse-DNS semantics. All objects, once assigned a UUID, are immutable. The immutability of objects referenced by a given UUID allows for the Haven database to be distributed over many, perhaps distant, computers. Ideally, there is only one Haven database (or, object namespace) for all eternity.

Prelude to Haven

I often find myself thinking about how the next great computing environment should function. Although computer hardware has advanced considerably over time, the user-oriented software that allows us access to that hardware's potential has been stuck. We're constantly rehashing the same tired metaphors that were developed decades ago: keyboards, mice, windows, icons, files, applications, clients, servers, users, passwords, and so on. A little more than a year ago, I started thinking about how the computers of the future should store and access data. After much refactoring of my ideas and their consequences, I have settled on a system that I call Haven, which I will be describing in this and later posts. This first post will talk about the sorts of problems that I have attempted to solve.