I’m looking forward to a challenging and exciting 3 years ahead!

It also features a standardised fundamentals ("kernel") package and applies Lorien’s persistent evolvable meta-architecture approach down to the dynamic interrupt table and system entry point, providing an even more uniformly applied system model.

With node-level technology now having reached a good level of maturity we’ll be starting to build higher-level services for simple evolvable networks and component management soon…

Some thoughts of an OS developer on MAC protocols for WSNs. The basic tradeoff of a MAC protocol is energy versus latency & throughput, where channel contention plays a major part in how a MAC protocol behaves. In Lorien you can cheaply switch the MAC protocol currently in use at any time, allowing the tradeoff to be changed as requirements and conditions change.

So what I’d like to see for MAC protocols is a standard, simple evaluation framework that allows results to be easily repeated and compared with reasonable precision. Here’s a shot at defining one - perhaps not perfect, but intended to be repeatable in any lab in the world. A couple of papers I’ve seen (e.g. [1], [2]) come sort of close to this but stop short of a clearly repeatable definition and high-level figures.

So I gave a demo at SenSys last week based around Lorien’s core paradigm of building to evolve.

I thought I’d write down why I think this is a good way to build systems software – and therefore as a foundation of all software. Unlike many of its contemporaries Lorien’s fundamental system building model is not an abstraction model, or a processing model, or resource management model; rather it is a fundamental model of software itself. The Lorien operating system is founded on a general model of software structure, composition and evolution uniformly applied to all of software. We find that with this model we can build all of the others, but with none of the others can we build Lorien, suggesting that it represents a more general system building model with which we should arguably construct all systems software. What’s interesting is that Lorien can do this construction of arbitrary functionality completely online, able to seemlessly change every aspect of itself to become whatever kinds of software (and abstractions) you currently need. This is a brief introduction to the development of Lorien: an OS built to evolve.

First, a quick history lesson. The history of operating systems can be summarised as building to abstract. A system designer creates what they think is a nice abstraction layer (or API) atop which all other functionality can be developed - all of the functions that other software might need to call on are encoded in this API. This is a bit like the famous Win32 API, or the POSIX model; above this API sits the software of applications and services which will (more or less) work on many different kinds of computer that host this same API. The collection of software currently running above this API is anticipated to change over time so that when the user wants to do some word processing they can launch their favourite corresponding application and start typing. When they’ve finished with their word processing task they might close that application (and I’ll come back shortly to why they tend to close it).