Slashdot Log In
Adopt a Lost Technology Today For R.O.S.
Posted by
timothy
on Mon Jan 12, 2004 09:02 PM
from the are-oh-what dept.
from the are-oh-what dept.
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."
This discussion has been archived.
No new comments can be posted.
Adopt a Lost Technology Today For R.O.S.
|
Log In/Create an Account
| Top
| 56 comments
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Couldn't they add a U to that? (Score:2, Funny)
nice ideas but.. (Score:1)
(http://jodi.org/)
I mean with regards to putting it into action.
Plan9 (Score:2, Interesting)
(http://mysite.verizon.net/spitzak)
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.
Re: kernel/userspace separation (Score:4, Funny)
(http://sgik.org/)
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:Old/new idea (Score:5, Informative)
FreeVMS (Score:3, Interesting)
(Last Journal: Friday October 15 2004, @08:35PM)
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.
Features? Just so long as it has drivers... (Score:2, Funny)
(http://www.ajwm.net/amayer/)
Great Idea, Except ... (Score:3, Interesting)
(Last Journal: Thursday April 21 2005, @12:15PM)
Seriously, what features from the Atari systems are so great, yet have been overlooked in modern systems?
Bad ideas and good ideas (Score:3, Insightful)
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- 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 (Score:4, Insightful)
(http://www.pseudorandom.co.uk/)
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
Joe Bloggs
# Who ordered order#003?
$ cat
001
# What is the name of the customer who ordered order#003?
$cat
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 (Score:4, Informative)
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.
Already too many OS... (Score:4, Insightful)
(http://www.iwriteiam.nl/)
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.
VMS logicals versus Unix environment variables (Score:1)
(http://neoneye.dk/)
BTW: anyone which dare to write a comparison between VMS's logicals and Unix's environment-variables? Are VMS logicals more secure? Wikipage Of VMS [rubyforge.org].
--
Simon Strandgaard
One Word (Score:2)
(http://www.mountainlogic.com/)
How can you have a great OS without such a tool?
Shouldn't this be on Sourceforge? (Score:3, Funny)
(http://ameoba.0pi.com/)
"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".
Give me the VMS distributed lock manager (Score:2)
Resources are represented in a tree form and you may only lock something if you have a compatible lock higher up the tree. The lock-modes are something like: NULL, Shared Read, Shared Write, Protected Read, Protected Write and Exclusive. Certain modes are defined as being compatible with other modes, i.e., protected write with shared read. The resource tree means that you can only lock a record for write if you have the file open for write. If you can't get a lock, you get forced to wait. However, you can implement code so the current lock holder is imformed there is a waiter so the holder can choose to release the locks.
Another neat thing is that anyone getting access to a lock can receive an attribute block which can contain arbitrary information. This block can be updated by any system with protected write or exclusive lock levels and is instantly relayed to other processes, whichever node on a cluster that they reside.
Of course, the lock system has access levels, so a user can't mess with system held locks.
It really gets fun though because the lock manager doesn't give a damn about what the resources refer to, so you can use it for all kinds of things.