Merge remote-tracking branch 'fp/master'

4 files changed, 73 insertions, 7 deletions

diff --git a/hurd/libstore/nbd_store.mdwn b/hurd/libstore/nbd_store.mdwn
index 8560fd44..3f161ba8 100644
--- a/hurd/libstore/nbd_store.mdwn
+++ b/hurd/libstore/nbd_store.mdwn
@@ -23,6 +23,17 @@ License|/fdl]]."]]"""]]
 Perhaps the protocol was extended?
 
 
+### IRC, freenode, #hurd, 2012-12-20
+
+    <youpi> if somebody has time to spend, building the nbd package makes
+      pfinet crash
+
+
+#### IRC, freenode, #hurd, 2012-12-21
+
+    <youpi> (in the testsuite)
+
+
 ## [xNBD](https://bitbucket.org/hirofuchi/xnbd/)
 
 
diff --git a/hurd/running/qemu/writeback_caching.mdwn b/hurd/running/qemu/writeback_caching.mdwn
index c9c53e3e..3b6c366b 100644
--- a/hurd/running/qemu/writeback_caching.mdwn
+++ b/hurd/running/qemu/writeback_caching.mdwn
@@ -1,5 +1,5 @@
-[[!meta copyright="Copyright © 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012
-Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2005, 2006, 2007, 2008, 2009, 2010, 2011, 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
@@ -13,7 +13,8 @@ License|/fdl]]."]]"""]]
 
 [[!tag open_issue_documentation]]
 
-IRC, freenode, #hurd, 2011-06-07
+
+# IRC, freenode, #hurd, 2011-06-07
 
     <braunr> hm, i guess i should have used cache=writeback with kvm before
       starting the debian installer :/
@@ -57,7 +58,8 @@ IRC, freenode, #hurd, 2011-06-07
     <braunr> well, if there is no I/O during downloading, downloading is faster
       :)
 
-IRC, freenode, #hurd, 2011-06-08
+
+# IRC, freenode, #hurd, 2011-06-08
 
     <braunr> youpi: does xen provide disk caching options ?
     <youpi> through a blktap, probably
@@ -70,7 +72,8 @@ IRC, freenode, #hurd, 2011-06-08
     <braunr> it really makes the hurd run a lot faster
     <braunr> as a workaround for emulators until I/O is reworked, ofc
 
-IRC, freenode, #hurd, 2011-06-09
+
+# IRC, freenode, #hurd, 2011-06-09
 
     <gnu_srs> braunr recommends to use writeback caching with kvm. Is this
       really recommended with the frequent crashes I experience?
@@ -88,3 +91,25 @@ IRC, freenode, #hurd, 2011-06-09
       as soon as the data is present in the host page cache.  This is safe as
       long as you trust your host.  If your host crashes or loses power, then
       the guest may experience data corruption." (from the qemu manpage)
+
+
+# IRC, freenode, #hurd, 2012-12-30
+
+    <gg0> http://bugs.debian.org/622319#51
+    <gg0> braunr: just pointing out writeback is default since qemu 1.3.0
+    <gg0> that makes hurd VMs faster by default :p
+    <braunr> ahh :)
+    <gg0> about data loss I had read (qemu man pages?) it may occur in case of
+      loss of power
+    <braunr> well yes
+    <gg0> probably on hurd may occur even with writethrough due to non
+      journaled ext2
+    <braunr> yes but the hurd flushes everything (and i mean everything) every
+      5 seconds
+    <gg0> http://lists.gnu.org/archive/html/qemu-devel/2012-02/msg02682.html
+    <braunr> so it's actually less likely to lose data because of the hurd than
+      because of power loss
+    <braunr> what i meant earlier is that we've never experienced unexpected
+      data loss because of qemu writeback policy
+    <braunr> if data is in the host cache and you lose power, qemu or not, you
+      lose data
diff --git a/hurd/translator.mdwn b/hurd/translator.mdwn
index 37f4e8bc..e0baf130 100644
--- a/hurd/translator.mdwn
+++ b/hurd/translator.mdwn
@@ -1,5 +1,5 @@
-[[!meta copyright="Copyright © 2007, 2008, 2009, 2010, 2011, 2012 Free Software
-Foundation, Inc."]]
+[[!meta copyright="Copyright © 2007, 2008, 2009, 2010, 2011, 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
@@ -57,6 +57,12 @@ the socket API calls (which are mapped by [[glibc]] to equivalent RPC calls)*,
 compared to *a [[libdiskfs]]-based translator implements a filesystem, based on
 a backing store*.
 
+As a translator is not different from any other user-space application, it can
+be written in any programming language.  The practicable constraint is that an
+interface suitable for doing [[RPC]]s should exist, which currently only exists
+for C ([[microkernel/mach/MIG]]).  For Lisp, Perl, [[user/jkoenig/Java]] there
+so far are only experimental and incomplete implementations.
+
 To learn how to write a translator, read the code!
 It is well documented, in particular, the header files.
 The [[Hurd_Hacking_Guide]] also has a tutorial.
diff --git a/hurd/translator/pfinet/ipv6.mdwn b/hurd/translator/pfinet/ipv6.mdwn
index d30cc850..edd31017 100644
--- a/hurd/translator/pfinet/ipv6.mdwn
+++ b/hurd/translator/pfinet/ipv6.mdwn
@@ -70,3 +70,27 @@ Amongst other things, support for [[IOCTL]]s is missing.
     <braunr> ok
     <braunr> i'd like to set this up on my VMs but it looks bugged :/
     <braunr> i can't manage to set correctly set the gateway
+
+
+### IRC, freenode, #hurd, 2012-12-12
+
+    <braunr> hm, pfinet seems not to support ipv6 well at all :(
+    <pinotree> braunr: really?
+    <braunr> pinotree: i can't manage to set a global address statically and
+      make it communicate with neighbours
+    <braunr> pfinet receives the advertisement (during neighbour discovery) but
+      immediately resends the same solicitation again
+    <gnu_srs> According to the pfinet/README IPv6 support was added in 2007
+      from Linux 2.2.14 while the rest is from 2.2.12
+    <braunr> according to me, bugs were added at the same time
+    <braunr> :p
+    <braunr> in addition, ipv6 in linux 2.2 was, uh, not working well either
+    <braunr> even with 2.4, it was still messy
+    <gnu_srs> maybe we should try to upgrade the TCP/IP stack to something
+      2.6+?
+    <gnu_srs> (a lot of work though)
+    <braunr> we've already had that discussion
+    <gnu_srs> Yes. What is the best way forward, a GSoC task? 
+    <gnu_srs> There is one already:
+      http://www.gnu.org/software/hurd/community/gsoc/project_ideas/tcp_ip_stack.html
+    <braunr> personally, i'd advocate resuing code from netbsd