IRC.

3 files changed, 117 insertions, 0 deletions

diff --git a/hurd/subhurd/discussion.mdwn b/hurd/subhurd/discussion.mdwn
new file mode 100644
index 00000000..3449edcd
--- /dev/null
+++ b/hurd/subhurd/discussion.mdwn
@@ -0,0 +1,69 @@
+[[!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]]."]]"""]]
+
+[[!tag open_issue_documentation]]
+
+IRC, freenode, #hurd, 2011-08-10
+
+    < braunr> youpi: aren't sub-hurds actually called "neighbor hurds" ?
+    < youpi> no idea
+    < braunr> i also don't understand the recursive property
+    < youpi> a user can run a subhurd
+    < neal> braunr: What don't you understand?
+    < youpi> a user in a subhurd can run a subhurd
+    < youpi> etc
+    < braunr> i'm not sure it's really recursive
+    < neal> youpi: At some point it was observed that you don't strictly
+      require any resources from the "parent" Hurd.
+    < neal> youpi: i.e., you could have two Hurds running "directly" on Mach
+    < youpi> sure
+    < neal> youpi: Hence neighbor rather than sub
+    < youpi> but you need to be root for that
+    < youpi> or else your subhurd can't do much
+    < neal> you need to have been authorized to use the required resouces
+    < youpi> which is about the same :)
+    < neal> depends how they are delegated
+    < youpi> that's still asking root for something
+    < neal> if you say so
+    < youpi> which is most probably not the default
+    < braunr> well, either you depend on the parent to do things on your
+      behalf, or you directly have some privileged ports
+    < braunr> i'd agree with youpi that it's pretty much having root access at
+      some point
+    < youpi> and usually you don't have privileged ports by default :)
+    < braunr> but we don't need to restrict the presentation to user only sub
+      hurds
+    < braunr> people don't mind switching to root on their desktops
+    < braunr> which is one of the reasons they ask "what does the hurd really
+      bring me today ?"
+    < braunr> but being able to run truely separate hurds or recursive hurds is
+      something nice most OSes can't do easily
+    < youpi> switching to root becomes a *pain* when you have to do it 1 every
+      two commands
+    < braunr> yes sure, but some people might just say you're clumsy :x
+    < neal> The question is: can I start a sub-hurd from within another hurd
+      that survives the parent's hurd exiting?  The answer is yes.  The reason
+      is that the sub-hurd can be constructed in such a way that it does not
+      rely on the parent.  In this case, the parent does not necessarily
+      subjugate the sub-hurd.  Hence the name.
+    < braunr> but that's out of the scope of the discussion
+    < antrik> using the traditional, root only mechanism, neighbour-hurd is
+      indeed a more appropriate term. apart from the initial terminal being
+      proxied to the parent system by the boot program, they are really equal
+    < antrik> with zhengda's work on non-root subhurds, you rely on various
+      proxies in the parent system to access privileged resources; so subhurd
+      is indeed a more appropriate term in this case
+    < antrik> (not only non-root subhurds in fact... when using any of the
+      proxies, such as the network multiplexer -- even if still running as
+      root...)
+    < youpi> antrik: you could still give a com0 port as terminal
+    < antrik> I don't think that's actually supported in the boot
+      program... but it doesn't really matter, as you don't really need the
+      terminal anyways -- you can always log in through the network
diff --git a/hurd/translator/discussion.mdwn b/hurd/translator/discussion.mdwn
new file mode 100644
index 00000000..e038ba84
--- /dev/null
+++ b/hurd/translator/discussion.mdwn
@@ -0,0 +1,25 @@
+[[!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]]."]]"""]]
+
+[[!tag open_issue_documentation open_issue_hurd]]
+
+IRC, freenode, #hurd, 2011-08-25:
+
+    < frhodes> how can I replace an existing running server with a new one
+      without rebooting?
+    < antrik> frhodes: depends. if other critical things depend on it, you
+      can't. there is no mechanism to serialize and pass on the open sessions
+    < antrik> in some situations, you can orphan the old translator while
+      starting a new one, so the previous clients will stay with the old one
+      while new one will get the new one
+    < antrik> obviously that only works for things that aren't exclusive by
+      nature
+    < antrik> in some cases, you might even be able simply to remove the old
+      translator... but obviously only for non-critical stuff :-)
diff --git a/hurd/translator/procfs/jkoenig/discussion.mdwn b/hurd/translator/procfs/jkoenig/discussion.mdwn
index 64e3776e..01bbea42 100644
--- a/hurd/translator/procfs/jkoenig/discussion.mdwn
+++ b/hurd/translator/procfs/jkoenig/discussion.mdwn
@@ -184,3 +184,26 @@ IRC, freenode, #hurd, 2011-07-22
     <pinotree> status is 644 though
     <jkoenig> but status contains information which anyone can ask to the proc
       server anyway, I think.
+
+
+# `/proc/mounts`, `/proc/$pid/mounts`
+
+IRC, freenode, #hurd, 2011-07-25
+
+    < pinotree> jkoenig: btw, what do you think about providing empty
+      /proc/mounts and /proc/$pid/mounts files?
+    < jkoenig> pinotree, I guess one would have to evaluate the consequences
+      wrt. existing use cases (in other words, "I have absolutely no clue
+      whatsoever about whether that would be desirable" :-)
+    < jkoenig> pinotree, the thing is, an error message like "/proc/mounts: No
+      such file or directory" is rather explicit, whereas errors which would be
+      caused by missing data in /proc/mounts would maybe be harder to track
+    < braunr> this seems reasonable though
+    < braunr> there already are many servers with e.g. grsecurity or chrooted
+      environments where mounts is empty
+    < pinotree> well, currently we also have an empty mtab
+    < braunr> pinotree: but what do you need that for ?
+    < braunr> pinotree: the init system ?
+    < pinotree> and the mnt C api already returns no entries (or it bails out,
+      i don't remember)
+    < pinotree> not a strict need