SIMTICS Isn't MULTICS

This is a temporary homepage, until I can find time to write out something better. The purpose of this page is simply to provide a starting point for this project.

This project is running on Sourceforge.net's servers

What Is SIMTICS?

SIMTICS is an attempt to do for MULTICS what Linux and GNU did for UNIX - that is, to provide a GPL OS which meets the MULTICS specifications, but also builds on those specifications. In other words, leverage everything written and learned since.

Now, MULTICS was a project that evolved over time. It didn't have anything that could be considered a "formal" specification. Rather, it had a series of informal specifications that changed as the users' needs changed.

For the purposes of this project, the "specification" of MULTICS will be taken as being that set of requirements and definitions, from as many existing sources as can be researched, that are essential to the functioning of the OS, AND/OR that differentiate MULTICS from other OS'.

Please note: This is NOT intended to be a MULTICS "clone". Much has been learned over the years, about software design and OS architecture. Portability, which was not an issue for MULTICS, has to be for SIMTICS, or it's going to have an interest level of zero.

On the flip-side, MULTICS was no toy system. Indeed, Unix is a heavily cut-down derivative. MULTICS required customized hardware, to provide some of it's capabilities. Indeed, some features of MULTICS (such as variable-sized segments) are rarely, if ever, implemented today, owing to the complexity.

What is this meant to achieve?

There are many possible outcomes of a project of this sort. Nor is the project limited to only producing one outcome. Here is a (brief) list of the targets that have been set:

1. Produce a collection of portable GPLed libraries, which perform limited subsets of the MULTICS system calls that (in general) are non-trivial, or necessary for other produced code to be spec-compliant.
2. Produce or leverage an existing PL/I compiler to allow testing with pre-existing binaries.
3. Produce a skeletal OS which can lever the libraries to imitate a defined set of MULTICS operations.
4. Extend the libraries and OS to include functionality necessary for a modern OS, without breaking the specs.
5. Extend the libraries to include further MULTICS-specific (ie: non-UNIX) concepts.
6. Repeat the last two, until the system is able to do anything that either MULTICS -OR- any modern UNIX can do, efficiently, OR the sky falls down, OR everyone gets bored and re-writes pac-man for their digital TV.

Is this an ambitious project?

Yes! Of course it is! We're talking about developing a system that some of the largest names in computing couldn't even finish over a 33 year period! And they were getting paid to work on it, full-time!

On the other hand, the approach and concept this project is modelled after is that used (very sucessfully) by the Free Software Foundation and Linus Torvalds, with the idea that Linux took rather less time to write than the original Unix, suggesting that splitting the kernel from the development tools & libraries might be a very practical approach to follow.

Do you think SIMTICS will reach the final objective?

Does it matter? It doesn't seem to have crippled GNU that HURD was never finished. Every routine that can be used by someone else is a useful product. Getting a full SIMTICS OS developed may actually prove less useful than getting a working set of MULTICS-compliant libraries. Alternatively, it might be the kernel that turns out to be useful and the libraries that fade to black.

In the end, the only sane answer is that nobody'll know what the "real" final objective is, until it's reached. Until then, it's whistling in the dark.