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

IRC, freenode, #hurd, 2012-07-31

<gg0> subhurd seems like bsd jail (tried none of them)
<antrik> gg0: nope. BSD jails are mostly chroot AIUI. subhurd is quite
  different
<antrik> gg0: you actually boot a completely new system instance
<antrik> complete with all the Hurd servers, UNIX daemons etc.
<braunr> jails are between subhhurds and chroots :p
<braunr> i suppose there is nothing against making the root server of the
  subhurd use a file instead of a raw disk, is there ?
<gg0> well, I said jails cos afaik are more isolated from real system than
  chroots
<braunr> yes
<gg0> maybe comparing subhurd to virtual machines would be more
  appropriated then
<braunr> they're not VMs either
<gg0> say chroot -> jail -> subhurd -> vm ?
<braunr> unless you consider the microkernel to be a hypervisor, with its
  own architecture, which some actually do
<braunr> gg0: something like that, yes
<gg0> [system-in-system evolution]
<braunr> a subhurd is an operating system instance
<braunr> i think the closest analogy you can get is openvz
<antrik> yeah, I'd also consider it closest. but it's still quite
  different: with OpenVZ, the kernel facilities are only logically
  isolated; but they use the same kernel code. with subhurds, most of the
  system facilities are independent

IRC, freenode, #hurd, 2012-08-03

<antrik> hm... are Mach task IDs exposed to userspace?
<braunr> antrik: ids ?
<braunr> antrik: what do you call a mach task id ?
<antrik> task have numeric IDs in the kernel
<antrik> I wonder whether these are ever exposed to userspace
<braunr> i'm not sure
<braunr> i don't remember the had numeric IDs
<braunr> they*
<antrik> well, perhaps I'm making things up... but I believe I saw such IDs
  in the debugger and/or in error messages
<braunr> probably their address
<braunr> or creation time orpc_sample
<antrik> braunr: well, any unique ID would do
<braunr> antrik: yes but i was wondering what kdb would actually show
<antrik> I just realised that it would be useful for debugging accross
  subhurds or kernel/userspace if some kind of unique task IDs could be
  shown in ps output
<braunr> yes
<braunr> this requires some thought though
<braunr> ps shouldn't show that
<braunr> there should be mach specific commands i suppose
<braunr> but then, gdb and other tools wouldn't have access to subhurd
  tasks either
<antrik> why shouldn't ps show that? I don't think it's any more sensitive
  information than all the other stuff ps shows...
<braunr> it doesn't feel right
<braunr> i would want my system instances to be truely isolated
<braunr> and use special "cross instance" facilities
<braunr> when necessary
<antrik> that's completely orthogonal to what I'm talking about
<braunr> like eth-multiplexer
<braunr> you seem to be talking about security
<braunr> or privacy
<antrik> we discussed such options when zhengda worked on rootless subhurd
<antrik> no, I'm talking about convenient debugging
<braunr> right
<braunr> i don't think it'zs orthogonal here
<braunr> if we increase separation, it becomes less convenient
<antrik> for debugging purposes you would *not* use the isolation options
<braunr> ok so you propose two modes of operations
<antrik> BTW, as an isolated subhurd relies on the parent, it makes no
  sense to hide subhurd tasks from the parent hurd -- only hide parent hurd
  task from the subhurd
<braunr> agreed
<antrik> so even with an isolated subhurd global task IDs would still be
  useful

IRC, freenode, #hurd, 2012-08-06

<braunr> antrik: if i'm right, the root file system executable is read from
  the parent, right ?
<antrik> braunr: probably... I'm not sure about that part
<braunr> antrik: i've installed the same packages in both the main and
  subhurds to be sure
<braunr> and to have the right binary and debugging symbols in gdb anyway

IRC, freenode, #hurd, 2013-01-19

<zacts> what is the hurd equivalent of a freebsd jail?
<braunr> zacts: i'd say subhurds
<zacts> what advantages would a subhurd have over a freebsd jail?
<zacts> basically that is
<braunr> it virtually guarantees a mistake can't compromise the main system
<zacts> ah ok
<braunr> in theory, subhurds can run without root privileges
<braunr> (but there are currently a few things that prevent it)

IRC, freenode, #hurd, 2011-06-07

<zacts> would hurd jails be more powerful than FreeBSD jails? how so?
<braunr> not more powerful
<braunr> easier to develop
<braunr> safer
<braunr> perhaps more powerful too, but that entirely depends on the
  features you want inside

IRC, freenode, #hurd, 2013-10-04

<braunr> hm, looks like we broke subhurds again
<braunr> freezes after starting exec
<teythoon> o_O
<braunr> looks like some translator refuses to start
<braunr> teythoon: we need better error reporting first :)

subhurd error messages.

<braunr> and better visibility in general
<braunr> teythoon: it may be that the subhurd i'm using is a bit od
<braunr> old
<braunr> one weird thing about subhurds is that they actually use the
  ext2fs and linker from the host
<braunr> so it's better if the subhurd and the host uses the same bootstrap
  protocol :)
<teythoon> braunr: isn't boot --boot-root=DIR there to specify which root
  translator and linker to use?
<braunr> teythoon: yes but you don't want your root file system mounted
  from the host when starting your subhurd
<teythoon> you can mount it r/o just fine, no?
<braunr> ideally, we'd have a userspace version of grub reading the files
  from the disk, as it's done when booting
<braunr> hm
<braunr> right

IRC, freenode, #hurd, 2013-10-07

<teythoon> braunr: btw, did you straighten out your subhurd issue?
<braunr> teythoon: no i haven't