Re: Niches for the Hurd: evaluation method; was: DRM musings, capabilities and stuff

[olafBuddenhagen]

Hi,

On Thu, Feb 19, 2009 at 11:46:38PM +0100, Michal Suchanek wrote:
> On 23/01/2009, olafBuddenhagen@gmx.net <olafBuddenhagen@gmx.net>
> wrote:

> > Design and feasible use cases are *not* orthogonal in practice.
> 
> They are certainly not. I never said they are.

You did imply it, by repeatedly claiming that all we want to achieve is
possible with Coyotos.

> >  Of course you could hack Coyotos to deny processes from hiding
> >  stuff from their parents. Only that would be a damned stupid thing
> >  to do, as it would completely compromise the security system of
> >  Coyotos, which heavily relies on this property.
> 
> I do not see where it does.

I can't tell you where it does, but it's more or less what Shapiro
claimed himself in the origial discussion.

Anyways, as neither of us seems well informed about that, I guess we
better drop the subject.

> Note that the genode system that you mentioned does use the
> hierarchical security model and still uses DRM memory for services.

I does? So not a good example after all. That's a pity.

> If you think you cannot live without gnome and its supposed
> integration you just port dbus and make use of the system features
> available to make it as secure as possible.

Note that I'm not just talking about running existing GNOME or OpenMoko
stuff, which obviously requires dbus. I'm talking about integrating new
components with the existing framework.

*Of course* one could implement and use dbus, as well as any other
legacy interfaces, to allow integrating new and old components
smoothly... Oh wait, that's precisely what we are doing with the Hurd.

> When you are trying to bring some innovation you cannot do that by
> clinging unquestioningly to any established approach, framework, and
> piece of software.

We aren't. In fact we created a completely new system architecture. And
the system is expressly designed to make it easy to move on and use new
stuff whenever people desire so -- but with the full set of traditional
APIs as starting point. We provide compatibility be default, and the
option to change things; rather than something completely new as
default, and an option to go back and implement compatibility...

This might not be the ideal approach for research work on radically new
ideas. But I'm sure it's the right approach for allowing innovation,
while providing a system useful in the real world.

-antrik-