On Wed, Oct 26, 2005 at 10:16:47PM +0200, Marcus Brinkmann wrote:
At Wed, 26 Oct 2005 21:32:14 +0200,
Bas Wijnen <address@hidden> wrote:
- security
- capabilities
- persistence
- real time
Marcus: is this the type of input you wanted?
Almost. I have a similar list, but I am not sure it is attacking the
issue at the right angle. Let me explain.
Is persistence a goal? This depends on what you want to do. If you
want to pull the plug from your computer and see the same desktop
before the power outage afterwards, then yes, it seems to be a goal.
However, personally, I don't really have this goal, although it is a
nice bonus.
Agreed. Actually the main two reasons I see persistence as a good thing at
the moment are removing the need for boot scripts (including rebooting to test
if they work as expected), and the fact that they can remove the need for
passive translators.
Here are some other goals you can have: Stability, robustness, Small
memory footprint (for embedded applications), Support for legacy
applications...
The point of this mail is to make a distinction between design goals,
and engineering mechanisms to achieve them.
Ok, so the current list of goals is:
- security (needs to be more specific)
- confinement
- confinement with endogenous verification
- persistance
- small memory footprint
- support for legacy applications
I'd say all of them are nice. :-) But it may be possible that we need to
choose some and drop others.
I think it is very important to separate the two, but we can't make a clear
separation: The design goals dictate the feasible engineering mechanisms.
That doesn't mean they can't be separated. They should be, and it should be
clear which one we talk about. Obviously they are linked, but it should be
clear if something is a goal or a method. I was not making the distinction.
Thank you for saying.
This is why Jonathan wants us to come clear, because only by settling on the
design goals we can settle on the feasible mechanisms to achieve them.
That makes sense.
I think in the end we will be faced with a dilemma: Either we have to accept
the logical consequences of our stated design goals, which may be deep.
This includes removing any paradoxes by dropping some in a set of
conflicting design goals. Or we drop some of our design goals to open up
space for other engineering mechanisms.
What's it gonna be?
Eh... What did you just say? Either we drop some goals so the rest is
possible, or we make the rest possible by dropping some goals? I don't think
I understand the dilemma...
Thanks,
Bas