[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Michal Suchanek
Subject: Re: A niche for the Hurd - next step: reality check
Date: Tue, 25 Nov 2008 23:59:57 +0100

2008/11/23  <olafBuddenhagen@gmx.net>:
> 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:
>> 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.

There is a catch here - the inertia binds people to Windows, Linux,
Solaris, and perhaps some BSD if they are adventurous.

The Hurd cannot compete in hardware support and ported application
base to these. So there must be other compelling reason - some
innovation that disturbs the inertia.


>> 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?

As pointed out in another mail the Coyotos has exactly one unwanted
feature that can be easily added to any system which implements

I am not sure if there are features the Hurd needs and Coyotos in not
intended to support. I am not aware of any but I am certainly not the

>> 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.

I am aware that most usable applications these days are POSIX and some
POSIX compatibility is needed.

That does not mean that the system core has to be tainted with insane
and incoherent POSIX interfaces.

The only GNU programs that are tightly tied to POSIX are Coreutils.
Most other stuff puts some layers above the POSIX base in an attempt
to preserve programmer sanity, and performs functions unrelated to
POSIX that would work on a different kind of system as well.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]