From 902ccccf1de52204846948410cbd1a8849b691c2 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge <tschwinge@gnu.org>
Date: Tue, 11 Mar 2014 21:48:24 +0100
Subject: IRC.
---
open_issues/anatomy_of_a_hurd_system.mdwn | 82 ++++++++++++++++++++++++++++
open_issues/nightly_builds_deb_packages.mdwn | 23 ++++++++
2 files changed, 105 insertions(+)
(limited to 'open_issues')
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
--
cgit v1.2.3