IRC.

2 files changed, 105 insertions, 0 deletions

diff --git a/open_issues/anatomy_of_a_hurd_system.mdwn b/open_issues/anatomy_of_a_hurd_system.mdwn
index 932e11a6..496d2a06 100644
--- a/open_issues/anatomy_of_a_hurd_system.mdwn
+++ b/open_issues/anatomy_of_a_hurd_system.mdwn
@@ -1346,3 +1346,85 @@ Actually, the Hurd has never used an M:N model. Both libthreads (cthreads) and l
     <bwright> irAwesome.
     <bwright> Plan9 is exactly it.
     <braunr> enjoy
+
+
+# IRC, freenode, #hurd, 2014-03-11
+
+    <ltx> Does anyone have a distributed OS over GNU/hurd project running?
+    <ltx> (GNU/hurd has many of the utilities to make this easy, but it still
+      requires some more utilities for transparent computation)
+    <braunr> not at the moment, no
+    <braunr> and i consider our ipc inappropriate if you want system able to
+      run over heterogeneous hardware
+    <braunr> or rather, our RPCs
+    <ltx> I haven't spent the time, this is speculative (in the worse "let's do
+      everything magically!" way.)
+    <ltx> Just wondering if this exists outside of plan9 (which is limited in
+      some ways.)
+    <braunr> dragonflybsd had plans for a SSI
+    <braunr> there are ancient research systems that actually did the job
+    <braunr> such as amoeba
+    <braunr> here at the hurd, we just don't have the manpower, and the people
+      spending time on the project have other interests
+    <ltx> Yeah, that seems like a large problem.
+    <ltx> GNU/hurd is self hosting (in the "I like working on it" way), yes?
+    <ltx> I've done some work on it, but don't really know how nice it is.
+    <braunr> yes it is
+    <ltx> Working from a microkernel to add pseudo-SSI features to a bunch of
+      servers seems like a much more trivial task than, say, modifying TLK.
+    <braunr> posix conformance and stability are good enough that more than 70%
+      of debian packages build and most of them work fine
+    <braunr> tlk the linux kernel ?
+    <ltx> Yes.
+    <braunr> first time i see this acronym :)
+    <braunr> and yes i agree, a microkernel is much much more suited for that
+    <braunr> but then, i consider a microkernel better suited for practically
+      everything ... :)
+    <ltx> :)
+    <ltx> I'm wondering how to mix SSI with network-awareness.
+    <braunr> mach used to have a network server
+    <braunr> which would merely act as a proxy for capabilities
+    <braunr> network drivers were in kernel though
+    <ltx> That's the simple way of sharing the sources.
+    <ltx> I'm wondering how we can make a software stack that's network aware;
+      completely transparent SSI can lead to inefficiencies in userspace, as it
+      may do things the kernels won't expect. Having to deal with the network
+      through a network server is a headache.
+    <braunr> what kind of problems do you have in mind ?
+    <ltx> Still working on defining the problem. I think that's half the
+      problem.
+    <ltx> (For any problem.)
+    <ltx> Beyond that, it's just some coding ;)
+    <braunr> ok
+    <braunr> sounds interesting :)
+    <braunr> i'd love to see a modern SSI in action
+    <braunr> but that's really a secondary goal for me so glad to see someone
+      making this his primary goal
+    <braunr> doctoral thesis ?
+    <ltx> ... Undergrad who's been hacking away since grade school.
+    <braunr> heh :)
+    <ltx> 18 y/o sophomore at a respected technical college, dealing with
+      boredom :)
+    <braunr> well throroughly thinking about "defining the problem" is an
+      excellent reflex
+    <teythoon> :) stick around, the hurd is fun
+    <braunr> it does help fight boredom a lot indeed ...... )
+    <braunr> :)
+    <cluck> maybe it'd be possible to port the relevant features from plan9 now
+      that there is a gpl'ed version
+    <teythoon> either way, we'd need network-transparent mach messaging
+    <teythoon> which mach messaging could do, but gnumach does not implement
+      this currently
+    <cluck> teythoon: afaiui if there was a proper 9fs2000 hurd server the rest
+      could be hidden behind the curtains 
+    <teythoon> ah, well, that sounds like a 9p network filesystem translator
+    <cluck> teythoon: also iirc plan9 uses libmach for some things so i suppose
+      a port wouldn't be completely impossible
+    <teythoon> given that in plan9 everything is a file, that might be enough
+      to use plan9 services
+    <cluck> teythoon: yes, it'd be the easiest route (at least initially) i
+      believe
+    <teythoon> careful, lots of stuff is named mach-something
+    <cluck> bloody ernest mach and his damned famous-ness-ish
+    <cluck> =)
+    <teythoon> :D
diff --git a/open_issues/nightly_builds_deb_packages.mdwn b/open_issues/nightly_builds_deb_packages.mdwn
index fc9c2f18..1cf33091 100644
--- a/open_issues/nightly_builds_deb_packages.mdwn
+++ b/open_issues/nightly_builds_deb_packages.mdwn
@@ -958,3 +958,26 @@ See also [[nightly_builds]].
       version 4.8.2 (Debian 4.8.2-7) ) #1 SMP Debian 3.11.10-1 (2013-12-04)
     <gg0> user01@jessie01 ~$ uname -v
     <gg0> #1 SMP Debian 3.11.10-1 (2013-12-04)
+
+
+## IRC, freenode, #hurd, 2014-03-10
+
+    <gg0> teythoon: err, i had unpacked your packages to initrd but
+      gnumach/ext2fs.static i was using for multiboot were debian ones
+    <gg0> now with yours by reading system /proc/mounts (not chroot one) i get
+      read error: (ipc/mig) bad request message ID
+    <gg0> mixing up things
+    <teythoon> gg0: yes, that is to be expected. the message ids for the
+      relevant rpcs changed "recently". i'm really sorry about that.
+    <teythoon> but in general, you should use the hurd components from one
+      source together
+    <teythoon> gg0: yes, that is to be expected. the message ids for the
+      relevant rpcs changed "recently". i'm really sorry about that.
+    <teythoon> but in general, you should use the hurd components from one
+      source together
+
+
+## IRC, OFTC, #debian-hurd, 2014-03-10
+
+    <gg0> tschwinge: i just meant Debian Jenkins provides (hopefully for hurd
+      too) continuos testing of debian installer, it doesn't produce .debs