Aircastle Project

[Blurb]

This page aims to describe some of the ideas of Martin Mares regarding a future of operating systems. The Only Right Description would probably be an exact transcription of mj's lectures, but none is available (yet? ;-). Thus, this is unevitably partially my personal interpretation, nevertheless you should still get the basic idea.

[About]

In the crowd of the current operating systems, there is an empty space - operating system which would be fully object oriented AND network oriented. Right, this project aims to fill this gap. Now, what we mean by the goals mentioned above?

• Everything is an object - this allows especially encapsulation (the other object properties will be of course useful as well), which can be used to transparently move objects around the network and allow people to access them regardlessly to their actual location. File is an object, process is an object and so on.
• Objects are distributed - most objects can be moved around between various machines which participate on the same network. This way, when machine running a precious process needs to be shutdowned, the object of the process is suspended, moved to another machine and resumed. This can apply to the files as well, while obviously in no way requiring them to move if it's impossible or unreasonable. This also doesn't prevent intelligent clustering of related objects (processes and files being used by them), but it rather encourages it.
• The network is P2P - technically, there is no fixed hiearchy in the network, each member participates fully. It can ask others to host its objects, and others may ask it to host their objects. Obviously, some intelligence should be implemented, which would choose reasonable location for the object. The machine power and resources should be a factor there as well, thus there will be probably some natural hiearchization in fact.
• Binary files are architecture independent - in order to have the previous points fulfilled effectively, the objects should just run on any suitable machine in the network. Also, they shouldn't use any special bytecode, nor they should be interpreted, but they should be even optimalized for the given architecture. The most effective way to do that is to have sources as a primary distribution mean of the executables. Any executable is primarily a source archive (eg. tarball), optionally accompanied with a cached compiled binary; such a binary could be deleted upon disk space shortage. Also, the binary contains a footprint of the relevant hardware configuration it was built for, and when the configuration doesn't match, it should be rebuilt before being executed.

This provides very flexible, versatile and elegant design especially for distributed applications, file sharing, but even for regular work. The points above imply many other things, like highly modular kernel (everything is an object; ie. you can implement /dev/null in userspace by simply creating a file object behaving like /dev/null) and perfectly and transparently optimalized applications. Also it is feasible for running long-term processes which need to be coordinated, fault-proof and backupped. The Inter-Process Communication can be fully transparent, regardless where the other process is located - the communication method (traditional IPC, UN*X sockets, internet sockets, pigeons, ...) is internal choice transparent (ideally) to the user.

[Specifications]

There's no specification done yet, except the basic principles of operation mentioned above. We expect the specification to be designed and written during development of the reference implementation.

Just to give you an example how the object hiearchy would look like:

[Object]
  | (defines basic properties - code, data and hooks abstraction, permissions)
  |
  +-- [File]
  |     | (defines read/write/seek)
  |     |
  |     +-- [DataFile]
  |     |     | (common code to provide read/write/seek upon data property)
  :     :     |
  :     :     `-- [TextFile]
  .     .           | (defines line-oriented interface)
  .     .           `----------------------------------

[Implementations]

There's no implementation done yet. We expect the first version of the reference implementation to be realized as a set of UN*X daemons providing the neccessary API for the Aircastle objects. That won't be too fast, but we believe that it will demonstrate well the flexibility and merits of the design.

[Contact]

This page has been originally written by Petr Baudis (pasky@ucw.cz), based on the ideas of Martin Mares (mj@ucw.cz). If you will find concepts of this project interesting or if you will have any questions, feel free to contact us. If, by some wicked misfortune, this project will become more popular, we may even set up a mailing list. Especially when there will be some move for writing of specifications and practical implementations ;-).