Prepare toolchain/logs/master branch.

1 files changed, 0 insertions, 120 deletions

diff --git a/faq/which_microkernel/discussion.mdwn b/faq/which_microkernel/discussion.mdwn
deleted file mode 100644
index ffdc6720..00000000
--- a/faq/which_microkernel/discussion.mdwn
+++ /dev/null
@@ -1,120 +0,0 @@
-[[!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...