EROS 1.1 relased under GPL

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.

Comments

I'm Uncomfortable With This...

[ewhac]

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

Re: I'm Uncomfortable With This...

[Pseudonym]

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.

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.

Disk Mirroring in EROS.

[jcr]

I'm not sure if Shap's FAQ mentions this, but I will.

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

Orthogonal Persistance

[Ian Bicking]

I think orthogonal persistance is the most important thing to happen in operating systems since multitasking.

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

Re:_|_ persistance??

[epopt]

It's not an inane question at all. It's a bit of obscure jargon that threw me the first time I heard it, too. I'm sure one of the EROS or KeyKOS folks can explain this better than I can, but since I don't see any of them wandering around here at the moment...

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!