Jonathan S. Shapiro, architect of the EROS persistant operating system announced that he would be putting the project on hold for at least a year. This followed a series of emails describing the mistakes he felt that EROS had made: 1, 2, 3, as well as an email describing what he thought it had done right.He also sent an email to the L4 hackers list, discussing the possibility of unifying the L4 and EROS kernels. The L4 microkernel has extremely high IPC performance and low context switch time. Several implementations of L4 exist, and the HURD expects to eventually replace their aging Mach kernel with L4. More emails and discussion are expected over the L4 list.
EROS Sleeps; L4/EROS Unity the Future?
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
from Jonathan’s e-mail I got the idea that EROS was largely an academic OS, with lots of unexplored concepts (and very good ones at that). Sure, the first try was a failing try, but the second try must be good.
The Eros project seems to have shifted course as a matter of habit over the years, the great C rewrite, the shift to a microkernel design, the change to focus on embedded systems. Meanwhile, there was never a real application available for this kernel, or even an easy way to test install it. I think even if the design has flaws, it would be best to get a running system to show for all the hard work that went into it. Not everything can be perfect.
What a waste of coding hours. He should have studied OS design for a longer period of time before rushing into coding/hacking and creating these serious design errors. These errors are nothing new… people have written papers about them for a while. Modern soft. eng. methodologies would have helped this project immensely. He should have started with an open spec which so that people can comment on it and point obvious pitfalls before even a single line of code has been written.
Anyway, I hope this is not too harsh as I’m not trying to slam anyone but just pointing to any future lad a way to do it properly.
Nick,
Come one now, even if he had read such things its hard to say if it would have effected his design. People write about why things are bad ideas all the time. And the fuels others to push into the idea and find a way to make it work, or find good in it.
Furthermore, I’m sure he learned a whole hell of a lot from doing what he did. Much more then if he just read about stuff. And now he will go on and do even more. I think much of this is a great learning experiance and far better then just reading or drawing a hypothetical OS out on paper. Someone out there is bound to learn from his work to.
I hate hearing that research in OS’s is done, I hear that a lot and it’s so silly. The way they work could be very differnt in 20-30 years. We might be looking back at UNIX and thinking how totaly wacky it was. There is many ways I can see OS’s working that I have never seen done. Maybe there is a reason, maybe no one has gone there.
I think projects that are much more experimental and wacky are better then projects that want to follow paths allready done. I don’t think he ever intended this to be an OS of mass use, or even much use at all, as are many such OS’s. They are just to learn. Someday these people, often students can go on to Apple and MS and use their experiance in great ways.
He should have studied OS design for a longer period of time before rushing into coding/hacking and creating these serious design errors.
Having casually followed EROS development for a while now, as well as studied the KeyKOS, I feel fairly certain that Shapiro didn’t just rush into coding/hacking. In fact, academics rarely do.
It seems more like the problems that EROS encountered are the problems of excessive academic research and design. UNIX evolved from the ideas of bright, knowledgeable people operating from the standpoint of engineers. EROS was much more in the academic vein – build a “perfect” platform, which results in lots of complications at ring 0, which I think is the real failing of EROS, and the three ideas mentioned here are just symptoms of that.
I had briefly looked at EROS a long time ago, and the concepts it was investigating looked very interesting, stuff that hadn’t been implemented anywhere else. As it is only ‘on hold’ and not abandoned, I think it still holds great promise in exploring advanced topics in the OS field. There is nothing wrong with having a rest, it can provide clarity by stepping back a notch, and also some people just get ”burnout” from working on one project constantly, so it might go some ways to rejuvanating the project once it does resume development.
Is anyone here knowledegable about L4? What properties of the kernel give it fast context switching (does it have a co-operative model as an option to application writers)?
We might be looking back at UNIX and thinking how totaly wacky it was.
What? I’ve always thought that.
L4 has fast IPC not, context switching.
L4’s fast(short) IPC its done using a randevou model where the receiver suspends execution while waiting, the sender stores the message into registers and context switches to the receiver eliminating any vm subsystem operations and hence the speed.
so the applications have to cooperate no way of doing it otherwise.
that’s all, 8 comments? nobody mentioned the ideas behind eros and keykos…?