[[!meta copyright="Copyright © 2011, 2012 Free Software Foundation, Inc."]]

[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version 1.2 or
any later version published by the Free Software Foundation; with no Invariant
Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
is included in the section entitled [[GNU Free Documentation
License|/fdl]]."]]"""]]

[[!tag open_issue_documentation]]

[[!toc]]


# Olaf, 2011-04-10

This version mixes up three distinct phases: rewrite from scratch; redesign;
own microkernel.

While Okuji initially might have intended a direct port of the existing Hurd
code, by the time I started following Hurd development (2004 IIRC), it has been
long clear that Hurd/L4 is a rewrite from scratch.

The next phase was the desire of Neal and especially Macrus to completely
reinvent the design of the Hurd. This was mostly fueled by Shapiro's influence,
resulting in a security-above-everything rage. It was in this phase that not
only the original L4 has been abandonend, but also all thoughts about using
newer L4 variants (which might have been suitable) were forsaken in favor of
Shapiro's Coyotos.

The whole idea of redesigning the Hurd -- especially for security concerns --
is highly controversial: I always strongly objected to it; and Marcus later
admitted himself that he got carried away and lost sight of what really matters
for the Hurd. (But only after realising that Shapiro's notion of high security
is fundamentally incompatible with the GNU philosophy.) I opted for not
explicitely mentioning this aspect in the FAQ at all, as it's impossible to
explain properly in a compact form, and probably impossible at all to do it in
an objective fashion.

The final phase -- following the realisation of incompatibility with
Shapiro/Coyotos -- was the attempt to create new microkernels specifically for
Hurd's needs. Marcus abandonned his pretty soon, and never made it public, so I
didn't mention it at all; but Viengoos is still relevant in certain ways.

BTW, my original text also more explicitely answers the question what happened
to the Coyotos port -- which after all is what the title promises...

All in all, I still think my text was better. If you have any conerns with it,
please discuss them...


# seL4

## IRC, freenode, #hurd, 2011-09-27

    <cjuner> Does anyone remember/know if/why not seL4 was considered for
      hurd-l4? Is anyone aware of any differences between seL4 and coyotos?


## IRC, freenode, #hurd, 2011-09-29

    <antrik> cjuner: the seL4 project was only at the beginning when the
      decision was made. so was Coyotos, but Shapiro promised back then that
      building on EROS, it would be done very fast (a promise he couldn't keep
      BTW); plus he convinced the people in question that it's safer to build
      on his ideas...
    <antrik> it doesn't really matter though, as by the time the ngHurd people
      were through with Coyotos, they had already concluded that it doesn't
      make sense to build upon *any* third-party microkernel
    <cjuner> antrik, what was the problem with coyotos? what would be the
      problem with sel4 today?
    <cjuner> antrik, yes I did read the FAQ. It doesn't mention seL4 at all
      (there isn't even much on the hurd-l4 mailing lists, I think that being
      due to seL4 not having been released at that point?) and it does not
      specify what problems they had with coyotos.
    <antrik> cjuner: it doesn't? I thought it mentioned "newer L4 variants" or
      something like that... but the text was rewritten a couple of times, so I
      guess it got lost somewhere
    <antrik> cjuner: unlike original L4, it's probably possible to implement a
      system like the Hurd on top on seL4, just like on top of
      Coyotos. however, foreign microkernels are always created with foreign
      design ideas in mind; and building our own design around them is always
      problematic. it's problematic with Mach, and it will be problematic with
      any other third-party microkernel
    <antrik> Coyotos specifically has different ideas about memory protection,
      different ideas about task startup, different ideas about memory
      handling, and different ideas about resource allocation
    <cjuner> antrik, do any specific problems of the foreign designs,
      specifically of seL4 or coyotos come to mind?
    <antrik> cjuner: I mentioned several for Coyotos. I don't have enough
      understanding of the matters to go into much more detail
    <antrik> (and I suspect you don't have enough understanding of these
      matters to take away anything useful from more detail ;-) )
    <antrik> I could try to explain the issues I mentioned for Coyotos (as far
      as I understand them), but would that really help you?


# Xnu (Darwin)


## IRC, freenode, #hurd, 2012-03-30

    <mel__> did people consider to port Hurd to Darwin? i.e. replace GNU Mach
      with Darwin?
    <braunr> no
    <braunr> well, quickly only
    <mel__> wouldn't it be a reasonable idea?
    <mel__> after all, Darwin is production-ready and contains a Mach side.
    <braunr> not more than fixing gnumach itself, or using linux instead
    <mel__> well.
    <braunr> those implementations have diverged with time
    <mel__> i see
    <mel__> the fsf should pay people for fixing gnu mach then. :)
    <antrik> mel__: indeed someone consided Xnu (the actual kernel of Darwin) a
      while back; but I think he shelved the idea again. not sure about the
      exact reasons
    <antrik> Xnu implements a few improvements that might be helpful; but it
      doesn't address the really fundamental issues that matter for a true
      multiserver system...