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