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

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

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.