EROS 1.1 relased under GPL 143
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.
Re:_|_ persistance?? (Score:1)
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.
Please... (Score:1)
Re: (Score:1)
Funding from DARPA (Score:1)
I think my observation here is that conspiracy theories are usually oversubscribed.
Re:No root... Credential downward spiral? (Score:1)
See my answer about killing programs, as that is also relevant.
Re:Don't Panic(tm) (Score:1)
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).
Re:Realtime? (Score:1)
This is a case of drift between the web site and what has so far been completed.
Re:Double-edged sword. (Score:1)
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.
Re:One of the coolest things about EROS: persisten (Score:1)
Re:One of the coolest things about EROS: persisten (Score:1)
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.
Re:Licensing terms (Score:1)
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.
Off-topic Eros Meaning (Score:1)
Re:Orthogonal Persistence, AS/400 and the Web (Score:1)
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?
Re:Realtime? (Score:1)
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.
Re: (Score:1)
Re: (Score:2)
Re:Realtime? (Score:1)
Heh. (Score:2)
I imagine OS/2 will start to see better sales.
- A.P.
--
"One World, one Web, one Program" - Microsoft promotional ad
Linux trustees project? (Score:1)
Quality of Service (Score:2)
Re:how do you upgrade persistent objects? (Score:1)
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.
Old News (Score:1)
Quick! (Score:2)
We're becoming too popular! Jump ship now, before it's too late! Don't risk assimilation! Argh...
Linux Capabilities FAQ 0.1 (Score:1)
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.
Re:cupid? (Score:1)
I'm Uncomfortable With This... (Score:4)
EROS looks like an excellent foundation for, as an example, an electronic funds transfer system, where you absolutely do not want errant/hostile code running around in the system. However, I'm not sure about its utility on more "traditional" desktop systems.
The EROS FAQ mentions that there is no such thing as 'root'; there is no user who has total authority. This is a double-edged sword. While the absence of root makes compromising a system difficult (since there's no Obvious Target to gain access to), it also prevents a legitimate user from manipulating or killing processes that simply refuse to grant the capability.
The scenario I'm envisioning here is an EROS-based Web Terminal. An unethical vendor could supply a terminal which, among other things, transmits your bookmarks and passwords to a central database to be analyzed and resold to telemarketroids. (Or, insert your favorite Dark Scenario here.) In an EROS-based system, there would be no way for a user to Do The UNIX Thing and kill the offending process.
Perhaps it's just my Type-A personality, but I find I'm uncomfortable with the idea of a program or system that could potentially refuse to do what I want, just because some $(EXPLETIVE) programmer thought it was none of my business.
Schwab
eCos vs. EROS (Score:2)
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.
Realtime free OS (Score:2)
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.
Comment removed (Score:4)
Re: (Score:1)
I've been net nannied! (Score:3)
I can't access the er*os-os site! Dumb filtering software.
Re: (Score:1)
Not only that, but.. (Score:1)
..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
Bad comparison spotted again :) (Score:1)
Bit rot (Score:1)
"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 [upenn.edu] (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.
----
Re:Disk Mirroring in EROS. (Score:1)
Re:I'm Uncomfortable With This... (Score:1)
This research was supported by DARPA under Contracts #N66001-96-C-852,
#MDA972-95-1-0013, and #DABT63-95-C-0073. Additional support was provided
by the AT&T Foundation, and the Hewlett-Packard, Tandem Computer, and Intel
Corporations.
Re:Double-edged sword. (Score:1)
The point of a capability model (Score:1)
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
Licensing terms (Score:2)
- 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...
Re:Orthogonal Persistance (Score:1)
Re:Think of what this can mean to kernal developme (Score:1)
--
"I was a fool to think I could dream as a normal man."
B. B. Buick
Re:I've been net nannied! (Score:1)
Why I am not a moderator when I would like to be ?
Moderator, please moderate the precedent post as funny (or sad if you are this poor guy)
What do HURD guys think about EROS ? (Score:1)
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.
Re:One of the coolest things about EROS: persisten (Score:1)
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.
Re:System info (Score:1)
Re:Disk Mirroring in EROS. (Score:2)
Another nice feature is that nearly ALL disk access is sequential (when the transaction log is comitted, the writes are ordered so that the head basically sweeps across the disk, ending up at the beginning of the log area. VERY NICE.
Re:An end to viruses. -- Unix has no viruses. (Score:1)
Re:General Purpose Versus Embedded Servers (Score:2)
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.
What about the HURD? (Score:1)
HURD is admittedly not very advanced, but it is still more so than EROS right now.
I love the concept but... (Score:2)
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.
how do you upgrade persistent objects? (Score:2)
Gotta Start Somewhere (Score:2)
And if we want to accomplish anything with the new system any time soon, what are we to do?
UNIX [hex.net] 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
Re:General Purpose Versus Embedded Servers (Score:1)
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.
Re:Please... (Score:1)
What does X11 need root access for besides changing video modes?
As I understand it, on EROS you would just give X11 the capability to write the video hardware and use the network.
Assuming the kernel can grant that capability, of course...
As for wanting X11, EROS may actually have its own GUI, as the release notes mention that it does not _yet_ have a bitmapped interface and support is planned for Mach64 cards, along with some others.
In that case, X would probably work somewhat like the fbcon driver currently does: just make calls to the kernel driver.
A UNIX Environmont atop EROS (Score:2)
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.
General Purpose Versus Embedded Servers (Score:3)
The key to making EROS useful to people running Linux would be to build a "GNU System" atop EROS, parallelling building a "GNU System" atop the Linux kernel.
(Note that I usually call "systems based on the Linux kernel" by the moniker Linux; the use of the RMS term happens to be usefully descriptive here; I'm not trying to do any politically-motivated Newsspeak here.)
I would tend to think that the Debian [debian.org] folks would be the most prepared to create an overall system atop EROS, as they have both
The major alternative that, based on the deployment of predecessor systems like KeyKOS, [upenn.edu] is likely to take place quite a bit, is that EROS might instead be largely used to construct "somewhat embedded systems" rather than the general purpose system that comes from installing the typical Linux distribution.
This might include:
Which would parallel what Oracle has been working on with the "Raw Iron" Oracle 8i Appliance [oracle.com]
I'd kind of like to see both approaches, as that is the most likely way for EROS to become more widely used.
Re:General Purpose Versus Embedded Servers (Score:1)
Semi-serious point, anyway. It occurred to me that there are one or two applications out there where
(a) the distinction between RAM and disk is blurry, to say the least
(b) things stay in a running or runnable state between power-cycles.
I've acquired Zipdisks; Eros is going home tonight to be played with
Re: (Score:1)
Re:System info (Score:1)
- Sam
high-level languages on EROS? (Score:1)
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.... :-)
Re:Orthogonal Persistance (Score:2)
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.
Re: (Score:1)
Still time to consider a still better option (Score:1)
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
Needed for Orange Book Security to get A,B,C Level (Score:1)
Re:General Purpose Versus Embedded Servers (Score:2)
Re: (Score:1)
Re:Yes, but those people are shallow. (Score:1)
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?
Ive been excited about this OS for a while (Score:1)
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.
^~~^~^^~~^~^~^~^^~^^~^~^~~^^^~^^~
Re:Basically, you use a stand-in. (Score:1)
Persistence in Linux? (Score:1)
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
Re: I'm Uncomfortable With This... (Score:5)
EROS has no concept of root because the kernel has no concept of a user at all. In a capability-based OS with POSIX, users are part of the executive (or the Hird of Unix-Replacing Daemons). There's no reason why the executive can't implement a root user, i.e. one with the capability to do anything.
One benefit of using capabilities rather than users and groups is that it's possible to restrict your own access. Suppose I want to run a program which I don't necessarily trust. I can drop myself into a "sub-user" with all my previous permissions, except that I have no rights to write to the file system, and run it safe in the knowledge that nothing is going to be trashed. Just like chroot() only much more flexible.
Re:I'm Uncomfortable With This... (Score:1)
People like the pentagon and the CIA and the NSA and the FBI need to have computer systems that people can access, but they can't allow their people to give away information to others. They CANNOT allow Bob to give away his access to secret data to some other user on the system.
Anyway, where do you think the research money for this came from? My guess is DARPA, the Defense Advanced ResearchProjects Agency.
Crypt.x
Orthogonal Persistance (Score:4)
Most of the other things people are doing are boring at best. SMP? Anything but new -- so you stick a few more processors in a box. Security? Capabilities are definately the right way to do stuff (EROS uses them), but they don't change computers that much. They just fine tune and generalize security, and would allow information to be more easily shared -- plus getting rid of all the dumb sandbox efforts -- but they wouldn't change what computing meant.
Microkernels were only really important on the implementation side, even if they were to have succeded. Distributed computing is still a long way off in any meaningful manner -- resource farms aren't too interesting. I can't think of much really exciting... maybe OO, CORBA, and the like have some interesting possibilities in extending the basic infrastructure on a computer.
Orthogonal persistance doesn't seem all that interesting -- persistance already exists, after all, but you just have to explicitly save (in an app), or open a file (from code). But when persistance comes for free everything is just so much easier -- and making it easier to program stuff really is important. Objects become something tangible, not attached to a process or a session. If you added OS-level garbage collection then you'd have something really powerful. Objects would finally subsume processes and algorithms and the computer would be an environment instead of a machine.
My head is in the clouds at the moment, excuse me. Anyway, if you feel like reading other clouded thoughts on OS design (none of it by me), you might be interested in the all-talk TUNES [tunes.org] OS. Less code makes room for more talk! But you got to give them credit, at least they don't pretend to be anything but what they are :)
System info (Score:1)
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
Re:Quick! (Score:1)
Same thing with a lot of linux users: they used it because it set them apart from the crowd. Now? "Linux has sold out."
Hot d*mn! (Score:1)
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...Re:Licensing terms (Score:1)
The guy clearly feels strongly enough about his project to put teetering on seven figures into it so maybe he was 'forced' into GPL-ing it in order to get some of the Open Source crowd in to help and make it work. He doesn't want to see his baby fail so he bit the bullet that would get more people involved. And it worked too - I bet he gets at least one contributor on the basis of the /. article alone.
Re:Needed for Orange Book Security to get A,B,C Le (Score:1)
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.
Re:One of the coolest things about EROS: persisten (Score:2)
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.
the selfish case for the GPL (Score:1)
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.)
Linux too mass market? Then try OS/2! (Score:1)
SMP is unsexy but important (Score:1)
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.
Re:Any GUI for EROS (Score:2)
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).
Re: (Score:1)
Re: (Score:1)
Not really new (Score:1)
>Chris
This conecpt has been implemented before in L3 [tu-dresden.de].
Uli Luckas
Re:One of the coolest things about EROS: persisten (Score:1)
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
L3 URL: http://os.inf.tu-dresden.de/L4/l3.html (Score:1)
Squeak (Score:1)
Comment removed (Score:3)
Yes, but those people are shallow. (Score:2)
--
"One World, one Web, one Program" - Microsoft promotional ad
Comment removed (Score:3)
No root... Credential downward spiral? (Score:3)
One interesting aspect of EROS' model is that the line between the filesystem and memory seems nonexistant. RAM is merely a cache for objects, and the "state of the universe" is held on the HD. Everything's an object, and the system embodies the continual evolution of those objects. (If I misunderstood, someone please correct me.)
What's interesting about this model is that there is no clear beginning, end, or reboot, just as there isn't any clear concept of a "user" or anything else. The whole system is a collection of objects that are interacting with each other in various ways.
Unless I've missed something, this could lead to an interesting problem wherein the existing pool of objects lacks sufficient capabilities to continue to function. Since the whole system is persistent, how do you recover?
If there is a means to "restart" the system (and bring the system back to a reasonable continuum of objects), how is access to this mechanism controlled? Can you accidentally drop the capability to invoke the "restart"? I don't count the Big Red Button as a reasonable answer for restarting the system...
--Joe--
Re: (Score:2)
Re:Linux too mass market? Then try OS/2! (Score:1)
Get IBM to OpenSource OS/2
Re:Double-edged sword. (Score:2)
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--
Re:Realtime? (Score:1)
Raw access to resources is a speed concern, not a real-time concern. If there is a guaranteed maximum time that you have to wait between sending data to the serial port and it arriving, then that is a real-time operation, no matter how long that guaranteed time is.
Of course, speed will probably make the difference between choosing one real-time system over another, but it's the guarantee which makes the system real-time, not the speed.
Re:_|_ persistance?? (Score:4)
The idea is that the mechanisms that make a program persistent are orthogonal to the mechanisms that let the program do whatever it actually does. No file writes (no files, yeah!), no "save to disk", none of that. The program runs under the illusion that it is running on a 100% non-stop machine, regardless of actual stoppages of the underlying hardware.
Some installations of EROS' predecessor, KeyKOS, have had processes running literally for years, in the face not only of hardware failures but in some cases complete replacements of the underlying hardware with newer generation machines. The only reason EROS can't make this claim is that it hasn't been around long enough to accumulate the track record!
Re:Orthogonal Persistence, AS/400 and the Web (Score:2)
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."