Hobby OS projects (by alaric)
On top of HELIUM, things start to get interesting. See, ARGON is a network-savvy operating system. In fact, it's designed to operate as a cluster, with a standalone machine being handled as a degenerate cluster of only one node.
This has three main advantages.
The first is scalability. An ARGON system can be grown by adding more machines. Very few, and possibly no (I'm still working on the details), parts of the system don't scale up fairly linearly as more machines are added... depending on the workload and so on (not all tasks are parallelisable, although many very interesting and profitable ones are... such as providing network services to a large number of clients).
The second is reliability. By replicating persistent state (files and stuff) across multiple nodes in the cluster, the failure of a node can be tolerated by just continuing with the state stored on other nodes.
The third is managability. Anyone who's had to look after an installation of several servers, or a room full of desktops, will appreciate the value of having them all be one logical system - where software installations and configuration changes are done to the cluster as a unified whole, and the individual machines only having attention paid to them if their hardware needs tinkering with, or for special nonuniform setups like splitting the cluster into Internet-connected nodes for providing public services and firewall-protected internal nodes which are trusted with important data.
In order to make this work seamlessly without placing an undue burden on application designers, clustering has to be implemented at a low level within the OS. For a start, it strongly affects the data model of persistent storage; traditional file access just won't cut it. You need transactions and locking to manage the concurrent access to distributed and replicated data, and orthogonal atomic operations on objects to allow for efficient operation. Also, systems for routing work to nodes with the appropriate resources to do that work are required.
Another concern at this level is security. TCSEC class B and above requires Mandatory access control, which is traditionally only really used in military systems. However, with computer crime being a major cost to businesses and individuals, I think it should be ubiquitous. Therefore, as well as supporting clustering, at this level ARGON also provides labelled security.
All of this is implemented by TUNGSTEN, the distributed storage manager, WOLFRAM, the cluster internal management protocol, and MERCURY, the application-leverl communications protocol used to request services from clusters (either within a cluster, or between clusters). WOLFRAM and MERCURY share IRIDIUM, a transport-layer protocol, and TUNGSTEN uses WOLFRAM to manage distributed replicated state, using IRON as the fundamental data model and representation (it's like XML, XDR, or ASN.1).
At this level, also, the state of a cluster is partitioned into application-level things called entities. Each entity contains its own TUNGSTEN state, isolated from the state of all other entities. The TUNGSTEN state of an entity includes data and code, perhaps written in the CHROME programming language (which is compiled to HYDROGEN virtual machine code, naturally) - or perhaps in some other language that can be compiled to HYDROGEN, and thus run portable. When a request to do some work comes in via MERCURY, it is always targetted at a particular entity; the requisite code is fetched from the TUNGSTEN state of the entity, and runs with read/write access to that state.
Sun 16th Jul 2006 12:15 am 
Subscribe
By James, Thu 18th Dec 2008 @ 11:13 am
So whens the release? 😛 Wouldn't mind testing this thing with a couple of old forth apps I got kicking around on my drive. -Jim