This is interesting. I find that I don't agree with Theo, though I think I understand where he is coming from and I suspect that in the end we will all agree completely.
The part I disagree with is the assertion that any operating system that chooses to implement a posix mode is fundamentally doomed to inherit all the security vulnerabilities that are inherent in the design of posix.
It is true that any POSIX program in such a system inherits the vulnerabilities of POSIX. It does not follow that the system as a whole inherits those vulnerabilities, because it is possible to run an entire POSIX system within a security box. Inside the box you have all the problems of POSIX, but *only* inside the box. You can then selectively migrate server applications to native mode.
These leaves two issues:
I guess that at some level my response to (1) is that people can implement cruddy clients anywhere. We can create a runtime environment in which it is easier to implement good clients, and this is a deceptively powerful fact. Witness that MS has made component programming real by facilitating ActiveX/COM objects. Whatever the flaws of COM, MS *has* successfully altered the way people build applications by facilitating a desired style of app building.
That said, we can't force programmers to write correct code -- or even to *want* to write correct code.
My response to (2) is that Darwinism is a beautiful thing, and that people who don't migrate mission-critical code out of POSIX are a short-term and self-limiting problem.
If you buy this somewhat tongue-in-cheek reasoning, then there is still one further problem, which I tend to think of as "the Mach fallacy" [this labeling is probably uncharitable on my part, and I'ld appreciate a new label]. The Mach fallacy goes like this:
Step one: build a potentially interesting new sysem. Step two: build a compatibility environment Step three: tell people that the main purpose of your new system is to run this compatibility environment really well. Step four: observe that nobody ever really explores the richness of the original system.
I am hopeful that we can prevent this cycle in step three by telling people that we have a compatibility environment but that it's use is deprecated and the system exists for building serious applications in native mode for the sake of higher reliability and security.
I could be wrong about this strategy. It's certainly tempting to punt POSIX. The problem is that the argument Kragen has made about the ease of installing the EROS kernel applies equally to the ease of getting user applications running. I believe that over time we'll replace those applications, but we need to live long enough to let that happen.
My personal compromise is to say: "let's get a compatibility solution limping along so that there is enough there to use and then focus the research on how to use the native system."
Will this work? Remains to be seen.
Sounds like we should sign Theo up to work on EROS, though... :-)
shap