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.
Normally, you get persistance by doing
FILE *myfile;
myfile=open("somefile.txt", "w");
put(myinfo, myfile);
And, of course put is some complicated procedure that converts any information into a string, and God help you if you have pointers in that data. Persistance here is not independant of other issues, but is deeply involved with the internals of your code.
With orthogonal persistance you simply create an object (i.e., a bit of data) and it is persistant -- it exists until destroyed, not until the process is killed, not until the computer is rebooted, until you actually get rid of it (garbage collection and other language constructs can make the destruction easy). More importantly, if you have a pointer to an object you don't have to worry about it just disapearing out from under you, or making a local copy that your process controls, or whatever.
all the people who force themselves to do "the different thing" have already jumped ship to FreeBSD.
DON'T port X11 to this OS. They have a clean start with good foundation, so don't ruin it with the bloated buggy X11. This OS deserve a little better than mistakes from the past, and a good UI with fast and efficient graphics.
Tell me how you really feel :P
"EROS does provide checkpointing, but at too coarse a granularity to be useful for a transaction database. "
As it happens, EROS does provide the ability to explicity append pages to the most recent checkpoint, so you can get the transaction assurance you need. MOst apps don't need to do this, but if you have to have it, you can get it.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
I think my observation here is that conspiracy theories are usually oversubscribed.
See my answer about killing programs, as that is also relevant.
More generally, you don't even need root authority in UNIX to kill your own processes, so the question was a bit confused to begin with.
In EROS, the model is that you provide the storage and the CPU time that your programs execute with. While you can't examine the storage these programs allocate without their permission, you can shoot the storage allocator from which they were obtained, which reclaims all of the storage (including the processes).
This is a case of drift between the web site and what has so far been completed.
There is also a designed mechanism for keeping objects in memory. Regrettably also not yet implemented. As I said in an earlier response, the real-time features of EROS are not really there yet.
Card state and external connections are not persistent. In the case of your example, it is the responsibility of the display manager to be able to recreate the state of the display when the system restarts.
Just so you know, the 2Gbyte limit is a Linux limit rather than an x86 limit. In EROS, every process gets up to 3Gbytes of virtual address space, and this could be raised to 3.5Gbytes without a lot of work. The 3Gbyte space is potentially a window onto a much larger space.
The original research release occurred before EROS was ready for other people to work on it. A lot of people were wanting to look at the code, and I wanted to make it possible without getting flooded by reaction. The result was a lot of flack from bratty college kids claiming that they were entitled to EROS for free because they said so. This was taking a lot of my time, and led me to put up the $$$ figure (which is accurate, by the way) to get them to go away.
The second license (a modified MPL) was open source, with the qualifier that I had reserved rights to everything. The purpose of this was to get a few early people to help check things out without being overwhelmed while I finished my dissertation. Also, I wanted to figure out how to deal with the security branding issue.
I am now done with my dissertation, and the branding issue has been resolved, thus GPL.
Indeed the FAQ hasn't been updated, which is an error on my part in cutting the GPL release. It should be fixed very shortly.
Initialy I thought this was a joke due to EROS being a erotica lobby group here in australia
But I've almost never seen any real information on it -- probably because of the proprietary thing. Do you know of any good resources/papers/descriptions of AS/400 on the web?
I thought that "real-time" had to do with getting raw access to resources. This way, I can know *exactly* when data arrives at my serial port, for example.
Everything in EROS, on the other hand, seems hyper-abstracted. No users; no files; no filesystems, for that matter; only objects.
Doesn't this make me somewhat at that object's mercy with regard to when exactly something happens? Can I be sure my data is actually written to disk? How can I be sure that there even is a disk? Did this stream arrive at the serial port just now, or was it 60ms ago and I'm just now being told about it?
Perhaps I'm just clueless here, or missing something obvious in my sleepy stupor. But their claims to being real-time just seem spurious to me.
"I have a good idea why it's hard to verify programs. They're usually wrong." --Manuel Blum, FOCS 94
Is a pretty long way off.
Keep in mind though, that any app that leaks memory in EROS is going to have to be FIXED, because when you use up the memory you've been given, you STOP. X would certainly benefit from being ported to EROS, but EROS would be better off with something like Berlin or Display Postscript.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
>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."
According to the Programmer's Intro, you can get direct access to the hardware via keys. Very direct in fact; the kernel just confirms that it won't get toasted, then lets you loose. I'm not sure how close to real-time it gets--the key itself is still in the way--but it's better than nothing.
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?"
This project is one to improve the Linux security model if reading that stuff about Capabilities made you feel inadequate :-)
Matthew @ Bytemark Hosting
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.
The upgrader stuns the old object by waiting until the old object is idle and demanding a fault capability to it. At this point, the old object is frozen and cannot be invoked by anyone else.
The upgrader now clones the process nodes of the old object's process. In effect, we have just copied the old object into a new process.
The upgrader now installs into the old process a new address space: the address space for the new object. It then sets the old process registers to the appropriate startup values to give the new object a chance to initialize itself. It also places a capability to the old object into a well-defined register in what is now the new object's process. Note that we've now effectively done a complete brain transplant on the original process. All holders of the old object still have capabilities to this process, which is now obeying new code.
The upgrader now lets the transplanted process start running. During initialization, the new object uses its capability to the old object to transfer any necessary data from the old object and then tells the old object to destroy itself.
Finally, the new object returns to the null capability, becoming available for new invocations.
It all sounds much more complicated than it is. Most of this can be built in a library.
Didn't that happen back in April?
Peace and love, y'all
We're becoming too popular! Jump ship now, before it's too late! Don't risk assimilation! Argh...
~ Kish
This FAQ was written and is maintained by:
/usr/src/linux/include/linux/capability.h.
n ux-privs/kernel-2.1/
e s/sucap.c. It is
// p=process, f=file
Alexander Kjeldaas
1) What is a capability?
The name "capabilities" as used in the Linux kernel can be confusing.
First there are Capabilities as defined in computer science. A
capability is a token used by a process to prove that it is allowed to
do an operation on an object. The capability identifies the object
and the operations allowed on that object. A file descriptor is a
capability. You create the file descriptor with the "open" call and
request read or write permissions. Later, when doing a read or write,
the kernel uses the file descriptor as an index into a datastructure
that indicates what operations are allowed. This is an efficient way
to check permissions - you create the necessary datastructures to
check permissions once during the "open" call. Later read and write
calls only have to do a table lookup. Other operations on
capabilities include copying capabilities, giving a capability to
another process, modifying a capability, and revoking a capability.
Modifying a capability can be something like taking a read-write
filedescriptor and making it read-only. A capability often has a
notion of an "owner" which is able to invalidate all copies and
derived versions of a capability. Entire OSes are based on this
"capability" model, with varying degrees of purity. There are other
ways of implementing capabilities than the file descriptor model -
traditionally special hardware has been used, but recently the memory
management unit of the CPU is often used.
Then there is something quite different called "POSIX capabilities"
which is what Linux uses. Capabilities here are a partitioning of the
all powerful root privilege into a set of distinct privileges. Users
familiar with VMS or "Trusted" versions of other UNIX variants will
know this under the name "privileges". The reason we use the name
"capabilities" in Linux is that this is what the POSIX draft uses.
2) So what is a "POSIX capability"?
A process has three sets of bitmaps called the Inheritable(I),
Permitted(P), and Effective(E) capabilities. Each capability is
implemented as a bit in each of these bitmaps which is either set or
unset. When a process tries to do a privileged operation, the
operating system will check the appropriate bit in the Effective set
of the process (instead of checking whether the effective uid of the
process i 0 as is normally done). The Permitted set of the process
indicates the capabilities the process can use. The process can have
capabilities set in the permitted set that are not in the effective
set. This means that the process has temporarily lowered this
capability. A process is allowed to set a bit in its Effective set
only if it is available in the Permitted set. The distinction between
Effective and Permitted exists so that processes can "bracket"
operations that need privilege. The Inheritable capabilities are the
capabilities of the current process that should be inherited by child
processes. The Permitted set of a process is masked against the
Inheritable set before being transferred to another process. "Another
process" means a process image after an exec() call. Capabilities are
copied to child processes or threads. The capability rules (see own
question) are only enforced during exec().
3) What about other entities in the system? Users, Groups, Files?
Files have capabilities. Conseptually they have three bitmaps just as
processes, but we call them by other names to avoid confusion. Only
executable files have capabilities, libraries don't have capabilities
(yet). They three sets are called the Allowed set, the Forced set, and
the Effective set. The Allowed set indicates what capabilities the
executable is allowed to receive from an execing process. The Forced
set is a set of capabilities created out of thin air and given to the
process after execing the executable. The forced set is similar in
nature to the setuid feature. In fact, the setuid bit from the
filesystem is "read" as a full Forced set by the kernel. The
Effective set is acutally not a set, but a single bit. It indicates
which bits set in the permitted set of the new process should be set
in the effective set of the new process. However, transferring only a
few bits from the Permitted set to the Effective bit doesn't seem to
be useful. The Effective set is best thought of as a "capability
aware" bit. Only if the executable is aware of the capability API can
it start with an empty Effective set.
NOTE: Filesystem support for capabilities is not part of Linux 2.2
Users and Groups don't have associated capabilities from the kernel's
point of view, but it is entirely reasonable to associate users with
capabilities. By letting the "login" program set some capabilities it
is possible to make a "backup" user for example. This could be
implemented as a PAM module. However, this is not done yet. Also see
question about capability policies.
4) What capabilities exist?
The capabilities available in Linux are listed and documented in the
file
5) Are Linux capabilities hierarchical?
No, you cannot make a "subcapability" out of a Linux capability as in
capability-based OSes.
6) What about passing capabilities between processes?
Currently this is done by a systemcall setcap which can set the
capability of another process. This requires the CAP_SETPCAP
capability which you will only grant to a _few_ processes.
CAP_SETPCAP was intended as a workaround to be able to implement
filesystem support for capabilities using a daemon outside the kernel.
There has been discussions about implementing socket-level capability
passing. This means that you can pass a capability over a socket. No
support for this exists in the normal kernel however.
7) I see securelevel has been removed from 2.2 and are superceeded by
capabilities. How do I emulate securelevel using capabilities?
The setcap system call can remove a capability from _all_ processes on
the system in one atomic operation. The setcap utility from the
libcap distribution will do this for you. The utility requires the
CAP_SETPCAP privilege to do this. The CAP_SETPCAP capability is not
enabled by default.
libcap is available from
ftp://ftp.kernel.org/pub/linux/libs/security/li
8) Seems I need a CAP_SETPCAP capability that I don't have to make use
of capabilities. How do I enable this capability?
Well no, but for some uses such as emulating securelevel you need it.
What you do is you change the definition of CAP_INIT_EFF_SET and
CAP_INIT_INH_SET to the following in include/linux/capability.h:
#define CAP_INIT_EFF_SET { ~0 }
#define CAP_INIT_INH_SET { ~0 }
This will start init with a full capability set and not with
CAP_SETPCAP removed.
9) How do I start a process with a limited set of capabilities?
Get the libcap library and use the execcap utility. The following
example starts the update daemon with only the CAP_SYS_ADMIN
capability.
execcap 'cap_sys_admin=eip' update
10) How do I start a process with a limited set of capabilities under
another uid?
Use the sucap utility which changes uid from root without loosing any
capabilities. Normally all capabilities are cleared when changing uid
from root. The sucap utility requires the CAP_SETPCAP capability.
The following example starts updated under uid updated and gid updated
with CAP_SYS_ADMIN raised in the Effective set.
sucap updated updated execcap 'cap_sys_admin=eip' update
[ Sucap is currently available from
ftp://ftp.guardian.no/pub/free/linux/capabiliti
intended to be put in the progs directory of libcap.]
11) What are the "capability rules"
The capability rules are the rules used to set the capabilities of the
new process image after an exec. They work like this:
pI' = pI
(***) pP' = fP | (fI & pI)
pE' = pP' & fE [NB. fE is 0 or ~0]
I=Inheritable, P=Permitted, E=Effective
' indicates post-exec().
Now to make any sense of the equations think of fP as the Forced set
of the executable, and fI as the Allowed set of the executable.
Notice how the Inheritable set isn't touched at all during exec().
12) What are the laws for setting capability bits in the Inheritable,
Permitted, and Effective sets?
Bits can be transferred from Permitted to either Effective or
Inheritable set.
13) Where is the standard on which the Linux capabilities are based?
There used to be a POSIX draft called POSIX.6 and later POSIX 1003.1e.
However after the committee had spent over 10 years, POSIX decided
that enough is enough and dropped the draft. There will therefore not
be a POSIX standard covering this aspect anytime soon. This may lead
to that the POSIX draft is available for free, however.
Peace and love, y'all
Why is Cupid the macot for Eros?
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});
Sandboxing is a sensible optimization. Why pay the firmware cost for checking on the fly that every operation is allowed in the security model, if you can statically prove that they all must be?
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."
EROS is a system that address how you and I can share a machine without trusting each other. Nemesis is an OS for getting the ultimate performance out of the hardware.
EROS does a far better job performance-wise than UNIX, but it doesn't go as far down that road as the single address-space approach of Nemesis and some other approaches like ExoKernal.
-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.
Shap doesn't have any philosophical problem with free software, and he certainly realizes that EROS has to be open source if it's going to get anywhere.
He had some issues with certain details of the GPL, but I know he's been talking with ESR about it for several months now.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
..jawad explicitly stated that he was talking about lusers (er, I mean users), not developers (which was what ``Roblammo'' over there was ostensibly insinuating). The luser base (as opposed to the user base, which uses GNU/Linux stuff because it's sensible to do so, not so they can be ``hip and trendy'') isn't going to matter a whole lot to the hacker contingent that is central to GNU/Linux development (or any other developers, really, because obviously companies /want/ to make it big, not cater to lusers who will only support them if their popularity rating are under such and such %). Those developers aren't going to drop what they're doing just because yet another OS came out. Unlike ``underground bands'', most of the core developers aren't out to make a buck, so how many ``groupies'' they have.. doesn't matter much.. Edging upward in status amongst their peers, however, is a much more widespread goal. =P (along with the various moral imperative and other gift culture rationales)
Of course, if you were to believe the media, you'd think that no one used Linux for any reason /other/ than to ``be cool'' (well, along with a number of other things.. like ``Linux is insecure, doesn't scale /at all/" etc. and that ``Microsoft kicks ass, you should buy their stock'' etc. or some other random nonsense, depending on which media outlet you're talking about). The problem with that assertation is this: if you're stupid enough to use an /OS/ just to ``be cool'', you're probably not intelligent enough to use Linux properly, and will be running back to Windows or whatever in no time flat. =P
~ Kish
It's easy to start a new rockband that produces music. It's a lot harder to start a new OS that plays a prerecorded mp3.
Orthogonal persistence is a wonderful concept but if taken to its logical extreme it could have some problems.
"Bit rot" is a fact of life in big systems. Lots of interconnected components sometimes develop internal inconsistencies in their state and fail. Being able to reboot the system is often the only way to recover.
You can't really reboot a persistent system - it just restores the last state and continues from there. Essentially, it lives forever.
It is true that software today wastes a lot of resources in translating back and forth between the tranisent memory image and the persistent filesystem state, but it gives you the ability to reboot if something goes wrong.
I don't know about EROS but in KeyKOS (EROS's predecessor) there was no way to initialize the system - it was shipped as the memory image of a running copy which was somehow created manually by the deveopers and after that it lives forever. If you experience bit rot the only thing you can do is hope you know when it really started and restore a backup made prior to that time, losing all changes done since.
----
Stop worrying about the risks of nuclear power and start worrying about the risks of not using nuclear power.
Smaller and simpler, sure. But, then, you can do that today just by calling mmap() on the database under most Unix systems. Well, no. Certainly you could use mmap() to get a memory mapped file, but there are a couple of deficiencies associated with that approach. First, the page table isn't saved across a reboot or restart of the process, so you can't be sure you'll get back that mmap in the same place. That means you can't use pointers, which means that you are either doing without them (and getting bad performance issues) or keeping data elsewhere before copying it to the mmap'ed segment. That's not a lot better than writing occasionally to a file. Second, EROS has checkpointing to ensure that saved state of many different objects are all saved at an identical time and are consistent with each other. That consistency is very hard to guarantee except at the operating system level. I'm not yet sure what I think of this, but it definitely is something new and unique. It provides some concepts and abilities that just can't reasonably happen under a traditional RAM/disk model a la UNIX, Windows, Mac, VMS, etc. Chris
Anything that can be done with an ACL model can be done with a capability model. The reverse is not true.
A number of papers on the EROS page illustrate the problem with ACL's -- since a process MUST have a user ID, it isn't necessarily possible for a process to have only the permissions it needs for a particular job, and NO MORE.
John
John_Chalisque
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...
For people interested in learning about persisence in real life situations, there is a paper entitled A Persistent System in Real Use - Experiences of the First 13 Years.
OK, how do I share data with my friends? What about sharing data across multiple architectures with different endianness?
Has the EROS programmer dude ever heard of object serialisation and why it's a good idea?
You can do this now with MkLinux, which uses the Mach microkernel. Just be careful that you don't give both kernels the same root directory.
--
"I was a fool to think I could dream as a normal man."
B. B. Buick
Flamebait and stupid
Offtopic and stupid
EROS seems to have a nice security model and have automic persistency support, it is GPL, small and seems to be quite fast according the small benchmark which has been made.
I don't know about it's real time capabilities though...
The guys who are working on HURD could, may be take a look at EROS, and report here what they think about it, this should be very interesting.
One thing that bothers me about this persistence is that they would need to save the state of various cards on your machine, too, which I doubt that they do. I would imagine that some of these 3D accelerator cards require a good bit of initialization.. so you're playing some cool 3D game, the power goes off.. 15 seconds later your game starts up again and you can't see anything anymore.
For a server, I think it would be really cool, though.
If you don't want attackers to get to them, posting it on slashdot is a bad idea then.
------ Curiosity killed the cat. {satisfaction brought it back | it didn't die ignorant | lack of it is killing mankind
do we cry about viruses in the unix world? Of course not, although possibly, the are not a problem. So an end to virus cry is a blah statement.
------ Curiosity killed the cat. {satisfaction brought it back | it didn't die ignorant | lack of it is killing mankind
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.
It seems to me that the HURD already has this concept of capabilities: Mach port rights are exactly that, capabilities. The Hurd ``auth'' server emulates users using these capabilities, so the OS can function as Unix (with multiple UIDs per process), but you have all the libraries and stuff to bypass this and use the basic Mach mechanisms.
HURD is admittedly not very advanced, but it is still more so than EROS right now.
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.
If we stuck with this attitude from the beginning, we'd still be using JCL and COBOL for everything. It's a new system, how about new tools?
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.
From the FAQ:
2.Is it possible to run binaries from Linux or other UNIX systems under EROS?
Short Answer: Not yet, but it will be.
Longer Answer:
It's possible to build a UNIX environment that runs on top of EROS, and we intend to do so. That
environment will run both conventional UNIX binaries and will also be able to access EROS-based services.
In fact, it will be possible to run multiple UNIX environments at once. If desired, each user can be given a
UNIX system that they fully control and adminster, without compromising the security of the other UNIX
environments on the machine.
So they're actually planning on doing this themselves. Actually, the interesting part is the last bit where you can give each user "root" without danger of them wrecking other people's work.
Glückwünsche, haben Sie Slashdot ermordet, indem Sie zum korporativen Druck beugten und Subskriptionen einlei
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.
oooohhh, and the get defensive about it when you point it out! LOL!
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.
Unfortunately saving the entire state of a machine would probably be impossible because of hardware design. There are plenty of hardware devices that will allow you to set a state, but not query that state back. They assume you know what you set up.
Watch out about "orthogonal" persistence. It is almost never so easy when the machine is talking to the outside world. You often can't "rollback" the state of the other machines you're talking to. And if you could, each one needs to be notified in its own way about how to rollback. That will always be the application's responsibility, it will never be "orthogonal". On the whole, though, I think this is all very exciting and I hope this goes far.
EROS today does not have a self-hosted development system. To make a program to run under EROS, you write it under linux or FreeBSD, generate an ELF binary, and then use EROS' process builder to make an EROS domain out of the ELF binary.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
- Sam
The secret to enjoying Slashdot is to realize that it should not be taken too seriously.
I had to reinstall Linux on my machine last night (moral: when the RH6.0 upgrade program says you don't have enough free space on /, don't click on the "Continue Upgrade Anyway" button ... but I digress), and if I'd known I could get a GPL'd EROS, I'd have set up a partition for it.
Despite my interest in EROS, though, I don't have a lot of experience in C programming (and virtually none in C++), so I'm not sure how much I could accomplish by fumbling around in a completely new OS. Are there any high-level languages that run under EROS and that allow one to manipulate its special features? (A crude but standards-compliant Scheme implementation shouldn't take too long to write ... unless, of course, I'm the one writing it.... :-)
send all spam to theotherwhitemeat@ropine.com
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.
Which is a shame. It means that innovations in this OS (which I hear incorporates some novel ideas) will never become industry standards, because publishers of commercial operating systems cannot adopt them. The same would not be true if a business-friendly license such as the BSD license were used. (The ability of developers to reuse BSD licensed code without "giving away the farm" is responsible for the standardization of the TCP/IP protocol -- and, in turn, for the success of the Internet.)
As developers, we must consider the long term results of our actions and the effects they have in the real world (in which, whether we like it or not, self-interest has an important role to play). If we remain sheltered, we will make bad decisions. Sad to say, I think that stamping the GPL on yet another major work is exactly this sort of bad decision.
There is probably still a short period of time in which the leaders of the project can save the day by licensing the code under a BSD-style license rather than the GPL, and I would urge them to do that. If they would like to see their ideas propagate, become standard, and benefit the largest possible number of people, this is by far the best course of action. There is no downside; projects with BSD-like licenses, including Apache and FreeBSD, have ample numbers of developers. And the upside is fantastic. If the developers of EROS are reading this list, and care about the future of their code and of the software world in general, I urge them to make it so.
--Brett Glass
The concept of "root" doesn't exist in capability based computers for ultra high security levels at A and B. Presently, no ones ever developed an OS that meets security level A. The reason is is because at this level it is more paper than s/w and centers around Security Threat risks. There have been actual hardware computers built around descriptor-based capabilities vs. what we have now as address-based capabilities. This will be the direction Linux will have to take to get into lets say Banking and "Trusted" systems and to achieve the different levels of the Orange book levels to be certified.
The way this works in EROS, is that you would have another object whose purpose is just to take your capability invocation and forward it to whatever process is actually going to do the work.
That forwarder, BTW, can also do tricks like send all invocations to both version A and version B, so that a voting module can watch for deviations in behaviour.
Check out Norm Hardy's paper on the "factory" object, which you should be able to find somewhere in the KeyKOS material on the www.eros-os.org web site.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
> Most of us use Linux because it works, I hope, not because it's not what the status quo uses.
This has truth, but am I correct in stating that much of the city of Linux was built with bricks forged in the desire to develop a great idea into a working idea?
Programmers are like those of us who play with Lego blocks. They start with a notion of what to build, work it into a finished model... it is zoomed around the room with engine noises, then sits briefly on the shelf, and then the pieces are turned to another idea shortly afterwards. The point is the development of the bold new idea.
There are indeed those who try simply to be counter-culture and grasp at a new OS for the sake of being such. There are also those who grasp a new OS for the intellectual pursuit of making it work. The latter sort are for whom this article is posted, yes?
A digital picture is worth 0x01F4 dwords. - Jessie Tracer / Electric Keet
Like four years now. Its one of the things that might actually motivate me to finish my CS degree or at least take an OS class. This OS I really like.
~ ^~~~^~~^~
But I see two things really. The first works off of a comment someone told me when I was shouting that 1.0 came out. He said "Linux getting a little usable and featured for you?"
I see two reasons to get excited about this, one is that the design is new and exciting, the other is the chance to pioneer.
The names in Linux are pretty set in infamy. And they should be they've earned it. But some of us are wanting to do a little pioneering of our own. I think of "Support Your Local Sheriff on this one"
sherrif: "I'm going to Australia, last of the frontier to do a little pioneering."
Town Father:"I thought this was frontier and we was pioneers."
Its a real land of opportunity for people who already feel a little population pressure in Linux.
And the OS design is just great enough to be a real opportunity. Some real avanues to invent some real interesting possibilities.
^~~^~^^~~^~^~^~^^~^^~^~^~~^^^~^^~
If your system was powered down in the middle of a database update after reboot the update continued, where it was interrupted. No DB curruption!
L3's persistence implementaiton was based on two 'lazy' copies of the virtual memory. One of a consisten state and the ther one was the working copy. That is the first time you change a memory page, it is copied. The after a fixed interval, an new lazy copy of working memory becomes the new 'consisten' state copy.
My question to the public is wouldn't this be a desirable thing to have in Linux? And the question do the developers does that seem a hard thing to implement?
It seems like a simple concept. But there seems to be a huge pile of implications for the kernel drivers. A process might even be in a system call when the system wakes up again.
I am verry ecited to hear your comments.
Uli Luckas
Anything that's as hard to install as Linux 0.02 is going to be damn good!!!
Cupid is the Roman name for the Greek god Eros.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
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 :)
--
telnet www.eros-os.org
Trying 158.130.6.119...
Connected to www.eros-os.org.
Escape character is '^]'.
Red Hat Linux release 4.2 (Biltmore)
Kernel 2.0.30 on an i586
login:
---
Spot the mistake here. Talk about old huh? I hope they upgrade before attackers get to them..
Ohh well
- Yiango
we also get a lot of 'sweet lovin' words from the greek god eros.
-erotic
-eroticism
--
rJames.org - illustration
It's possible to build a UNIX environment that runs on top of EROS, and we intend to do so. That environment will run both conventional UNIX binaries and will also be able to access EROS-based services.
In fact, it will be possible to run multiple UNIX environments at once. If desired, each user can be given a UNIX system that they fully control and adminster, without compromising the security of the other UNIX environments on the machine.
Soon, I too can have a Beowulf cluster...Three words for your ingrate carcass: fast, stable, and organized. I could care less about being some limp dicked rebel geek.
In practical terms, there isn't must difference between B3 & A1, they have the same security setup, but A1 has been formally proven to be secure, while that's not a requirement for B3. However, I'm pretty sure that most B3 systems have been formally proven, just not in the documentation & verbosity to get certified for A1.
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.
offtopic and stupid.
offtopic and stupid...
Anyone can now take EROS and add features to it, but they can't use those added features to gain a competitive advantage over EROS's creator, because he has access to the same source code that they use. This is an especially important trump-card if a company with deep pockets decides that they like EROS, but they don't like it enough to give its creator a piece of their action.
I agree that BSD-style licenses have a practical value when it comes to networking standards, and one could argue that the BSD is more altruistic than the GPL. However, if you don't want other people to prosper from your code at your expense, and both the proprietary route and a Mozilla-style license have failed to get you the financial benefits you hoped for, then the GPL is a better fallback position than the BSD. (I think this is why Red Hat puts all the software it writes under the GPL.)
send all spam to theotherwhitemeat@ropine.com
If you're looking for an alternative operating system that will probably never have the problem of being too mass market, then consider OS/2. Yeah, it's not open source, but there's quite a bit of source code and easily-expandable published interfaces for it. Plus, almost every Unix/Linux app will compile under it with only minor changes.
And the men who hold high places must be the ones who start
To mold a new reality... closer to the heart
SMP is decidedly unsexy in a lot of ways, but it's _hard_ to do right and in a sane way. One of the reasons I like BeOS is because not only does it have fine-grained SMP, but it also encourages - nay, requires - threading in all sorts of places, thus vastly boosting the benefits of having multiple processors.
When we hit the limits of Moore's law, we'll _have_ to scale to more processors - and then SMP will be horribly important to even casual users.
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.
Don't worry; you can always deallocate all the storage that a process is using (by deleting its space bank), and obviously it won't be able to continue running. Also, whenever you start a new process, the system gives you a capability to that process. You can then use that capability to kill the process if you want. Just make sure you don't lose it!
Disclaimer: I'm not an EROS hacker, so this is all AFAIK.
Unfortunately you have to keep most of the serialization code if you wish to communicate, browse the Web... And communications are even less reliable than file systems.
...the line between the filesystem and memory seems nonexistant...
Actually, as far as the EROS kernal is concerned, thre is no such thing as a "file", in the sense of something with a name, that lives on the disk, etc.
There are pages, and ranges, and domains, but basically it's all VM. None of the "copy from the disk to kernal memory, copy from kernal memory to userland, etc. All memory access is page faults.
Now, if you want to set up a program that does what a conventional file system does, you can, but that's not something that concerns the Kernal.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
>Chris
This conecpt has been implemented before in L3.
Uli Luckas
Oh, you have the same limit on linux, but you can hold extra data in files.
Wouldn't that render the whole thing useless for fullblown database servers?
Uli Luckas
The L3 URL should have read: http://os.inf.tu-dresden.de/L4/l3.html
Honestly, I don't see this going anywhere. For people who want a more innovative OS I recomend Squeak running on top of Linux kernel. I think that Smalltalk basicly perfected object orientation, after all they are the people who invented it!
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!
For some, this may be an inane question, but wth is orthogonal persistance. I was a mathematics major but I do not understand the concept of orthogonality in this context.
Where exactly does it say it is realtime?
Microkernel, I think, though.
P.
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."
The as/400 is a very cold, dark thing, best stayed away from. Although full of some good ideas, many old bad ideas remain(from it's system 38 roots). It is not sexy like unix, not good for hacking on and it is the pinnacle of proprietary, high price tagged, old IBM way of doing things. Using one is like being chained to an iron maiden day in and day out. It's primary language(RPG) is decadant and a perfect match for the operating system it runs on. Stay away, you have been warned.
Joe Rice
jlrice@crosswinds.net
Strange you'd mentioned it, I browsed their mailing list archive a couple of days ago and mr. Shapiro wrote something on just this subject...
. html
http://www.eros-os.org/~majordomo/cap-talk/0116
Strange you'd mentioned it, I browsed their mailing list archive a couple of days ago and mr. Shapiro wrote something on just this subject... http://www.eros-os.org/~majordomo/cap-talk/0116.ht ml
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!
These OS's all sound neat... not just EROS either, but also the Nemesis mentioned and ExoKernel that I've read of before.
Unfortunately, there still seems to be a bit of confusion about how to introduce a bit of nifty tech. What I wanted to know, from reading all these wonderful releases of info and such, was, "What difference this will make to my computing experience, should I try one of these new OS's?"
Now you don't have to mention it - it is a callous and greedy thing to say, I realize that. But frankly, isn't this what it all comes down to? What good is it for you on the desktop if it can't run a web browser, the GNU tools, art programs, etc? At least EROS mentioned, albiet with a great deal of obscurity, that they would be supporting UNIX binaries - which is a good thing. But when these babies are ready for public consumption, let us know what they can do for us as well... not just what we can do for them.
Ah well. I'm not coder, so I probably don't have any right making these spurious and trite observations. Flames, commence!
Know ye not that ye are Gods???
It was released several months ago, but under a different license. I got the impression that the main author was not keen on free software, but he seems to have changed his mind.
P.
Smaller and simpler, sure. But, then, you can do that today just by calling mmap() on the database under most Unix systems. What you lose in this design is control. The database software probably has a better picture of what it's going to access, and in what order than does the OS's generic VM/buffer cache. Because it knows this, it can schedule reads and writes much more efficiently (at least in theory) than the OS could. (That's why a number of database engines support a "raw device" mode which bypasses the OS and filesystem altogether.)
This brings up an interesting, related point: Real-time programming has got to be more difficult in such a machine, unless there's a set of APIs (and associated capabilities) for ensuring a set of objects is in memory at a particular time. Otherwise, you have little control over when you fetch data from disk, because as an object, you don't see the disk -- it's abstracted away.
--Joe--
Program Intellivision!
Under EROS, you could have multiple instances of the Linux kernal running, and automatically watch for differences in their behaviour.
Imagine if you're writing a driver, and you could do A/B comparisons between versions of your code, in situ, without restarting the machine.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
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."