Merge commit '96611f76b833159bafeab3443229dfa690178d92' into master-news_next

Conflicts:
	news/2010-03-31.mdwn

31 files changed, 226 insertions, 87 deletions

diff --git a/community/gsoc/project_ideas/debian_installer.mdwn b/community/gsoc/project_ideas/debian_installer.mdwn
index ca10a61e..43682e8b 100644
--- a/community/gsoc/project_ideas/debian_installer.mdwn
+++ b/community/gsoc/project_ideas/debian_installer.mdwn
@@ -21,6 +21,21 @@ Some preliminary work has been done, see
 The goal is to have the Debian Installer fully working on the Hurd.  It
 requires relatively little Hurd-specific knowledge.
 
+A lot of the "non-Linux support" part of the project has already been done thanks to a previous GSoC, so at least no ground reason should bar the project. A lot of the required udebs are already in Debian or are pending upload, so that building an image and booting it does already work. A preliminary list of what remains is
+
+ * Add initrd support to GNU Mach, unless youpi does it before :) This should not be very complicated by re-using the iopl driver code.
+ * hurdify genext2fs to handle 4096 block size by default (see bug #562999) and support translator entries.
+ * Port busybox. This needs to be synchronized with kfreebsd people, who have probably already done some work, but that seemingly still hasn't been merged. In the meanwhile, youpi has a version with most of it disabled so a d-i image can actually be built.
+ * Port keyboard-setup to configure the xkb driver of the Hurd console
+
+As a starting point to get a grasp at how the debian installer is built, students might wish to look at the current Debian installer source and build process on Linux:
+
+ * svn co svn://svn.debian.org/d-i/trunk/installer/
+ * cd installer/build
+ * make build_monolithic
+
+The same can be done on hurd-i386 but a few non-uploaded packages are needed, see http://people.debian.org/~sthibault/hurd-i386/README-d-i
+
 Possible mentors: Samuel Thibault (youpi)
 
-Exercise: Try to get one piece of the installer running on Hurd.
+Exercise: Fix a couple of Hurd issues in busybox.
diff --git a/community/gsoc/project_ideas/disk_io_performance.mdwn b/community/gsoc/project_ideas/disk_io_performance.mdwn
index bb047308..b6c857b0 100644
--- a/community/gsoc/project_ideas/disk_io_performance.mdwn
+++ b/community/gsoc/project_ideas/disk_io_performance.mdwn
@@ -11,21 +11,21 @@ is included in the section entitled
 [[!meta title="Disk I/O Performance Tuning"]]
 
 The most obvious reason for the Hurd feeling slow compared to mainstream
-systems like GNU/Linux, is very slow harddisk access.
+systems like GNU/Linux, is very slow hard disk access.
 
 The reason for this slowness is lack and/or bad implementation of common
-optimisation techniques, like scheduling reads and writes to minimalize head
+optimization techniques, like scheduling reads and writes to minimize head
 movement; effective block caching; effective reads/writes to partial blocks;
 reading/writing multiple blocks at once; and read-ahead.  The
 [[ext2_filesystem_server|hurd/translator/ext2fs]] might also need some
-optimisations at a higher logical level.
+optimizations at a higher logical level.
 
 The goal of this project is to analyze the current situation, and implement/fix
-various optimisations, to achieve significantly better disk performance. It
+various optimizations, to achieve significantly better disk performance. It
 requires understanding the data flow through the various layers involved in
-disk acces on the Hurd ([[filesystem|hurd/virtual_file_system]],
+disk access on the Hurd ([[filesystem|hurd/virtual_file_system]],
 [[pager|hurd/libpager]], driver), and general experience with
-optimising complex systems.  That said, the killing feature we are definitely
+optimizing complex systems.  That said, the killing feature we are definitely
 missing is the read-ahead, and even a very simple implementation would bring
 very big performance speedups.
 
diff --git a/community/gsoc/project_ideas/download_backends.mdwn b/community/gsoc/project_ideas/download_backends.mdwn
index 749597a6..f794e814 100644
--- a/community/gsoc/project_ideas/download_backends.mdwn
+++ b/community/gsoc/project_ideas/download_backends.mdwn
@@ -19,7 +19,7 @@ Download protocols like FTP, HTTP, BitTorrent etc. are very good candidates for
 this kind of modularization: a program could simply use the download
 functionality by accessing FTP, HTTP etc. translators.
 
-There is already an ftpfs traslator in the Hurd tree, as well as an [httpfs
+There is already an ftpfs translator in the Hurd tree, as well as an [httpfs
 translator on hurdextras](http://www.nongnu.org/hurdextras/#httpfs); however,
 these are only suitable for very simple use cases: they just provide the actual
 file contents downloaded from the URL, but no additional status information
@@ -35,7 +35,7 @@ The goal of this project is to design a suitable interface, implement it for at
 least one download protocol, and adapt apt-get (or some other program) to use
 this as a backend.
 
-This task requires some design skills and some knowlegde of internet protocols,
+This task requires some design skills and some knowledge of internet protocols,
 to create a suitable interface. Translator programming knowledge will have to
 be obtained while implementing it.
 
diff --git a/community/gsoc/project_ideas/driver_glue_code.mdwn b/community/gsoc/project_ideas/driver_glue_code.mdwn
index e1b8d22e..9c063e9f 100644
--- a/community/gsoc/project_ideas/driver_glue_code.mdwn
+++ b/community/gsoc/project_ideas/driver_glue_code.mdwn
@@ -11,7 +11,7 @@ is included in the section entitled
 
 [[!meta title="New Driver Glue Code"]]
 
-Although a driver framework in userspace would be desirable, presently the Hurd
+Although a driver framework in user space would be desirable, presently the Hurd
 uses kernel drivers in the microkernel,
 [[GNU_Mach|microkernel/mach/gnumach]]. (And changing this would be far beyond a
 GSoC project...)
@@ -23,7 +23,7 @@ this project is to redo the glue code, so we can use drivers from current Linux
 versions, or from one of the free BSD variants.
 
 While it would be certainly possible to create custom glue code again, a more
-sustainable and probably also easier approch is to use
+sustainable and probably also easier approach is to use
 [[DDE]] instead -- it already
 does the hard work of providing an environment where the foreign drivers can
 run, and has the additional advantage of being externally maintained.
@@ -44,3 +44,6 @@ ethernet) from a recent system, and try to port it to run in the existing
 driver framework in GNU Mach. Completing the port might be too involved for the
 exercise; but it's pretty likely that you will find something else to improve
 in the glue code while working on this...
+
+*Status*: [[Zheng Da|zhengda]] is working on DDE, and has mostly completed the
+initial port.
diff --git a/community/gsoc/project_ideas/dtrace.mdwn b/community/gsoc/project_ideas/dtrace.mdwn
index 93c2a5f3..4a46cf38 100644
--- a/community/gsoc/project_ideas/dtrace.mdwn
+++ b/community/gsoc/project_ideas/dtrace.mdwn
@@ -16,7 +16,7 @@ problems, these are mostly just guesses. Better understanding what really
 causes bad performance is necessary to improve the situation.
 
 For that, we need tools for performance measurements. While all kinds of more
-or less specific profiling tools could be convieved, the most promising and
+or less specific profiling tools could be conceived, the most promising and
 generic approach seems to be a framework for logging certain events in the
 running system (both in the microkernel and in the Hurd servers). This would
 allow checking how much time is spent in certain modules, how often certain
@@ -34,7 +34,7 @@ with integrating existing components as well as low-level programming.
 
 Possible mentors: Samuel Thibault (youpi)
 
-Exercise: In lack of a good exercise directly related to this taks, just pick
+Exercise: In lack of a good exercise directly related to this task, just pick
 one of the kernel-related or generally low-level tasks from the bug/task
 trackers on savannah, and make a go at it. You might not be able to finish the
 task in a limited amount of time, but you should at least be able to make a
diff --git a/community/gsoc/project_ideas/file_locking.mdwn b/community/gsoc/project_ideas/file_locking.mdwn
index af010c98..0159b091 100644
--- a/community/gsoc/project_ideas/file_locking.mdwn
+++ b/community/gsoc/project_ideas/file_locking.mdwn
@@ -10,7 +10,7 @@ is included in the section entitled
 
 [[!meta title="Fix and Complete File Locking Support"]]
 
-Over the years, [[UNIX]] has aquired a host of different file locking mechanisms.
+Over the years, [[UNIX]] has acquired a host of different file locking mechanisms.
 Some of them work on the Hurd, while others are buggy or only partially
 implemented. This breaks many applications.
 
diff --git a/community/gsoc/project_ideas/gnat.mdwn b/community/gsoc/project_ideas/gnat.mdwn
index b7f2ea62..97a4a552 100644
--- a/community/gsoc/project_ideas/gnat.mdwn
+++ b/community/gsoc/project_ideas/gnat.mdwn
@@ -15,9 +15,9 @@ also a number of other Debian packages depending on GNAT, and thus not
 buildable on the Hurd.
 
 The goal of this project is getting GNAT fully working in Debian GNU/Hurd. It
-requires implementing some explicitely system-specific stuff in GNAT, and maybe
+requires implementing some explicitly system-specific stuff in GNAT, and maybe
 fixing a few other problems. Good knowledge of Ada is a must; some Hurd
-knowledge will have to be aquired while working on the project.
+knowledge will have to be acquired while working on the project.
 
 Possible mentors: Samuel Thibault (youpi)
 
diff --git a/community/gsoc/project_ideas/gnumach_cleanup.mdwn b/community/gsoc/project_ideas/gnumach_cleanup.mdwn
index e75c9d3e..4aef0d1b 100644
--- a/community/gsoc/project_ideas/gnumach_cleanup.mdwn
+++ b/community/gsoc/project_ideas/gnumach_cleanup.mdwn
@@ -11,7 +11,7 @@ is included in the section entitled
 [[!meta title="GNU Mach Code Cleanup"]]
 
 Although there are some attempts to move to a more modern microkernel
-alltogether, the current Hurd implementation is based on
+altogether, the current Hurd implementation is based on
 [[GNU_Mach|microkernel/mach/gnumach]], which is only a slightly modified
 variant of the original CMU [[microkernel/Mach]].
 
@@ -19,7 +19,7 @@ Unfortunately, Mach was created about two decades ago, and is in turn based on
 even older BSD code.  Parts of the BSD kernel -- file systems, [[UNIX]] [[mechanism]]s
 like processes and signals, etc. -- were ripped out (to be implemented in
 [[userspace_servers|hurd/translator]] instead); while other mechanisms were
-added to allow implementing stuff in userspace.
+added to allow implementing stuff in user space.
 ([[Pager_interface|microkernel/mach/external_pager_mechanism]],
 [[microkernel/mach/IPC]], etc.)
 
diff --git a/community/gsoc/project_ideas/language_bindings.mdwn b/community/gsoc/project_ideas/language_bindings.mdwn
index 8b493e19..a27b0d30 100644
--- a/community/gsoc/project_ideas/language_bindings.mdwn
+++ b/community/gsoc/project_ideas/language_bindings.mdwn
@@ -30,10 +30,10 @@ Several approaches are possible when creating such bindings. One way is simply
 to provide wrappers to all the available C libraries ([[hurd/libtrivfs]], [[hurd/libnetfs]]
 etc.). While this is easy (it requires relatively little consideration), it may
 not be the optimal solution. It is preferable to hook in at a lower level, thus
-being able te create interfaces that are specially adapted to make good use of
+being able to create interfaces that are specially adapted to make good use of
 the features available in the respective language.
 
-These more specialised bindings could hook in at some of the lower level
+These more specialized bindings could hook in at some of the lower level
 library interfaces ([[hurd/libports]], [[hurd/glibc]], etc.); use the
 [[microkernel/mach/MIG]]-provided [[microkernel/mach/RPC]] stubs directly; or
 even create native stubs directly from the interface definitions. The
diff --git a/community/gsoc/project_ideas/lexical_dot-dot.mdwn b/community/gsoc/project_ideas/lexical_dot-dot.mdwn
index 764cd37f..e0dabc01 100644
--- a/community/gsoc/project_ideas/lexical_dot-dot.mdwn
+++ b/community/gsoc/project_ideas/lexical_dot-dot.mdwn
@@ -22,7 +22,7 @@ resolution.
 Some application already use lexical resolution internally for that reason. It
 is generally agreed that many problems could be avoided if the standard
 filesystem lookup calls used lexical resolution as well. The compatibility
-problems probably would be negligable.
+problems probably would be negligible.
 
 The goal of this project is to modify the filename lookup mechanism in the Hurd
 to use lexical resolution, and to check that the system is still fully
diff --git a/community/gsoc/project_ideas/libcap.mdwn b/community/gsoc/project_ideas/libcap.mdwn
index 10ca508e..875b462f 100644
--- a/community/gsoc/project_ideas/libcap.mdwn
+++ b/community/gsoc/project_ideas/libcap.mdwn
@@ -14,7 +14,7 @@ libcap is a library providing the API to access POSIX capabilities. These allow
 giving various kinds of specific privileges to individual users, without giving
 them full root permissions.
 
-Although the Hurd design should faciliate implementing such features in a quite
+Although the Hurd design should facilitate implementing such features in a quite
 natural fashion, there is no support for POSIX capabilities yet. As a
 consequence, libcap is not available on the Hurd, and thus various packages
 using it can not be easily built in Debian GNU/Hurd.
diff --git a/community/gsoc/project_ideas/libdiskfs_locking.mdwn b/community/gsoc/project_ideas/libdiskfs_locking.mdwn
index 2a08b387..570a9581 100644
--- a/community/gsoc/project_ideas/libdiskfs_locking.mdwn
+++ b/community/gsoc/project_ideas/libdiskfs_locking.mdwn
@@ -18,8 +18,8 @@ faulty paths causing these lockups.
 
 The task is systematically checking the [[hurd/libdiskfs]] code for this kind of locking
 issues. To achieve this, some kind of test harness has to be implemented: For
-exmple instrumenting the code to check locking correctness constantly at
-runtime. Or implementing a unit testing framework that explicitely checks
+example instrumenting the code to check locking correctness constantly at
+runtime. Or implementing a unit testing framework that explicitly checks
 locking in various code paths. (The latter could serve as a template for
 implementing unit checks in other parts of the Hurd codebase...)
 
diff --git a/community/gsoc/project_ideas/libgtop.mdwn b/community/gsoc/project_ideas/libgtop.mdwn
index ef1b2bcb..14304de2 100644
--- a/community/gsoc/project_ideas/libgtop.mdwn
+++ b/community/gsoc/project_ideas/libgtop.mdwn
@@ -24,9 +24,9 @@ The goal of this project is a fully functional libgtop in Debian GNU/Hurd. Some
 application(s) using it also need to be ported, e.g. gnome-system-monitor.
 
 Some bits of this work are easy, others need some digging into Hurd internals.
-This task doesn't require any specific previous knowlegde (besides of general
+This task doesn't require any specific previous knowledge (besides of general
 C/UNIX programming skills of course); but during the course of the project,
-some knowlegde about Hurd internals will have to be obtained, along with a bit
+some knowledge about Hurd internals will have to be obtained, along with a bit
 of Debian stuff.
 
 Possible mentors: Samuel Thibault (youpi)
diff --git a/community/gsoc/project_ideas/mtab.mdwn b/community/gsoc/project_ideas/mtab.mdwn
index 60dde525..a60a8038 100644
--- a/community/gsoc/project_ideas/mtab.mdwn
+++ b/community/gsoc/project_ideas/mtab.mdwn
@@ -22,7 +22,7 @@ is no central place keeping track of mounts.
 
 As a consequence, there is currently no easy way to obtain a listing of all
 mounted file systems. This also means that commands like `df` can only work on
-explicitely specified mountpoints, instead of displaying the usual listing.
+explicitly specified mountpoints, instead of displaying the usual listing.
 
 One possible solution to this would be for the translator startup mechanism to
 update the `mtab` on any `mount`/`unmount`, like in traditional systems.
@@ -31,7 +31,7 @@ with passive translators, i.e., translators that are not presently running, but
 set up to be started automatically whenever the node is accessed?  Probably
 these should be counted among the mounted filesystems; but how to handle the
 `mtab` updates for a translator that is not started yet?  Generally, being
-centralized and event-based, this is a pretty unelegant, non-hurdish solution.
+centralized and event-based, this is a pretty inelegant, non-hurdish solution.
 
 A more promising approach is to have `mtab` exported by a special translator,
 which gathers the necessary information on demand.  This could work by
@@ -64,7 +64,7 @@ other filtering rules might be desirable.
 
 After taking decisions on the outstanding design questions, the student will
 implement both the actual [[mtab_translator|hurd/translator/mtabfs]], and the
-necessery interface(s) for gathering the data.  It requires getting a good
+necessary interface(s) for gathering the data.  It requires getting a good
 understanding of the translator mechanism and Hurd interfaces in general.
 
 Possible mentors: Olaf Buddenhagen (antrik), Carl Fredrik Hammar (cfhammar)
diff --git a/community/gsoc/project_ideas/namespace-based_translator_selection.mdwn b/community/gsoc/project_ideas/namespace-based_translator_selection.mdwn
index d40d73ac..67e3fc28 100644
--- a/community/gsoc/project_ideas/namespace-based_translator_selection.mdwn
+++ b/community/gsoc/project_ideas/namespace-based_translator_selection.mdwn
@@ -8,7 +8,7 @@ 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="Namspace-based Translator Selection"]]
+[[!meta title="Namespace-based Translator Selection"]]
 
 The main idea behind the Hurd is to make (almost) all system functionality
 user-modifiable ([[extensible_system|extensibility]]).  This includes a
@@ -26,7 +26,7 @@ file, and presents a virtual file with the uncompressed contents.  Or the other
 way around.  Or a translator that presents an
 [[XML_file_as_a_directory_tree|hurd/translator/xmlfs]].  Or an mbox as a set of
 individual files for each mail ([[hurd/translator/mboxfs]]); or ever further
-breaking it down into headers, body, attachements...
+breaking it down into headers, body, attachments...
 
 This gets even more powerful when translators are used as building blocks for
 larger applications: A mail reader for example doesn't need backends for
@@ -40,7 +40,7 @@ There are a few problems with the way translators are set, though. For one,
 once a translator is set on a node, you always see the translated content. If
 you need the untranslated contents again, to do a backup for example, you first
 need to remove the translator again. Also, having to set a translator
-explicitely before accessing the contents is pretty cumbersome, making this
+explicitly before accessing the contents is pretty cumbersome, making this
 feature almost useless.
 
 A possible solution is implementing a mechanism for selecting translators
@@ -61,7 +61,7 @@ place of the original ones.
 
 In the long run it's probably desirable to have the mechanism implemented in
 the standard name lookup mechanism, so it will be available globally, and avoid
-the overhead of a proxy; but for the beginnig the proxy solution is much more
+the overhead of a proxy; but for the beginning the proxy solution is much more
 flexible.
 
 The goal of this project is implementing a prototype proxy; perhaps also a
diff --git a/community/gsoc/project_ideas/nfs.mdwn b/community/gsoc/project_ideas/nfs.mdwn
index 683287f7..e7c18324 100644
--- a/community/gsoc/project_ideas/nfs.mdwn
+++ b/community/gsoc/project_ideas/nfs.mdwn
@@ -11,12 +11,12 @@ is included in the section entitled
 [[!meta title="Improved NFS Implementation"]]
 
 The Hurd has both NFS server and client implementations, which work, but not
-very well: File locking doesn't work properly (at least in conjuction with a
+very well: File locking doesn't work properly (at least in conjunction with a
 GNU/Linux server), and performance is extremely poor. Part of the problems
 could be owed to the fact that only NFSv2 is supported so far.
 
 (Note though that locking on the Hurd is problematic in general, not only in
-conjuction with NFS -- see the [[file_locking]] task.)
+conjunction with NFS -- see the [[file_locking]] task.)
 
 This project encompasses implementing NFSv3 support, fixing bugs and
 performance problems -- the goal is to have good NFS support. The work done in
diff --git a/community/gsoc/project_ideas/package_manager.mdwn b/community/gsoc/project_ideas/package_manager.mdwn
index 43e53f7c..23304f6b 100644
--- a/community/gsoc/project_ideas/package_manager.mdwn
+++ b/community/gsoc/project_ideas/package_manager.mdwn
@@ -37,7 +37,7 @@ came about.  There are no global databases of any kind.  (Some things might
 require caching for better performance, but this must happen transparently.)
 
 The core of this approach is formed by [[hurd/translator/stowfs]], which
-creates a traditional unix directory structure from all the files in the
+creates a traditional Unix directory structure from all the files in the
 individual package directories.  But this only handles the lowest level of
 package management.  Additional mechanisms are necessary to handle stuff like
 dependencies on other packages.
diff --git a/community/gsoc/project_ideas/perl.mdwn b/community/gsoc/project_ideas/perl.mdwn
deleted file mode 100644
index bfe1968e..00000000
--- a/community/gsoc/project_ideas/perl.mdwn
+++ /dev/null
@@ -1,30 +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="Improving Perl Support"]]
-
-Perl is available on the Hurd, but there are quite a lot of test suite
-failures. These could be caused by problems in the system-specific
-implementation bits of Perl, and/or shortcomings in the actual system
-functionality which Perl depends on.
-
-The goal of this project is to fix all of these problems if possible, or at
-least some of them. Some issues might require digging quite deep into Hurd
-internals, while others are probably easy to fix.
-
-Note that while some Perl knowledge is probably necessary to understand what
-the test suite failures are about, the actual work necessary to fix these
-issues is mostly C programming -- in the implementation of Perl and/or the
-Hurd.
-
-Possible mentors: Samuel Thibault (youpi)
-
-Exercise: Make some improvement to Perl support on the Hurd, e.g. fixing one of
-the known test suite failures.
diff --git a/community/gsoc/project_ideas/perl_python.mdwn b/community/gsoc/project_ideas/perl_python.mdwn
new file mode 100644
index 00000000..34e877ab
--- /dev/null
+++ b/community/gsoc/project_ideas/perl_python.mdwn
@@ -0,0 +1,38 @@
+[[!meta copyright="Copyright © 2009, 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="Improving Perl or Python Support"]]
+
+Perl and Python are available on the Hurd, but there are quite a lot of test suite
+failures. These could be caused by problems in the system-specific
+implementation bits of Perl/Python, and/or shortcomings in the actual system
+functionality which Perl/Python depends on.
+
+The student applying for this project can pick either Perl or Python,
+whichever he is more comfortable with.
+(Perl is higher priority though; and there are more failures too.)
+
+The goal then is to fix all of the problems with the chosen language if possible, or at
+least some of them. Some issues might require digging quite deep into Hurd
+internals, while others are probably easy to fix.
+
+Note that while some Perl/Python knowledge is probably necessary to understand what
+the test suite failures are about, the actual work necessary to fix these
+issues is mostly C programming -- in the implementation of Perl/Python and/or the
+Hurd.
+
+Possible mentors: Samuel Thibault (youpi)
+
+Exercise: Take a stab at one of the testsuite failures,
+and write a minimal testcase exposing the underlying problem.
+Actually fixing it would be a bonus of course --
+but as it's hard to predict which issues will be easy and which will be tricky,
+we will already be satisfied if the student makes a good effort.
+(We hope to see some discussion of the problems in this case though :-) )
diff --git a/community/gsoc/project_ideas/procfs.mdwn b/community/gsoc/project_ideas/procfs.mdwn
index 85eec43c..d4760aae 100644
--- a/community/gsoc/project_ideas/procfs.mdwn
+++ b/community/gsoc/project_ideas/procfs.mdwn
@@ -33,7 +33,7 @@ interfaces.)
 This project requires learning [[hurd/translator]] programming, and
 understanding some of the internals of process management in the Hurd.  It
 should not be too hard coding-wise; and the task is very nicely defined by the
-exising Linux `/proc` interface -- no design considerations necessary.
+existing Linux `/proc` interface -- no design considerations necessary.
 
 **Note**: We already have several applications for this task.
 
diff --git a/community/gsoc/project_ideas/secure_chroot.mdwn b/community/gsoc/project_ideas/secure_chroot.mdwn
index 0a08bbf5..feb30a7c 100644
--- a/community/gsoc/project_ideas/secure_chroot.mdwn
+++ b/community/gsoc/project_ideas/secure_chroot.mdwn
@@ -16,10 +16,10 @@ good, as it allows easily escaping the `chroot`, for example by use of
 [[passive_translators|hurd/translator]].
 
 Many solutions have been suggested for this problem -- ranging from simple
-workaround changing the behaviour of passive translators in a `chroot`;
-changing the context in which passive translators are exectuted; changing the
+workaround changing the behavior of passive translators in a `chroot`;
+changing the context in which passive translators are executed; changing the
 interpretation of filenames in a chroot; to reworking the whole passive
-translator mechanism.  Some involving a completely different approch to
+translator mechanism.  Some involving a completely different approach to
 `chroot` implementation, using a proxy instead of a special system call in the
 filesystem servers.
 
diff --git a/community/gsoc/project_ideas/server_overriding.mdwn b/community/gsoc/project_ideas/server_overriding.mdwn
index 80beab4c..c35d88de 100644
--- a/community/gsoc/project_ideas/server_overriding.mdwn
+++ b/community/gsoc/project_ideas/server_overriding.mdwn
@@ -14,7 +14,7 @@ The main idea of the Hurd is that every user can influence almost all system
 functionality ([[extensible_system|extensibility]]), by running private Hurd
 servers that replace or proxy the global default implementations.
 
-However, running such a cumstomized subenvironment presently is not easy,
+However, running such a customized subenvironment presently is not easy,
 because there is no standard mechanism to easily replace an individual standard
 server, keeping everything else.  (Presently there is only the [[hurd/subhurd]]
 method, which creates a completely new system instance with a completely
@@ -40,7 +40,7 @@ mechanism would have to check an override table on each lookup, and apply the
 desired replacement whenever a match is found.
 
 Another approach would be server-side overrides. Again there are various
-variants. The actual servers themself could provide a mechanism to redirect to
+variants. The actual servers themselves could provide a mechanism to redirect to
 other servers on request. (3) Or we could use some more generic server-side
 namespace overrides: Either all filesystem servers could provide a mechanism to
 modify the namespace they export to certain clients (4), or proxies could be
diff --git a/community/gsoc/project_ideas/sound.mdwn b/community/gsoc/project_ideas/sound.mdwn
index b92f76da..8411831b 100644
--- a/community/gsoc/project_ideas/sound.mdwn
+++ b/community/gsoc/project_ideas/sound.mdwn
@@ -36,7 +36,7 @@ Possible mentors: Samuel Thibault (youpi)
 Exercise: This project requires kernel (driver framework) hacking as well as
 some Hurd server hacking; so the exercise should involve either of these, or
 even both. You could for example port some newer driver to run in the existing
-framework (see the [[device_driver|driver_glue_code]] project descrption), or
+framework (see the [[device_driver|driver_glue_code]] project description), or
 try to make some fix(es) to the [unfinished random device
 implementation](http://savannah.gnu.org/patch/?6088) created by Michael
 Casadevall.
diff --git a/community/gsoc/project_ideas/tcp_ip_stack.mdwn b/community/gsoc/project_ideas/tcp_ip_stack.mdwn
index b56bff51..735c8bbb 100644
--- a/community/gsoc/project_ideas/tcp_ip_stack.mdwn
+++ b/community/gsoc/project_ideas/tcp_ip_stack.mdwn
@@ -21,7 +21,7 @@ more flexibly. Rather than just having the standard socket interface, plus some
 lower-level hooks for special needs, there are explicit (perhaps
 filesystem-based) interfaces at all the individual levels; special application
 can just directly access the desired layer. All kinds of packet filtering,
-routing, tunneling etc. can be easily achieved by stacking compononts in the
+routing, tunneling etc. can be easily achieved by stacking components in the
 desired constellation.
 
 Implementing a complete modular network stack is not feasible as a GSoC
diff --git a/community/gsoc/project_ideas/testsuites.mdwn b/community/gsoc/project_ideas/testsuites.mdwn
new file mode 100644
index 00000000..4f8d43fc
--- /dev/null
+++ b/community/gsoc/project_ideas/testsuites.mdwn
@@ -0,0 +1,52 @@
+[[!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="Fix Compatibility Problems Exposed by Testsuites"]]
+
+A number of software packages come with extensive testsuites.
+Some notable ones are Perl, Python, GNU Coreutils, and glib.
+While these testsuites were written mostly to track regressions in the respective packages,
+some of the tests fail on the Hurd in general.
+
+While in some cases these might point to wrong usage of system interfaces,
+most of the time such failures are actually caused by shortcomings in Hurd's implementation of these interfaces.
+These shortcomings are often not obvious in normal use,
+but can be directly or indirectly responsible for all kinds of failures.
+The testsuites help in isolating such problems,
+so they can be tracked down and fixed.
+
+This task thus consists in running some of the mentioned testsuites
+(and/or any other ones that come to mind),
+and looking into the causes of failures.
+The goal is to analyze all failures in one or more of the listed testsuites,
+to find out what shortcomings in the Hurd implementation cause them (if any),
+and to fix at least some of these shortcomings.
+
+Note that this task somewhat overlaps with the [[Perl/Python task|perl_python]] listed above.
+Here the focus however is not on improving the support for any particular program,
+but on fixing general problems in the Hurd.
+
+This is a very flexible task:
+while less experienced students should be able to tackle at least a few of the easier problems,
+other issues will be challenging even for experienced hackers.
+No specific previous knowledge is required for this task;
+only fairly decent C programming skills.
+While tracking down the various issues,
+the student will be digging into the inner workings of the Hurd,
+and thus gradually gaining the knowledge required for Hurd development in general.
+
+Possible mentors: Samuel Thibault (youpi)
+
+Exercise: Take a stab at one of the testsuite failures,
+and write a minimal testcase exposing the underlying problem.
+Actually fixing it would be a bonus of course --
+but as it's hard to predict which issues will be easy and which will be tricky,
+we will already be satisfied if the student makes a good effort.
+(We hope to see some discussion of the problems in this case though :-) )
diff --git a/community/gsoc/project_ideas/tmpfs.mdwn b/community/gsoc/project_ideas/tmpfs.mdwn
index 93215d07..63b4effe 100644
--- a/community/gsoc/project_ideas/tmpfs.mdwn
+++ b/community/gsoc/project_ideas/tmpfs.mdwn
@@ -15,7 +15,7 @@ actual disk storage, but only by anonymous memory, i.e. lives in the RAM (and
 possibly swap space).
 
 A simplistic way to implement such a memory filesystem is literally creating a
-ramdisk, i.e. simply allocating a big chunck of RAM (called a memory store in
+ramdisk, i.e. simply allocating a big chunk of RAM (called a memory store in
 Hurd terminology), and create a normal filesystem like ext2 on that.  However,
 this is not very efficient, and not very convenient either (the filesystem
 needs to be recreated each time the ramdisk is invoked).  A nicer solution is
diff --git a/community/gsoc/project_ideas/unionfs_boot.mdwn b/community/gsoc/project_ideas/unionfs_boot.mdwn
index 6c83092b..d9f1a9e1 100644
--- a/community/gsoc/project_ideas/unionfs_boot.mdwn
+++ b/community/gsoc/project_ideas/unionfs_boot.mdwn
@@ -11,7 +11,7 @@ is included in the section entitled
 [[!meta title="Allow Using unionfs Early at Boot"]]
 
 In [[UNIX]] systems, traditionally most software is installed in a common directory
-hierachy, where files from various packages live beside each other, grouped by
+hierarchy, where files from various packages live beside each other, grouped by
 function: user-invokable executables in `/bin`, system-wide configuration files
 in `/etc`, architecture specific static files in `/lib`, variable data in
 `/var`, and so on.  To allow clean installation, deinstallation, and upgrade of
diff --git a/community/gsoc/project_ideas/valgrind.mdwn b/community/gsoc/project_ideas/valgrind.mdwn
index 319d33a7..c6fc7459 100644
--- a/community/gsoc/project_ideas/valgrind.mdwn
+++ b/community/gsoc/project_ideas/valgrind.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2009 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2009, 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
@@ -8,12 +8,73 @@ 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="Porting valgrind to the Hurd"]]
+[[!meta title="Porting Valgrind to the Hurd"]]
 
-Valgrind is a very powerful tool to debunk bugs. However, in order to do so, it needs deep knowledge of the behavior of kernel traps. In the case of GNU/Hurd, there is a bunch of system calls that GNU Mach handles directly, but also all the MIG RPCs (Remote Procedure Calls) which return their result either inline or through memory allocated by the kernel.
+[Valgrind](http://valgrind.org/) is an extremely useful debugging tool for memory errors.
+(And some other kinds of hard-to-find errors too.)
+Aside from being useful for program development in general,
+a Hurd port will help finding out why certain programs segfault on the Hurd,
+although they work on Linux.
+Even more importantly, it will help finding bugs in the Hurd servers themselfs.
 
-The goal is thus to teach valgrind the exact semantics of all MIG RPCs, most probably in an automatic way from the .defs files.
+To keep track of memory use,
+Valgrind however needs to know how each system call affects the validity of memory regions.
+This knowledge is highly kernel-specific,
+and thus Valgrind needs to be explicitely ported for every system.
 
-As a starter, students can try to teach valgrind a couple of Linux ioctls, as this will make them learn how to use the read/write primitives of valgrind.
+Such a port involves two major steps:
+making Valgrind understand how kernel traps work in general on the system in question;
+and how all the individual kernel calls affect memory.
+The latter step is where most of the work is,
+as the behaviour of each single system call needs to be described.
+
+Compared to Linux,
+Mach (the microkernel used by the Hurd) has very few kernel traps.
+Almost all system calls are implemented as RPCs instead --
+either handled by Mach itself, or by the various Hurd servers.
+All RPCs use a pair of mach\_msg() invocations:
+one to send a request message, and one to receive a reply.
+However, while all RPCs use the same mach\_msg() trap,
+the actual effect of the call varies greatly depending on which RPC is invoked --
+similar to the ioctl() call on Linux.
+Each request thus must be handled individually.
+
+Unlike ioctl(),
+the RPC invocations have explicit type information for the parameters though,
+which can be retrieved from the message header.
+By analyzing the parameters of the RPC reply message,
+Valgrind can know exactly which memory regions are affected by that call,
+even without specific knowledge of the RPC in question.
+Thus implementing a general parser for the reply messages
+will already give Valgrind a fairly good approximation of memory validity --
+without having to specify the exact semantic of each RPC by hand.
+
+While this should make Valgrind quite usable on the Hurd already, it's not perfect:
+some RPCs might return a buffer that is only partially filled with valid data;
+or some reply parameters might be optional,
+and only contain valid data under certain conditions.
+Such specific semantics can't be deduced from the message headers alone.
+Thus for a complete port,
+it will still be necessary to go through the list of all known RPCs,
+and implement special handling in Valgrind for those RPCs that need it.
+
+The goal of this task is at minimum to make Valgrind grok Mach traps,
+and to implement the generic RPC handler.
+Ideally, specific handling for RPCs needing it should also be implemented.
+
+Completing this project will require digging into Valgrind's handling of system calls,
+and into Hurd RPCs.
+It is not an easy task, but a fairly predictable one --
+there shouldn't be any unexpected difficulties,
+and no major design work is necessary.
+It doesn't require any specific previous knowledge:
+only good programming skills in general.
+On the other hand,
+the student will obtain a good understanding of Hurd RPCs while working on this task,
+and thus perfect qualifications for Hurd development in general :-)
 
 Possible mentors: Samuel Thibault (youpi)
+
+Exercise: As a starter,
+students can try to teach valgrind a couple of Linux ioctls,
+as this will make them learn how to use the read/write primitives of valgrind.
diff --git a/community/gsoc/project_ideas/virtualization.mdwn b/community/gsoc/project_ideas/virtualization.mdwn
index 3a677306..822b8d99 100644
--- a/community/gsoc/project_ideas/virtualization.mdwn
+++ b/community/gsoc/project_ideas/virtualization.mdwn
@@ -25,7 +25,7 @@ desired constellations.
 The goal is to create a set of powerful tools for managing at least one
 desirable virtualization scenario. One possible starting point could be the
 [[hurd/subhurd]]/[[hurd/neighborhurd]] mechanism, which allows a second almost totally
-independant instance of the Hurd in parallel to the main one.
+independent instance of the Hurd in parallel to the main one.
 
 While subhurd allow creating a complete second system instance, with an own set
 of Hurd servers and [[UNIX]] daemons and all, there are also situations where it is
@@ -35,8 +35,8 @@ to create such a subenvironment with a single command would be very helpful.
 
 It might be possible to implement (perhaps as a prototype) a wrapper using
 existing tools (chroot and [[hurd/translator/unionfs]]); or it might require more specific tools,
-like some kind of unionfs-like filesytem proxy that mirrors other parts of the
-filesystem, but allows overriding individual locations, in conjuction with
+like some kind of unionfs-like filesystem proxy that mirrors other parts of the
+filesystem, but allows overriding individual locations, in conjunction with
 either chroot or some similar mechanism to create a subenvironment with a
 different root filesystem.
 
diff --git a/community/gsoc/project_ideas/vm_tuning.mdwn b/community/gsoc/project_ideas/vm_tuning.mdwn
index 9e802188..ecc5f9f4 100644
--- a/community/gsoc/project_ideas/vm_tuning.mdwn
+++ b/community/gsoc/project_ideas/vm_tuning.mdwn
@@ -14,7 +14,7 @@ Hurd/[[microkernel/Mach]] presently make very bad use of the available physical
 system. Some of the problems are inherent to the system design (the kernel
 can't distinguish between important application data and discardable disk
 buffers for example), and can't be fixed without fundamental changes. Other
-problems however are an ordinary lack of optimisation, like extremely crude
+problems however are an ordinary lack of optimization, like extremely crude
 heuristics when to start paging. (See <http://lists.gnu.org/archive/html/bug-hurd/2007-08/msg00034.html> for example.)
 Many parameters are based on assumptions from
 a time when typical machines had like 16 MiB of RAM, or simply have been set to
@@ -23,7 +23,7 @@ arbitrary values and never tuned for actual use.
 The goal of this project is to bring the virtual memory management in Hurd/Mach
 closer to that of modern mainstream kernels (Linux, FreeBSD), by comparing the
 implementation to other systems, implementing any worthwhile improvements, and
-general optimisation/tuning. It requires very good understanding of the Mach
+general optimization/tuning. It requires very good understanding of the Mach
 VM, and virtual memory in general.
 
 This project is related to [[!GNU_Savannah_task 5489]].
diff --git a/community/gsoc/project_ideas/xattr.mdwn b/community/gsoc/project_ideas/xattr.mdwn
index 55961547..7178d826 100644
--- a/community/gsoc/project_ideas/xattr.mdwn
+++ b/community/gsoc/project_ideas/xattr.mdwn
@@ -21,7 +21,7 @@ fields in the inode to store Hurd-specific metadata: most notable passive
 translator settings. As these fields are Hurd-specific, they can't be accessed
 by the standard methods from Linux for example, so it's not possible to fully
 work with a Hurd filesystem on GNU/Linux (copy, backup etc.); and also, even
-when on Hurd, only tools that explicitely support the Hurd-specific information
+when on Hurd, only tools that explicitly support the Hurd-specific information
 can handle them.
 
 Using extended attributes instead of custom fields for the Hurd-specific