2 files changed, 89 insertions, 0 deletions
diff --git a/community/weblogs/antrik/hurd-mission-statement.mdwn b/community/weblogs/antrik/hurd-mission-statement.mdwn
new file mode 100644
index 00000000..592e176a
--- /dev/null
+++ b/community/weblogs/antrik/hurd-mission-statement.mdwn
@@ -0,0 +1,39 @@
+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
new file mode 100644
index 00000000..9e6143bf
--- /dev/null
+++ b/community/weblogs/antrik/plan9-and-the-hurd-major-differences.mdwn
@@ -0,0 +1,50 @@
+[[!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...