fix merge

5 files changed, 60 insertions, 51 deletions

diff --git a/hurd/debugging/translator/capturing_stdout_and_stderr.mdwn b/hurd/debugging/translator/capturing_stdout_and_stderr.mdwn
index 646738b1..1e8c4ef6 100644
--- a/hurd/debugging/translator/capturing_stdout_and_stderr.mdwn
+++ b/hurd/debugging/translator/capturing_stdout_and_stderr.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2008 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2008, 2009 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
@@ -9,7 +9,8 @@ is included in the section entitled
 [[GNU Free Documentation License|/fdl]]."]]"""]]
 
 Sometimes it may already be helpful to capture a translator's `stdout` and
-`stderr`, for example like this:
+`stderr`, for example in this situation where [[translator/pfinet]] was
+silently dying all the time, without any console output:
 
     $ sudo settrans -fgap ↩
       /servers/socket/2 ↩
@@ -31,3 +32,7 @@ for appropriate `fflush`es on these, or force them to be line buffered again
 using the appropriate glibc magic (`setvbuf`).  Otherwise you'll see text in
 the output files only if either glibc herself decides to flush (after some KiB
 of text) the after translator exits.
+
+It is a [[!taglink open_issue_hurd]] to decide / implement / fix that
+(all?) running (passive?) translators' output should show up on the
+console / syslog.
diff --git a/hurd/porting/guidelines.mdwn b/hurd/porting/guidelines.mdwn
index 1beb53a0..5fd66292 100644
--- a/hurd/porting/guidelines.mdwn
+++ b/hurd/porting/guidelines.mdwn
@@ -170,12 +170,15 @@ This comes from ioctls.  Fixing this is easy if the structure members can be exp
 `#define _IOT_termios /* Hurd ioctl type field.  */ \
   _IOT (_IOTS (tcflag_t), 4, _IOTS (cc_t), NCCS, _IOTS (speed_t), 2)`
 
-because `struct termios` holds 4 members of type `tcflag_ts`, then `NCCS`
-members of type `cc_tsi` and finaly 2 members of type `speed_ts`.
-
-As you can see, this limits the number of kinds of members to 3, and in
-addition to that (see the bitfield described in `ioctls.h`), the third
-kind of member is limited to 3 members.
+The rationale behind is that on the Hurd ioctl numbers actually encode how the
+data should be transferred via RPC: here `struct termios` holds 4 members of
+type `tcflag_ts`, then `NCCS` members of type `cc_tsi` and finaly 2 members of
+type `speed_ts`, so the RPC mecanism will know how to transfer them.
+
+As you can see, this limits the number of contiguous kinds of members to 3, and
+in addition to that (see the bitfield described in `ioctls.h`), the third kind
+of member is limited to 3 members.  This is a design limitation, there is no way
+to overcome it at the moment.
 
 Note: if a field member is a pointer, then the ioctl can't be expressed
 this way, and that makes sense, since the server you're talking to
diff --git a/hurd/running/debian/porting.mdwn b/hurd/running/debian/porting.mdwn
index 10ee4c5c..aa044570 100644
--- a/hurd/running/debian/porting.mdwn
+++ b/hurd/running/debian/porting.mdwn
@@ -17,7 +17,7 @@ Hurd, however, many programs fail to build for various reasons.
 A [list of build failures including error
 messages](http://unstable.buildd.net/buildd/hurd-i386_Failed.html) can be
 found, as well as a [preliminary
-analysis](http://lists.debian.org/debian-hurd/2007/07/msg00000.html) of them and [solutions](http://lists.debian.org/debian-hurd/2007/07/msg00001.html).
+analysis](http://lists.debian.org/debian-hurd/2007/07/msg00000.html) of them and [solutions](http://lists.debian.org/debian-hurd/2007/07/msg00001.html), and some more details in [[hurd/porting/guidelines]].
 
 It might be a good idea to record your intention to port something either in
 the list below or in the [Alioth task
diff --git a/hurd/running/qemu.mdwn b/hurd/running/qemu.mdwn
index a059f3b1..48d87b35 100644
--- a/hurd/running/qemu.mdwn
+++ b/hurd/running/qemu.mdwn
@@ -71,7 +71,7 @@ Now take the number of sectors for the beginning of the partition and multiply i
 
 ## Having QEMU create *virtual FAT disk images*
 
-[Manual](http://fabrice.bellard.free.fr/qemu/qemu-doc.html#SEC24).
+[Manual](http://www.nongnu.org/qemu/qemu-doc.html#SEC25).
 
 QEMU has a facility to create FAT file systems on-the-fly:
 
@@ -97,7 +97,7 @@ If you just want to access the internet from within QEMU, you can setup pfinet f
     # settrans -afgp /servers/socket/2 /hurd/pfinet -i eth0 -a 10.0.2.15 -g 10.0.2.2 -m 255.255.255.0
     # echo "nameserver 10.0.2.3" > /etc/resolv.conf
 
-(See also <http://fabrice.bellard.free.fr/qemu/qemu-doc.html#SEC30>.)
+(See also <http://www.nongnu.org/qemu/qemu-doc.html#SEC32>.)
 
 Outgoing internet connections should just work then.
 
diff --git a/hurd/status.mdwn b/hurd/status.mdwn
index cc303dcf..3ee8ddcf 100644
--- a/hurd/status.mdwn
+++ b/hurd/status.mdwn
@@ -1,5 +1,5 @@
-[[!meta copyright="Copyright © 2001, 2002, 2007, 2008 Free Software Foundation,
-Inc."]]
+[[!meta copyright="Copyright © 2001, 2002, 2007, 2008, 2009 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
@@ -60,42 +60,43 @@ already expect delays; to disappoint them in this way as
 well would be unfortunate. Moreover, it would lessen the
 possibility that they would want to try the Hurd again in the future.
 
-## Usability status 2009-06-11
 
-*(This text is taken from two emails posted on the [[bug-hurd mailinglist|mailing_lists]] 
-by Olaf Buddenhagen)*
-
-I have been using the Hurd for most of my everyday work for some two
-years now. Most of the time it's pretty OK, but occasionally programs
-crash, or the screen session dies, or even the whole system. Also,
-various programs simply don't work at all, or don't work in certain
-situations.
-
-While I have learned to work around many of these issues, I don't
-believe I would be able to use it as my primary system, without having a
-GNU/Linux system running in parallel, as a fallback for all the stuff
-that doesn't work on the Hurd.
-
-My everyday work includes reading/writing email and other texts, preparing and giving
-presentations, text-mode web browsing, viewing pictures, IRC, reading
-PDF documents, programming, and various other random stuff...
-
-[...]
-
-One particular problem for desktop use is the fact that while X does
-work, it works very poorly -- it's not only slow and jerky all the time,
-but also tends to lock up completely. (At least with the local socket
-transport... Haven't tried whether forcing TCP works better.)
-
-Note that while many of the stability problems are simply bugs to fix,
-the system will still be very fragile in the absence of these -- a
-simple port leak is sufficient to kill it within seconds. This is
-something that can't be easily solved. Properly fixing this will require
-a sound resource accounting framework, i.e. very fundamental changes to
-the system... Though I tend to believe that it could be improved at
-least partially, at the expense of flexibility, by enforcing certain
-fixed limits on users, processes etc. like other UNIX systems do.
-
-[...]
-
-[But] unlike a few years back [...] the system is stable enough under load nowadays [...].
+## Usability Reports
+
+### Olaf Buddenhagen, 2009-06-09
+
+> I have been using the Hurd for most of my everyday work for some two
+> years now. Most of the time it's pretty OK, but occasionally programs
+> crash, or the screen session dies, or even the whole system. Also,
+> various programs simply don't work at all, or don't work in certain
+> situations.
+> 
+> While I have learned to work around many of these issues, I don't
+> believe I would be able to use it as my primary system, without having a
+> GNU/Linux system running in parallel, as a fallback for all the stuff
+> that doesn't work on the Hurd.
+> 
+> My everyday work includes reading/writing email and other texts, preparing and giving
+> presentations, text-mode web browsing, viewing pictures, IRC, reading
+> PDF documents, programming, and various other random stuff...
+> 
+> [...]
+> 
+> One particular problem for desktop use is the fact that while X does
+> work, it works very poorly -- it's not only slow and jerky all the time,
+> but also tends to lock up completely. (At least with the local socket
+> transport... Haven't tried whether forcing TCP works better.)
+> 
+> Note that while many of the stability problems are simply bugs to fix,
+> the system will still be very fragile in the absence of these -- a
+> simple port leak is sufficient to kill it within seconds. This is
+> something that can't be easily solved. Properly fixing this will require
+> a sound resource accounting framework, i.e. very fundamental changes to
+> the system... Though I tend to believe that it could be improved at
+> least partially, at the expense of flexibility, by enforcing certain
+> fixed limits on users, processes etc. like other UNIX systems do.
+> 
+> [...]
+> 
+> [But] unlike a few years back [...] the system is stable enough under
+> load nowadays [...].