Slashdot Log In
EROS 1.1 relased under GPL
Posted by
Roblimo
on Thu Oct 28, 1999 01:15 AM
from the yet-another-operating-system dept.
from the yet-another-operating-system dept.
ROSE writes "EROS: The Extremely Reliable Operating System, is now released under GPL. See EROS web site for details. For those who don't know what is EROS, read FAQ for details." Cute lil' Cupid mascot, too. This might make a nice project for people who feel Linux is too "mass market" for them these days.
This discussion has been archived.
No new comments can be posted.
EROS 1.1 relased under GPL
|
Log In/Create an Account
| Top
| 143 comments
(Spill at 50!) | Index Only
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
(1)
|
2
(1)
|
2
I'm Uncomfortable With This... (Score:4)
EROS looks like an excellent foundation for, as an example, an electronic funds transfer system, where you absolutely do not want errant/hostile code running around in the system. However, I'm not sure about its utility on more "traditional" desktop systems.
The EROS FAQ mentions that there is no such thing as 'root'; there is no user who has total authority. This is a double-edged sword. While the absence of root makes compromising a system difficult (since there's no Obvious Target to gain access to), it also prevents a legitimate user from manipulating or killing processes that simply refuse to grant the capability.
The scenario I'm envisioning here is an EROS-based Web Terminal. An unethical vendor could supply a terminal which, among other things, transmits your bookmarks and passwords to a central database to be analyzed and resold to telemarketroids. (Or, insert your favorite Dark Scenario here.) In an EROS-based system, there would be no way for a user to Do The UNIX Thing and kill the offending process.
Perhaps it's just my Type-A personality, but I find I'm uncomfortable with the idea of a program or system that could potentially refuse to do what I want, just because some $(EXPLETIVE) programmer thought it was none of my business.
Schwab
Disk Mirroring in EROS. (Score:4)
In EROS, there is the VM. In the VM, there are ranges. Disks have storage that provides backup for ranges. If I attach a 4 gig disk to an EROS system, the moral equivalent of "mount" tells the kernal that there is backing store on this controller, for the range from X to X + 4 gigs. Now the space bank can hand out read and write capablities for another 4 gigs worth of memory pages.
If I then attach another 4 gig disk, and advise the kernal that this second disk is to cover the same range, then the kernal says "Oh! I have additional backing storage for this range, and look: It's not up to date!" The paging logic will then take care of copying the pages in the range from VM to this additional backing store.
Now, consider the checkpoint. The checkpoint is the set of pages that have changed since the last checkpoint. They get written all at once. The pages in the checkpoint are the most recently used pages. If you fault on reading a page, it is most likely to be in the checkpoint,therefore, probably right under the head.
Effectively, RAM is just a cache for the disk. The checkpoint range on the disk is a cache for the normal range on the disk. migration of pages from the checkpoint to the normal ranges is done by a normal task, which doesn't interrupt your other processes.
Now, picture this: Instead of writing checkpoints only to the disk, you can also write them to a tape. Now you have an audit trail. (Maybe you don't care about knowing the historical state of your EROS server to five-minute increments, so you coalesce checkpoints, and your tape can reconstruct the state of the machine for say, every hour for the last week.)
Or, you can send them across the ethernet to another machine. Now you have a hot backup. See where this is going? EROS can do full-blown TANDEM-style multiple-hardware redundancy on commodity machines joined only by ethernet.
EROS is the coolest thing in OS's since Multics, IMNSHO.
-jcr
I've been net nannied! (Score:3)
I can't access the er*os-os site! Dumb filtering software.
General Purpose Versus Embedded Servers (Score:3)
The key to making EROS useful to people running Linux would be to build a "GNU System" atop EROS, parallelling building a "GNU System" atop the Linux kernel.
(Note that I usually call "systems based on the Linux kernel" by the moniker Linux; the use of the RMS term happens to be usefully descriptive here; I'm not trying to do any politically-motivated Newsspeak here.)
I would tend to think that the Debian [debian.org] folks would be the most prepared to create an overall system atop EROS, as they have both
The major alternative that, based on the deployment of predecessor systems like KeyKOS, [upenn.edu] is likely to take place quite a bit, is that EROS might instead be largely used to construct "somewhat embedded systems" rather than the general purpose system that comes from installing the typical Linux distribution.
This might include:
Which would parallel what Oracle has been working on with the "Raw Iron" Oracle 8i Appliance [oracle.com]
I'd kind of like to see both approaches, as that is the most likely way for EROS to become more widely used.
Re: I'm Uncomfortable With This... (Score:5)
EROS has no concept of root because the kernel has no concept of a user at all. In a capability-based OS with POSIX, users are part of the executive (or the Hird of Unix-Replacing Daemons). There's no reason why the executive can't implement a root user, i.e. one with the capability to do anything.
One benefit of using capabilities rather than users and groups is that it's possible to restrict your own access. Suppose I want to run a program which I don't necessarily trust. I can drop myself into a "sub-user" with all my previous permissions, except that I have no rights to write to the file system, and run it safe in the knowledge that nothing is going to be trashed. Just like chroot() only much more flexible.
Orthogonal Persistance (Score:4)
Most of the other things people are doing are boring at best. SMP? Anything but new -- so you stick a few more processors in a box. Security? Capabilities are definately the right way to do stuff (EROS uses them), but they don't change computers that much. They just fine tune and generalize security, and would allow information to be more easily shared -- plus getting rid of all the dumb sandbox efforts -- but they wouldn't change what computing meant.
Microkernels were only really important on the implementation side, even if they were to have succeded. Distributed computing is still a long way off in any meaningful manner -- resource farms aren't too interesting. I can't think of much really exciting... maybe OO, CORBA, and the like have some interesting possibilities in extending the basic infrastructure on a computer.
Orthogonal persistance doesn't seem all that interesting -- persistance already exists, after all, but you just have to explicitly save (in an app), or open a file (from code). But when persistance comes for free everything is just so much easier -- and making it easier to program stuff really is important. Objects become something tangible, not attached to a process or a session. If you added OS-level garbage collection then you'd have something really powerful. Objects would finally subsume processes and algorithms and the computer would be an environment instead of a machine.
My head is in the clouds at the moment, excuse me. Anyway, if you feel like reading other clouded thoughts on OS design (none of it by me), you might be interested in the all-talk TUNES [tunes.org] OS. Less code makes room for more talk! But you got to give them credit, at least they don't pretend to be anything but what they are :)
One of the coolest things about EROS: persistence. (Score:3)
What this means, is that in EROS, anything you put in memory stays there, across power losses or what have you, until and unless you change it.
When you start up an EROS machine, in effect, it re-mounts its previous swap space. Everything is where it was. This includes all of the running processes!
In EROS, to start a program, (invoke a start capability) there's none of the copy-copy-copy run bsuiness like you have in UNIX. An EROS domain has the very same memory map, whether it's running or not. As far as the kernal is concerned, the only difference between an running process and a not-running process, is that the running process has an entry in the thread table.
Think about how much of the code we've written exists just to deal with the unreliability of file systems, or to translate between in-memory and on-disk representation of the same data.
Imagine if you will, how much smaller a database engine could be, if it could simply keep everything it wants to remember in virtual memory.
An end to viruses. (Score:3)
There's no reason for your word processing app to have a write capability to its own code segment. If a program gets confused due to a stack-smashing attack, it doesn't matter *what* you push on the stack, the process can't maunfacture any new capabilities.
Consider also that in EROS, if you don't have a capability for something, your code can't even detect its existence. It's just not in your memory map, period.
-jcr
No root... Credential downward spiral? (Score:3)
One interesting aspect of EROS' model is that the line between the filesystem and memory seems nonexistant. RAM is merely a cache for objects, and the "state of the universe" is held on the HD. Everything's an object, and the system embodies the continual evolution of those objects. (If I misunderstood, someone please correct me.)
What's interesting about this model is that there is no clear beginning, end, or reboot, just as there isn't any clear concept of a "user" or anything else. The whole system is a collection of objects that are interacting with each other in various ways.
Unless I've missed something, this could lead to an interesting problem wherein the existing pool of objects lacks sufficient capabilities to continue to function. Since the whole system is persistent, how do you recover?
If there is a means to "restart" the system (and bring the system back to a reasonable continuum of objects), how is access to this mechanism controlled? Can you accidentally drop the capability to invoke the "restart"? I don't count the Big Red Button as a reasonable answer for restarting the system...
--Joe--
Re:_|_ persistance?? (Score:4)
The idea is that the mechanisms that make a program persistent are orthogonal to the mechanisms that let the program do whatever it actually does. No file writes (no files, yeah!), no "save to disk", none of that. The program runs under the illusion that it is running on a 100% non-stop machine, regardless of actual stoppages of the underlying hardware.
Some installations of EROS' predecessor, KeyKOS, have had processes running literally for years, in the face not only of hardware failures but in some cases complete replacements of the underlying hardware with newer generation machines. The only reason EROS can't make this claim is that it hasn't been around long enough to accumulate the track record!