Firstly, MULTICS, being an acronym and all that, really does need to be capitalized. (Or, as a QA person where I work would put it - capitalizified.)
People have almost certainly borrowed from MULTICS, in one form or another. However, nobody has ever built anything useful from such work, aside from UNIX.
The problem is, most architectures for Operating Systems are designed by people who probably know a lot about design, but not very much about usability or extensibility.
A couple of examples:
- L4 is a nice microkernel, and there are two flavours of Linux build round it - vanilla & real-time. Seen any Linux distros pick up on it?
- "Ants" is a distributed kernel, which farms processes efficiently over networks with any kind of topology. If it were actually useful, it would render projects such as Cosm, distributed.net and SETI@Home obsolete and petty. If. You see it in use, lately?
This is the problem. There are a lot of brilliant concepts out there, but that's ALL they end up being. For an OS to become anything more than an interesting side-show, it has to be practical, useful, and extensible.
Ok, so would a re-write of MULTICS meet these criteria?
First, let's try practical. The project is going to start by creating a development suite that complies with MULTICS' specification. This would allow developers on non-MULTICS platforms to play with the API. This is the keystone to the whole project. Without that suite, development would be impossible.
However, not only does it make MULTICS development possible, it also provides added tools for programmers across the board, for completely unrelated work. In a real sense, then, the development suite is practical, regardless of whether the kernel itself ever is, or indeed is ever developed. (Much like GCC is useful, even though HURD has remained a pipe-dream.)
Now, how about useful? Here, we need to examine a couple of MULTICS' strengths -- SMP and security. Modern OS', including Linux and Windows 2000, support only very primitive security models. In today's heavily-networked world, these models are as effective as a paper watchdog. MULTICS, on the other hand, was the first B2-certified OS. Unlike most OS', security was built-in from the start, rather than wrapped round inherently-insecure components. There is no telling if that improved the design of Classic MULTICS, but it does mean that a MULTICS II should have negligable overhead from the security.
SMP is another issue that causes endless problems. Very, VERY few Operating Systems are scalable, because of the complexity of all the various issues. Again, SMP tends to be bolted-on, rather than an inherent part of the design. As a result, it tends to scale badly. By using an OS specification that includes SMP, again, this should not be a problem. If the design is correct, it should be as correct for N processors as it is for 1, where N is any number you feel like throwing in there.
Finally, we get onto extensibility. This project is not about building around a closed, sealed specification, set in stone. It's about using that specification as a starting-point, as a guaranteed minimal set of functions, and extending it. Again, this goes back to how OS' are written. If Linux 0.65 had the same capacity to load/unload driver modules as 2.4.3 has, it would not have needed the substantial re-writes that it underwent, each time a design flaw came up.
If MULTICS II is built with extensibility as a priority, then anyone can add whatever capability they feel like, at any time, without causing endless conflicts and upgrade problems.
[ Parent ]