[[!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