Conversation with #inferno at Wed Oct 15 20:24:24 2008 on powerman@irc.freenode.net (irc)
(20:24:24) #inferno: The topic for #inferno is: Inferno and Limbo | Website: http://www.vitanuova.com/inferno/index.html | Documentation: http://www.vitanuova.com/inferno/docs.html | Wiki: http://canto.hopto.org/wiki/1/index.html | Tutorial: http://www.resc.rdg.ac.uk/twiki/bin/view/Resc/InfernoTutorial | Mailing list archives: http://dir.gmane.org/gmane.os.inferno.general
(21:45:37) eekee left the room (quit: Read error: 145 (Connection timed out)).
(21:46:56) pierre- [n=pierre@93-81-113-182.broadband.corbina.ru] entered the room.
(22:36:29) pierre- left the room (quit: Read error: 110 (Connection timed out)).
(23:45:24) andguent left the room (quit: "Leaving").
(00:57:49) KillerX left the room (quit: ).
(00:58:03) KillerX [n=anant@gentoo/developer/KillerX] entered the room.
(03:32:43) KillerX left the room (quit: ).
(03:50:07) KillerX [n=anant@gentoo/developer/KillerX] entered the room.
(04:41:43) ooooo left the room (quit: Remote closed the connection).
(04:42:02) ooooo [i=none@201.80.219.33] entered the room.
(04:53:50) KillerX left the room (quit: ).
(05:27:50) underspecified left the room (quit: ).
(06:08:54) eekee [n=eekee@cpc1-lanc4-0-0-cust860.brig.cable.ntl.com] entered the room.
(06:15:19) underspecified [n=eric@clair18.naist.jp] entered the room.
(08:53:50) underspecified left the room (quit: ).
(09:02:56) underspecified [n=eric@clair18.naist.jp] entered the room.
(09:07:30) underspecified left the room (quit: Client Quit).
(09:11:54) underspecified [n=eric@clair18.naist.jp] entered the room.
(09:30:11) mjl-: morning all
(10:27:40) acmeuser [n=acmeuser@CPE-121-219-61-108.vic.bigpond.net.au] entered the room.
(10:27:53) acmeuser left the room.
(10:28:37) underspecified left the room (quit: ).
(10:39:27) underspecified [n=eric@clair18.naist.jp] entered the room.
(10:42:10) Guest68682 [n=none@9souldier.org] entered the room.
(10:43:43) Guest68682 is now known as soul9
(10:46:32) underspecified left the room (quit: ).
(10:48:08) underspecified [n=eric@clair18.naist.jp] entered the room.
(10:56:37) underspecified left the room (quit: ).
(10:59:37) underspecified [n=eric@clair18.naist.jp] entered the room.
(11:00:20) underspecified left the room (quit: Client Quit).
(11:10:21) underspecified [n=eric@clair18.naist.jp] entered the room.
(13:08:19) KillerX [n=anant@gentoo/developer/KillerX] entered the room.
(14:32:17) rog_ [n=rog@78.148.25.44] entered the room.
(14:58:00) andguent [n=andre@p4FF661B8.dip.t-dialin.net] entered the room.
(16:24:41) underspecified left the room (quit: ).
(17:47:51) underspecified [n=eric@softbank220043052011.bbtec.net] entered the room.
(18:30:57) pierre- [n=pierre@89-179-74-43.broadband.corbina.ru] entered the room.
(20:28:01) eno: hi, how do ppl do the equivalent of "grep -r pattern dirname" on inferno?
(20:28:30) eno: (i'm trying to do that in acme-sac)
(20:31:33) rog_: eno: what does -r do?
(20:31:46) rog_: eno: recursive?
(20:35:43) rog_: eno: you could do: grep pattern `{fs filter {mode -d} dirname}
(20:36:54) rog_: eno: although that won't start the grep until the entire filetree has been walked. often that's not a problem though.
(20:40:34) olegfink: fs filter {mode -d} dirname | getlines {grep pattern $line}?
(20:42:32) rog_: olegfink: that's possible. but it'll be quite slow, as it'll be running one grep for each file. it would be quite easy to write a simple version of xargs if desired.
(20:43:25) olegfink: ah, I thought for inferno the penalty for a call isn't that big.
(20:43:55) rog_: olegfink: it's still noticeable.
(20:44:59) olegfink: ah, ok.
(20:45:09) olegfink: by the way, who has written fs(1)?
(20:45:59) olegfink: it is said that complex programs always have a subset of LISP in their code, fs apparently implements much of ML (or I suspect its author is familiar with some strictly-typed language)
(20:47:15) rog_: but i've just realised that fs's exec has the functionality built in. ooh, wasn't i keen? fs exec -n 5 @ {grep pattern $file} {filter {mode -d} .}
(20:47:37) rog_: olegfink: it was me...
(20:48:13) rog_: olegfink: i was trying to avoid going as far as the usual complete functional languages.
(20:49:31) rog_: olegfink: i was inspired by the composability and ease-of-use of shell pipelines, but thought it should be possible to be a little more flexible, while not bringing on the whole shebang of turing-completeness.
(20:50:22) rog_: olegfink: hence: a small, finite number of non-composable types. and simple pipe-like semantics.
(20:50:22) olegfink: I wish you moved a little bit further, I'd love to see something like ocaml generating dis and interfacing limbo modules.
(20:50:45) olegfink: fs is great, strange I never noticed it before
(20:52:02) rog_: olegfink: i did try to go further (see sh-alphabet (1)). but i was trying to go too far for the limits of limbo...
(20:52:33) rog_: olegfink: basically, i needed one of a) closures b) type dynamic or c) existential types.
(20:52:56) olegfink: oh, you just answered the very question I was going to ask.
(20:53:36) rog_: olegfink: so for the time being, fs is more useful, as it fits more nicely in as a shell command. although the syntax of alphabet is better (you can actually write commands as a pipeline)
(20:55:16) olegfink: haskell guys can do impressive things as long as they're in haskell, and we're a bit behind a system running completely in haskell, so I was always wondering if there is a language-neutral way of acheiving typed features etc.
(20:55:45) rog_: what sort of typed features?
(20:56:54) olegfink: typed pipes, maybe typed files? (I want declarative parsing)
(20:57:01) rog_: BTW, i've been playing with haskell recently. it's nice. but it's very easy to make stuff that's really hard to understand.
(20:57:27) rog_: olegfink: the alphabet thing was all about typed pipes.
(20:58:21) rog_: olegfink: it all came about when i needed a flexible archive/unarchiver. i wrote it using processes communicating via channels, and realised how nice it was to use and extend.
(21:00:04) rog_: and i was trying to make a system where as many things as possible would plug together with no hassle, like unix pipes do. the less types there are, the more commands will be written in terms of the same types, and hence will be interoperable.
(21:01:36) rog_: if a stream of bytes is flexible enough to do all the stuff it can in unix, surely just adding a few more carefully chosen types could add to the power, while not opening the door to all the other complexity...
(21:01:55) rog_: hence, no higher-order types in alphabet.
(21:02:20) rog_: what do you mean by "declarative parsing"?
(21:03:42) olegfink: something that might look similar to structured regexps, but typeful. a way to define the contents of the file.
(21:04:08) olegfink: that is, my file starts with an integer n, then go n lines of text, then three floats
(21:05:02) rog_: what does that get you?
(21:05:42) gualteri [n=saoro@84.123.3.224.dyn.user.ono.com] entered the room.
(21:05:52) rog_: there are any number of typeful structured file formats out there.
(21:06:04) olegfink: an easy way to read a file, but that doesn't make really much sense for a shell, more for a language
(21:06:08) rog_: i wouldn't want to build any of them into the filesystem
(21:07:10) olegfink: I don't mean structured formats, I mean a way to define a structure on a plain byte stream
(21:07:22) rog_: there's always yacc...
(21:07:37) pierre-: olegfink, do you mean parsec-like things?
(21:07:57) rog_: but... what is "defining a structure on a plain byte stream" if it's not a structured format.
(21:07:59) rog_: ?
(21:08:25) ***rog_ needs to look at parsec
(21:08:31) pierre-: http://www.haskell.org/haskellwiki/Parsec
(21:08:57) olegfink: pierre-: yes (to the extent of my familiarity with haskell)
(21:09:00) rog_: i know, but i've already spent too much time, and i've no pressing need for it right now...
(21:09:15) ***rog_ goes and looks at parsec
(21:09:36) gualteri: sorry to interfere, but i hit this recently: http://code.google.com/p/protobuf/
(21:10:49) rog_: gualteri: yeah, i was going to mention those. but i couldn't remember the name. ta!
(21:11:02) olegfink: well, it wasn't a feature request, more of a try to discuss some stuff that's interesting for me and that I don't quite understand 
(21:12:44) olegfink: rog_: what are the uses for sh-alphabet as you see it?
(21:14:12) olegfink: what do you mean by high-order types?
(21:15:42) rog_: olegfink: the uses of sh-alphabet? well, i saw it as a successor to sh(1), to be honest. so, unbounded uses... architecturally, it fits better in to inferno than sh, which is taken directly from rc.
(21:16:10) rog_: olegfink: by higher-order types, i mean types defined in terms of other types, e.g. structures, arrays, lists, etc.
(21:17:04) olegfink: some may argue that if string is a primitive type, then so are array and list
(21:17:06) rog_: olegfink: i liked the possibility of having scripts as simple as shell scripts, but strictly typed.
(21:17:30) rog_: olegfink: they may. but i'd disagree.
(21:17:50) rog_: olegfink: you can treat strings as atoms just as much as numbers.
(21:18:30) rog_: olegfink: the bourne shell has essentially two types: string and file descriptor. and it does pretty well.
(21:19:29) rog_: olegfink: i like the universality of byte streams. but there are some things you just can't do with byte streams (fs was the original, canonical example)
(21:20:45) olegfink: yes, I think MS Research has recently came up with some shell prototype that has typed fs, proc (and some other?) data
(21:23:07) rog_: do you have a reference?
(21:23:11) olegfink: and read is essentially a string -> fd cast, right?
(21:24:25) olegfink: seems it's called powershell now, http://www.microsoft.com/windowsserver2003/technologies/management/powershell/default.mspx
(21:24:54) olegfink: I haven't seen it apart from some examples, but it looked like it does typed pipes
(21:25:25) olegfink: ls | measure-object -p length -s
(21:25:29) olegfink: is a du(1)
(21:25:52) rog_: olegfink: well, kind of. read is certainly a string -> fd conversion operator...
(21:26:45) rog_: olegfink: i looked at powershell some time ago. i was a little bit underwhelmed. but then i think they had different design goals.
(21:27:46) olegfink: seems plumber is the first candidate to use typing?
(21:27:58) olegfink: as it effectively casts from string to some other type
(21:29:01) olegfink: interesting how would a type-aware acme look like, "everything is plain text unless you intepret it"
(21:29:15) rog_: olegfink: maybe. but you'd have to get a plumbing channel from the window server. and it means you couldn't plumb cross-network.
(21:29:38) olegfink: interpret even.
(21:30:10) rog_: olegfink: don't get me wrong. i really like byte-streams. and text. i don't think that everything should be type-aware. acme does just fine...
(21:31:21) rog_: that's why alphabet has at its root the types fd and string - they're supposed to be the kind of "universal currency" of exchange between any other type sets.
(21:32:13) olegfink: in fs(1), you add fs as an internal type
(21:32:41) olegfink: and I can't do much about it.
(21:32:50) olegfink: shouldn't, say, ls return fs?
(21:33:05) olegfink: or am I misunderstanding your intentions?
(21:34:32) rog_: olegfink: it's an opaque type. but you're given operations on it that should make it useful.
(21:35:44) rog_: olegfink: ls should probably return fd. but fs doesn't have a concept of fds. alphabet does, and i think /fs/ls in alphabet does return fd.
(21:36:21) rog_: olegfink: the points is that ls converts a set of directory entries into a user-readable format.
(21:36:31) rog_: s/points/point/
(21:36:59) olegfink: http://technet.microsoft.com/en-us/magazine/cc138003.aspx <-- "rethinking the pipeline". apparently author doesn't have an idea of what unix pipeline is.
(21:38:03) olegfink: ah, so it's the other way around
(21:38:14) olegfink: ls is fs -> string
(21:38:45) rog_: yup. well actually fs -> fd because it streams the output.
(21:39:08) rog_: and actually, it's entries -> fd because it doesn't need a well-formed filesystem hierarchy as input.
(21:39:26) pierre-: olegfink, imho ls is path -> fs and "show" is default interpreter's action :-)
(21:39:35) ***olegfink goes back to reading sh-alphabet(1).
(21:39:39) rog_: the point about fs is that it's an entire tree. entries is just a set of dir entries.
(21:40:13) rog_: pierre-: depends if you're talking ls(1) or the ls inside fs...
(21:40:28) olegfink: that calls for a list, doesn't it?
(21:40:31) rog_: pierre-: i was talking about the latter.  but it's confusing...
(21:40:33) olegfink: what is ls a b c?
(21:41:08) olegfink: fd -> fd -> fd -> fd?
(21:41:15) olegfink: or 'fd list' -> fd?
(21:41:21) rog_: olegfink: you can't do that in fs(1). or alphabet, i don't think.
(21:41:52) olegfink: ahh, going back to the manual yet again.
(21:42:29) rog_: olegfink: but it *could* be defined ls entries [entries ...]
(21:42:48) rog_: in which case its type would be ls entries [entries...] -> fd
(21:44:33) ***rog_ has forgotten how to use alphabet!
(21:46:08) olegfink: ehh, could you give me an example with /status?
(21:47:30) rog_: olegfink: see alphabet-main(1) for some example alphabet commands that use it.
(21:48:18) olegfink: ah, so the commands that return status are ones that could be called 'impure'
(21:48:43) rog_: olegfink: kinda. they're the ones that actually run an external command.
(21:48:45) olegfink: that makes much sense
(21:49:09) rog_: olegfink: although by haskell standards, quite a lot is "impure"!
(21:49:53) rog_: olegfink: ... though in fact it all looks quite pure at the alphabet level, it's true.
(21:53:29) olegfink: very interesting
(21:53:45) olegfink: I would like to see fd in ML
(21:54:06) rog_: so, despite what the manual says, the type of ls in alphabet is : [-um] /fs/entries -> /fd
(21:54:51) rog_: i should really update that man page.
(21:55:22) rog_: i've often thought about doing a version of alphabet in some other language, maybe ML or haskell. it woudn't be hard.
(21:55:50) rog_: although in inferno, it does benefit considerably from the cheap threads and channels.
(21:56:59) olegfink: ocaml can be ported to inferno quite easily, I think, after all, there is a patch for it to emit java bytecode.
(21:57:05) rog_: i kinda like it, as it feel sort of half-way between the "strict typing" and "dynamic typing" worlds.
(21:57:27) olegfink: (and interface jre)
(21:57:31) rog_: olegfink: how does that patch cope with the lack of tail-call in the JVM
(21:57:34) rog_: ?
(21:59:40) pierre-: rog_, perhaps the same way as x86 codegen?
(22:00:19) olegfink: x86 has (as most assemblies) a tail-call as far as I understand
(22:00:20) rog_: pierre-: i suppose it's ok if it doesn't have to generate java-callable functions...
(22:01:25) rog_: olegfink: in assembly, a tail-call is just a JMP. but if you're using the virtual-machine infrastructure for function frames, etc, then you need a "call-replacing-frame" operation.
(22:01:35) pierre-: olegfink, java doesn't have tail call, but afaik it does have jump
(22:02:00) rog_: olegfink: i know that Clojure doesn't have tail calls for precisely this reason.
(22:02:44) rog_: it's ok if you're tail-calling the same function. but it's not so easy if you've got mutual recursion.
(22:02:57) olegfink: I think it uses some kind of a runtime support for this.
(22:03:16) olegfink: "It is then particularly interesting to access Java classes from the Objective Caml program. This can be done in plain Cadmium by using the Cadmium runtime library that allows calls to Java reflection methods."
(22:03:25) olegfink: http://nickel.x9c.fr/
(22:04:41) olegfink: interesting, never thought it's so principal.
(22:05:32) olegfink: rog_: but seems porting to dis is even easier, at least a codegen would look like pretty much like any other native generator
(22:05:35) rog_: anyway, the inferno VM doesn't currently support tail-calling...
(22:06:49) olegfink: ah, so I won't be able to call dis functions?
(22:08:59) rog_: olegfink: i don't see why not. you just won't be able to write the usual tail-call reliant code without running out of space.
(22:10:19) rog_: olegfink: also, dis doesn't currently support closures. i think i remember russ cox suggesting a single elegant operator that made them straightforward. i can't rember when though.
(22:10:57) olegfink: on inferno-list?
(22:12:14) olegfink: http://article.gmane.org/gmane.os.inferno.general/2429 ?
(22:13:11) rog_: well done! i was googling around and failed to find it... what search terms did you use?
(22:13:36) olegfink: I was using gmane's search on 'closure'. this was the second match.
(22:14:06) rog_: i'd forgotten about gmane...
(22:15:35) olegfink: yeah, suprisingly google fails here, though it apparently indexes gmane.
(22:16:44) rog_: olegfink: google's sometimes surprisingly bad at finding obscure stuff that you know is there...
(22:17:29) olegfink: does it make sense to add closures and first-class functions to limbo (perhaps with the proposed dis change) or to port some functional language?
(22:18:51) rog_: olegfink: i think i'd like to see closures/first-class functions in limbo. it's a difficult issue, because limbo has always prided itself on predictable memory usage and GC behaviour. but when you introduce closures, suddenly cyclic has no meaning any more.
(22:19:26) rog_: olegfink: (because you can always create a closure that points to itself, without the type system being able to check it)
(22:21:31) olegfink: well, at least now I know there exists a group 'Closure' which has a song 'Inferno'
(22:22:03) rog_: that *is* good to know
(22:23:12) olegfink: err, why isn't the type system able to check such a recursive closure?
(22:27:09) rog_: i convinced myself of that ages ago. i'll just make another example.
(22:27:53) olegfink: probably I just don't understand, but seems ocaml's type system handles such things quite well.
(22:29:36) pierre-: olegfink, f 1 = 1; f 2 = f 2?
(22:29:37) rog_: olegfink: there's no problem doing the type checking. it's checking that there are no circular references which isn't possible (i think).
(22:31:04) pierre-: olegfink, perhaps you can't exclude f 2 = f 2 because it also corresponds to Y? but it seems i'm wrong
(22:32:00) olegfink: as far as I understand your example is just a normal closure
(22:34:05) olegfink: hmm, or maybe I'm wrong, as it isn't marshalled (a closure should, right?)
(22:34:55) pierre- left the room (quit: Read error: 60 (Operation timed out)).
(22:39:37) rog_: olegfink: here's an example of the kind of thing i mean: http://hpaste.org/11209#a0
(22:40:06) rog_: (this assumes inline functions in limbo with closures)
(22:40:18) rog_: s/inline/nested/
(22:41:14) rog_: there's no way that the type system can know that assigning to the f element of the S structure is going to create a circular reference.
(22:42:23) rog_: so basically any adt holding a function pointer must be considered potentially cyclic. which would be pretty awkard in practice, i think. so it might just be best to get rid of the cyclic keyword altogether.
(22:47:54) olegfink: ah, got it.
(22:48:10) olegfink: interesting how other languages are handling that.
(22:48:50) rog_: olegfink: i don't know of any other languages that bring non-circularity assertions into the language.
(22:53:48) olegfink: is there some reading about this aspect of limbo? (I don't remember reading about that)
(22:55:30) olegfink: ah, it's just my memory not serving me.
(22:57:53) rog_: olegfink: the language reference (which is quite readable) talks about it.
(22:58:42) rog_: olegfink: basically, if there are mutually-referencing adts, you're not allowed to assign to individual possibly-cyclic fields unless you've declared the fields to be cyclic.
(22:59:14) rog_: olegfink: even now, you can break it by using module references, to be honest, so it's not perfect.
(22:59:28) olegfink: yes, I should re-read 'the limbo programming language'. 
(22:59:41) rog_: olegfink: yes, you should. it's well written.
(22:59:55) rog_: olegfink: and limbo is such a nice language.
(23:00:53) olegfink: yes, but I haven't written a line in it (that's why I forgot everything) (apart from the tests we used to debug JIT, but that doesn't really count).
(23:03:43) rog_: olegfink: it's the language i've most enjoyed programming in.
(23:04:20) rog_: olegfink: in particular, syntactically and practically lightweight channels and processes are a revelation.
(23:04:46) rog_: olegfink: they make dealing with concurrent stuff a total joy.
(23:05:09) rog_: olegfink: (rather than the nightmare it often is in other languages)
(23:09:11) rog_: i saw a classic example of this recently. see http://acmqueue.com/modules.php?name=Content&pa=showpage&pid=554
(23:12:05) olegfink: rog_: interesting, thanks.
(23:13:01) paigeadele left the room (quit: "leaving").
(23:13:31) paigeadele [i=erratic@75.146.55.252] entered the room.
(23:14:18) olegfink: rog_: by the way, do you know something about the 'mips routers' inferno was said to be running on at vitanuova?
(23:15:09) olegfink: I've heard some rumors about it, but the mailing list only knows about a port of emu to linux/mips for some linksys wifi router
(23:20:19) rog_: olegfink: no i don't, sorry. charles has ported inferno to all kinds of stuff...
(23:22:16) gualteri: olegfink, are you refering to this?: http://osdir.com/ml/os.inferno.general/2007-03/msg00131.html
(23:24:39) olegfink: yes, a port to wrt54g by Richard Miller
(23:25:17) olegfink: rog_: ocaml has a 'let rec' binding pretty similar to limbo's 'cyclic'
(23:25:36) olegfink: that is, you can only reference a value in a 'rec' binding
(23:27:37) olegfink: e.g. let f x = f x would bind f call to a previously bound f (if any), while let rec f x = f x would bind f to itself
(23:28:27) olegfink: (which is tail-optimized, regarding our previous discussion, hah)
(23:28:47) powerman1: sorry, that may be a silly question, but is anybody know reason to use this coding style:
(23:28:47) powerman1: implement Something; Something: module { init: fn(...); };
(23:28:47) powerman1: instead of:
(23:28:47) powerman1: implement Command; include "sh.m";
(23:28:47) powerman1: when developing module designed to use as shell command?
(23:29:00) rog_: olegfink: but let rec doesn't influence the type system. the nice thing about limbo is that by looking at the type of a particular value, you can tell if it will be immediately cleaned up by the reference counting, or might be delayed.
(23:29:50) rog_: powerman1: if you do the latter, then your module will be just called "Command" in the ps listing...
(23:30:07) powerman1: rog_: thanks :) 
(23:30:44) olegfink: ah, so it exists to simplify the GC?
(23:31:06) rog_: powerman1: (although i think now you can do: implement Foo, Command; include "sh.m"; Foo: module {}; init: fn(...)) and it'll choose the first module name
(23:31:57) rog_: olegfink: it exists so that you can write programs with predictable GC characteristics (important on the small systems that inferno has traditionally targetted)
(23:32:37) rog_: olegfink: it doesn't simplify the GC at all (which actually doesn't know about which things are tagged with "cyclic" or not
(23:32:51) mjl-: rog_: are you still working at vn?
(23:33:09) olegfink: if the adt is not 'cyclic', it can be garbage collected when there are no references to it
(23:33:15) rog_: mjl-: no
(23:33:47) mjl-: hmm, ok.  other inferno stuff?  or is that in the past for you?
(23:33:48) olegfink: if the adt is 'cyclic', it can be garbage collected when there are no references to it except it pointing to itself
(23:33:51) mjl-: for work i mean
(23:33:56) ***olegfink doesn't understand the difference
(23:34:05) ***mjl- just booked flights to greece!
(23:34:08) mjl-: for iwp9
(23:34:28) rog_: olegfink: more: if the adt is not "cyclic" then it can be garbage collected *immediately* when there are no references to it.
(23:35:31) olegfink: why can't I do the same for a 'cyclic' adt?
(23:35:44) rog_: mjl-: currently my work doesn't involve inferno (although i still use it all the time). it'd be great to more stuff with it, but there are issues with computer/real-life balance :-)
(23:35:55) olegfink: if there are no external references to it, I can garbage collect it immediately
(23:36:19) rog_: olegfink: it's a classic GC problem: how do you know when there are no external references to it?
(23:37:21) powerman1: rog_: even if that possible (never seen in docs several interfaces in single implement) I don't think it make something more simple or clear
(23:37:39) mjl-: rog_: heh, i share your feelings :)
(23:37:58) rog_: powerman1: i'd tend to agree. that might be different if the shell interface wasn't so simple, however...
(23:38:03) mjl-: rog_: do you happen to have a website, perhaps even with some limbo code? :)
(23:38:35) rog_: mjl-: no. although most of my limbo code is in the inferno distribution...
(23:39:04) olegfink: rog_: ah, seems I understand now, there isn't an easy way to detect circular dependencies
(23:39:27) rog_: mjl-: there are a few bits and pieces i made available on the plan9 sources site to do plan9 authentication from inferno.
(23:39:54) rog_: mjl-: do i know you, BTW?
(23:40:10) mjl-: ah, good to hear
(23:40:12) mjl-: rog_: probably not
(23:40:17) mjl-: mechiel is my real name
(23:40:26) mjl-: i did a gsoc project for inferno, last year
(23:40:35) rog_: ah, which one?
(23:40:36) mjl-: never met for real, unless you were at iwp9v1 :)
(23:40:43) mjl-: the venti & vac stuff
(23:41:00) mjl-: (and i started on some other code near the end of the gsoc, but that wasn't finished)
(23:41:17) rog_: that was a good one... i was working with someone on related stuff, but he never got off the ground.
(23:41:46) mjl-: ah i remember
(23:41:50) mjl-: cocytus
(23:41:58) mjl-: or something similar (hard to remember the name)
(23:42:09) rog_: i haven't been to any of the iwp9 gatherings. some day i will.
(23:42:20) powerman1: rog_: btw, it worked, and ps call it "HelloWorld+Command" ;^)
(23:42:22) rog_: work/life balance again!
(23:42:56) rog_: powerman1: ah. that's not as good then. but still better than just "Command"
(23:48:01) uriel: 22:34  * mjl- just booked flights to greece!
(23:48:04) uriel: mjl-: WTF?!?!
(23:48:19) olegfink: well, thanks a lot roger and sorry for so many stupid questions.
(23:49:04) olegfink: time for me to leave.
(23:57:04) gualteri left the room.
(00:00:40) rog_: olegfink: not stupid at all. it was pleasant to get back into that inferno frame of mind again...
(00:18:27) rog [n=rog@78.148.25.44] entered the room.
(00:35:28) rog_ left the room (quit: Read error: 110 (Connection timed out)).
(01:12:22) rog left the room (quit: Remote closed the connection).
(01:14:03) rog [n=rog@78.148.25.44] entered the room.
(02:19:05) powerman1: small ques about access control. if there many different services on network and many users, then how to control which users have access to which services? right now I see two ways for this:
(02:19:05) powerman1: a) run one auth service in network, each service and user get cert from it, and by default all users have access to all services. then each service should support own list of allowed users (it get user name from user's cert when he connecting)
(02:19:05) powerman1: b) run a lot of auth services (on different ports) - one per each service, and have users get separate cert from separate auth for each service they need access to
(02:19:45) powerman1: is there ease way, or if not, then which one of these preferred and why?
(03:14:36) ooooo left the room (quit: Remote closed the connection).
(03:21:34) KillerX left the room (quit: ).
(03:46:59) underspecified left the room (quit: ).
(03:53:36) ooooo [i=none@201.80.219.33] entered the room.
(04:30:35) jas___ [n=jas@adsl-69-215-39-41.dsl.chcgil.ameritech.net] entered the room.
(04:39:24) jas left the room (quit: Read error: 110 (Connection timed out)).
(04:56:14) underspecified [n=eric@clair18.naist.jp] entered the room.
(05:04:07) defn left the room (quit: Remote closed the connection).
(05:19:51) defn [i=tao@silenceisdefeat.org] entered the room.