1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
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
|
