Prepare toolchain/logs/master branch.

2 files changed, 0 insertions, 89 deletions

diff --git a/community/weblogs/antrik/hurd-mission-statement.mdwn b/community/weblogs/antrik/hurd-mission-statement.mdwn
deleted file mode 100644
index 592e176a..00000000
--- a/community/weblogs/antrik/hurd-mission-statement.mdwn
+++ /dev/null
@@ -1,39 +0,0 @@
-For a while I have been thinking about the lack of a roadmap for the
-Hurd; but now I realized that we lack something even more fundamental: a
-simple mission statement -- i.e. saying where we want to go, rather
-than how we want to get there. I think many of the problems we have are
-directly or indirectly related to that.
-
-As we didn't have such a mission statement so far, the people currently
-involved have vastly different ideas about the mission, which of course
-makes it a bit hard to come up with a suitable one now. However, I
-managed to come up with something that I believe is generic enough so
-all contributors can subscribe to it:
-
->   *The mission of the Hurd project is: to create a general-purpose
->   kernel suitable for the GNU operating system, which is viable for
->   everyday use, and gives users and programs as much control over their
->   computing environment as possible.*
-
-*"Suitable for GNU"* in the first part implies a number of things. I
-explicitely mentioned *"general-purpose"*, because this an important
-feature that sets the Hurd apart from many other microkernel projects,
-but isn't immediately obvious.
-
-I didn't mention that it must be entirely free software, as this should
-be obvious to anyone familiar with GNU.
-
-Another thing I did not mention, because it's too controversial: how
-much UNIX do we need? I think that being suitable for GNU requires a
-pretty high degree of UNIX compatibility, and also that the default
-environment looks to the user more or less like UNIX. However, some
-people claimed in the past that GNU could do without UNIX -- the wording
-used here doesn't totally preclude such views.
-
-The second part also leaves a lot of slack: I for my part still believe
-that a Mach-based Hurd can be viable for everyday use; but those who
-think that a microkernel change is required, should be happy with this
-wording as well.
-
-The third part tries to express the major idea behind the Hurd design in
-the most compact and generic way possible.
diff --git a/community/weblogs/antrik/plan9-and-the-hurd-major-differences.mdwn b/community/weblogs/antrik/plan9-and-the-hurd-major-differences.mdwn
deleted file mode 100644
index 9e6143bf..00000000
--- a/community/weblogs/antrik/plan9-and-the-hurd-major-differences.mdwn
+++ /dev/null
@@ -1,50 +0,0 @@
-[[!meta copyright="Copyright © 2009 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="Major differences between Plan9 and the Hurd"]]
-
-There are some similarities between the Hurd and Plan 9 regarding the file 
-system handling -- but there are also very fundamental differences which go 
-far beyond monolithic vs. microkernel design:
-
-- The Hurd is UNIX (POSIX) compatible
-
-- While (almost) all services are attached to the file system tree, not
-  all services actually export a file system interface!  
-  
-  Personally, I advocate using FS-based interfaces as much as possible.
-  Yet, there are some cases where they get very awkward and/or
-  inefficient, and domain-specific interfaces simply make a lot more
-  sense.  
-  
-  Also, some Hurd services are indeed used to implement the file systems
-  in the first place -- they work below the FS level, and obviously
-  can't use an FS interface!
-
-- File systems are completely decentralized -- clients always talk to
-  the FS servers directly, without any central VFS layer. (I don't think
-  that's the case in Plan 9?)  
-  
-  This offers much more flexibility -- the way the FS interfaces
-  themselves work can be modified. Many things can be implemented as
-  normal translators, that would require special VFS support on other
-  systems. (Extended attributes, VFS-based union mounts, local
-  namespaces, firmlink, magic file name suffixes etc.)
-
-- The system design allows users and applications to change almost all
-  aspects of the system functionality in the local environment easily
-  and without affecting other parts of the system.  
-  
-  (This is possible with Plan 9 to some extent; but the Hurd allows it
-  at a much lower level -- including stuff like the filesystem
-  interfaces, access control mechanisms, program execution and process
-  management, and so on.)
-
-I hope I didn't forget any major differences...