Re: design goals vs mechanisms (was: Re: Let's do some coding :-)

[Bas Wijnen]

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
- no ACLs
- persistent sessions for users
- hard real time
- soft real time
- stability
- robustness (what's the difference with stability?)
- 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

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://129.125.47.90/e-mail.html

signature.asc
Description: Digital signature