diff options
Diffstat (limited to 'community/weblogs/antrik')
-rw-r--r-- | community/weblogs/antrik/hurd-mission-statement.mdwn | 39 | ||||
-rw-r--r-- | community/weblogs/antrik/plan9-and-the-hurd-major-differences.mdwn | 50 |
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... |