Adopt a Lost Technology Today For R.O.S. 56
submitted by Simon Strandgaard writes "When new operating systems gets designed today, great systems such as Amiga, Atari and VMS, seems to get overlooked in regard to their original features not found on other OSes. It might be time to collect and categorize those special unique features under the great/lost ideas wiki, so new OSes don't have to re-invent the wheel and re-innovate." This is all for R.O.S., a "ruby-centric operating system."
Plan9 (Score:2, Interesting)
In theory it fixes all the problems with Unix, while still keeping to the original design philosophy.
Old/new idea (Score:3, Interesting)
Performance should improve a lot too. A P4 pays a couple of hundred clock-cycles penalty for each system call. Context switches are close to 1000 clocks. With a single address-space OS, you can get all the advantages of a microkernel providing services via OS servers, without any performance hit.
FreeVMS (Score:3, Interesting)
FreeVMS [freevms.free.fr] (Mailing list archive) [nvg.org]
It's based on Linux for the moment, but it'll split eventually. Despite the homepage being a bit out of date, the project is alive; in fact I'm working on cleaning up the code a bit.
Re: kernel/userspace separation (Score:3, Interesting)
--------
Yeah, but with a safe language
With safe languages, there is no need for it.
The problem with "safe" languages is that the underlying system can be used for such odious purposes as D"R"M, and there is no way to get around it.
----------
Not at all. Systems-level safe languages (Lisp, for example) usually have a dialect used for kernel-level development. In this scheme, binaries would have to be signed, to ensure that the native code was compiled by the safe compiler. However, this signing only has to be strong enough to protect a traditional security model. Root users, of course, should be allowed to run unsafe, kernel-level code if they want.
And you would have to have a "safe"-language-only policy on such a system, or you would have a security nightmare similar to that of MS-Windows.
--------
You could always run "unsafe" code in a virtual machine.
(I certainly wouldn't want to use such a system; I like C, even though I usually use Python (a "safe" language).)
---------
C could be made safe, if you added runtime checks for array indexing, and disable pointer arithmatic except for arrays. Unless you're writing kernel-level code, you shouldn't use those features anyway. Or, you could just run it in a VM.
Performance could be enhanced by doing more things in libraries (e.g., a ramdisk used exclusively by one application (or a limited set of mutually-trusted/ing applications) could be supported entirely in userspace, with no context-switching necessary).
---------
The MIT exokernel does this. They've shown some impressive performance gains in certain apps, but the design is, by necessity, highly unconventional (the kernel provides extremely primitive abstractions, namely memory pages and raw disk blocks). And it just moves the bottleneck around. Depending on what you're doing, an extremely low-level kernel API could very well cause a lot more system calls than a high-level kernel API.
Or several mutually-trusting/ed intercommunicating apps could share the same address space, so no VM remapping would be necessary when switching from one to another, nor would a system call be necessary.
---------
You're essentially talking about threads. However, the problem is that you want sharing, but still want protection. Threads can corrupt each others memory, and that's unacceptable. Would you want your webbrowser to crash if your email client did as well? With a safe language, you get fine-grained control of who you trust. The only people you've got to trust are the ones you explicitly hand your object references to, and then only when dealing with that specific object.
(This would be kind of like a lightweight thread mechanism, but different threads could be loaded from different binaries.)
---------
Linux can do this exact thing via the clone() system call, but its of limited usefulness, because most of the time, processes do *not* completely trust each other.
I don't know if any of this would actually be feasible, though, since I haven't really worked on the guts of an OS for about 20 years.
---------
Its certainly doable (and indeed, has been done), but there are better ways now
Great Idea, Except ... (Score:3, Interesting)
Seriously, what features from the Atari systems are so great, yet have been overlooked in modern systems?
Re:Old/new idea (Score:3, Interesting)
1) You couldn't access the byte representation of pointers directly, nor do arithmatic on them. This meant that the only way to access an object was to be handed a pointer to it.
2) Array bounds were checked.
Since the Amiga used C/ASM (IIRC) neither of these conditions held true, which is the reason for the iffy stability.
Note, that you can easily do the LispM-style machine without hardware type tagging. Gwydion's Dylan compiler*, for example, emits guaranteed-safe binaries on regular x86 machines.
*> The CMU Common Lisp compiler ordinarily does the same thing, but unlike Dylan, Common Lisp has an "unsafe" mode that turns of certain checks.