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