Some work on OSes has provided more unique results. This stuff is really not ready for users, as it takes quite a bit of thought to get your mind around the consequences of the design concepts.
The big concept that I keep seeing these days is that of making OSes "object oriented," and then having data persistence, which potentially eliminates the need for "files" and "file systems." (The other aspect is that people keep thinking that they need to reimplement Linux in C++ "to make it object-oriented." Unfortunately, G++ is not nearly as robust as GCC, and not much value would be provided by the exercise overall.)
While the notion of not needing to load things is pretty neat, I am not convinced that file systems are truly dinosaurs that ought to be discarded.
My thesis in favor of file systems is that in order to organize the sets of objects in a coherent fashion so that they are manageable, it is necessary to have some sort of universal "object hierarchy," and have a "universal" set of tools that can manipulate those objects.
A file system is a very powerful sort of hierarchy (a rooted tree) that should be able to represent anything that can be put into a hierarchy. Plan 9 is the seminal system that tries to represent "everything" as a hierarchy looking like a file system. This is discussed in the paper The Use of Name Spaces in Plan 9. Hurd extends this by proposing attaching DBMS-like "views" to file hierarchies. This can be called a "Virtual File System," or "VFS."
Similarly, a file can be treated as either the source or destination of a stream of data. The Unix Philosophy urges the use of this abstraction; this is a useful abstraction that is different from the "object oriented" notion of grouping objects.
It seems to me that an object system that can't be rendered in a VFS fashion is likely a spaghetti of not-particularly organized material whose representation is problematic at best. I have observed this in action; SAP's R/3 software stores all programs in a database in the form of a single enormous table. Unfortunately, you lose all form of hierarchy in the process. There are a variety of other tables that do crossreferencing between related components, but one loses the advantage of having the single powerful representation.
Traditional FORTH systems also suffer somewhat from this problem; they store both programs and data in the form of "BLOCKS," which typically are 1024 byte blocks of disk space. A neat aspect of this is that it is trivial to create virtual memory systems on top of this; with a decent sized BLOCK cache, "disk" accesses become extremely fast. Unfortunately, quite a lot of effort has to be expended on the part of anyone that touches the system in order to do "block management," creating manually whatever hierarchy might be wanted.
There are some SNMP tools that allow you to look at network configuration as if it were a VFS. You can head to "subdirectories" that represent the hierarchy of network 'features.' This is a very nice example of the the "wonders" of "everything as a file hierarchy."
It would be nice if RDBMSes such as Oracle and Sybase had a "file system" representation that represented system configuration including tuning parameters in the form of a VFS. Note that some people that are working with PostgreSQL are working on much this sort of thing via what they are calling Storage. It is not clear whether they intend to merely provide read-only access, or if they will provide the ability to create records, tables, and such by creating "files" on the filesystem. Ensuring consistency when creating a complex database object would be quite a challenge.
The docfs Unified Documentation Storage and Retrieval for Linux Systems proposes to use a VFS to manage system documentation; documentation would be created using SGML and placed in an appropriate directory; file requests to /usr/man result in a daemon creating manual pages from the SGML sources. (Probably with assorted caching to keep the system quick...)
Another approach that various projects have been considering is to store files in a fairly static fashion (sometimes with cryptic, made-up names so that users are not tempted to fiddle with them in that file structure), and then collect as much metadata as possible about those files and store them in some form of database, whether a text management system, SQL relational database, or some other nonrelational database. The notion is that you collect as much metadata about the documents as possible and stow it in the database; you can then search for documents based on the various characteristics. If this includes some sort of near-full-text search, it can be quite potent. Beagle is a GNOME system made for this purpose; one front end for this is Dashboard , which monitors what you type, and then uses Beagle to search your documents for others that may be related.
This OS makes use of "orthogonal persistence." The rise of object-oriented databases has gone hand in hand with the creation of "persistent objects." Persistence refers to the notion that an object keeps its value between invocations of programs. This eliminates the need to explicitly load and save data. This is tremendously useful when running simulations.
Persistence has not been a traditional feature of Unix-like operating systems, where processes normally provide you with a memory slate that appears clean when they start, and clean themselves out of memory when they terminate. (This is something that Windows NT tries to do...)
In a perhaps less-designed way, persistence has commonly been a feature of highly language-oriented operating systems such as FORTH, Smalltalk, and LISP Machines. These systems have stored in a persistent fashion extensive information about environment and system state, sometimes to the point of being able continue work almost as if uninterrupted after system shutdown.
It can be valuable to preserve system state, rather than having to recreate it repeatedly. Text editor "system" states tend to be a good case in point. It would be desirable to load up "yesterday's work session," with macros , variables, and buffer configurations set as they were yesterday as a starting point for today's work.
X Windows is a good example of a system where users would benefit from a persistent database of "system state." I find myself running the same programs week after week (they're robust enough that I don't necessarily stop/restart programs even on a daily basis), and would find it valuable to be able to save the system state so that the system would return to that state the next time I log in.
Unfortunately, this "sword" has two edges. Persistence means that configuration errors from the past can come back to haunt you later. It can also be a nice thing for configuration to be associated just with a single session. If I don't like the configuration, non-persistence means that restoring the old configuration merely requires that I restart the program and let it reconstruct the environment from a clean slate. I recently had problems reconfiguring Novell Groupwise so that it wouldn't bring messages up in a "full screen mode."
It is crucial that there be powerful enough tools that you can reasonably use to fix problems in the persistent configuration, and to indicate whether a particular change relates to:
A change that I want to use for the upcoming operation;
A change I want to use for the present "session;"
A change for all time.
A "persistent programming system" providing, much like Grasshopper, orthogonal persistence, integrated with a strongly-typed Algol-like language
Name Spaces As Tools for Integrating the Operating System Rather Than As Ends in Themselves
This system, from the Fluke/Flux project at University of Utah, has taken the approach of building OSes by "publishing libraries." They build library components and a set of interfaces to let them communicate.
Allows integrating code from elsewhere
This has allowed them to use device drivers and networking code assortedly from Linux and FreeBSD , so that they have not needed to "reinvent" those things. They use the "acclaimed" Linux network card drivers with BSD 4.4 TCP/IP network code
Building custom environments
The "natural" thing to build on top of a new OS kernel is a Unix/poSIX system. The "Fluke" OS is an OS that uses OSKit, and is a "modern, microkerneled Unix-like system."
But since the OSKit exposes system components, it is possible to build highly customized environments. A "quick project" was to build a ML/OS, an environment tuned to run Standard ML, a functional language. ML's system model is somewhat exotic, eschewing stacks in favor of aggressive heap allocation and garbage collection techniques. Implementing this efficiently atop a Unix is very difficult; implementing it atop bare hardware has also proved to be a formidable task. OSKit exposed appropriate functionality to turn implementation of ML/OS into a single semester graduate project.
Other "custom environments" have included SR/OS (SR is a language for writing concurrent programs) and a Java/pc.
In effect, OSKit provides a decent infrastructure for quickly building novel OS environments.
University of Utah wasn't making sources available for a while; here is an alternative source for FluxOS Sources.
Knit: Component Composition for Systems Software
Knit is a new component definition and linking language for systems code. Written to help with OSKit, it essentially replaces their use of COM to interface in driver code from FreeBSD and Linux.
The Off++ microkernel - written using Univerity of UTAH's OSKIT.
OS based on CORBA, Off++ microkernel, OSKIT
RVM - Lightweight recoverable virtual memory - CODA - Like Multics Segments
Flask - a security architecture for the Distributed Trusted Operating System (DTOS) Project, the basis for the recent NSA/SecureComputing efforts to further secure Linux.
An OS project that uses such things as:
L4 Development Site for MIPS, Alpha, and StrongARM processors
Sawmill - A Highly Configurable OS that has been ported to run on L4, and which plans some Linux-related work.
A Bell Labs toolkit for generating specialized OSes; rather reminiscent of OSKit
The SPIN Operating System group at the University of Washington is now making available a source-release of the SPIN Operating System. SPIN is a dynamically extensible operating system written in Modula-3. The source package includes the kernel and various applications that take advantage of the extensibility of the core operating system. This release runs on a Pentium/PentiumPro class processor and requires a Linux build environment.
A Caching Model of Operating System Design
This is a microkernel-like system developed at Stanford University that is specifically designed to encourage running emulation systems atop it.
This project seeks to build an OS based on the principles of reflectivity (the system can "examine itself") and persistence.
At this point, they have some extensive language analyses that suggest that they are not satisfied with any languages currently available, and need to do design work that goes to that level.
I am somewhat skeptical that so ambitious a set of requirements will even result in the creation of a useful language, let alone a useful OS...
MOSIX - Shared-Nothing Scalable Computing Clusters for *BSD and Linux
EROS - Extremely Reliable Operating System
EROS is a pure capability system. All system resources, including processes, are transparently persistent. The implementation provides high-performance application execution within a provably securable architecture (note, however, that the implementation of this architecture has not been proven). Application areas for systems of this kind potentially include active networks, high availability servers, and handheld platforms. The previous generation of this architecture, KeyKOS has been used in both credit card transaction processing and networking applications.
EROS has been released under the GPL.
cvs -d :pserver:anoncvs@cvs.eros-os.org:/home/anoncvs/cvs checkout eros
KeyKOS is a persistent, pure capability operating system, described as having a "nanokernel architecture." It is a predecessor to EROS.
It has been used to create an environment called KeyNIX much similar to Unix, as well as the KeyTXF facility that provides an object-oriented transaction processing facility.
KeyKOS was implemented on the IBM System/370 architecture, and was later ported to Motorola 68K and 88K processor families.
The Coyotos Secure Operating System
Coyotos is a secure, microkernel-based operating system that builds on the ideas and experiences of the EROS project. Much of the code developed for EROS will migrate directly to Coyotos. It is implemented in BitC, a language that is something of a cross between ML and Scheme , which has well-defined, mechanically-specified semantics to allow them to do formal verifications of security and correctness properties.
Legion: A Worldwide Virtual Computer
This computing system might be characterized as a "parallel scientific computing" equivalent to CORBA; it seeks to split processing efficiently across many hosts, and runs as a middleware substrate that can run on many platforms, including Unix-like systems such as Linux.
A bit more about Hydra, showing, once more, that IBM does take advantage of improvements in technology, but doesn't always publicize how "k00l" it is.
I suspect that business users of AS/400 wouldn't be all that excited to hear a sales pitch based on " AS/400 is based on cutting-edge research into capabilities and other stuff that accountants probably won't understand... "
I believe Hydra/CMP was the name of a research project in the early 1960's (possibly at Carnegie-Mellon) which did pioneering work in capabilities, objects, single-level store, and a number of other then-highly-advanced ideas. I no longer have the ACM publication that described it, and it has been a long time since I read it, so I'm sorry I can't be more detailed or accurate. I distinctly remember this project, because it has a modern descendant: the IBM AS/400, which itself is a successor to the first commercial implementation of these ideas, the IBM System/38. Most of the Hydra features made it into the AS/400; one that did not was user creation of new object types. The AS/400 has:
By the way, I don't, and never have, worked for IBM. I just do a fair amount of AS/400 work. Also, while the AS/400 is so hi-tech under the covers, the programmer does not particularly benefit. The main language has been RPG (no local variables, six-character names,...), and the editor has zero levels of undo. The command language is very good interactively, but less so for compiled programs. Shell scripts? What are they? I'm not sure where one goes to find out more (without buying one), because IBM doesn't particularly push the technical side of this machine in their advertising. -- | ||
| --Marcus Redivo | ||
The Roadrunner Operating System
Single user, multithreaded, Real Time OS with a single address space (thus being fast but unsafe), based somewhat on the Fairchild RT kernel.
An operating environment based on Self
This is an OS that initially competed particularly directly with Apple's MacOS. It provides a more robust multitasking kernel than MacOS, encourages the use of multithreaded code as well as SMP, and is apparently a pretty neat development environment. Like NeXT, BeOS was a company founded by ex-Apple employees that apparently decided that they couldn't build the systems they wanted to build at Apple. Like Apple and NeXT, they designed both an OS and hardware on which to run it. Also like NeXT, they have since concluded that it is better for them to just sell software.
Many people wanted Apple to buy Be out and turn BeOS into the next version of MacOS. Apple bought NeXT instead. Jean Louis Gassee, formerly of Apple, now of Be, made commentary on the "Apple gyrations", in an essay entitled I Like Apple So Much I Want Two of Them
Written by a former Be guy, this seems intended to provide something similar to the BeOS kernel, supporting multiple processors, threading, a POSIX-like API, and an architecture that supports having parts of the graphical infrastructure in the kernel.
Sprite: A Research OS
This was a somewhat Unix-like research operating system that proved to be a useful test bed for developments in such areas as:
Distributed processing;
Cacheing file systems;
Logging/Journalling file systems.
ASPLOS-IX Wild and Crazy Ideas Session II: Back to the Future
Presentations on Fairly Wild computational ideas... The last one included paper proposals on:
The Freedom CPU Project
Dynamic Compilation/Evolutionary Architectures
Esoteric Computation Models or Media
Explotations of ILP
Multiprocessing and Cache Coherence
Reconfigurable Computing
Programmer Support
Realtime Support
Capabilities and Security
Intelligent Memory and DRAM modifications
Intelligent Disks and other I/O
An OS implemented in Oberon...