[cap-talk] Gnu Hurd status? Power box?

[Jed Donnelley]

On 3/20/2008 1:15 PM, Pierre THIERRY wrote:
> Scribit Jed Donnelley dies 20/03/2008 hora 10:23:
>> R.e. "the effort seems stalled" - what is driving (or not) the Hurd
>> development?

> Beware that here we are talking about two quite different projects.

Thanks Pierre.  Very helpful.

> First, there is the Hurd as it exists currently. It is an operating
> system that is in use today, albeit not in critical installations.
> Between Linux and the BSDs, and probably also because of its performance
> shortcomings, it has not seen many contributions for years. The
> development effort was somewhat stalled, although it is intereseting to
> see that in the last two years, it is having a second youth by the
> arrival of new contributors that have been dedicated in getting Hurd
> development to a higher pace.
> 
> But the Hurd as it is is based on a rather old µ-kernel, Mach, that
> predates many optimisations in IPC design, which makes Hurd pale in
> comparison of any other OS, monolithic or not, when it comes to speed
> and reactivity.

Of course some would argue that such performance problems are
inherent in µ-kernel approaches to OS development, but I hope
its clear that, while I've done considerable work in that
space (optimizing a µ-kernel-based system), I don't agree with
that position (again from my own work where we succeeded in
reducing the µ-kernel induced overhead to negligible levels).

> So there has been an effort to port the current Hurd to L4, but this
> effort led its developers to discover a number of shortcomings in the
> architecture of the Hurd, including in its security.

I'm curious to know what the basic problem was.  Have any pointers?

> In the last
> discussions about a possible next generation Hurd, they seemed decided
> to go with a capability-based design with persistence. But the
> mailing-list of this sub-project has been mostly silent for months.
> 
> Note the the current Hurd is not a capability-based system, although
> Mach may support that kind of architecture. The Hurd is interesting in
> the fact that it strives to overcome many of the shortcomings of Unix
> WRT to flexibility. For example, you don't have mount points that only
> the root user can deal with, but arbitrary processes can be plugged in
> the FS wherever a user has write permissions. Also, the Hurd is using
> Debian's infrastructure, and thousands of Debian packages are built for
> the Hurd. To ease access to the Hurd, there even is a pre-packaged disk
> image of a runnable Hurd system, that you can use with QEMU or
> Virtualbox, or convert to a VMWare image.

thanks again.

When you say "the current Hurd is not a capability-based system"
do you mean that none of the APIs that it makes available provide
visibility for the base Mach IPC mechanism?  If so, isn't this
approach somewhat inevitable in that any API other than something
Posix compatible would have few to no applications to use it?

In this regard I find it interesting to speculate about the possibility
of a "portable" Power Box implementation.  Any such Power Box
implementation seems to me to have two essential interfaces
to deal with:

A.  The user interface - where it accepts commands in the form
of mouse/pointer movements and clicks and possible textual
input and interprets these in terms of designating POLA
application execution, and

B.  The application interface where it must deal with
delegating specified POLA access to programs that it runs
on the user's behalf (besides managing and communicating
program status).

I know I didn't get much traction last time I mentioned
something like the above ("caplib"), but I thought I'd split
it up a bit and try again ;-)

If the Hurd was to ever to benefit in the sense of POLA
for user level applications from an underlying µ-kernel
then it seems that it too would require a Power Box
implementation.  Doesn't it seem natural to want to
leverage one of the existing implementations?

--Jed  http://www.webstart.com/jed/