Use proper headings for individual project ideas

1 files changed, 24 insertions, 24 deletions

diff --git a/community/gsoc/project_ideas.mdwn b/community/gsoc/project_ideas.mdwn
index 64af20c7..c25caf6a 100644
--- a/community/gsoc/project_ideas.mdwn
+++ b/community/gsoc/project_ideas.mdwn
@@ -17,7 +17,7 @@ If you have questions regarding the projects, or if there is more than one that
 you are interested in and you are unsure which to choose, don't hesitate to
 contact us -- on [[IRC]] or using [[mailing_lists]].
 
-* Lisp, Python, ... bindings
+## Lisp, Python, ... bindings
 
 The main idea of the Hurd design is giving users the ability to easily
 modify/extend the system's functionality. This is done by creating filesystem
@@ -50,7 +50,7 @@ choice, and some example servers to prove that it works well in practice. This
 project will require gaining a very good understanding of the various Hurd
 interfaces. Skills in designing nice programming interfaces are a must.
 
-* virtualization using Hurd mechanisms
+## virtualization using Hurd mechanisms
 
 The main idea behind the Hurd design is to allow users to replace almost any
 system functionality. Any user can easily create a subenvironment using some
@@ -121,7 +121,7 @@ Completing this project will require gaining a very good understanding of the
 Hurd architecture and spirit. Previous experience with other virtualization
 solutions would be very helpful.
 
-* namspace based translator selection
+## namspace based translator selection
 
 The main idea behind the Hurd is to make (almost) all system functionality
 user-modifiable. This includes a user-modifiable filesystem: The whole
@@ -181,7 +181,7 @@ programming; but the implementation should not be too hard. Perhaps the hardest
 part is finding a convenient, flexible, elegant, hurdish method for mapping the
 special extensions to actual translators...
 
-* fix file locking
+## fix file locking
 
 Over the years, UNIX has aquired a host of different file locking mechanisms.
 Some of them work on the Hurd, while others are buggy or only partially
@@ -195,7 +195,7 @@ them.
 This task will require digging into parts of the code to understand how file
 locking works on the Hurd. Only general programming skills are required.
 
-* procfs
+## procfs
 
 Although there is no standard (POSIX or other) for the layout of the /proc
 pseudo-filesystem, it turned out a very useful facility in GNU/Linux and other
@@ -222,7 +222,7 @@ 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.
 
-* new driver glue code
+## new driver glue code
 
 Although a driver framework in userspace would be desirable, presently the Hurd
 uses kernel drivers in the microkernel, gnumach. (And changing this would be
@@ -238,7 +238,7 @@ This is a doable, but pretty involved project. Experience with driver
 programming under Linux (or BSD) is a must. (No Hurd-specific knowledge is
 required, though.)
 
-* server overriding mechanism
+## server overriding mechanism
 
 The main idea of the Hurd is that every user can influence almost all system
 functionality, by running private Hurd servers that replace or proxy the global
@@ -288,7 +288,7 @@ This tasks requires some understanding of the Hurd internals, especially a good
 understanding of the file name lookup mechanism. It's probably not too heavy on
 the coding side.
 
-* dtrace support
+## dtrace support
 
 One of the main problems of the current Hurd implementation is very poor
 performance. While we have a bunch of ideas what could cause the performance
@@ -312,7 +312,7 @@ in their Mach-based kernel might be helpful here...)
 This project requires ability to evaluate possible solutions, and experience
 with integrating existing components as well as low-level programming.
 
-* hurdish TCP/IP stack
+## hurdish TCP/IP stack
 
 The Hurd presently uses a TCP/IP stack based on code from an old Linux version.
 This works, but lacks some rather important features (like PPP/PPPoE), and the
@@ -333,7 +333,7 @@ layers, it's up to the student to design and implement the various interfaces
 at each layer. This task requires understanding the Hurd philosophy and
 translator programming, as well as good knowledge of TCP/IP. 
 
-* improved NFS implementation
+## 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
@@ -350,7 +350,7 @@ important for now, and shall be the major focus of this project.
 The task has no special prerequisites besides general programming skills, and
 an interest in file systems and network protocols.
 
-* fix libdiskfs locking issues
+## fix libdiskfs locking issues
 
 Nowadays the most often encountered cause of Hurd crashes seems to be lockups
 in the ext2fs server. One of these could be traced recently, and turned out to
@@ -367,7 +367,7 @@ implementing unit checks in other parts of the Hurd codebase...)
 This task requires experience with debugging locking issues in multithreaded
 applications.
 
-* convert Hurd servers to pthreads
+## convert Hurd servers to pthreads
 
 The Hurd was originally created at a time when the pthreads standard didn't
 exist yet. Thus all Hurd servers and libraries are using the old cthreads
@@ -395,7 +395,7 @@ This project requires relatively little Hurd-specific knowledge. Experience
 with multithreaded programming in general and pthreads in particular is
 required, though.
 
-* sound support
+## sound support
 
 The Hurd presently has no sound support. Fixing this requires two steps: One is
 to port kernel drivers so we can get access to actual sound hardware. The
@@ -414,7 +414,7 @@ time for porting more drivers, or implementing a more sophisticated userspace
 infrastructure. The latter requires good understanding of the Hurd philosophy,
 to come up with an appropriate design.
 
-* disk I/O performance tuning
+## 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.
@@ -431,7 +431,7 @@ requires understanding the data flow through the various layers involved in
 disk acces on the Hurd (filesystem, pager, driver), and general experience with
 optimising complex systems.
 
-* VM tuning
+## VM tuning
 
 Hurd/Mach presently make very bad use of the available physical memory in the
 system. Some of the problems are inherent to the system design (the kernel
@@ -448,7 +448,7 @@ implementation to other systems, implementing any worthwhile improvements, and
 general optimisation/tuning. It requires very good understanding of the Mach
 VM, and virtual memory in general.
 
-* mtab
+## mtab
 
 In traditional monolithic system, the kernel keeps track of all mounts; the
 information is available through /proc/mounts (on Linux at least), and in a
@@ -503,7 +503,7 @@ implement both the actual mtab translator, and the necessery interface(s) for
 gathering the data. It requires getting a good understanding of the translator
 mechanism and Hurd interfaces in general.
 
-* gnumach code cleanup
+## gnumach code cleanup
 
 Although there are some attempts to move to a more modern microkernel
 alltogether, the current Hurd implementation is based on gnumach, which is only
@@ -531,7 +531,7 @@ This task requires good knowledge of C, and experience with working on a large
 existing code base. Previous kernel hacking experience is an advantage, but not
 really necessary.
 
-* xmlfs
+## xmlfs
 
 Hurd translators allow presenting underlying data in a different format. This
 is a very powerful ability: It allows using standard tools on all kinds of
@@ -569,7 +569,7 @@ This task requires pretty good designing skills. Good knowledge of XML is also
 necessary. Learning translator programming will obviously be necessary to
 complete the task.
 
-* allow using unionfs early at boot
+## 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
@@ -601,7 +601,7 @@ Completing this task will require gaining a very good understanding of the Hurd
 boot process and other parts of the design. It requires some design skills also
 to come up with a working mechanism.
 
-* fix tmpfs
+## fix tmpfs
 
 In some situations it is desirable to have a file system that is not backed by
 actual disk storage, but only by anonymous memory, i.e. lives in the RAM (and
@@ -629,7 +629,7 @@ implementation. It requires digging into some parts of the Hurd, incuding the
 pager interface and translator programming. This task probably doesn't require
 any design work, only good debugging skills.
 
-* lexical dot-dot resolution
+## lexical dot-dot resolution
 
 For historical reasons, UNIX filesystems have a real (hard) .. link from each
 directory pointing to its parent. However, this is problematic, because the
@@ -650,7 +650,7 @@ to use lexical resolution, and to check that the system is still fully
 functional afterwards. This task requires understanding the filename resolution
 mechanism. It's probably a relatively easy task.
 
-* secure chroot implementation
+## secure chroot implementation
 
 As the Hurd attempts to be (almost) fully UNIX-compatible, it also implements a
 chroot() system call. However, the current implementation is not really good,
@@ -675,7 +675,7 @@ new mechanisms. (Translators.) More important than the acualy code is the
 documentation of what he did: He must be able to defend why he chose a certain
 approach, and explain why he believes this approach really secure.
 
-* hurdish package manager for the GNU system
+## hurdish package manager for the GNU system
 
 Most GNU/Linux systems use pretty sophisticated package managers, to ease the
 management of installed software. These keep track of all installed files, and
@@ -710,7 +710,7 @@ mechanisms are necessary to handle stuff like dependencies on other packages.
 
 The goal of this task is to create these mechanisms.
 
-* To create an installer for Debian GNU/Hurd. 
+## To create an installer for Debian GNU/Hurd. 
 
 The idea is to port the debian installer to the hurd. The following link has some 
 relevant information http://wiki.debian.org/DebianInstaller/Hurd