Thursday, July 26, 2007

Temporal and Bitemporal in One Sentence

Temporal database support allow efficiently answering questions like "What was the state of this entry on Monday?", and bitemporal database support, questions like "What was the state of his entry on Monday, if I had asked on Tuesday?"

Tuesday, June 19, 2007

Distributed Revision Control Yields Centralized Advantages

The new distributed revision control systems (DRCS) have some important advantages for traditional use, apart from the ability to commit without an internet connection.

DRCS make code review much easier. Instead of using an entirely different system for managing the code review process, developers can check all of their un-reviewed changes into a branch, and merge changes as they get reviewed.

DRCS can support graduated continuous integration. In sufficiently large projects, continuous integration can cause frequent build breakage. Instead of having a single, volatile HEAD, subprojects can have their own independent integration branches, which they merge to the superproject integration branch at longer intervals.

DRCS support "lines of development", or working on multiple independent features. With traditional RCS, once a feature is committed it becomes part of the blob, and may not easily be dealt with as a separate identity.

The original motivation for DRCS was empowering decoupled open source contributors, so it's mildly ironic that this functionality should be so valuable for BigCo development as well.

Wednesday, May 30, 2007

Libertarian OS

What would an operating system look like if it were designed to maximize freedom of development? Could we support a web of code to match the existing web of documents?

It'd need:
  • A security framework
  • A dependency framework
  • No extra baggage
For security, programs would be extremely limited by default. They'd have no network, filesystem, or driver access. In order to do anything, they'd use APIs to
  • request reading or writing an existing file, selected by the user
  • request writing a new file
  • suggest a url to visit (optionally with post data).
This restricted behavior could safely allow running programs from even the least trusted sources. It's in the spirit of the "One laptop per child" project's revolutionary security model Bitfrost.

For dependencies, programs should specify urls (possibly self-certifying) of code that they depend on. All code could be cached locally or downloaded anew as desired. This is in the spirit of package management approaches without "side effects", like Nix and Zero Install.

Once there's a sufficiently powerful dependency framework, we need not hard code any dependency on "standard software" like programming languages or gui toolkits. Programs could be transported in llvm bytecode.

Implicitly trusted programs could be subject to phishing attacks just as websites currently are, so it would be desirable to have some sort of petnames scheme, as well as a spoof-resistant UI for distinguishing programs.