Prepare toolchain/logs/master branch.

12 files changed, 0 insertions, 531 deletions

diff --git a/faq/binary_compatibility.mdwn b/faq/binary_compatibility.mdwn
deleted file mode 100644
index e9dfcdb8..00000000
--- a/faq/binary_compatibility.mdwn
+++ /dev/null
@@ -1,33 +0,0 @@
-[[!meta copyright="Copyright © 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]]
-
-IRC, freenode, #hurd, 2012-01-13:
-
-    <veganman> sothere's absolutelyno way,evenslowly to run i386 linuxcode
-      under hurd/i386? Ihave a small app, commercial, which I have to get
-      running there
-    <veganman> no source
-    <braunr> no way
-    <braunr> you'd need to create a userspace linux server catching linux
-      system calls and calling hurd specific stuff to implement them
-    <braunr> it doesn't exist, it may be hard to implement
-    <braunr> some cases will definitely be hard to implement
-    <veganman> so, no magic linux lxemu on windows?
-    <veganman> or linuxemu on plan9
-    <pinotree> nope
-    <veganman> I remember somethingsilly, sonmone hadcompiled linux asauser
-      applicationon plan9 and inserted his own binaries as
-      acodeobject,toberunon plan9, for useon ibm hpc hatrdware
-    <veganman> it was ron minich
-    <veganman> 5e.iwp9.org/slides/linuxemu.pdf
-    <veganman> I think that was it
-    <veganman> google for linux & cnk for additional clues
diff --git a/faq/ghamp.mdwn b/faq/ghamp.mdwn
deleted file mode 100644
index 16849aff..00000000
--- a/faq/ghamp.mdwn
+++ /dev/null
@@ -1,18 +0,0 @@
-[[!meta copyright="Copyright © 2010 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]]."]]"""]]
-
-[[!meta title="GHAMP"]]
-
-*GHAMP* is the GNU/Hurd-based Apache, MySQL, PHP solution stack -- analoguous
-to GLAMP, which is based on GNU/Linux.
-
-Pronounce it like the *G* in
-[GNU](http://www.gnu.org/pronunciation/pronunciation.html), followed by a
-mostly silent *H*, and *AMP* as in amplifier.
diff --git a/faq/how_many_developers.mdwn b/faq/how_many_developers.mdwn
deleted file mode 100644
index a96e0576..00000000
--- a/faq/how_many_developers.mdwn
+++ /dev/null
@@ -1,63 +0,0 @@
-[[!meta copyright="Copyright © 2010, 2011 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]]."]]"""]]
-
-[[!meta title="How many developers are working on the GNU Hurd, and why so
-few?"]]
-
-
-# How Many Developers?
-
-One handful works on the core of the system in their free time, and another
-handful helps with [[Debian GNU/Hurd|hurd/running/debian]] and
-[[hurd/running/Arch_Hurd]] packaging.  Also, an additional handful of former
-developers are still available for answering technical questions, but are not
-participating in the current development anymore.
-
-In the past (that is, a lot of years ago), the FSF did pay a few developers for
-working full time on the GNU Hurd.  But that was for a limited amount of time
-only, and evidently, it was too little for getting the system into a
-competitive state.  Nowadays, it's only unpaid (apart from some
-[[bounties|tag/bounty]]) and free-time volunteers' work.
-
-In contrast to the Linux kernel, there is no industry involvement in
-development.  For one, this is a good thing: independency; no conflicts of
-interests.  For another, it is also a bad thing: no dedicated full-time
-manpower -- which matters a lot.
-
-
-# Why So Few?
-
-We can only speculate.  One major problem might be that the [[architectural
-benefits|advantages]] are generally perceived as very abstract, with little
-practical benefit.  We currently don't have many tools that are actually making
-use of all the possibilities.
-
-Another reason is that it's been taking too long.  Today, most people don't
-believe it will ever be ready for production use, and thus would consider
-involvement a waste of time.  This latter point is invalid, of course, as
-learning can never be a waste of time.  The same holds for the [[challenges]]
-raised by the GNU Hurd -- we can only learn and improve upon working on them.
-
-For likely the same reasons there is no industry interest in the GNU Hurd: its
-advantages are too abstract and incomplete for being of interest there.
-
-As for the scientific sector, the GNU Hurd projects was rather about *using* a
-[[microkernel]] intead of doing research on them, for example.  But, there have
-been some projects and theses done, and some scientific papers published on GNU
-Hurd topics, and we're generally very interested in further such projects.
-
-
-# Attracting New Faces
-
-We're an open project: any interested party (*you*!) are very welcome to start
-[[contributing]].  Mentoring is possible, too, to help you get started.
-
-Likewise, for reaching out to new developers, we're participating in [[Google's
-Summer of Code program|community/gsoc]].
diff --git a/faq/how_many_developers/discussion.mdwn b/faq/how_many_developers/discussion.mdwn
deleted file mode 100644
index 8e4c487a..00000000
--- a/faq/how_many_developers/discussion.mdwn
+++ /dev/null
@@ -1,65 +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]]."]]"""]]
-
-
-# IRC, freenode, #hurd, 2011-05-22
-
-    <silver_hook> Since apparently Hurd's aim is a very stable and transparent
-      system ...why aren't there any companies backing it up?
-    <antrik> silver_hook: it's not in a state yet where it would be
-      commercially interesting
-    <antrik> silver_hook: and after some epic failures in the 90s, few
-      companies dare to invest in microkernel development...
-    <silver_hook> Isn't MacOS X running on top of Mach?
-    <antrik> yes, but it's not a true microkernel system
-    <antrik> for one, it's single-server, which is boring
-    <antrik> also it uses co-location, i.e. runs all the system code in the
-      kernel address space -- they are separated only formally
-    <antrik> even NT is more of a microkernel system I think
-    <silver_hook> Oh, OK, I'm not that knowledgeable about kernels to know
-      that.
-    <antrik> well, now you know :-)
-    <silver_hook> Yup, thanks :)
-    <antrik> most people don't know this, so don't worry
-    <silver_hook> I was just wondering that it might be potentially an ideal
-      server system, right?
-    <antrik> well, *potentially* it might be an ideal general-purpose system,
-      which includes server use... though personally I think the advantages of
-      the architecture are more visible in desktop use, as servers tend to be
-      rather streamlined, with little need for individualisation :-)
-    <antrik> however, it still remains to be proven that true (multi-server)
-      microkernel operating systems actually work for general-purpose
-      applications...
-    <silver_hook> antrik: I mean regarding hosting or virtual servers.
-    <antrik> so far, they are only successful in the much simpler embedded
-      space
-    <antrik> well, yes, the Hurd architecture in theory allows very much
-      flexibility regarding virtual environments... I once blogged about
-      that. not sure whether server applications really require that
-      flexibility though. I think most people are pretty happy with the various
-      virtualisation/container solutions available in Linux. again, the
-      flexibility is more relevant in the desktop space IMHO
-    <antrik> dosn't mean it wouldn't be useful for servers too... just not as
-      much of a selling point I fear :-)
-
-
-# IRC, freenode, #hurd, 2011-07-09
-
-    <antrik> gnu_srs1: regarding your question why people aren't interested in
-      workin on Hurd: Eric Raymond explains it pretty well in his famous
-      "Cathedral and Bazaar" paper
-    <antrik> people are more likely to work on something that *almost* works
-      for them, and where they only have to fill in a few missing bits
-    <antrik> the Hurd doesn't almost work for anyone
-    <antrik> actually, you should probably reread the whole paper. it's
-      essentially an analysis why the Hurd failed compared to Linux
-
-
-# [[open_issues/mission_statement]]
diff --git a/faq/network_transparency.mdwn b/faq/network_transparency.mdwn
deleted file mode 100644
index aefaf500..00000000
--- a/faq/network_transparency.mdwn
+++ /dev/null
@@ -1,22 +0,0 @@
-[[!meta copyright="Copyright © 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]]
-
-IRC, freenode, #hurd, 2012-01-21:
-
-    <chromaticwt> is it possible to transfer servers running on one microkernel
-      on one machine, to another microkernel running on a different machine?
-    <chromaticwt> two machines will be running the complete os
-    <antrik> well, if the code for network-transparent IPC still existed, it
-      might be possible to move a task to another machine, while keeping the
-      port associations with the original system...
-    <antrik> if you mean actually moving it to another system, that's pretty
-      much impossible in any system that has stateful interfaces
diff --git a/faq/posix_compatibility.mdwn b/faq/posix_compatibility.mdwn
deleted file mode 100644
index 4490b7cb..00000000
--- a/faq/posix_compatibility.mdwn
+++ /dev/null
@@ -1,32 +0,0 @@
-[[!meta copyright="Copyright © 2010, 2011 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]]."]]"""]]
-
-[[!meta title="POSIX compatibility"]]
-
-Is it favorable of rather a hindrance to be compatible to POSIX and similar
-standards?
-
-A lot of things in POSIX et al. are designed for [[UNIX]]-like systems with
-traditional monolithic [[kernel]]s.
-
-Thus, a [[microkernel]]-based system, as ours is, has to employ a bunch of
-detours, for example to implement the [[`fork` system call|glibc/fork]].
-
-On the other hand, (mostly) complying to these standards, made a really big
-body of software *just work* without any (or just trivial) [[hurd/porting]].
-Especially so for command-line programs, and libraries.
-
-But: a large part of today's user programs are not written according to POSIX
-et al. low-level interfaces, but against GNOME, GTK+2, and other high-level
-frameworks and libraries.  It may be a valid option to enrich these instead of
-striving for total POSIX compliance -- and the high-level programs (that is,
-their users) may not even notice this, but we would avoid a lot of overhead
-that comes with wrapping the [[Hurd interfaces|hurd/interface]] to be POSIX
-compliant.
diff --git a/faq/posix_compatibility/discussion.mdwn b/faq/posix_compatibility/discussion.mdwn
deleted file mode 100644
index 0d722c9e..00000000
--- a/faq/posix_compatibility/discussion.mdwn
+++ /dev/null
@@ -1,25 +0,0 @@
-[[!meta copyright="Copyright © 2010, 2011 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]]
-
-\#hurd IRC channel on Freenode, 2010-12-21:
-
-    <antrik> tschwinge: the writeup ignores the fact that POSIX compatibility
-      is not only for applications, but also for users familiar with the UNIX
-      environment
-    <antrik> also, I still don't buy the fact that most software is not written
-      for POSIX. even if assuming that GNOME programs don't use POSIX (which is
-      only half true), there is a lot of other software in a system that is
-      just as important, though less visible
-    <antrik> (server software, startup system, device management, automation,
-      ...)
-    <antrik> tschwinge: BTW, I meant to (and partially did) write a blog
-      article on this topic -- but I didn't get around to finish it...
diff --git a/faq/sharing_the_user_space.mdwn b/faq/sharing_the_user_space.mdwn
deleted file mode 100644
index ec880827..00000000
--- a/faq/sharing_the_user_space.mdwn
+++ /dev/null
@@ -1,23 +0,0 @@
-[[!meta copyright="Copyright © 2010 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]]."]]"""]]
-
-*Question:* Could it be possible to have a system installation where you can
-dual-boot using either the [[Linux]] kernel, or the GNU Hurd, so that
-everything but the kernel is shared?
-
-*Answer:* Given that both Linux and GNU Hurd are using the [[ELF]] binary
-format, this could indeed be made possible, if all programs agreed to rely on
-only one abstraction layer, for example the standard C library ([[glibc]]).
-(Additionally, for example for [[system call]]s that are not covered by glibc
-calls, you'd need to be able to reliably trap and emulate these.)  However,
-Linux' and the GNU Hurd's [[ABI]]'s have sufficiently diverged, so that this is
-not easy to do.  That's why you can't currently install a system in this way,
-but you need a separate installation of the userspace suited for the Linux
-kernel, or the GNU Hurd.
diff --git a/faq/smp.mdwn b/faq/smp.mdwn
deleted file mode 100644
index e95edcd2..00000000
--- a/faq/smp.mdwn
+++ /dev/null
@@ -1,28 +0,0 @@
-[[!meta copyright="Copyright © 2009, 2011 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]]."]]"""]]
-
-[[!meta title="Does GNU/Hurd support SMP/Multicore?"]]
-
-The Hurd servers themselves are multithreaded, so they should be able to take benefit of the parallelism brought by SMP/Multicore boxes. This has however never been tested yet because of the following.
-
-[[microkernel/Mach]] used to be running on SMP boxes like the [[!wikipedia
-Intel_iPSC/860]], so principally has the required infrastructure.  It has
-however not yet been enhanced to support nowadays' SMP standards like ACPI,
-etc.  Also, [[GNU Mach|microkernel/mach/gnumach]]'s Linux device driver glue
-code likely isn't SMP-safe.  As this glue code layer is not used in the
-[[microkernel/mach/gnumach/ports/Xen]] port of GNU Mach, the plan is to try it
-in this enviroment first.
-
-[[!tag open_issue_gnumach open_issue_xen]]
-
-That is why for now GNU/Hurd will only use one logical processor (i.e. one core or one thread, depending on the socket type).
-
-Once this issue is solved, there are follow-up issues about
-[[open_issues/multiprocessing]] and [[open_issues/multithreading]].
diff --git a/faq/system_port.mdwn b/faq/system_port.mdwn
deleted file mode 100644
index c831c36f..00000000
--- a/faq/system_port.mdwn
+++ /dev/null
@@ -1,47 +0,0 @@
-[[!meta copyright="Copyright © 2011 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]]."]]"""]]
-
-[[!meta title="Doing a GNU/Hurd System Port"]]
-
-How difficult is it to port the GNU/Hurd system to run on another architecture?
-
-The GNU/Hurd system consists of [[/Hurd]] servers running as user-space
-processes on top of the [[GNU Mach|microkernel/mach/gnumach]] microkernel.  The
-system functionality is usually accessed through the
-[[POSIX|posix_compatibility]] interface that is provided by [[/glibc]] and
-[[/libpthread]].
-
-A whole-system port involves touching all these components, with varying
-degree, of course.
-
-For a CPU architecture port, the microkernel is the most involved part,
-followed by glibc and the threading library.
-
-The original [[microkernel/Mach]] microkernel was portable to a number of
-architectures which were a lot more popular at the beginning of the 1990s than
-they are now.
-
-The GNU/Hurd system is currently available for the x86 architecture.  This
-includes emulators such as [[hurd/running/QEMU]] (or KVM), or
-[[hurd/running/VirtualBox]].  Besides this, there is a port for the [[Xen
-domU|microkernel/mach/gnumach/ports/xen]] *sub-architecture*.
-
-Further on, there are some [[unfinished porting
-attempts|microkernel/mach/gnumach/ports]] for the Alpha, MIPS and PowerPC
-architectures.  These have not been completed due to little developer interest.
-
-Another option is to do the port at a different layer: port the Hurd servers to
-not run on the GNU Mach microkernel, but instead on top of [[another
-microkernel|which_microkernel]].  Or, even by providing a Mach emulation layer
-on top of a monolithic kernel.  For example, there could be a port for [[having
-Mach run as a POSIX user-space process|open_issues/mach_on_top_of_posix]], or
-by implementing the [[Mach IPC|microkernel/mach/ipc]] facility (as well as
-several others) as Linux kernel modules.  While there have been some
-experiments, no such port has been completed yet.
diff --git a/faq/which_microkernel.mdwn b/faq/which_microkernel.mdwn
deleted file mode 100644
index 84b661e4..00000000
--- a/faq/which_microkernel.mdwn
+++ /dev/null
@@ -1,55 +0,0 @@
-[[!meta copyright="Copyright © 2009, 2011 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]]."]]"""]]
-
-[[!meta title="What happened with the Hurd ports to the L4 / Coyotos / Viengoos
-microkernels?"]]
-
-<!-- This page shares some text with history/port_to_another_microkernel.  -->
-
-It is a frequently asked question, which microkernel the Hurd should be based
-upon assuming that [[microkernel/Mach]] is no longer considered state of the
-art, and it is well known that there has been a lot of discussion about this
-topic, and also some code produced, but then, years later, the Hurd is still
-based on [[GNU Mach|microkernel/mach/gnumach]].
-
-Around the turn of the millenium, some of the Hurd developers began
-experimenting with using other [[microkernel]]s for the Hurd, as they have been
-encountering a number of fundamental design issues with the [[Mach
-microkernel|microkernel/mach]], mostly with respect to
-[[open_issues/resource_management_problems]].
-
-At that time, L4 (Pistachio) was the prime candidate.  A reimplementation of
-the Hurd on this microkernel looked promising, and got pretty far (running some
-simple POSIX programs, such as `banner`).  However, over time some lingering
-design issues turned out to be fundamental problems: the original L4 is not
-suitable for building object-capability systems like the Hurd.  Thus
-development was aborted in 2005.
-
-During that process, Neal Walfield and Marcus Brinkmann started on a period of
-research on other microkernels, getting in deeper contact with other
-researchers.  There was a lot of discussion, and a lot of good ideas produced,
-but a straight-forward port of the Hurd to such a modern microkernel (Coyotos,
-or the new L4 variants, for example) didn't seem feasible to them anymore: they
-found microkernel design and system design to be interconnected in very
-intricate ways, and this demanded design changes in the Hurd's core itself.
-
-Based on this experience, the next step was to write an own microkernel
-instead, which Neal Walfield began doing with his experimental
-[[microkernel/Viengoos]] project, for his research on resource management.
-Currently he works in another research area though, and thus Viengoos is on
-hold.
-
-Note that while none of the microkernel research work is active now, the
-previous experiments already yielded a lot of experience, which will be very
-useful in the further development / improvement of the mainline (Mach-based)
-Hurd implementation.
-
-For more details about this topic, please see our history page about the
-[[history/port_to_another_microkernel]].
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...