Adopt a Lost Technology Today For R.O.S.

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."

Comments

Couldn't they add a U to that?

[TMLink]

Maybe they should call it the "Ruby-centric Operating Uniformly System"...that way they'd already have a mascot.

Old/new idea

[be-fan]

I'd like to see the end of the kernel/userspace separation. Just put everything in one address space. With safe languages, there is no need for it. The safe language you can get fine-grained protection with close to zero performance overhead. This makes the VM a great deal less complex (read Charles Cranor's UVM paper to see the complexity cause by VM-enabled sharing) and faster/less memory-hungry.

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.

Re:Old/new idea

[topologist]

LISP Machines had unified address spaces and a lot more. Looks like the site referred to in the article has a decent summary (I'd add more, but I'm too young to have used them, so I'll leave it to someone with first-hand experience :-)

Re:Old/new idea

[be-fan]

On a related note, there is a nifty project on SourceForge about a kernel that does precisely what I'm talking about. The safe language in use is a natively-compiled, heavily Lisp-influenced language with low-level extensions for kernel development.

Re:Old/new idea

[be-fan]

Type tagging isn't a protection mechanism. Its an optimization for dynamic dispatch (virtual calls in C++/Java-speak). The protection in the Lisp Machine came from two conditions:

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.

FreeVMS

[JDWTopGuy]

Since VMS was mentioned, I'd like to let people know about this project:
FreeVMS (Mailing list archive)

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.

Features? Just so long as it has drivers...

[AJWM]

... for my card reader.

Re: kernel/userspace separation

[some guy I know]

I'd like to see the end of the kernel/userspace separation. Just put everything in one address space.

You mean like MS-Windows?

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.
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.
(I certainly wouldn't want to use such a system; I like C, even though I usually use Python (a "safe" language).)

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).
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.
(This would be kind of like a lightweight thread mechanism, but different threads could be loaded from different binaries.)

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.

Re: kernel/userspace separation

[be-fan]

You mean like MS-Windows?
--------
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 ...

[zangdesign]

that those innovations on older systems would have to be pretty much reinvented anyway, since the older machines were developed with closed or copyrighted codebases. Not to mention which, most of those "innovative" features have been superseded by the better features available on more modern systems.

Seriously, what features from the Atari systems are so great, yet have been overlooked in modern systems?

Bad ideas and good ideas

[davegaramond]

Good ideas

- unified name space (like Unix's single root / hierarchy)
- filesystem as database (why do we have to put stuffs in two different things anyway?); the filesystem should support hierarchiecal as well as relational paradigm. one can put a SQL interface on top of it
- using a safe, higher level, garbage-collected, OO language (about time to kill C, damnit!), also as another poster noted, this can eliminate kernelspace/userspace separation
- everything is a file
- everything is a component
- Unicode

Bad ideas

- registry (at least the windows do it currently): it's like the 777 version of /etc
- XML for configuration (YAML is a better choice)
- package managers or installers (the OS should be modular and component-friendly enough to render this unnecessary; think a PC with pluggable PCI cards or USB devices; adding/removing software components should be as easy as plugging/unplugging hardware devices)
- resource fork/multiple stream or something like that (if i want two different content, i'll make two different record/file, thank you)

Not sure

- GUI at the lowest level?

Re:Bad ideas and good ideas

[smcv]

- using a safe, higher level, garbage-collected, OO language (about time to kill C, damnit!), also as another poster noted, this can eliminate kernelspace/userspace separation

So... your security model breaks utterly as soon as someone finds a bug in the *compiler*?

(Incidentally, what is your compiler or interpreter written in, and why would I use an OS that only supports one language?)

- filesystem as database (why do we have to put stuffs in two different things anyway?); the filesystem should support hierarchiecal as well as relational paradigm. one can put a SQL interface on top of it

With an efficient enough filesystem (ReiserFS?) you could do something like this:

(extra linebreaks for clarity)

# What is the name of customer #001?
$ cat /tables/CUSTOMER/001/name

Joe Bloggs

# Who ordered order#003?
$ cat /tables/ORDER/003/customer

001

# What is the name of the customer who ordered order#003?
$cat /tables/CUSTOMER/$(- registry (at least the windows do it currently): it's like the 777 version of /etc

I'm sure parts of the Registry (HKEY_LOCAL_MACHINE?) are read-only for ordinary (non-Administrator) users; if you're right, though, the Registry is even worse than I thought.

IMO the main problem with the Registry is that it's in a few opaque binary files with a non-obvious structure; Unix configuration files are usually structured text, so it's easy to see whether a config file has become corrupted, possible to undo the damage, and possible to change everything with a simple text editor rather than having to invoke regedit. Unix config files are also split up sensibly (per-application) so they're easier to manage.

- package managers or installers (the OS should be modular and component-friendly enough to render this unnecessary; think a PC with pluggable PCI cards or USB devices; adding/removing software components should be as easy as plugging/unplugging hardware devices)

Hmm. So, how do you add software? Do you just copy a file-which-is-really-a-directory, MacOS-style?

If so, how do you suggest managing libraries? If every application has its own copies of all its libraries (or is statically linked), when someone finds a bug in, say, zlib, every program that used zlib needs an update. With separate library packages and intelligent dependency checking, you should only need to update zlib itself (and in a package management system, zlib should have been installed automagically the first time you installed an app which needed it).

Re:Bad ideas and good ideas

[JKR]

I'm sure parts of the Registry (HKEY_LOCAL_MACHINE?) are read-only for ordinary (non-Administrator) users; if you're right, though, the Registry is even worse than I thought.

On versions of Windows based on a real OS (NT and above) all the registry objects have security permissions associated with them. For a long time you needed two different registry editors because only regedt32.exe handled security, but XP has finally merged the functionality into one program. Most of the OS-related keys have security permissions such that ordinary users cannot break them.

There is a quantity of broken software (Kodak KPCMS, I'm talking to YOU) out there that just can't cope with storing user settings in the correct hive and thus needs to have its global settings made writable by anyone, but this is slowly improving. Now if only Adobe could fix the bug that requires oridinary users to have file create permissions in the root directory. It's not as if per-user temporary directories haven't been implemented since NT4.

Jon.

Re:Plan9

[AtrN]

Definitely. Plan 9 has wonderful ideas however it is covered by the following patent which may affect a development that uses its best ideas.

Already too many OS...

[Frans Faase]

...that are designed from the bottom-up, instead of top-down. Whether a OS makes us of a file-system or a relational database to store data, is really not interesting from the perspective of the end-user (application programs). The same is true for so many OS related design decisions.

If you want to be truely revolutionary, you should take the top-down approach and start with a solid object-model (with a clearly defined semantics), and only then start thinking about how to implement the rest.

Shouldn't this be on Sourceforge?

[ameoba]

I looked at the webpage and well... I saw nothing.

"Wouldn't it be cool if we could write an OS that's better than everything else out there. I want it to be radically different. Please join me & be brilliant & provide all the inspiration and drive to make me famous for heading this project".