Merge branch 'master' of flubber:~hurd-web/hurd-web

14 files changed, 290 insertions, 255 deletions

diff --git a/contributing/web_pages.mdwn b/contributing/web_pages.mdwn
index d1b3c0fc..b2e96121 100644
--- a/contributing/web_pages.mdwn
+++ b/contributing/web_pages.mdwn
@@ -130,13 +130,22 @@ is also read-only.
 
     $ git clone http://www.bddebian.com:8888/git/hurd-web [dest]
 
-For all cases: if you omit `[dest]` it will default to `hurd-web`.
+Or, you can check out the Savannah repository:
 
-Later, you can just `cd` into the `hurd-web` directory and run a `git pull` to
-get hold of the latest changes others have been installing in the mean time.
-(In most cases, you should use `git pull --rebase`,
-to avoid useless *Merge branch ...* messages.  See the
-Git documentation for details.)
+    $ git clone git://git.savannah.gnu.org/hurd/web.git [dest]
+
+See <http://git.savannah.gnu.org/cgit/hurd/web.git>.  If you're using the `ssh`
+protocol, and you're a member of the Hurd's [[rules/Savannah_group]], you can
+also push to this repository.  The disadvantage of pushing to the Savannah
+repository is that there is no [[ikiwiki]] installation where the pushed
+changes are immediatelly rendered and viewable by everyone.
+
+For all cases: if you omit `[dest]` it will default to `hurd-web` for the
+`bddebian.com` repositories, or `web` for a Savannah clone.
+
+Later, you can just `cd` into the `hurd-web` or `web` directory, and, for
+example, run `git pull` to get hold of the latest changes others have been
+installing in the mean time.
 
 ## Editing the Content
 
diff --git a/contributing/web_pages/news/moth_next.mdwn b/contributing/web_pages/news/moth_next.mdwn
index 2555cd73..cd03a366 100644
--- a/contributing/web_pages/news/moth_next.mdwn
+++ b/contributing/web_pages/news/moth_next.mdwn
@@ -25,7 +25,7 @@ else="
 
 <!--basic structure of a MotH entry. Adapt, reduce and add points as needed. At the end, try to make the text flow as a unified whole.-->
 
-This month [hurd hacker]  [item]
+In the third quarter of 2011, the [hurd hacker]  [item]
 
 Also …
 
@@ -43,27 +43,69 @@ And …
 
   * [[toolchain/ELFOSABI_GNU]]
 
-  * [Arch Hurd, DDE](http://www.archhurd.org/news/22/)
-
-  * Arch Hurd will have a booth at [FrOSCon](http://www.froscon.org/).
-
-  * Bits from the Debian GNU/Hurd porters,
-    id:"20110721172827.GF4057@const.famille.thibault.fr",
-    <http://lists.debian.org/debian-devel-announce/2011/07/msg00002.html>
-
-  * [[2011-q2-ps]]
-
-  * GSoC end
-
-  * mcsim memory allocator project
-
-  * GHM.
-
-      * <http://audio-video.gnu.org/video/ghm2011/>; Samuel.  Slides.  Also add
-      all to media.
-
-  * Richard's new buildd.
-
-    Is this for Q4?
+  * The Arch Hurd Hackers [packaged DDE](http://www.archhurd.org/news/22/), so
+    Linux 2.6 drivers can now be compiled on Arch Hurd to run in
+    userspace. At the time of writing it supports network cards, while
+    other driver-types still need their interfaces ported.
+
+  * Also they had
+    [a booth at FrOSCon](http://www.froscon.de/aussteller/projekt) and
+    [released a new Arch Hurd LiveCD](http://www.archhurd.org/news/24/),
+    so new users can easily test the current state of the Arch flavor
+    of the Hurd.
+
+  * The videos and slides from the GNU Hacker Meeting 2011 in Paris
+    are [online](http://www.gnu.org/ghm/2011/paris/), including the
+    talk from Samuel Thibault:
+    [GNU/Hurd, aka. Extensibility from the Ground](http://audio-video.gnu.org/video/ghm2011/Samuel_Thibault-GNU_Hurd.ogv)
+    ([slides](http://www.gnu.org/ghm/2011/paris/slides/samuel-thibault-hurd.pdf)). He
+    explains nicely how the simple concept of translators gives power
+    to non-priviledged and casual users (once we get some of those :)
+    ) without security implications, and how Sub-Hurds and
+    Neighbor-Hurds compare to Linux containers.
+
+        “It’s all about freedom #0”
+
+  * Samuel Thibault wrote a new
+    [Bits from the Debian GNU/Hurd porters](http://lists.debian.org/debian-devel-announce/2011/07/msg00002.html)
+
+  * Thomas Schwinge improved the technical documentation of the
+    [[hurd/io_path]] in translators to make it easier for new developers to start hacking.
+
+  * Guillem Jover, Fridolin Pokorny and Jonathan Neuschäfer
+    [sent](http://lists.gnu.org/bug-hurd/2011-08/msg00184.html)
+    [many](http://lists.gnu.org/bug-hurd/2011-08/msg00093.html)
+    [patches](http://lists.gnu.org/bug-hurd/2011-08/msg00030.html) for
+    gnumach, improving stability, fixing memory leaks and cleaning up
+    code.
+
+  * Jeremie Koenig finished his Google Summer of Code project to
+    [Improve Java on Hurd](http://www.gnu.org/software/hurd/user/jkoenig/java.html). He
+    [improved the Hurd signalling](http://lists.gnu.org/bug-hurd/2011-06/msg00073.html),
+    ported OpenJDK and created a
+    [Java Hurd-Library](https://github.com/jeremie-koenig/hurd-java)
+    which already allows writing a
+    [Hello World translator in Java](https://github.com/jeremie-koenig/hurd-java/blob/master/HelloMach.java),
+    though still pretty low-level.
+
+  * Maksym Planeta replaced GNUmach’s old zalloc memory allocator with
+    the new balloc from Richard Braun
+    ([integration commit](http://git.savannah.gnu.org/cgit/hurd/gnumach.git/commit/?id=50d073c5ef0feb1676606d0068abf626e8297cd7)),
+    which handles slabs and should waste less memory than zalloc. Also
+    balloc has a cpu cache level, so it should work faster on SMP
+    systems, once we get up do date SMP CPU drivers for GNUmach.
+
+  * 69.96% of debian packages
+    [are now available for the Hurd](https://buildd.debian.org/stats/graph-big.png),
+    so we’re getting closer to the goal of reaching 85%. If you can
+    port debian packages and want to help the Hurd, this is the
+    perfect time to get in contact and
+    [port your favorite missing package](http://www.debian.org/ports/hurd/hurd-devel-debian)
+    to the Hurd.
+  
+  * And Richard Braun contributed a new
+    [[buildd,_porterbox_and_public_box|public_hurd_boxen]] via
+    sceen.net, making it easier to test the Hurd without much setup as
+    well as improving debian packaging.
 
 """]]
diff --git a/open_issues/dde.mdwn b/open_issues/dde.mdwn
index 9e2ec742..e2cff94f 100644
--- a/open_issues/dde.mdwn
+++ b/open_issues/dde.mdwn
@@ -8,25 +8,8 @@ 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]]."]]"""]]
 
-[[General Information|/dde]].
-
-
-# IRC, freenode, #hurd, 2011-10-18
+[[!tag open_issue_hurd open_issue_gnumach]]
 
-[[!tag open_issue_hurd]]
-
-    [DDE crash, or similar]
-    <youpi> it's fake_local_irq_disable_flags(), then raw_local_irq_disable(),
-      then raw_local_irq_restore(), which *does not* release the cli_lock
-    <youpi> the "prove it" comment is (as I expected) completely wrong
-    <youpi> npnth: http://paste.debian.net/137784/
-
-[[137784]]
+[[General Information|/dde]].
 
-    <youpi> could you try this patch ?
-    <youpi> (I've not even tried to build it)
-    <npnth> youpi: speaking of which, it still seems to hang :/  I'll 1) double
-      check it applied correctly and 2) get a gdb output if it did
-    <youpi> npnth: could you add printing the value of unlock_refcnt?
-    <youpi> so we can check what's happening
-    <npnth> unlock_refcnt is at 0, interesting
+Still waiting for interface finalization and proper integration.
diff --git a/open_issues/dde/137784 b/open_issues/dde/137784
deleted file mode 100644
index 1529465b..00000000
--- a/open_issues/dde/137784
+++ /dev/null
@@ -1,43 +0,0 @@
-diff --git a/libdde_linux26/lib/src/arch/l4/cli_sti.c b/libdde_linux26/lib/src/arch/l4/cli_sti.c
-index 051f259..6a8c460 100644
---- a/libdde_linux26/lib/src/arch/l4/cli_sti.c
-+++ b/libdde_linux26/lib/src/arch/l4/cli_sti.c
-@@ -4,6 +4,8 @@
- 
- /* IRQ lock reference counter */
- static atomic_t      _refcnt   = ATOMIC_INIT(0);
-+/* Refcnt value at which unlocking the cli_lock (it's not always 0) */
-+static int unlock_refcnt;
- static ddekit_lock_t cli_lock;
- 
- /* Check whether IRQs are currently disabled.
-@@ -57,9 +59,6 @@ void fake_local_irq_restore(unsigned long flags)
- /* Store the current flags state.
-  *
-  * This is done by returning the current refcnt.
-- *
-- * XXX: Up to now, flags was always 0 at this point and
-- *      I assume that this is always the case. Prove?
-  */
- unsigned long __raw_local_save_flags(void)
- {
-@@ -82,7 +81,7 @@ void raw_local_irq_restore(unsigned long flags)
- {
- 	Assert(cli_lock != NULL);
- 	atomic_set(&_refcnt, flags);
--	if (flags == 0)
-+	if (flags == unlock_refcnt)
- 		ddekit_lock_unlock(&cli_lock);
- }
- 
-@@ -95,7 +94,9 @@ void raw_local_irq_disable(void)
- 	if (cli_lock == NULL)
- 		ddekit_lock_init_unlocked(&cli_lock);
- 
--	nested_lock(cli_lock);
-+	if (nested_lock(cli_lock))
-+		/* Tell the corresponding restorer to release cli_lock */
-+		unlock_refcnt = atomic_read(&_refcnt);
- 	atomic_inc(&_refcnt);
- }
- 
diff --git a/open_issues/libpthread_pthread_key_create_reuse.mdwn b/open_issues/libpthread_pthread_key_create_reuse.mdwn
deleted file mode 100644
index ca2da2f5..00000000
--- a/open_issues/libpthread_pthread_key_create_reuse.mdwn
+++ /dev/null
@@ -1,82 +0,0 @@
-[[!meta copyright="Copyright © 2011 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]]."]]"""]]
-
-[[!meta title="libpthread: pthread_key_create, reuse"]]
-
-[[!tag open_issue_libpthread]]
-
-IRC, FreeNode, #hurd, 2011-07-02:
-
-    < pinotree> hm, maybe i found a libpthread bug
-    * pinotree tries a testcase
-    < pinotree> yesssss, found the bug :)
-    < pinotree> youpi: it's a problem of the key reuse in pthread_key_create()
-    < youpi> it doesn't reset it?
-    < youpi> were you looking at the licq issue?
-    < pinotree> no, gtest
-    < youpi> k
-    < youpi> licq has a failing threadspecific issue
-    < youpi> [  FAILED  ] ThreadSpecificData.dataDeletedWhenThreadExits
-    < pinotree> basically, pthread_key_delete() does not delete the key values
-      from the "thread_specifics" ihash
-    < pinotree> but those were new keys, so i'm not sure it is allowed to
-      return values of previous keys?
-    < pinotree> after all, the actual key value is an implementation detail,
-      applications shouldn't care about it being reused
-    < pinotree> (imho)
-    < youpi> Upon key creation, the value NULL shall be associated with the new
-      key in all active threads.
-    < youpi> ok, so we have to clear it in all threads
-    < youpi> that's a pity
-    < pinotree> or just remove the entry from the hash on key removal
-    < youpi> pinotree: from all the hashes, you mean?
-    < pinotree> youpi: from how i see it, adding a snippet like
-      http://paste.debian.net/121690/ in pthread_key_delete() should do the job
-    < youpi> that only drops from the current thread
-    < pinotree> ah hm, other threads
-    < youpi> we need to drop from all  threads
-    < youpi> that's the pity part
-    < pinotree> youpi: the licq case could look like a similar issue, at a
-      veeery quick glance
-
-Test program: [[pthread_key_create_reuse.c]]
-
-
-2011-11-01:
-
-    <pinotree> youpi: about the bug with pthread keys (reuse): would be an
-      acceptable solution having a mutex for the thread_specifics of each
-      thread?
-    <youpi> you mean one per thread, one global, or one per key, or ?
-    <youpi> what is it supposed to protect?
-    <pinotree> the thread_specifics of each thread
-    <youpi> pinotree: but against what?
-    <pinotree> the idea would be: when destroying a key, iterate over all the
-      exiting threads and remove the key data from the thread_specifics of each
-      thread
-    <youpi> one of the issue is getting to browse through the whole list of
-      threads
-    <youpi> the other is concurrency between that, and a thread dying
-    <pinotree> there's the __pthread_threads_lock rwlock
-    <youpi> it should be enough to keep it locked during the iteration
-    <pinotree> but that wouldn't be enough when one thread is destroying a key,
-      and another one is doing {get,set}specific() on that key
-    <youpi> that's not supposed to happen
-    <pinotree> mmm
-    <youpi> “The effect of calling pthread_getspecific() or
-      pthread_setspecific() with a     key value not obtained from
-      pthread_key_create() or after key has been     deleted with
-      pthread_key_delete() is undefined.”
-    <youpi> undefined -> you are allowed to just blow up
-    <pinotree> but it's not been deleted yet... :)
-    <youpi> it could be, just a matter of time
-    <youpi> you're not supposed to rely on time-luckyness :)
-    <pinotree> mmm
-    <pinotree> bah, you've convinced me ( :) )
diff --git a/open_issues/libpthread_pthread_key_create_reuse/pthread_key_create_reuse.c b/open_issues/libpthread_pthread_key_create_reuse/pthread_key_create_reuse.c
deleted file mode 100644
index f7f5874e..00000000
--- a/open_issues/libpthread_pthread_key_create_reuse/pthread_key_create_reuse.c
+++ /dev/null
@@ -1,48 +0,0 @@
-#include <pthread.h>
-#include <stdio.h>
-#include <assert.h>
-
-#define DEBUG
-
-void del(void *x __attribute__((unused)))
-{
-}
-
-void work(int val)
-{
-  pthread_key_t key1;
-  pthread_key_t key2;
-
-#ifdef DEBUG
-  printf("work/%d: start\n", val);
-#endif
-  assert(pthread_key_create(&key1, &del) == 0);
-  assert(pthread_key_create(&key2, &del) == 0);
-#ifdef DEBUG
-  printf("work/%d: pre-setspecific: %p,%p\n", val, pthread_getspecific(key1), pthread_getspecific(key2));
-#else
-  assert(pthread_getspecific(key1) == NULL);
-  assert(pthread_getspecific(key2) == NULL);
-#endif
-  assert(pthread_setspecific(key1, (void *)(0x100 + val)) == 0);
-  assert(pthread_setspecific(key2, (void *)(0x200 + val)) == 0);
-#ifdef DEBUG
-  printf("work/%d: post-setspecific: %p,%p\n", val, pthread_getspecific(key1), pthread_getspecific(key2));
-#else
-  assert(pthread_getspecific(key1) == (void *)(0x100 + val));
-  assert(pthread_getspecific(key2) == (void *)(0x200 + val));
-#endif
-  assert(pthread_key_delete(key1) == 0);
-  assert(pthread_key_delete(key2) == 0);
-}
-
-int main()
-{
-  int i;
-
-  for (i = 0; i < 8; ++i) {
-    work(i + 1);
-  }
-
-  return 0;
-}
diff --git a/open_issues/performance/io_system/binutils_ld_64ksec.mdwn b/open_issues/performance/io_system/binutils_ld_64ksec.mdwn
index d0b8ea7f..931fd0ee 100644
--- a/open_issues/performance/io_system/binutils_ld_64ksec.mdwn
+++ b/open_issues/performance/io_system/binutils_ld_64ksec.mdwn
@@ -27,10 +27,6 @@ extracted from cdf7c161ebd4a934c9e705d33f5247fd52975612 sources, 2010-10-24.
 On the idle grubber, this one repeatedly takes a few minutes wall time to
 complete successfully, contrary to a few seconds on a GNU/Linux system.
 
-> On order of slowness may in fact be due to a Xen-specific issue, see
-> [[xen_lseek]].  (But there are probably still one or two orders left, even
-> without Xen.)
-
 While processing the object files, there is heavy interaction with the relevant
 [[hurd/translator/ext2fs]] process.  Running [[hurd/debugging/rpctrace]] on
 the testee shows that (primarily) an ever-repeating series of `io_seek` and
@@ -38,19 +34,6 @@ the testee shows that (primarily) an ever-repeating series of `io_seek` and
 shows the equivalent thing (`_llseek`, `read`) -- but Linux' I/O system isn't
 as slow as the Hurd's.
 
----
-
-IRC, freenode, #hurd, 2011-09-01:
-
-    <youpi> hum, f951 does myriads of   71->io_seek_request (32768 0) = 0 32768
-    <youpi> no wonder it's slow
-    <youpi> unfortunately that's also what it does on linux, the system call is
-      just less costly
-    <youpi> apparently gfortran calls io_seek for, like, every token of the
-      sourced file
-    <youpi> (fgetpos actually, but that's the same)
-    <youpi> and it is indeed about 10 times slower under Xen for some reason
-
-Also see testcase [[test-lseek.c]] and [[test-mach.c]]
-
-[[!tag open_issue_xen]]
+As Samuel figured out later, this slowness may in fact be due to a Xen-specific
+issue, see [[Xen_lseek]].  After the latter has been addressed, we can
+re-evaluate this issue here.
diff --git a/open_issues/xen_lseek.mdwn b/open_issues/xen_lseek.mdwn
index accc7c8f..756abf5e 100644
--- a/open_issues/xen_lseek.mdwn
+++ b/open_issues/xen_lseek.mdwn
@@ -10,6 +10,17 @@ License|/fdl]]."]]"""]]
 
 [[!tag open_issue_xen]]
 
+IRC, freenode, #hurd, 2011-09-01:
+
+    <youpi> hum, f951 does myriads of   71->io_seek_request (32768 0) = 0 32768
+    <youpi> no wonder it's slow
+    <youpi> unfortunately that's also what it does on linux, the system call is
+      just less costly
+    <youpi> apparently gfortran calls io_seek for, like, every token of the
+      sourced file
+    <youpi> (fgetpos actually, but that's the same)
+    <youpi> and it is indeed about 10 times slower under Xen for some reason
+
 IRC, freenode, #hurd, 2011-11-02:
 
     <youpi> btw, we have a performance issue with xen
@@ -33,3 +44,14 @@ IRC, freenode, #hurd, 2011-11-02:
       http://www.gnu.org/software/hurd/open_issues/performance/io_system/binutils_ld_64ksec.html
 
 [[performance/io_system/binutils_ld_64ksec]].
+
+Also see the simple testcases [[test-lseek.c]] and [[test-mach.c]].
+
+IRC, freenode, #hurd, 2011-11-05:
+
+    <youpi> [test-mach.c is] mostly as a reference for the trap overhead
+    <youpi> 0.56µs (xen) vs 0.48µs(kvm) on test-mach
+    <youpi> 455µs(xen) vs 16µs(kvm) on test-lseek
+    <youpi> that might simply be an issue in the RPC  mechanism, which behaves
+      badly with the xen memory management
+    <youpi> yes, about 0.5ms for an lseek, that's quite high :)
diff --git a/open_issues/performance/io_system/test-lseek.c b/open_issues/xen_lseek/test-lseek.c
index 667dce66..667dce66 100644
--- a/open_issues/performance/io_system/test-lseek.c
+++ b/open_issues/xen_lseek/test-lseek.c
diff --git a/open_issues/performance/io_system/test-mach.c b/open_issues/xen_lseek/test-mach.c
index 90337346..90337346 100644
--- a/open_issues/performance/io_system/test-mach.c
+++ b/open_issues/xen_lseek/test-mach.c
diff --git a/public_hurd_boxen.mdwn b/public_hurd_boxen.mdwn
index 5a281368..6bce8ffb 100644
--- a/public_hurd_boxen.mdwn
+++ b/public_hurd_boxen.mdwn
@@ -28,10 +28,14 @@ image|hurd/running/qemu]].
 "[[bddebian]]","goober","Debian GNU/Hurd","?"
 "[[bddebian]]","grubber","Debian GNU/Hurd","Celeron 2.2 GHz; 554 MiB","Xen domU on [[zenhost]]; for experimental stuff"
 "[[bddebian]]","[[zenhost]]","Debian GNU/Linux","Celeron 2.2 GHz","Xen dom0 for several hosts"
+"[[sceen]]","darnassus","Debian GNU/Hurd","Core i5 3.1 GHz, 1.8 GiB","KVM guest on shattrath; public Hurd box"
+"[[sceen]]","ironforge","Debian GNU/Hurd","Core i5 3.1 GHz, 1.8 GiB","KVM guest on shattrath; Debian buildd"
+"[[sceen]]","exodar","Debian GNU/Hurd","Core i5 3.1 GHz, 1.8 GiB","KVM guest on shattrath; Debian porterbox"
+"[[sceen]]","shattrath","Debian GNU/Linux","Core i5 3.1 GHz","KVM host"
 "Debian","[strauss.debian.net](http://strauss.debian.net/ssh)","Debian GNU/Hurd",,"all Debian Developers have access"
 """]]
 
-To request an account on the *[[bddebian]]* machines either contact
+To request an account on the *[[bddebian]]* or *[[sceen]]* machines, either contact
 *tschwinge* (other people might also be able to help) in [[IRC]]
 or send email to <hurd-shell-account@gnu.org> (please include your desired user
 name and public SSH key).  Also use these contact
@@ -41,14 +45,11 @@ addresses for requesting support with respect to software installations, etc.
 For easy access, you should append your public SSH key(s)
 to `~/.ssh/authorized_keys` on the remote machine.
 
-Also, add the [[!toggle id=bddebian_ssh_config text="following stanza (click
-here to toggle display)"]] to the `~/.ssh/config` file of the machine you're
-connecting from.
-
-[[!toggleable id=bddebian_ssh_config text="""
+Also, add the following stanza to the `~/.ssh/config` file of the machine
+you're connecting from.
 
     # Stanza from <http://www.gnu.org/software/hurd/public_hurd_boxen.html>,
-    # 2010-12-15.
+    # 2011-11-06.
 
     Host blubber.bddebian.com blubber
       HostName blubber.bddebian.com
@@ -80,13 +81,16 @@ connecting from.
       Port 2260
     
     Host blubber.bddebian.com blubber grubber.bddebian.com grubber snubber.bddebian.com snubber
-      ProxyCommand ssh zenhost socat - TCP4:%h:%p
+      # Tunnel through zenhost.
+      ProxyCommand ssh zenhost exec socat - TCP4:%h:%p
     
     Host *.bddebian.com blubber clubber flubber gnubber goober grubber snubber zenhost
+      # Don't worry about the IP address (dial-up connection).
       CheckHostIP no
       User [user name]
-
-The `CheckHostIP` statement is for not having to worry about the machines's IP
-addresses changing (due to being behind a dial-up connection).
-
-"""]]
+    
+    Host darnassus.sceen.net darnassus
+      HostName darnassus.sceen.net
+    
+    Host *.sceen.net darnassus
+      User [user name]
diff --git a/public_hurd_boxen/sceen.mdwn b/public_hurd_boxen/sceen.mdwn
new file mode 100644
index 00000000..25416857
--- /dev/null
+++ b/public_hurd_boxen/sceen.mdwn
@@ -0,0 +1,11 @@
+[[!meta copyright="Copyright © 2011 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]]."]]"""]]
+
+<http://www.sceen.net/>
diff --git a/user/Maksym_Planeta.mdwn b/user/Maksym_Planeta.mdwn
new file mode 100644
index 00000000..c44a4fcb
--- /dev/null
+++ b/user/Maksym_Planeta.mdwn
@@ -0,0 +1,135 @@
+[[!meta copyright="Copyright © 2011 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]]."]]"""]]
+
+[[!toc]]
+#Notes on tmpfs
+
+## mach-defpager
+
+[[defpager|http://www.bddebian.com:8888/~hurd-web/user/Maksym_Planeta/#defpager81111]]
+
+[[http://www.mail-archive.com/bug-hurd@gnu.org/msg18859.html]]
+
+## Steps
+
+1. Find out what causes crashes in tmpfs with defpager
+
+[[http://www.gnu.org/s/hurd/hurd/translator/tmpfs/notes_various.html]]
+
+TODO: Consider deleting of parameter "port" in function mach-defpager/default_pager.c:pager_port_list_insert
+since this parameter is unused
+
+2. Write own pager
+
+    6.11.11 Reading/writing for files that fit in vm_page_size works
+
+    7.11.11 Works for any size.
+
+3. Make links work
+
+    Symlinks behavior: [[links|http://www.bddebian.com:8888/~hurd-web/user/Maksym_Planeta/#links81111]]
+
+    8.11.11 Symlinks work.
+
+4. Control of used space by tmpfs.
+
+    TODO: Make tmpfs use not more space than it was allowed.
+
+5. Thread safety.
+
+    TODO: During execution tmpfs hangs in random places. The most possible is variant is deadlocks,
+    because nothing was undertaken for thread safety.
+
+6. After sometime of inactivity tmpfs exits.
+
+    TODO: Find out why and correct this.
+
+#Debugging
+
+To debug tmpfs, using libraries from "$PWD"/lib and trace rpc:
+
+    settrans -ca foo /usr/bin/env LD_LIBRARY_PATH="$PWD"/lib utils/rpctrace -I /usr/share/msgids/ tmpfs/tmpfs 1M
+    LD_LIBRARY_PATH="$PWD"/lib gdb tmpfs/tmpfs `pidof tmpfs` 
+
+For debugging ext2fs:
+
+    settrans --create --active ramdisk0 /hurd/storeio -T copy zero:32M  && \
+    /sbin/mkfs.ext2 -F -b 4096 ramdisk0 && \
+    settrans --active --orphan ramdisk0 /usr/bin/env LD_LIBRARY_PATH="$PWD"/lib utils/rpctrace -I /usr/share/msgids/ \
+    ext2fs/ext2fs.static ramdisk0
+
+#Questions
+
+1. What are sequence numbers? What are they used for?
+2. Is there any way to debug mach-defpager? When I set breakpoint to any function in it, pager never breaks.
+
+#Conversations
+
+## 8.11.11
+
+### links<a id="links81111"/>
+    (10:29:11) braunr: mcsim: ln -s foo/bar foo/baz means the link name is baz in the foo directory,
+    and its target (relative to its directory) is foo/bar (which would mean /tmp/foo/foo/bar in canonical form)
+    (10:29:42) braunr: youpi: tschwinge: what did ludovic achieve ?
+    (10:30:06) tschwinge: mcsim: As Richard says, symlink targets are always relative to the directory they're contained in.
+    (10:30:51) tschwinge: braunr: This Hydra/Nix (I wtill mix it all up) thing is kind of a package managing system.
+    (10:31:17) tschwinge: He has written scripts for bootstrapping a Hurd toolchain.
+    (10:31:26) braunr: oh ok
+    (10:31:27) mcsim: so, if I want to create link in cd, first I need to cd there?
+    (10:31:28) tschwinge: And then uses that to build a whole bootable image.
+    (10:31:36) mcsim: in foo*
+    (10:31:36) braunr: mcsim: just provide the right paths
+    (10:32:11) braunr: $ touch foo/bar
+    (10:32:14) braunr: $ ln -s bar foo/baz
+    (10:32:32) braunr: bar
+    (10:32:35) braunr: baz -> bar
+
+### defpager<a id="defpager81111"/>
+
+    earlier:
+    <tschwinge>: 1. On every system there is a ``default pager'' (mach-defpager).  That one is responsible 
+    for all ``anonymous memory''.  For example, when you do malloc(10 MiB), and then there is memory pressure, 
+    this 10 MiB memory region is backed by the default pager, whose job then is it to provide the backing store for this.
+    <tschwinge>: This is what commonly would be known as a swap partition.
+    <tschwinge>: And this is also the way tmpfs works (as I understand it).
+    <tschwinge>: malloc(10 MiB) can also be mmap(MAP_ANONYMOUS, 10 MIB); that's the same, essentially.
+    <tschwinge>: Now, for ext2fs or any other disk-based file system, this is different:
+    <tschwinge>: The ext2fs translator implements its own backing store, namely it accesses the disk for storing 
+    changed file content, or to read in data from disk if a new file is opened.
+    
+    ...
+
+    (10:36:14) mcsim: who else uses defpager besides tmpfs and kernel?
+    (10:36:27) braunr: normally, nothing directly
+    (10:37:04) mcsim: than why tmpfs should use defpager?
+    (10:37:22) braunr: it's its backend
+    (10:37:28) braunr: backign store rather
+    (10:37:38) braunr: the backing store of most file systems are partitions
+    (10:37:44) braunr: tmpfs has none, it uses the swap space
+    (10:39:31) mcsim: if we allocate memory for tmpfs using vm_allocate, will it be able to use swap partition?
+    (10:39:56) braunr: it should
+    (10:40:27) braunr: vm_allocate just maps anonymous memory
+    (10:41:27) braunr: anonymous memory uses swap space as its backing store too
+    (10:43:47) braunr: but be aware that this part of the vm system is known to have deficiencies
+    (10:44:14) braunr: which is why all mach based implementations have rewritten their default pager
+    (10:45:11) mcsim: what kind of deficiencies?
+    (10:45:16) braunr: bugs
+    (10:45:39) braunr: and design issues, making anonymous memory fragmentation horrible
+    
+    ...
+
+    (15:23:33) antrik: mcsim: vm_allocate doesn't return a memory object; so it can't be passed to clients for mmap()
+    (15:50:37) mcsim: antrik: I use vm_allocate in pager_read_page
+    (15:54:43) antrik: mcsim: well, that means that you have to actually implement a pager yourself
+    (15:56:10) antrik: also, when the kernel asks the pager to write back some pages, it expects the memory to become free.
+    if you are "paging" to ordinary anonymous memory, this doesn't happen; so I expect it to have a very bad effect
+    on system performance
+    (15:56:54) antrik: both can be avoided by just passing a real anonymous memory object, i.e. one provided by the defpager
+    (15:57:07) antrik: only problem is that the current defpager implementation can't really handle that...
diff --git a/user/musial.mdwn b/user/musial.mdwn
new file mode 100644
index 00000000..24a526be
--- /dev/null
+++ b/user/musial.mdwn
@@ -0,0 +1,19 @@
+[[!meta copyright="Copyright © 2011 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]]."]]"""]]
+
+Robert Musial
+
+Cleveland, OH
+
+musial [at] gnu [dot] org
+
+http://musial.sdf.org
+
+http://github.com/musial