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

[olafBuddenhagen]

Hi,

On Tue, Jan 13, 2009 at 01:44:59PM +0100, Michal Suchanek wrote:
> 2009/1/13  <olafBuddenhagen@gmx.net>:
> > On Fri, Jan 09, 2009 at 06:22:27PM +0100, Michal Suchanek wrote:

> > I'm not saying it is impossible to do for a really dedicated person.
> > But surely you don't want to claim that this is equivalent in
> > practice to a system where the user running an application has full
> > control over it in the first place?
> 
> And again the full control is most likely a matter of configuration,
> not the system in question.
> 
> You might not allow any application to use memory you cannot access.

And again, you are wrong. Design and feasible use cases are *not*
orthogonal in practice.

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.

You can't just change a fundamental property and still have a functional
system. All services need to be designed in a completely different
manner, to work in the hierarchical security model we are proposing.

> If that is practically feasible on the actual Coyotos implementation
> remains to be seen when such implementation is available.

No need to wait. AIUI the Coyotos design is almost identical to the EROS
one. Just check what is possible there, and you know your answer.

> And I do not think that the Coyotos design is perfect or the only
> possible. It's just far better in some respects than the current POSIX
> and POSIX-like systems.

And far worse in others...

> If you do not know any functionality that is actually forsaken here
> either then there might be no reason to stick to dbus at all.

Who says I don't? And how is it relevant whether *I* know of specific
dbus use cases?

I feel neither entitled nor inclined to discuss the merits of dbus. It
is totally beside the point. Merited or not, GNOME and OpenMoko and
others are using it extensively for interaction between components, and
thus integrating anything properly in these environments requires using
dbus. How hard is it to understand that?

> >> If you went on the "i do not need this but I imagine that somebody,
> >> somewhere might at some time ..." then you would include every
> >> function possible in every piece of software, and every piece of
> >> software would be an operating system on its own right with
> >> everything including the kitchen sink already packed in.
> >
> > The point is precisely *not* to implement all possible system
> > functionality in each single application, but rather to integrate
> > applications with each other, so existing functionality can be
> > reused in all kinds of situations.
> 
> But we are talking about adding (porting versus not porting) dbus
> here, not about application integration.

I don't know what *you* are talking about. *I* am talking about the fact
that interacting with existing components requires using existing
interfaces.

I merely pointed out -- as you brought this up -- that integrating
existing components is not bloat, but a remedy against it.

> > So you agree that it's possible to improve things, without forsaking
> > existing interfaces :-)
> 
> However, our position fundamentally differs in that you want a system
> built around legacy interfaces but I want a system with simple and
> clean interface that is powerful enough to express the deprecated
> legacy interfaces as compatibility layers when applications need them
> or abandoning them if they are no longer necessary.

Indeed, the difference is that we consider good support for existing
software and existing approaches a must, and anything beyond that a
bonus -- not the other way around.

-antrik-