summaryrefslogtreecommitdiff
path: root/hurd/subhurd/discussion.mdwn
diff options
context:
space:
mode:
Diffstat (limited to 'hurd/subhurd/discussion.mdwn')
-rw-r--r--hurd/subhurd/discussion.mdwn69
1 files changed, 69 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