4 files changed, 83 insertions, 6 deletions
diff --git a/community/gsoc/project_ideas/download_backends.mdwn b/community/gsoc/project_ideas/download_backends.mdwn
index f794e814..c0bdc5b2 100644
--- a/community/gsoc/project_ideas/download_backends.mdwn
+++ b/community/gsoc/project_ideas/download_backends.mdwn
@@ -1,12 +1,12 @@
-[[!meta copyright="Copyright © 2009 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2009, 2013 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]]."]]"""]]
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
 
 [[!meta title="Use Internet Protocol Translators (ftpfs etc.) as Backends for Other Programs"]]
 
@@ -19,8 +19,9 @@ 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 translator in the Hurd tree, as well as an [httpfs
-translator on hurdextras](http://www.nongnu.org/hurdextras/#httpfs); however,
+There is already an [[hurd/translator/ftpfs]] translator in the Hurd tree, as
+well as an [[hurd/translator/httpfs]] on
+[hurdextras](http://www.nongnu.org/hurdextras/); 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
 that are necessary for interactive use. (Progress indication, error codes, HTTP
diff --git a/community/gsoc/project_ideas/object_lookups.mdwn b/community/gsoc/project_ideas/object_lookups.mdwn
index 5075f783..88ffc633 100644
--- a/community/gsoc/project_ideas/object_lookups.mdwn
+++ b/community/gsoc/project_ideas/object_lookups.mdwn
@@ -40,3 +40,32 @@ accurate measurements in a system that lacks modern profiling tools would also
 be helpful.
 
 Possible mentors: Richard Braun
+
+
+# IRC, freenode, #hurd, 2013-09-18
+
+In context of [[!message-id "20130918081345.GA13789@dalaran.sceen.net"]].
+
+    <teythoon> braunr: (wrt the gnumach HACK) funny, I was thinking about doind
+      the same for userspace servers, renaming ports to the address of the
+      associated object, saving the need for the hash table...
+    <braunr> teythoon: see
+      http://darnassus.sceen.net/~hurd-web/community/gsoc/project_ideas/object_lookups/
+    <braunr> teythoon: my idea is to allow servers to set a label per port,
+      obtained at mesage recv time
+    <braunr> because, yes, looking up an object twice is ridiculous
+    <braunr> you normally still want port names to be close to 0 because it
+      allows some data structure optimizations
+    <teythoon> braunr: yes, I feared that ports should normally be smallish
+      integers and contigious at best
+    <teythoon> braunr: interesting that you say there that libihash suffers
+      from high collision rates
+    <teythoon> I've a theory to why that is, libihash doesn't do any hashing at
+      all
+    <pinotree> there are notes about that in the open_issues section of the
+      wiki
+    <teythoon> but I figured that this is probably ok for port names, as they
+      are small and contigious
+    <neal> braunr: That's called protected payload.
+    <neal> braunr: The idea is that the kernel appends data to the message in
+      flight.
diff --git a/community/gsoc/project_ideas/sound/discussion.mdwn b/community/gsoc/project_ideas/sound/discussion.mdwn
new file mode 100644
index 00000000..4a95eb62
--- /dev/null
+++ b/community/gsoc/project_ideas/sound/discussion.mdwn
@@ -0,0 +1,47 @@
+[[!meta copyright="Copyright © 2013 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]]."]]"""]]
+
+[[!taglink open_issue_documentation]]: update [[sound]] page.
+
+
+# IRC, freenode, #hurd, 2013-09-01
+
+    <rekado> I'm new to the hurd but I'd love to learn enough to work on sound
+      support.
+    <rekado>
+      http://darnassus.sceen.net/~hurd-web/community/gsoc/project_ideas/sound/
+      says drivers should be ported to GNU Mach as a first step.
+    <rekado> Is this information still current or should the existing Linux
+      driver be wrapped with DDE instead?
+    <auronandace> if i recall correctly dde is currently only being used for
+      network drivers. i'm not sure how much work would be involved for sound
+      or usb
+
+
+## IRC, freenode, #hurd, 2013-09-02
+
+    <rekado> The sound support proposal
+      (http://darnassus.sceen.net/~hurd-web/community/gsoc/project_ideas/sound/)
+      recommends porting some other kernel's sound driver to GNU Mach.  Is this
+      still current or should DDE be used instead?
+    <pinotree> rekado: dde or anything userspace-based is generally preferred
+    <braunr> rekado: both are about porting some other kernel's sound driver
+    <braunr> dde is preferred yes
+    <rekado> This email says that sound drivers are already partly working with
+      DDE: http://os.inf.tu-dresden.de/pipermail/l4-hackers/2009/004291.html
+    <rekado> So, should I just try to get some ALSA kernel parts to compile
+      with DDE?
+    <pinotree> well, what is missing is also the dde←→hurd glue
+    <braunr> rekado: there is also a problem with pci arbitration
+    <rekado> pinotree: I assumed DDEKit works with the hurd and we could use
+      any DDE/<other kernel> glue code with it
+    * rekado looks up pci arbitration
+    <pinotree> only for networking atm
+    <rekado> ah, I see.
diff --git a/community/gsoc/project_ideas/valgrind.mdwn b/community/gsoc/project_ideas/valgrind.mdwn
index 76675796..6663eec2 100644
--- a/community/gsoc/project_ideas/valgrind.mdwn
+++ b/community/gsoc/project_ideas/valgrind.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2009, 2010, 2011 Free Software Foundation,
+[[!meta copyright="Copyright © 2009, 2010, 2011, 2013 Free Software Foundation,
 Inc."]]
 
 [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable