Re: A niche for the Hurd - next step: reality check

[olafBuddenhagen]

Hi,

On Thu, Nov 20, 2008 at 11:24:42PM +0100, Michal Suchanek wrote:
> 2008/11/20 <olafBuddenhagen@gmx.net>
> > On Thu, Nov 13, 2008 at 11:17:29PM +0100, Michal Suchanek wrote:

> > Things are much more complicated in reality; but conceptually, UIDs
> > on Hurd can be regarded more or less as directory capabilities,
> > giving access to a set of other, more specific capabilities.
[...]
> > This is what the Hurd is all about, what I like it for: It opens new
> > possibilities the users can take advantage of, but without forcing
> > them; without throwing the familiar UNIX environment overboard
> > entirely.

> Yes, the Hurd is based on Mach which implements ports - capabilities
> but hides this under the POSIX interface.

I'm not sure "hide" is the right word here... It doesn't immediately
confront the user with the internals, but direct use of the advances
possibilities resulting from them is encouraged.

> In my view saying "this is like posix but it's really capabilities,
> and you can do this, that and even more now" is much harder for the
> users than saying "our system is based on capabilities, and these work
> like this".

This might sound alluring in theory, but it just doesn't work in
practice. The truth is that people are *much* more comfortable with
moving to something that looks familiar than to something completely
new.

Often this is objectively justifiable, as the migration costs can easily
outweigh the benefits from the better but less familiar solution. But
even in cases where the more radical approch is objectively better in
the long run, most people will still prefer the more familiar one. This
is simple psychology -- you can't win against that.

A short glance at history should convince you that inertia is the
strongest ruling force by far in the computer industry. If you want to
have *any* chance of people adapting something new, you have to make the
barriers as low as realistically possible.

> Note that even POSIX has the UNIX permissions, ACLs, and Windows which
> are somewhat POSIX-like have ordered ACLs. Still most users will only
> want a GUI dialog which allows them to share a file with another user
> and are not interested in the internals of the system. These are
> important for the software developers and administrators, not users.

You are perfectly right: To the average end user, who just clicks around
in his GUI, the use or not-use of capabilities is hardly noticable.
(Except that all existing software needs to be adapted...)

However, this is not really relevant to the Hurd. As I pointed out in
another subthread, the Hurd is a volunteer project, and for a large
volunteer project ever to become attractive to average end users, it
first needs to attract loads of developers. And for developers,
switching to a pure capability system is a *huge* barrier.

When I'm talking about users here, I don't mean Aunt Tillie. I mean
"power users" -- people who are pushing the limits of the system, and
can actually contribute to development. It is the kind of users who make
heavy use of POSIX features, and thus extremely unlikely to move to
something entirely different.

> > I think there are some misunderstandings here. Your information
> > seems to originate mostly from the l4-hurd list discussions from the
> > "Coyotos era"; while you are lacking both the background that lead
> > up to it, and insight about what happend when these discussions died
> > down...
> >
> > First of all, you may not be aware that most of the people taking
> > part in these discussions, like you, have not been involved in Hurd
> > development before, and know very little about the original
> > Hurd/Mach design. Neal and Marcus -- the initiators of the original
> > Hurd/L4 port -- being the notable exception.
> 
> I think most of the people talking in the discussion were Hurd
> developers. There were very few people in fact and I think I was an
> exception not being a Hurd hacker.

It is interesting that you got this impression -- but it's simply wrong.

There were some other Hurd developers who chipped in a few times; but
those people who carried the bulk of the debate, aside from Marcus and
Neal, were all outsiders/newcomers: some of them contributed a bit to
Hurd/L4, but none of them did any major work on the original Hurd. This
is something I know for sure.

I actually looked through the archives now to make really sure I'm not
lying here.

> As I see it the problem with Coyotos is more political than technical.
> Technically it might be possible to just not use additional feature
> present in the kernel but politically it is a problem if a DRM-capable
> design is popularized by being used in the Hurd.

It's technical as well: Having to omit some of the Coyotos functionality
we don't want; requireing stuff Coyotos is not designed for -- we would
have to work around the functionality offered by Coyotos, meaning
unnecessary complexity... Same story as with Mach.

Why not just create something offering exactly the functionality we
need?

> Still for me the fact that the user tools work in terms of UIDs is
> flawed even if there are expanded possibilities how UIDs can be used.
> 
> I personally want as few and as simple concepts as possible to make up
> the foundation of the system and the current Hurd does not provide
> that for me. The direct integration of user tools with the capability
> concept which would supposedly be part of Coyotos would greatly
> simplify the system compared to the Hurd.

The one defining feature of the Hurd is the fact that it is the GNU
kernel, and consequently must support existing GNU (i.e. POSIX) software
without any major changes. Anything else may be up for discussion, but
this is not.

If you really insist on a completely different system, throwing POSIX
overboard alltogether, the Hurd is indeed not the right project for you.

-antrik-