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

[olafBuddenhagen]

Hi,

On Tue, Nov 25, 2008 at 11:59:57PM +0100, Michal Suchanek wrote:
> 2008/11/23  <olafBuddenhagen@gmx.net>:

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

As it turns out, people migrate from proprietary Unices to GNU/Linux en
masse, while there is rather little migration from Windows to GNU/Linux
-- precisely because the UNIX similarity keeps the barriers low and thus
there is little inertia to overcome.

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

Of course we need compelling reasons -- that's exactly the purpose of
this thread.

However, if the "innovation" makes the switch even harder, there is
nothing won -- the increase in inertia is easily higher than the
increase in motivation.

So what we need is the ability to offer compelling advantages, while at
the same time staying as much UNIX-like as possible on the surface --
which is precisely what the Hurd design achieves. (Though admittedly we
make little use of the abilities so far...)

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

You mean the constructor mechanism, which allows easily implementing
DRM? No, this is not an implication of implementing security. It only is
under the assumption that security requires hiding things from the user
-- and we believe this assumption to be wrong.

Anyways, In another recent mail I pointed out three major problems with
Coyotos as a base for Hurd (the constructor being only one of them), and
forgot a fourth one. (Unsuitable IPC mechanism.) I'm sure there are more
to be found on closer inspection.

But it doesn't really matter whether it's one problem or ten. In
microkernel design, all features are closely interrelated -- changing a
single major property will affect the whole design.

Coyotos is tailored to suit one particular system design. This design is
definitely not appropriate for the Hurd, so Coyotos is out. That's
pretty much all there is to say.

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

Can you point out specific examples of insane and incoherent POSIX
interfaces tainting the Hurd core? Otherwise, this discussion is
pointless.

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

Well, show me the masses of GNU software running on EROS, or even Plan9
and BeOS. (Though I'm not sure the latter two should be counted in --
they are not POSIX-compatible, but very similar is spirit...)

-antrik-