Slashdot Mirror
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.
>I'm not sure how they can call this a real-time environment.
In EROS, you need a start capability to invoke an object, and when you ask an object to do something for you, the time allotment comes out of your pocket, not the system's.
The time-slicing is quite rigid, and you simply can't get any more of the CPU cycles than your capabilities allow you to take. Even the time if takes to context-switch to your thread, is charged (if you will) to your thread's time allotment. (I believe it's the case that you may get more time than you expect, but there's no way to get more time than your limit.)
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
I imagine OS/2 will start to see better sales.
- A.P.
--
"One World, one Web, one Program" - Microsoft promotional ad
"Remember when the U.S. had a drug problem, and then we declared a War On Drugs, and now you can't buy drugs anymore?"
Capabilities are good, but I prefer the Quality-of-Service ideas implemented in nemesis. This is an even more radical OS - it does away completely with traditional OS concepts like virtual memory and priorities. The result is an OS that can perform tasks like multimedia with blistering performance. A prerelease version is available for downloading here. It has a BSD style license.
We're becoming too popular! Jump ship now, before it's too late! Don't risk assimilation! Argh...
~ Kish
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
Editor, A1-AAA AmeriCaptions
Anyone seriously considering using an OSS RTOS should look at eCos and RTEMS, as well as EROS. Search /. for more info, and check out eCos at http://www.cygnus.com. And no, I don't work for Cygnus. Here are some facts about eCos:
1. Open sourced under the ECPL, whose terms are quite like the
LGPL. Since RTOS's normally get linked with the application,
this is important for commercial users.
2. Ported to many hardware platforms. Many of the ports are
supported by Cygnus, and there are additional user contributed
ports.
3. A TCP/IP stack has been contributed. Last time I checked,
this still hasn't made it to the FTP site yet.
4. Cygnus has some pretty good people supporting the open source
on the mailing list, in addition to paid support.
5. There is a simulator which runs on top of Linux. This
allows you to debug the OS (except the hardware
abstraction layer, or HAL) and your application
using GNU tools.
Changes aren't permanent, but change is.
Finally, a free realtime OS which is useful for more than embedded applications. I've been waiting for something like it for a couple of years now.
BeOS has shown us all that realtime quality of service guarantees are important for modern media applications, which sadly is something that other free OS projects haven't realised. (Not a criticism of them; it's also important to achieve lots of raw speed in web and database serving. At least their approach is better than Microsoft's. "Multimedia performance not good enough, eh? Let's just stick the GDI into the kernel. It still counts as a microkernel if it's 14Mb in size, right?")
Maybe finally I can use a free OS to burn a CD and watch an animation while waiting for that compile to finish without fear of the CD being ruined. Maybe finally I can use a free OS to mix 16 channel audio. I can hardly wait for EROS to get POSIX support.
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
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
The only title of honor that a tyrant can grant is "Enemy of the State."
I can't access the er*os-os site! Dumb filtering software.
Check out these two points in the availability section of the FAQ :
- Is EROS Free Software? What are the terms of use?
EROS is not free software. EROS is being made widely available for personal, research, and certain non-profit use. All such use must be non-commercial. It will also be made available under reasonable licensing terms for commercial use.
Draft versions of the license agreements can be found here. The draft licenses are an attempt to compromise between making the system widely available and not losing my shirt. These drafts can be taken as a reasonable indication of intent, but please note that they are not yet final.
Many people seem to have the idea that EROS should be given away in the style of Linux or the various BSD-like systems. These people are entitled to their opinions. I do not share them.
I have put a large amount of effort and my own money into this project -- teetering on seven figures, when last I sat down to calculate it. I have absolutely no sympathy for the idea that writing a few hundred lines of driver code should give you the right to free use of this work, so please don't delay the release by trying
to convince me with an argument of this form.
If you build a good driver, I'll gladly incorporate it into the system and redistribute it for you. If you want that driver to have the BSD copyright so that others can derive from it, that is fine. For the present, I am not incorporating GNU-copyrighted materials into the core system.
- How about Open Source?
It may prove, in the end, that the Open Source model is the best way to advance a commercial EROS effort. We are tentatively leaning that way. If so, that decision will be taken as a strategic marketing choice. When the time comes to make that decision, we'll solicit input from the community. Please don't distract us from getting the release out by pressing the matter now.
If we do go the Open Source route, we will do so with at least one modification:
Because EROS is a secure system, there needs to be a central source that ``vets'' and ``brands'' the distribution. When somebody asks ``secure according to whom?'' There needs to be an answer. Also, people need to know if they are running the vetted version or some modification of that.
This means that we will be fairly strict about the use of the name ``EROS.'' If you distribute a modified system, you will be able to call it ``EROS derived,'' but you will not be able to call it ``EROS.'' The official release will also be digitally signed or one-way hashed so that users can verify its authenticity.
The implications of this issue have not yet been thought out. As I said before, we will solicit input at the appropriate time.
Obviously the FAQ hasn't been updated, but I still think it gives us insight on their attitude. Considering how the author felt like a the time, I don't quite understand how he finally went to release EROS under the GPL. It seems like a big turn around...
Also consider, a completely different sort of networked cluster system (made possable by the security model, where connecting to the net means that your node joins a world cluster. Some of your objects are marked for your access only, and others are world accessable.
I'm not expecting to see that next week, but eventually, it could happen.
I cant get it to compile. It freaks out with awk somehow, and I have NO idea why. I will of course keep trying.
The persistant objects is probably what I like the most about it, altho' memory leaks could be a killer. I hope theres a 'reset object' call that reinitialises an object from its original template (or whatever it has).
I think I like the idea because its so unlike anything I've used before, except my Psion 3a, which is lying in bits on my desk.
-Yarn - Rio Karma: Excellent
Let's say that I have a service within EROS that could be invoked at any time, and many other processes have the capabilities to invoke that service. Now, let's say I want to upgrade to a new version of that service that has a backwards-compatible interface, without disturbing any other process in the system. How does EROS handle this? Do system utilities have a "replace me" capability? Is there some kind of package manager that stands as an abstraction barrier between a service and the processes that use it?
send all spam to theotherwhitemeat@ropine.com
And if we want to accomplish anything with the new system any time soon, what are we to do?
UNIX has been remarkably persistent over the year as a useful environment for prototyping.
If there's nothing in common between EROS and Linux, and, in particular, if there are practically no tools available for EROS, there's going to be little merit to making a leap over to EROS.
The point here is that there are two particularly relevant outcomes:
That makes for a challenging transition, and, for a would-be newcomer, they may say
Since EROS is different, it is obviously appropriate to add new tools in support of that. That is not synonymous with the contention that
If you're not part of the solution, you're part of the precipitate.
That buys you not merely a somewhat familiar environment, but also a goodly chunk of the sizable toolset that people are accustomed to using on Linux.
If you're not part of the solution, you're part of the precipitate.
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 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, 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
I'd kind of like to see both approaches, as that is the most likely way for EROS to become more widely used.
If you're not part of the solution, you're part of the precipitate.
If your driver maintains state information, and knows how to move the hardware from reset to any given state, You effectively (more or less) have persistant hardware states.
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 :)
One thing that bothers me about this persistence is that they would need to save the state of various cards on your machine, too
That can be a hard problem, but it is NOT an impossable one. What it amounts to is that the checkpoint recovery code must understand that hardware is only half way in the persistant universe, and that the driver must have recovery code that can re-init the driver, and play back a transaction log in order to bring the hardware to the correct (checkpointed) state.
If OS design moves more in this direction, customers will demand (and eventually get) checkpoint friendly hardware.
Keep in mind though, that any app that leaks memory in EROS is going to have to be FIXED
That problem (though very real) can be mitigated through a good garbage collection system. (sweep for unreferenced objects etc.) Hopefully, by greatly simplifying object management, there will be less such leaks in the first place (though there will be leaks).
Most of the discussion here so far ahs been about EROS's security model, but I'd like to point out also that EROS has GLOBAL, ORTHOGONAL PERSISTENCE.
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.
The only title of honor that a tyrant can grant is "Enemy of the State."
--
"One World, one Web, one Program" - Microsoft promotional ad
"Remember when the U.S. had a drug problem, and then we declared a War On Drugs, and now you can't buy drugs anymore?"
In EROS, the capablity to read, write and execute are separate and distinct.
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
The only title of honor that a tyrant can grant is "Enemy of the State."
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--
Program Intellivision!
EROS today, just runs its own benchmarks and regression tests. It needs about six man-months of work before it's ready to host any network-based services, and AFAIK, getting a self-hosted development environment on EROS has the higher priority.
Today, to create an EROS process, you generate an ELF binary under Linux, and then transmogrify that into an EROS domain.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
EROS does provide checkpointing, but at too coarse a granularity to be useful for a transaction database. (That is, unless I missed something.) You still need to implement a two-phase commit that you know has committed to some non-volatile storage.
Consider an EROS-based transaction database that's sitting between two other entities in a transaction. (For example, suppose it's running bank software at your bank and you're doing an Electronic Funds Transfer.) Just as you initiate the EFT, the EROS box "sends" the money to the remote bank and updates the ledger, and tells everyone that all updates are successful. Now suppose the power goes out at your bank. The remote bank has updated its ledger, you've updated your ledger, but has the EROS box flushed the changes to disk yet?
This problem exists whether or not you've abstracted away RAM vs. disk as EROS does. For certain classes of application, you must know that a given object is committed to non-volatile storage as part of the transaction protocol. (In fact, that's the reason many high-end transaction systems use solid-state "disks" to store transaction journals.) Does EROS provide for this need?
--Joe--
Program Intellivision!
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!
-- Remember that we live in a world where all the really big decisions are made by people with short attention spans.
You might like to look at IBM's AS/400, and its predecessor System/38 - both have orthogonal persistence, i.e. everything is an object and some are just persistent.
Despite its proprietary nature, the AS/400 has an interesting architecture, and is highly popular as a mid-range system.
The rise of web-based applications (e.g. www.opendesk.com, an open sourced web desktop, and desktop.com, as well as the handy web-based database, www.flashbase.com) may make it much easier for radically different OS architectures to flourish. It also makes it easier for older architectures to do well - e.g. IBM's OS/390 mainframes remain a good way to do truly enormous amounts of back-end transactional processing, and they can run web applications just like anything else.
To paraphrase the New Yorker cartoon, "on the Web, nobody knows you're an AS/400."