[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Niches for the Hurd: evaluation method; was: DRM musings, capabilit
Re: Niches for the Hurd: evaluation method; was: DRM musings, capabilities and stuff
Mon, 23 Feb 2009 11:20:58 +0100
> On Thu, Feb 19, 2009 at 11:46:38PM +0100, Michal Suchanek wrote:
>> On 23/01/2009, olafBuddenhagen@gmx.net <olafBuddenhagen@gmx.net>
>> > 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.
That's because I think that the design of the Coyotos core is similar
enough and flexible enough.
Not because I think it is practically feasible to implement anything
on top of everything.
>> 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.
Well, perhaps it's a practical way of handling resource allocation for
services so it emerges naturally on systems that care about such
But if you can come up with another way it sure would be interesting.
>> 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.
Good luck attracting new users then.