14 files changed, 552 insertions, 14 deletions

diff --git a/hurd/translator/eth-filter.mdwn b/hurd/translator/eth-filter.mdwn
new file mode 100644
index 00000000..4f59b402
--- /dev/null
+++ b/hurd/translator/eth-filter.mdwn
@@ -0,0 +1,26 @@
+[[!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]]."]]"""]]
+
+# IRC, freenode, #hurd, 2013-07-27
+
+[[!tag open_issue_hurd]]
+
+    <youpi> ok, so as usual we actually *already* have a firewall
+    <youpi> it's the eth-filter translator from zheng da
+    <youpi> it has just never been really pushed forward...
+    <teythoon> good news :)
+    <youpi> well, the bad news is that it probably doesn't support connection
+      tracking
+    <youpi> since it's just bpf
+    <youpi> using the libpcap syntax
+    <teythoon> well, a stateless fw should do for Debian/Hurds needs for now,
+      right?
+    <youpi> yes
+    <youpi> and it does work indeed
diff --git a/hurd/translator/examples.mdwn b/hurd/translator/examples.mdwn
index 867d4935..4947808e 100644
--- a/hurd/translator/examples.mdwn
+++ b/hurd/translator/examples.mdwn
@@ -16,7 +16,7 @@ or [hurd-extras](http://www.nongnu.org/hurdextras/).
 
     cvs -z3 -d:pserver:anonymous@cvs.savannah.nongnu.org:/sources/hurdextras co <modulename> 
 
-* httpfs translator 
+* [[httpfs]] translator
 
 <!-- Prevent ikiwiki / Markdown rendering bug.  -->
 
@@ -28,7 +28,7 @@ or
     $ cd tmp/
     $ ls -l      
 
-* ftpfs translator
+* [[ftpfs]] translator
 
 <!-- Prevent ikiwiki / Markdown rendering bug.  -->
 
@@ -67,13 +67,13 @@ This is not as fast as `tar czvf newfile.tar.gz all my files`, but at least it's
 
     $ settrans -fgca /servers/socket/2 /hurd/pfinet -i <interface> -a <ip address> -m <subnet mask> -g <gateway ip>
    
-* Console translator -- setting up virtual consoles  
+* [[Console]] translator -- setting up virtual consoles
 
 <!-- Prevent ikiwiki / Markdown rendering bug.  -->
 
     $ console -d vga -d pc_mouse -d pc_kbd -d generic_speaker /dev/vcs
    
-* iso9660fs translator --  'mounting' your cdrom 
+* [[iso9660fs]] translator --  'mounting' your cdrom
 
 <!-- Prevent ikiwiki / Markdown rendering bug.  -->
 
diff --git a/hurd/translator/exec.mdwn b/hurd/translator/exec.mdwn
index 54abba7e..1dc0ea26 100644
--- a/hurd/translator/exec.mdwn
+++ b/hurd/translator/exec.mdwn
@@ -1,4 +1,5 @@
-[[!meta copyright="Copyright © 2009, 2012 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2009, 2012, 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
@@ -11,4 +12,9 @@ License|/fdl]]."]]"""]]
 The *exec* server, listening on `/servers/exec`, is responsible for
 preparing the execution of processes.
 
+
+# Open Issues
+
+  * [[open_issues/exec]].
+
   * [[open_issues/exec_memory_leaks]].
diff --git a/hurd/translator/ext2fs.mdwn b/hurd/translator/ext2fs.mdwn
index 20faed5e..e2f6b044 100644
--- a/hurd/translator/ext2fs.mdwn
+++ b/hurd/translator/ext2fs.mdwn
@@ -179,6 +179,69 @@ small backend stores, like floppy devices.
 That would be a nice improvement, but only after writeback throttling is implemented.
 
 
+## Stripped vs. Unstripped `ext2fs.static`
+
+[[!tag open_issue_hurd]]
+
+
+### IRC, freenode, #hurd, 2013-09-17
+
+    <teythoon> I always had some trouble with dropping a rebuild ext2fs.static
+      into my test system and I never figured out why
+    <teythoon> I just followed a hunch and stripped the binary, and all of the
+      sudden it works
+    <teythoon> any ideas why?
+    <tschwinge> teythoon: I quick search found me:
+      <https://savannah.gnu.org/bugs/?8497> and
+      <http://news.gmane.org/find-root.php?message_id=%3c4090243E.2040605%40comcast.net%3e>.
+    <teythoon> tschwinge: ugh, thanks for the pointers ;)
+    <tschwinge> teythoon: They won't help too much I fear.  Anyway, good
+      intuition (or whatever) ;-) that you found this out.
+    <tschwinge> teythoon: Not exactly related to stripped/unstripped per se
+      (that is, debug information), but in the past we've had an issue about
+      relro (see binutils/glibc, <http://www.airs.com/blog/archives/189>),
+      where a variable (that erroneously happend to be in such a read-only
+      section, if I remember correct) was tried to be modified -- which worked
+      "sometimes": depending on where exactly it was located in the binary
+      (which shifted around a page
+    <tschwinge> boundary by stripped/unstripped), it'd segfault or not.  Burnt
+      several days on that before Samuel (IIRC) eventually figured it out.
+    <teythoon> tschwinge: well, thanks anyway ;)
+
+
+## Increased Memory Consumption
+
+### IRC, freenode, #hurd, 2013-09-18
+
+    <braunr> ext2fs is using a ginormous amount of memory on darnassus since i
+      last updated the hurd package :/
+    <braunr> i wonder if my ext2fs large store patches rework have introduced a
+      regression
+    <braunr> the order of magnitude here is around 1.5G virtual space :/
+    <braunr> it used to take up to 3 times less before that
+    <braunr> looks like my patches didn't make it into the latest hurd package
+    <braunr> teythoon: looks like there definitely is a new leak in ext2fs
+    <teythoon> :/
+    <braunr> memory only
+    <braunr> the number of ports looks stable relative to file system usage
+    <teythoon> braunr: I tested my patches on my development machine, it's up
+      for 14 days (yay libvirt :) and never encountered problems like this
+    <braunr> i've been building glibc to reach that state
+    <teythoon> hm, that's a heavy load indeed
+    <teythoon> could be the file name tracking stuff, I tried to make sure that
+      everything is freed, but I might have missed something
+    <braunr> teythoon: simply running htop run shows a slight, regular increase
+      in physical memory usage in ext2fs
+    <pinotree> old procfs stikes again? :)
+    <teythoon> braunr: I see that as well... curious...
+    <braunr> 16:46 < teythoon> could be the file name tracking stuff, I tried
+      to make sure that everything is freed, but I might have missed something
+    <braunr> how knows, maybe completely unrelated
+    <teythoon> the tracking patch isn't that big, I've gone over it twice today
+      and it still seems reasonable to me
+    <braunr> hm
+
+
 # Documentation
 
   * <http://e2fsprogs.sourceforge.net/ext2.html>
diff --git a/hurd/translator/fifo.mdwn b/hurd/translator/fifo.mdwn
new file mode 100644
index 00000000..857922fc
--- /dev/null
+++ b/hurd/translator/fifo.mdwn
@@ -0,0 +1,48 @@
+[[!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]]."]]"""]]
+
+The *fifo* translator implements named pipes (FIFOs).
+
+
+# Open Issues
+
+## Not Terminating
+
+[[!tag open_issue_hurd]]
+
+
+### IRC, OFTC, #debian-hurd, 2013-07-28
+
+    <gg0> seems fifos started dying, as they should. am i wrong?
+    <gg0> ( http://bugs.debian.org/629184 )
+    <azeem> so you're saying the bug should be closed?
+    <azeem> best to comment on the bug then
+    <gg0> i didn't hear anyone working on it, so i'm a bit surprised
+    <azeem> could be due to lower-level fixes to glibc or so
+    <gg0> and given often(:|) i'm wrong, i was asking
+    <pinotree> in two years there have been various changes in glibc and hurd
+    <pinotree> (for example the switch to pthreads)
+    <gg0> yeah seems fixed. mknod'ing one then removing it, doesn't leave any
+      process around
+    <gg0> cool
+    <azeem> then please follow-up on the bug and/or close it
+    <gg0> sure
+    <gg0> the pleasure of closing it/them is yours
+    <gg0> great job, whatever you did :)
+
+
+### IRC, OFTC, #debian-hurd, 2013-07-29
+
+    * gg0 wonders if it can close savannah one as
+        wellhttps://savannah.gnu.org/bugs/?17128
+    <pochu> gg0: wdym?
+    <pochu> gg0: got an example?
+    <gg0> http://bugs.debian.org/629184
+    <gg0> i didn't close it myself
diff --git a/hurd/translator/hostmux.mdwn b/hurd/translator/hostmux.mdwn
index 5fab2dc5..ef16505b 100644
--- a/hurd/translator/hostmux.mdwn
+++ b/hurd/translator/hostmux.mdwn
@@ -29,3 +29,18 @@ When <code>**/ftp**</code> is accessed, the first directory is interpreted as ho
 You can see the new created translator in the process list: <code>**ps ax | grep ftpsfs**</code> . You shoud see <code>**/hurd/ftpfs / ftp.yourhost.com**</code> .
 
 -- [[Main/PatrickStrasser]] - 13 Jul 2004
+
+
+# Open Issues
+
+## IRC, freenode, #hurd, 2013-09-21
+
+[[!tag open_issue_hurd]]
+
+    <jproulx> ls /http://<ip>:<port>/
+    <jproulx> the image came with a global translator though I see it doesn't
+      grokk the alternate port notation.
+    <youpi> oh right
+    <jproulx> I shall return to the fine documentation
+    <youpi> it's a hostmux, it doesn't understand ports
+    <youpi> damn, one thus can't url plain urls with that scheme
diff --git a/hurd/translator/httpfs.mdwn b/hurd/translator/httpfs.mdwn
new file mode 100644
index 00000000..dc4a62f7
--- /dev/null
+++ b/hurd/translator/httpfs.mdwn
@@ -0,0 +1,100 @@
+[[!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]]."]]"""]]
+
+`httpfs` is a virtual filesystem allowing you to access web pages and files.
+
+
+# Source
+
+<http://www.nongnu.org/hurdextras/#httpfs>
+
+
+# Documentation
+
+## IRC, freenode, #hurd, 2013-09-03
+
+[[!tag open_issue_documentation]]
+
+    <congzhang> hi, why I can't cd to /http:/richtlijn.be/~larstiq/hurd/ to do
+    <congzhang> 	    grep?
+    <pinotree> this is not ftp
+    <congzhang> it works for other file
+    <pinotree> ?
+    <congzhang> I can't cd to ~larstiq, I don't know why
+    <pinotree> http is not a filesystem protocol
+    <pinotree> while httpfs could try in representing it as such, it is not
+      something reliable
+    <congzhang> ok, it's not reliable
+    <congzhang> I expect it can expose dir like browser
+    <congzhang> so, the translator just know href from home page, and one by
+      one
+    <pinotree> uh?
+    <congzhang> if ...:80/a/b/c.png exits, but not has a href in homepage, so I
+      can't cd to a, right?
+    <pinotree> you are looking things from the wrong point of view
+    <pinotree> a web server can do anything with URLs, including redirecting,
+      URL rewriting and whatever else
+    <congzhang> so, how to understand httpfs's idea?
+    <congzhang> how httpfs list dir?
+    <pinotree> check its code
+    <congzhang> en, no need it's not reliable
+    <congzhang> it's not work, it's enough
+    <congzhang> I have an idea, for the file system, we explore dir level by
+      level, but for http, we change full path one 
+    <congzhang> once time
+    <congzhang> maybe can allow user to cd any directory, and just mark as some
+      special color to make user know the translator was not sure, file exist
+      or not
+    <congzhang> once the file exits, mark all the parent directory as normal
+      color?
+    <rekado> congzhang: you can find more info about httpfs here:
+      http://nongnu.org/hurdextras/
+    <pinotree> congzhang: you're still looking at http from the wrong point of
+      view
+    <pinotree> there are no directories nor files
+    <pinotree> you start a request for a URL, and you get some content back (in
+      case there's no error)
+    <congzhang> you mean httpfs just for kidding?
+    <pinotree> that the content is a web page listing a directory on the
+      filesystem of the web server machine, or a file sent back via the
+      connection, or a complex web page, it's the same
+    <rekado> congzhang: you can only get a list of files if the web server
+      responds with an index of files
+    <pinotree> "files"
+    <rekado> The readme explains how httpfs does its thing:
+      http://cvs.savannah.gnu.org/viewvc/*checkout*/httpfs/README?root=hurdextras
+    <congzhang> if I can't cd to /http:/host/a/b how to get
+      /http:/host/a/b/c.html, even the file exist?
+    <pinotree> you don't cd in http
+    <pinotree> cd is for changing directory, which does not apply to a protocol
+      like http which is not fs-oriented
+    <congzhang> yes, I agree with you, http was not fs-oriented
+    <congzhang> so httpfs was not so useful
+    <rekado> You can access the document directly, though, can't you?
+    <congzhang> rekado: I try once more
+    <congzhang> I can't
+    <congzhang> so, the httpfs need some extend, http protocol was not fs
+      oriented, so need some extend to make it work with file system
+    <pinotree> http is not designed for file system usage, so extending it is
+      useless
+    <congzhang> or, httpfs was not so useful
+    <pinotree> there are many other protocols for file systems
+    <congzhang> I don't think so
+    <pinotree> i do
+    <congzhang> if we can't make it more useful, remove it from hurd rep, or
+      extend it more useful
+    <congzhang> add some more rule, to make it work with file system
+    <pinotree> no
+    <congzhang> some paradox in it
+    <pinotree> which paradox?
+    <congzhang> for http vs file system
+    <pinotree> ???
+    <congzhang> tree oriented and  star topology oriented?
+    <pinotree> you don't make any sense
diff --git a/hurd/translator/nsmux.mdwn b/hurd/translator/nsmux.mdwn
index d156772b..6b3be79c 100644
--- a/hurd/translator/nsmux.mdwn
+++ b/hurd/translator/nsmux.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]]."]]"""]]
 
 # nsmux
 
@@ -119,3 +119,24 @@ of the simplest use-case of namespace-based translator selection in
 the form of translator `nsmux`.  The filter is partially implemented
 and this is the immediate goal.  Propagating translators down
 directories is the next objective.
+
+
+## Open Issues
+
+### IRC, freenode, #hurd, 2013-08-22
+
+[[!tag open_issue_hurd]]
+
+    < youpi> err, is nsmux supposed to work at all?
+    < youpi> a mere ls doesn't work
+    < youpi> I'm running it as a user
+    < youpi> echo * does work though
+    < teythoon> ah, yes, nsmux,,is,,funny :p
+    < youpi> well, perhaps but I can't make it work
+    < youpi> well, the trivial ,,hello does work
+    < youpi> but ,,tarfs doesn't seem to be working for instance
+    < youpi> same for ,,mboxfs
+    < youpi> ,,xmlfs seems to somehow work a bit, but not very far...
+    < youpi> so it seems just nobody is caring about putting READMEs wherever
+      appropriate
+    < youpi> e.g. examples in socketio/ ...
diff --git a/hurd/translator/pfinet.mdwn b/hurd/translator/pfinet.mdwn
index f6f69ea4..bf535b21 100644
--- a/hurd/translator/pfinet.mdwn
+++ b/hurd/translator/pfinet.mdwn
@@ -1,5 +1,5 @@
-[[!meta copyright="Copyright © 2002, 2004, 2005, 2007, 2008, 2011 Free Software
-Foundation, Inc."]]
+[[!meta copyright="Copyright © 2002, 2004, 2005, 2007, 2008, 2011, 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
@@ -33,6 +33,9 @@ installation.
 
   * [[DHCP]].
 
+  * [[IPv6]].
+
+  * [[eth-filter]]: Firewall.
+
   * [[Implementation]].
 
-  * [[IPv6]].
diff --git a/hurd/translator/pfinet/implementation.mdwn b/hurd/translator/pfinet/implementation.mdwn
index a77f1b10..3e66c870 100644
--- a/hurd/translator/pfinet/implementation.mdwn
+++ b/hurd/translator/pfinet/implementation.mdwn
@@ -27,6 +27,170 @@ implementation.
     <youpi> oh
     <braunr> http://jl-icase.home.comcast.net/~jl-icase/LinuxTCP2.html
 
+## IRC, freenode, #hurd, 2013-09-03
+
+In context of the item on [[/contributing]].
+
+    <rekado> About this task: "Make pfinet OK with the ethernet device going
+      away." --- how can I test this? How can I remove the ethernet device?
+    <pinotree> settrans on the ethernet device, handled by the netdde
+      translator
+    <pinotree> that is, make it go away (settrans -fg)
+    <rekado> Ah, I see.
+    <rekado> Thanks
+    <pinotree> check its status before with showtrans
+    <pinotree> then, after having made it go away, set it again
+    <rekado> I don't think I'm doing this right... After `settrans -fg
+      /dev/eth0` I should not be able to access the network anymore, but it
+      still works.
+    <rekado> How can I figure out which of the four network devices is actually
+      used?
+    <braunr> rekado: the file system is used to open files, i.e. access
+      services
+    <braunr> it's not used to revoke access
+    <braunr> once pfinet has obtained a port to the network device, it keeps it
+    <rekado> oh, yes, of course.  Sorry, this is all very
+      new to me.
+    <rekado> I'm not sure what the problem is that this task describes.  In
+      what way is pfinet "not OK" with the ethernet device going away?
+    <braunr> rekado: the idea is to make pfinet able to cope with a driver
+      crash
+    <rekado> Can I trigger a driver crash for test purposes? (Or do I have to
+      build a purposefully broken driver first?)
+    <braunr> use kill
+    <rekado> Oh, good.
+    <braunr> iirc, netdde doesn't restart correctly :x
+    <braunr> you'll probably have to fix it a bit
+    <braunr> i guess there is some persistent state that prevents it from
+      reinitializing correctly
+    <rekado> okay
+    <rekado> I may need one more pointer: where can I find the netdde code?
+      Grep'ing around I only see it only mentioned as an argument to
+      /hurd/devnode; also: should I work in some incubator branch or directly
+      in the hurd repo?
+    <braunr> rekado: incubator branch
+    <rekado> Okay. Thank you for your patience.  I'll play with this in the
+      next few days.
+    <braunr> enjoy
+    <rekado> :)
+
+
+### IRC, freenode, #hurd, 2013-09-05
+
+    <rekado> When I kill the /hurd/netdde process I can no longer access the
+      network (as expected);
+    <rekado> To restore connectivity I run "settrans -g eth0 /hurd/devnode -M
+      /dev/netdde eth0" from the /dev directory.
+    <rekado> When I access the network again everything is fine. (I do see a
+      message telling me "irq handler 11: release an dead delivery port"
+    <rekado> )
+    <rekado> Is it the goal to avoid having to run settrans again to run netdde
+      after it crashes or is killed?
+    <youpi> you don't need to run settrans again
+    <youpi> that should get triggered automatically
+    <rekado> Hmm, after killing netdde I get "Resource lost" when using wget.
+    <rekado> It doesn't seem to be restarted automatically.
+    <youpi> try again
+    <youpi> the first wget makes pfinet try to use netdde and fail, thus crash
+    <youpi> the second wil respawn pfinet
+    <youpi> ideally pfinet shouldn't die, that's a TODO mentioned in the
+      "contributing page"
+    <rekado> Ah, so that's what should be prevented.
+    <youpi> it's just a matter of making pfinet be fine with errors from the
+      eth translator, and simply reopen it instead of dying
+    <rekado> That's the thing I've been trying to figure out.
+    <rekado> when I run wget a second (or third) time I get a different error;
+      "Name or service not known."
+    <rekado> It's only okay again when I use settrans
+    <youpi> maybe the devnode translator also needs some fixing
+    <youpi> it's odd that I don't have the issue though
+    <rekado> I'm using the qemu image, updated just yesterday.
+    <youpi> same here
+    <youpi> anyway, now you know where to put your hands :)
+    <rekado> yes, thanks a lot.
+
+
+### IRC, freenode, #hurd, 2013-09-07
+
+    <rekado> in pfinet/ethernet.c:ethernet_open there's an assertion:
+      edev->ether_port == MACH_PORT_NULL
+    <rekado> This is violated when netdde was killed and the device is
+      reopened.
+    <rekado> I'm not sure what should be done: destroy the port before
+      reopening or drop the assertion?
+    <rekado> If I drop the assertion, Mach seems to handle this just fine.
+    <rekado> Says "irq handler 11: release an [sic] dead delivery port" and
+      then carries on without problems.
+    <rekado> Is this a warning or an error, or can this be ignored?
+    <rekado> (or none of the above?)
+
+
+### IRC, freenode, #hurd, 2013-09-08
+
+    <rekado> I have a simple patch for pfinet that lets it recover from an
+      error in ethernet_xmit when /hurd/netdde and /hurd/devnode have been
+      killed.
+    <rekado> It doesn't work, though, when only netdde has been killed.
+    <rekado> With devnode still around device_open fails with "(ipc/send)
+      invalid destination port"
+    <rekado> I don't know where device_open is defined and why this error is
+      returned.
+    <rekado> I guess the error refers to the "master_device" port returned by
+      file_name_lookup() in ethernet_open()
+    <rekado> Why would file_name_lookup() return an invalid port when netdde is
+      dead but devnode is still running?
+    <braunr> rekado: maybe because devnode needs to perform a fresh lookup as
+      well
+
+
+### IRC, freenode, #hurd, 2013-09-09
+
+    <rekado> braunr: re devnode: devnode only performs a single lookup in
+      parse_opt(), i.e. at start-up.
+    <rekado> I'll try to understand devnode enough to patch it.
+    <braunr> rekado: that's the problem
+    <braunr> it should perform a lookup every time it's opened
+
+[[!message-id "1378730237-8091-1-git-send-email-rekado@elephly.net"]],
+[[!message-id "1378731824-8928-1-git-send-email-rekado@elephly.net"]].
+
+    <rekado> I submitted two patches to the mailing list.  I've tested them on
+      Debian GNU/Hurd but based them on the incubator/dde branch.
+    <teythoon> rekado: awesome, reliability fixes are very much welcome
+
+
+### IRC, freenode, #hurd, 2013-09-18
+
+    <rekado> youpi: my apologies for the delay in getting back to you with
+      improvements to my pfinet/devnode patches. Been very busy.
+    <braunr> rekado: development pace on the hurd has always been slow, no need
+      to apologize
+
+## MAC Addresses
+
+[[!tag open_issue_hurd]]
+
+
+### IRC, freenode, #hurd, 2013-09-21
+
+    <jproulx> what command will show me the MAC address of an interface?
+    <youpi> ah, too bad inetutils-ifconfig doesn't seem to be showing it
+    <youpi> I don't think we already have a tool for that
+    <youpi> it would be a matter of patching inetutils-ifconfig
+
+
+## Routing Tables
+
+[[!tag open_issue_hurd]]
+
+
+### IRC, freenode, #hurd, 2013-09-21
+
+    <jproulx> Hmmm, OK I can work around that, what about routing tables, can I
+      see them?  can I add routes besides the pfinet -g default route?
+    <youpi> I don't think there is a tool for that yet
+    <youpi> it's not plugged inside pfinet anyway
+
 
 # Reimplementation, [[!GNU_Savannah_task 5469]]
 
diff --git a/hurd/translator/pflocal.mdwn b/hurd/translator/pflocal.mdwn
index dc2434dc..fdcc39f1 100644
--- a/hurd/translator/pflocal.mdwn
+++ b/hurd/translator/pflocal.mdwn
@@ -1,13 +1,35 @@
-[[!meta copyright="Copyright © 2000, 2008 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2000, 2008, 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]]."]]"""]]
 
 The implementation of the `pflocal` server is in the `pflocal` directory, and
 uses [[`libpipe`|libpipe]] (shared code with the [[named_pipe|fifo]]
 implementation).
+
+
+# Open Issues
+
+## `SO_REUSEADDR`
+
+### IRC, freenode, #hurd, 2013-09-19
+
+    <gnu_srs> Hi, is SO_REUSEADDR supported at all on Hurd? I can only find two
+      entries: 
+    <gnu_srs> in libdde-linux26 and pfinet/linux-src, and the functionality
+      seems to be unimplemented.
+    <pinotree> gnu_srs: pfinet supports it
+    <youpi> gnu_srs: grep talks about  pfinet/linux-src/net/core/sock.c:
+      case SO_REUSEADDR:
+    <youpi> two times
+    <gnu_srs> Yes, and that is the implementation?
+    <gnu_srs> I wrote a test for AF_INET and it works, but not for AF_UNIX
+      (maybe not so interesting case).
+    <pinotree> pflocal does not support it
+    <gnu_srs> Is that of interest at all?
diff --git a/hurd/translator/proc.mdwn b/hurd/translator/proc.mdwn
index 98940f87..d5e0960c 100644
--- a/hurd/translator/proc.mdwn
+++ b/hurd/translator/proc.mdwn
@@ -51,3 +51,25 @@ It is stated by `/hurd/init`.
       it could just exec sysvinit
     <teythoon> I just think it's easier to patch hurd than to remove the
       assumption that init is pid 1 from sysvinit
+
+
+## IRC, freenode, #hurd, 2013-09-13
+
+    <braunr> teythoon: also, as a feature request, i'd like the proc server not
+      to have pid 0, if you have any time to do that
+    <braunr> so it appears in top and friends
+    <teythoon> braunr: noted, that should be easy
+    <teythoon> not using 0 is probably a good thing, many things use pid 0 as
+      something special
+
+
+# Process Discovery
+
+## IRC, freenode, #hurd, 2013-08-26
+
+    < teythoon> somewhat related, I do not like the way the proc server just
+      creates processes for new mach tasks it discovers
+    < teythoon> that does not play well with subhurds for example
+    < braunr> teythoon: i agree with you on proc process-to-task mapping
+    < braunr> that's something i intend to completely rework on propel
+    < braunr> in a way similar to how pid namespaces work on linux
diff --git a/hurd/translator/procfs/jkoenig/discussion.mdwn b/hurd/translator/procfs/jkoenig/discussion.mdwn
index fcda453e..44b8cc77 100644
--- a/hurd/translator/procfs/jkoenig/discussion.mdwn
+++ b/hurd/translator/procfs/jkoenig/discussion.mdwn
@@ -150,6 +150,9 @@ License|/fdl]]."]]"""]]
     <youpi> it "just" needs to be commited :)
     <antrik> in either case, it can't hurt to bring this up again :-)
 
+[[community/gsoc/project_ideas/mtab/discussion]], *IRC, freenode, #hurd,
+2013-09-07*.
+
 
 # root group
 
@@ -305,6 +308,13 @@ License|/fdl]]."]]"""]]
 See also [[community/gsoc/project_ideas/mtab]].
 
 
+## IRC, freenode, #hurd, 2013-09-20
+
+    <pinotree> teythoon: should procfs now have $pid/mounts files pointing to
+      ../mounts?
+    <teythoon> pinotree: probably yes
+
+
 # `/proc/[PID]/auxv`
 
 Needed by glibc's `pldd` tool (commit
diff --git a/hurd/translator/ufs.mdwn b/hurd/translator/ufs.mdwn
new file mode 100644
index 00000000..4d611e95
--- /dev/null
+++ b/hurd/translator/ufs.mdwn
@@ -0,0 +1,38 @@
+[[!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]]."]]"""]]
+
+The `ufs` translator supports some kind of the Unix File System.  Beware, we're
+not aware of anybody having used/tested it in ages, so maybe it is very broken
+and will eat your data.
+
+
+# IRC, freenode, #hurd, 2013-08-30
+
+[[!tag open_issue_hurd]]
+
+    <Arne`> There might be a copyright problem: <nalaginrut> well, there seems
+      BSD-4clauses in the code:
+      http://git.savannah.gnu.org/cgit/hurd/hurd.git/tree/ufs/alloc.c
+    <Arne`> braunr, tschwinge: Do you have any info on that? 4-clause BSD and
+      GPL on the same code are a license incompatibility… 
+    <tschwinge> Arne`: I've put it onto my (long) TODO list.
+    <tschwinge> Easiest solution might be: rm -rf ufs.
+    <nalaginrut> will these affected code rewritten? or just modify license?
+    <mark_weaver> only the regents of the University of California could choose
+      to modify the license.
+    <youpi> nalaginrut: one can't modify a licence if one is not the author
+    <youpi> we can simply dump the code
+    <mark_weaver> s/author/owner/
+    <tschwinge> As I suppose ufs is unused/untested for a decade or so, I'd
+      have no issues with simply removing it from the tree, together with
+      ufs-fsck and ufs-utils.
+    <pinotree> tschwinge: or maybe extract the ufs stuff in an own repo, to be
+      imported as branch in incubator or own hurd/ufs.git?
+    <tschwinge> Sure, why not.