Removed (link) placeholders -- students will soon start looking at this page, so it should not look like a draft anymore. (Even though it really is...)

1 files changed, 9 insertions, 17 deletions

diff --git a/community/gsoc/project_ideas.mdwn b/community/gsoc/project_ideas.mdwn
index c2921dd5..8d6b6efc 100644
--- a/community/gsoc/project_ideas.mdwn
+++ b/community/gsoc/project_ideas.mdwn
@@ -27,8 +27,6 @@ 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.
 
-(links)
-
 * hurdish TCP/IP stack
 
 The Hurd presently uses a TCP/IP stack based on code from an old Linux version.
@@ -50,8 +48,6 @@ 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. 
 
-(links)
-
 * new driver glue code
 
 Although a driver framework in userspace would be desirable, presently the Hurd
@@ -68,8 +64,6 @@ 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.)
 
-(links)
-
 * server overriding mechanism
 
 The main idea of the Hurd is that every user can influence almost all system
@@ -86,7 +80,7 @@ The goal of this project is to provide a simple method for overriding
 individual standard servers, using environment variables, or a special
 subshell, or something like that.
 
-Various approaches for such a mechanism has been discussed before. (links)
+Various approaches for such a mechanism has been discussed before.
 Probably the easiest (1) would be to modify the Hurd-specific parts of glibc,
 which are contacting various standard servers to implement certain system
 calls, so that instead of always looking for the servers in default locations,
@@ -133,7 +127,7 @@ the context in which passive translators are exectuted; changing the
 interpretation of filenames in a chroot; to reworking the whole passive
 translator mechanism. Some involving a completely different approch to chroot
 implementation, using a proxy instead of a special system call in the
-filesystem servers. (links)
+filesystem servers.
 
 The task is to pick and implement one approach for fixing chroot.
 
@@ -304,7 +298,7 @@ The reason for this slowness is lack and/or bad implementation of common
 optimisation techniques, like scheduling reads and writes to minimalize head
 movement; effective block caching; effective reads/writes to partial blocks;
 reading/writing multiple blocks at once. The ext2 filesystem driver might also
-need some optimisation at a higher logical level. (links)
+need some optimisation 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
@@ -329,8 +323,6 @@ 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.
 
-(links)
-
 * improved NFS implementation
 
 The Hurd has both NFS server and client implementations, which work, but not
@@ -340,7 +332,7 @@ could be owed to the fact that only NFSv2 is supported so far.
 
 This project encompasses implementing NFSv3 support, fixing bugs and
 performance problems -- the goal is to have good NFS support. The work done in
-a previous unfinished GSoC project can serve as a starting point. (link)
+a previous unfinished GSoC project can serve as a starting point.
 
 Both client and server parts need work, though the client is probably much more
 important for now, and shall be the major focus of this project.
@@ -357,7 +349,7 @@ implemented. This breaks many applications.
 The goal is to make all file locking mechanisms work properly. This requires
 finding all existing shortcomings (through systematic testing and/or checking
 for known issues in the bug tracker and mailing list archives), and fixing
-them. (links)
+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.
@@ -378,7 +370,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
-subhurd/neighbour Hurd mechanism (link), which allows a second almost totally
+subhurd/neighbour Hurd mechanism, which allows a second almost totally
 independant instance of the Hurd in parallel to the main one. The current
 implementation has serious limitations though. A subhurd can only be started by
 root. There are no communication channels between the subhurd and the main one.
@@ -450,7 +442,7 @@ debugging purposes; but this is highly system-specific anyways, so there is
 probably no point in trying to duplicate this functionality as well...)
 
 The existing partially working procfs implementation from the hurdextras
-repository (link) can serve as a starting point, but needs to be largely
+repository can serve as a starting point, but needs to be largely
 rewritten. (It should use libnetfs rather than libtrivfs; the data format needs
 to change to be more Linux-compatible; and it needs adaptation to newer system
 interfaces.)
@@ -547,7 +539,7 @@ translator also would be nice if time permits, but is not mandatory part of the
 task.
 
 The existing partial (read-only) xmlfs implementation from the hurdextras
-repository (link) can serve as a starting point.
+repository can serve as a starting point.
 
 This task requires pretty good designing skills. Good knowledge of XML is also
 necessary. Learning translator programming will obviously be necessary to
@@ -571,7 +563,7 @@ The Hurd has had such a tmpfs for a long time. However, the existing
 implementation doesn't work anymore -- it got broken by changes in other parts
 of the Hurd design.
 
-There are several issues. (links) The most serious known problem seems to be
+There are several issues. The most serious known problem seems to be
 that for technical reasons it receives RPCs from two different sources on one
 port, and gets mixed up with them. Fixing this is non-trivial, and requires a
 good understanding of the involved mechanisms.