14:40 <kuroneko> should we take attendance?
14:40 <rsc9> howdy everyone.  
14:40 <uriel> could be worse ;)
14:40 <rmiller> hi
14:40 <uriel> ron is not here yet, but he didn't confirm if he would come, so I think we probably should start...
14:40 <ericvh> how much longer do we want to give Ron to show up?
14:40 <Major-Willard> yo russ
14:41 <ericvh> okay.
14:41 <kuroneko> we should make sure the logs and notes are available
14:41 <Major-Willard> i have pinged brz
14:41 <kuroneko> that way latecomers can catch up
14:41 <uriel> ericvh: lets start with the presentations and the status reports, if he comes he can read backlog...
14:41 <uriel> kuroneko: yes, I'm logging
14:41 <uriel> (if someone does too for backup, even better)
14:41 <ericvh> Okay, how do we want to handle order?
14:41  * kuroneko starts taking notes in acme.
14:41 <uriel> alphabetically?
14:42 <uriel> 20h, you start :)
14:42 <__20h__> No, have to edit jacc.
14:42 <uriel> __20h__: come on, what are you working on, and so on..
14:43 <__20h__> Ok: 1.) Multiauthdom 2.) Modularisation of the Installer 3.) dtLinux v2.6 with v9fs
14:43 <ericvh> Where are you with (1)?
14:43 -!- rawhump [~tiitl@math.ut.ee] has quit ["Leaving"]
14:43 <__20h__> If ddr.9grid.de gets online again, then only factotum is the part missing.
14:43 -!- haraoka [~yoshiyuki@59.187.204.155] has joined #plan9
14:44 -!- noselasd [~noselasd@80.239.96.162] has quit ["leaving"]
14:44 <__20h__> Authsrv and the backend are working.
14:44 <uriel> __20h__: what is your plan? how does it compare to pressotto proporsal?
14:44 <ericvh> When you get a chance can you put something up on the wiki about how this works and where to get authsrv and the backend?
14:44 -!- noselasd [~noselasd@80.239.96.162] has joined #plan9
14:44 <__20h__> The code is on my home CPUsrv and I won't release an alpha.
14:45 <uriel> __20h__: can you at least give some coments on it's design?
14:45 <__20h__> uriel, I take the keys of the users on the other nodes and use them for the tickets.
14:45 <rsc9> so this is private key still?
14:45 <__20h__> Yes, it will be.
14:46 <rsc9> I think that's a mistake.  If you're going to put in a new authsrv etc. and then be passing keys around, they should be public keys.
14:46 <__20h__> I want keyfs to be able to understand groups, so the node owner can create users for it.
14:46 <__20h__> So these can import the keyfs which does only export the keys.
14:46 <rsc9> That doesn't preclude public keys.
14:46 <__20h__> I mean /mnt/keys/$user/key;
14:47 <rsc9> Exporting keyfs means that now lots of auth servers have my key, instead of just one machine.  This doesn't make me feel safer.
14:48 <rsc9> I just hate to see more work go into private key auth when it's just not the right solution -- we built factotum to have a convenient way to store public keys.
14:48 <uriel> __20h__: any comments, any chance you an russ and maybe pressoto(and others interested in the matter) can discus this and come up to some greement?
14:49 <__20h__> No, uriel.
14:49 <uriel> __20h__: any reasons? 
14:50 <__20h__> No.
14:50 <uriel> ok, lets move on then
14:50 <rsc9> Well, I'm glad this discussion is going so well.  We should do this every day!
14:50 <ericvh> ;)
14:50 <uriel> rsc9: heh
14:50 <kuroneko> heh
14:50 <uriel> axelB: ?
14:50 <Major-Willard> brz: "ozinferno is living on Vashon Island off Seattle where it is very tranquil. it will be in NJ in two weeks and then paris."
14:50 <kuroneko> who's stepping up next? :)
14:51 <ericvh> better to keep things moving rather than getting into any in depth discussions anyways.
14:51 <ericvh> in-depth discussions are for the mailing list, not for this sort of meeting.
14:51 <vt3> agreed
14:51 <uriel> yes
14:51 <uriel> axelB seems to be away
14:51 <uriel> moving on, dho?
14:51 <uriel> away too
14:51 <ericvh> uriel: check the idle times first.
14:51 <uriel> if I skip someone let me know
14:51 <uriel> ericvh: yes, I'm an idiot
14:52 <Major-Willard> he's in CA
14:52 <kuroneko> ericvh next? :)
14:52 <uriel> ericvh: I think it's your turn then :)
14:52 <ericvh> okay - 9grid.us is slowing coming to life, it's main purpose is going to be a host for people to drawterm to in order to check out plan9 versus any sort of real grid apps.
14:53 <ericvh> With luck, it'll be available after the weekend.
14:53 <nashi> nice!
14:53 -!- dgil [~dgil@213.0.106.125] has quit ["Abandonando"]
14:53 <ericvh> the v9fs project is up to RC5 and the complaints from the pre-LKML communities seem to be diminishing, so RC5 will likely go to LKML on Monday.
14:53 <uriel> cool, one question about the grids, falling short of multihost auth, any chance to have an standarized way to get accounts?
14:53 <ericvh> uriel: that's an in depth discussion for a mailing list.
14:54 <uriel> ericvh: true, sorry..
14:54 <ericvh> but its a good point, and something which should be discussed.  I have no problem with authing off of sources though.
14:54 <uriel> i was wondering how the sources account creation works
14:54 <uriel> rsc9: ?
14:54 <ericvh> I have one of nemo's students (Gorka) showing up in mid-June to start working on 9P reliability stuff.
14:54 <ericvh> (wait for it uriel)
14:55 <ericvh> rsc9: is your app-space reliability stuff on sources somewhere?
14:55  * uriel tries to calm down, sorry, I'm really stressed
14:55 <Major-Willard> brz: you can also say that i'll IRC first week of june when in paris
14:55 <rsc9> Sources account creation works by interacting with a web server.  You could just use sources accounts as your auth domain if you wanted.
14:56 <uriel> rsc9: yes, I was wondering how httpd that runs as none can create accounts...
14:56 <ericvh> This summer there are two main projects for me: the reliability stuff and Linux kernel server support (which will likely be more than just u9fs as I want to be able to attach gateway devices, etc. directly to it).
14:57 <rsc9> There is a connection to a program in /srv that talks to a fossil fscons to create new accounts.
14:57 <ericvh> The other things that I'm interested in pursuing on the side is authsrv for Linux (already available?) and perhaps packaging plan9ports in a more Linux fashion (split up the components a bit so I can have people just grab the libraries and build environment to build synthetic file servers under Linux).
14:57 -!- mtgx [~mtgx@pD9553868.dip.t-dialin.net] has quit [Remote closed the connection]
14:58  * ericvh is finished now.
14:58 <uriel> ok, should should we move on?
14:58 <kuroneko> [let me catch up with my notes]
14:58 <uriel> :)
14:59 <ericvh> rsc9: do you have any problem with me repackaging p9p?  
14:59 <reezer> I cant add a new user: if I use "disk/kfscmd 'newuser reezer'" It says "kfscmd: can't open commands file"
14:59 <ericvh> I was thinking direct ease of use: rpms and what not.
14:59 <rsc9> ericvh: short answer: no, long answer: let's talk elsewhere.
14:59 <ericvh> rsc9: sure..
14:59 <uriel> reezer: we are in a meeting now, please ask in #acme or wait until we are done
14:59 <kuroneko> I'm interested in having a full fossil/venti like fileserver (or even ken-fs) hosted on LInux at some point.
15:00 <reezer> ok
15:00 <uriel> haraoka: ?
15:00 <kuroneko> [it would have saved me some major headaches recently]
15:00 <rsc9> porting fossil should not be too hard.  
15:00 <rsc9> seems a bit weird, but not hard.
15:01 -!- dgil [~dgil@213.0.106.125] has joined #plan9
15:02 <Major-Willard> brz: ozinferno doesn't need much doc 'cause the vita stuff will largely do but i just ain't got the time
15:02 <uriel> haraoka seems to be away(?)
15:02 <uriel> Jim7J1AJH: your turn :)
15:03 <Jim7J1AJH> no news.
15:03 <uriel> Jim7J1AJH: ok :)
15:03 <uriel> joe_c: now you! and you better be around! :)
15:04 <ericvh> future point of order: everyone that has something to say put themselves in the wiki, that way we don't go through this nonsense.
15:04 <uriel> well, kuroneko, maybe you can start and see if they show up ;)
15:04 <kuroneko> ok, my turn?
15:04 <uriel> ericvh: no, it will create a ton of conflicts, just /msg me
15:05 <ericvh> okay, everyone else msg uriel if they have something to say.
15:05 <uriel> kuroneko: yes
15:05 <ericvh> I'm just saying for the future, set agendas will control the chaos.
15:05 <kuroneko> I've been working on sparc32
15:05 <kuroneko> [in particular, sun4m hardware support]
15:06 <rsc9> Is it working?
15:06 <kuroneko> no progress in about 2-3 weeks, but its up to the point where promcalls vaugely work, the MMU can be mapped (but not reliably)
15:06 <kuroneko> IOMMU code is still broken.
15:06 <kuroneko> xalloc is broken
15:06 -!- dgil [~dgil@213.0.106.125] has quit ["Download Gaim: http://gaim.sourceforge.net/"]
15:06 <kuroneko> I've just gotten my home standalone plan9 systems working in the last 24 hours (literally)
15:06 <uriel> any comments on the xalloc plans? (/me remembers someting about it)
15:07 <kuroneko> so I'll be moving my development onto them soon so I don't have to worry about vmware eating my code
15:07 <kuroneko> I'm planning to rewrite xalloc
15:08 <kuroneko> mostly because the initialisation for it is a pain in the ass.
15:08 <kuroneko> and fixing it now will make other hardware ports easier.
15:08 <rsc9> keep jmk and me in the loop about your new xalloc design before you rewrite it.  we both have been running into limitations (him on amd64, me on  x86)
15:08 <kuroneko> the main thing I plan to fix is removing the assumption that memory exists in two contiguous regions
15:09  * uriel should fish rsc9's comments on xalloc in 9fans a while ago and put them on the "future directions" wiki page...
15:09 <kuroneko> and replacing it with something that can handle arbitary number of zones
15:09 <rsc9> kuroneko: if that's all your fixing i don't see why it needs a complete rewrite.  don't fall into the cadt trap.
15:09 <kuroneko> I don't plan a full rewrite yet.
15:10 <kuroneko> just the initialisation stuff
15:10 <kuroneko> and if that suffices, then it'll stay at that
15:10 <uriel> rsc9: can you give us an idea of what limitations you and jmk have hit, and what would you like to see done about it?
15:10 <rsc9> that's an in-depth discussion
15:10 <kuroneko> I'm on 9fans, so I'm happy to pick up comments there.
15:11 <uriel> rsc9: ok :)
15:11 <uriel> kuroneko: anything else?
15:11 <kuroneko> longer term:  general kernel device code cleanup stuff
15:11 <uriel> kuroneko: did you find any problems trying the fs?
15:11 <kuroneko> I need to try fs64 again
15:12 <kuroneko> and I have patches for fs which people probably won't like.
15:12 <uriel> rsc9: what is the stuatus of fs64 WRT the main distribution where AFAIK the intention is to deprecate everything that is not fossil/venti? :)
15:13 <kuroneko> my fs patch(es) work around quirks in the IDL PL7100s i'm using
15:13 <kuroneko> err, s/IDL/IDE/
15:13 <rsc9> geoff seems to be happy to maintain ken's file server, and we have no problem with that, but bell labs is moving on.
15:13 <kuroneko> One of the patches should be non-fatal
15:14 <kuroneko> and should make the jukebox enumeration code a bit more robust
15:14 <uriel> rsc9: any chance that if geoff wants his newer ken fs would be maintained/integrated into the BL distro?
15:14 <kuroneko> the other patch is specific to these jukeboxes and isn't worth touching.
15:15 <uriel> kuroneko: can you at least put that stuff in sources? it might be useful to someone who knows when...
15:15 <kuroneko> I *should* document the entire build procedure from scratch
15:15 <kuroneko> can somebody give me a writable directory in sources?
15:15 <uriel> kuroneko: rsc9 ;) (it's kind of documented in the wiki how to get a sources account)
15:16 <kuroneko> I've got a sources read account, not a writable directory...
15:16 <rsc9> if geoff sends us fs code we'll put it on sources.
15:16 <uriel> rsc9: ok, I will talk with him then
15:16 <uriel> kuroneko: that is what I was talking about
15:16 <kuroneko> I personally think if Geoff is happy with fs64 being distributed, then fs should fall to fs64
15:17 <kuroneko> fs64 should be able to replace it
15:17 <uriel> kuroneko: I'd like to see his work use sources as main repository, so things are not scatered all over the place, but I will bring it up with him and see what happens
15:18 <kuroneko> I'd also like to see that there is only one active ken-fs so we don't get reduplicated effort
15:18 -!- deen [~deen@www.sevsky.net] has joined #plan9
15:18 <kuroneko> although, geoff and myself are probably the only people fighting with it at the moment thanks to fossil/venti
15:18 <uriel> kuroneko: yes, absolutely, which is one of the reasons of keeping all work in a centralized place
15:19 <gdiaz> hi
15:19 <uriel> kuroneko: done?
15:19 <kuroneko> I think thats all the important stuff.
15:19 <uriel> gdiaz: you can take your turn now :)
15:20 <uriel> (what are you doing, and what is the status, and so on)
15:21 <gdiaz> oh, i only have tools for my own usage, that are no for general use (log parsers and so on that are useless for general public)
15:21 <uriel> gdiaz: what about 9grid.es?
15:22 <uriel> (and maybe your take on the whole cross-dom auth thing)
15:22 <gdiaz> i've got 9grid.org es (i can't buy .es domain, i need to be a company for that), have the machine and public ip, but is stalled due to work load :(
15:23 <gdiaz> next month i will have time to speak with 20h and start something more serious attempt about all cross-domain auth, etc
15:23 <uriel> ok, anything else? 
15:23 <gdiaz> no :( (i am in need of support :) )
15:24 <uriel> gdiaz: what kind of support?
15:24 -!- haraoka [~yoshiyuki@59.187.204.155] has quit [Read error: 110 (Connection timed out)]
15:24 <uriel> Major-Willard: your turn ;)
15:24  * Major-Willard has a bad hand -- accident on R&R
15:24 <Major-Willard> however
15:24 <uriel> :)
15:25 <Major-Willard> i have been tweaking the compiler for large macro expansions
15:25 <Major-Willard> it's 99.9% done
15:25 <Major-Willard> the 0.1% is subtle
15:26 <tmcm> oh, are we in the dev meeting?
15:26 <uriel> Major-Willard: it's all on sources? how much will it take to have it finished up and ready for production?
15:26 <uriel> tmcm: yes :)
15:26 <Major-Willard> cmd/8c & cmd/cc are on contrib/boyd
15:26 <rsc9> Just what we need - large macro expansions.
15:26 <Major-Willard> i learnt a lot about the compiler
15:27 <tmcm> rsc9: did you (or anyone else for that matter) have plans to fix those minor buffer overflows from that french report a few weeks ago?
15:27 <uriel> rsc9: please, lets try to be constructive(hell, even I'm trying to be constructive)
15:27 <Major-Willard> i ALSO decided that only a fool creates huge macros
15:27 <tmcm> afaict only like 1 or 2 were of any real consequence security-wise, but still...
15:27 <uriel> tmcm: wait a sec, we are going by turns ;)
15:27 <Major-Willard> ahh, fuck it
15:27 <rsc9> tmcm: it's starred in my gmail.  some day i'll get to it if no one else does.
15:28 <tmcm> ok
15:28 <uriel> Major-Willard: ok, anything else?
15:28 <rsc9> i was being a little constructive.  i'm glad boyd is fixing the limitations, i just agree that only a fool creates huge macros.
15:28 <Major-Willard> yeah, i been talking to brz about ozinferno
15:28 <uriel> rsc9: I think we all agree on that one ;)
15:28 <rsc9> i'd be a lot happier if someone else took care of them though.  a lot just change to snprint and it's done. 
15:29 <Major-Willard> nope
15:29 <uriel> rsc9: fixing the macro expansion is useful for the people taht are planning to move kencc to unix..
15:29 <tmcm> yeah, or add an (if len <...) before the cpy
15:29 <rsc9> just use snprint.
15:29 <uriel> any volunteers?
15:29 <rsc9> or strecpy.
15:29 <Major-Willard> nah
15:29 <tmcm> i'll see if i can knock a few out
15:30 <tmcm> time is tight right now :)
15:30 <Major-Willard> just change BUFSIZ and re-compile
15:30 <uriel> tmcm: cool
15:30 <kuroneko> was the report posted to 9fans?
15:30 <tmcm> yeah.
15:30 <uriel> kuroneko: yes
15:30  * uriel has to look for it and put it on the wiki TODO
15:30 <kuroneko> I might look at it when I get a chance then
15:31  * kuroneko has misplaced his fs patches
15:31 <uriel> ok, nashi?
15:31 <nashi> okay.
15:31 <nashi> running tip9ug servers.
15:31 <uriel> nashi: any issues with it?
15:31 <nashi> talking about multi authdom in tip9ug too.
15:31 <tmcm> kuroneko: http://schtarb.free.fr/plan9.txt
15:32 <tmcm> is the url from the original report
15:32  * kuroneko adds to the notes
15:32 <nashi> nothing particular so far.  everyone behaves good on mordor. :)
15:32 <uriel> nashi: :))
15:32 <uriel> nashi: aren't you working on some secret projects with vt3?
15:33 <rsc9> shhh!  it's a secret.
15:33 <uriel> :))
15:33 <nashi> what? are we doing some secret prj?
15:33 <uriel> nashi: dunno, =)
15:34 <nashi> anyway, i might be able to get a chance to do some p9 research  as a part of my work.
15:34 <uriel> cool
15:34 <nashi> i would like to make some distributed venti system.  or rather, venti proxy which fan out a write to multiple venti.
15:34 <rsc9> what would you use it for?
15:34 <uriel> nashi: what about your security concerns BTW?
15:35 <__20h__> devfs over network. ;)
15:35 <rsc9> there's a bad idea.
15:35 <tmcm> kuroneko: are the notes you're taking somewhere live now?
15:35 <nashi> it will work as a kind of oceanstore but one can do it far more easily by venti.
15:35 <kuroneko> nashi: tmcm: no.  they will be at the end.
15:36 <tmcm> ok.
15:36 <nashi> i'm done. thanks. :)
15:36 <vt3> nashi has also been discovering security issues with venti, working on japaneses fonts, and other things. he's being modest.
15:36 <kuroneko> teletha is not running a httpd just yet, and is unlikely to be.
15:36 <uriel> vt3: we know :)
15:36 <rsc9> how can there be security issues with a system that claims no security?
15:37 <nashi> hehe. :)
15:37 <uriel> rsc9: it would be nice to go from no-security into at-least-some-securty..
15:37 <vt3> then why do we need factotum if that were the case.
15:37 <rsc9> you don't need factotum for venti.
15:37 <vt3> point taken
15:38 <kuroneko> [I might have another converted developer to help the cause soon too - one of my friends will be likely looking into newsham's sparc64 port in more detail soon]
15:38 <nashi> one might not notice that venti has no security.  and there's a workaround to make it more secure. :)
15:38 <rsc9> in-depth discussion warning.
15:38 <uriel> ok :)
15:38 <uriel> noselasd: your turn
15:39 <ericvh> yeah.  I think it something worth talking about though.   We can extrapolate all the in-depth talking points from the notes and start 9fans threads on them.
15:39 <noselasd> uriel: eh ? I got nothing :-)
15:39 <uriel> noselasd: ok then, bad, bad, have something ready for next time ;P
15:39 <uriel> Oksel: you now!
15:40 <uriel> argh, who knows where he is, I will hunt him down, ...
15:40 <uriel> quintile: you then 
15:41 <uriel> blah, rmiller you I guess  then :)
15:41 <rmiller>  sorry i'm a irc newbie - is this working?
15:42 <uriel> rmiller: :)
15:42 <uriel> rmiller: yes :)
15:42 <rmiller>  pretty busy with other stuff but I'll catch up with some usb storage improvements soon
15:42 <noselasd> uriel: oh - only point I can mention, is I made lcc generate assembly 8a mostly understood, which was nice until I realized 8a wasn't very fully featured to put it mildly :-)
15:43 <quintile> rmiller: how difficult is usb attached disks (ipod) to support?
15:43 <rmiller>  usb itself still needs some work because it is too slow to be really useable for storage
15:44 <rmiller>  also lots of devices dont really obey the spec - haven't tried ipod yet
15:44 <Oksel> right
15:44  * Oksel is present! :)
15:44 <uriel> rmiller: what would be needed to boot from usb storage
15:44 <kuroneko> has anybody diced with the idea of implementing ieee1394 support?
15:44 <uriel> kuroneko: I seem to recal some coment about it in 9fans some time ago
15:45 <Oksel> rmiller: do you know why usb is slow?  i couldn't get past ~50kbyte/s
15:45 <rmiller>  uriel:
15:45 -!- McLone [~mclone@ns.viso.tr.ukrtel.net] has quit [Remote closed the connection]
15:45 <rsc9> do we have a usb 2.0 driver yet?
15:46 <rmiller>  Oksel: I know the immediate cause of slowness but not what causes that
15:46 <kuroneko> rsc9: I can see that being a problem
15:46 <uriel> rsc9: that would be nice, but if USB1 is slow, I don't see much point in aiming for 2.0, as the only real advantage is extra speed, and its' backwards compat
15:46 <kuroneko> I seem to recall that the EHCI docos was hard to get in an open manner
15:47 <rmiller>  Oksel: it is only able to send one packet per usb frame which is very limiting
15:47 <uriel> rmiller: any idea how to go about it?
15:47 <uriel> (btw, your comment about how to boot from usb storage din't show up :))
15:48 <rmiller>  uriel: forsyth may be looking at usb as well
15:48 <Oksel> rmiller: is that because of the way usb allocation work?  smt like "reserve so many % for isochronous" and turn whatever is left over to bulk?  i somehow got that idea, perhaps from you at twente9con
15:48 <rmiller>  uriel: booting from usb should work if your bios supports it
15:48 <uriel> rmiller: ah, cool
15:48 <rsc9> http://www.intel.com/technology/usb/download/ehci-r10.pdf
15:48 <musasabi> USB1.1 support would be very nice as all cheap USB devices seem to support that.
15:48 <uriel> rmiller: 9load and the kernel don't care about it? 
15:49 <rmiller>  Oksel: no, that isnt it
15:50 <Oksel> perhaps someone at a uni has need for usb2?  perhaps then i could implement it as thesis project or something, which should be coming up for me in a few months
15:51 <rmiller>  uriel: not sure about 9load now, it's a while since I looked at it
15:51 <uriel> rmiller: ok, thanks, I will investigate here when I have time, got some usb storage hardware recently..
15:51 <Oksel> 9load probably uses the bios?  and the kernel can load usbfs for boot?
15:51 <uriel> rmiller: anything else? any update on your smart card cool hacks? :)
15:52 <uriel> Oksel: 9load is known for it's lack of intelligence and not being very good at speaking with bioses
15:52 <rmiller>  sorry, with smart cards I'm still doing other stuff which I get paid for
15:53 <uriel> rmiller: ok, your demo at 9con was very cool :)
15:53 <rmiller>  uriel: thanks - maybe more one day
15:53 <kuroneko> rsc9: ooh.  ok.  ehci is obviously no longer taboo
15:53 <kuroneko> [if it ever was]
15:54 <uriel> Oksel: ok, you can take your place now ;P
15:54 <Oksel> wow, thank you uriel
15:55 <Oksel> anyway, i am not doing much specific right now
15:55 <Oksel> i'm interested in looking at usb stuff
15:55 <uriel> Oksel: lyar ;P
15:55 <Oksel> i modified usbd to automatically load usbmouse when a mouse gets plugged in
15:56 <Oksel> anyone want a more generic something for it?  or thinks its bad?  or should be done some way?
15:56 <Oksel> that way we could also get rid of the magic searching for unhandled devices in usb(audio mouse printer)
15:57 <Oksel> not that it's that magic
15:58 <uriel> no comments? well, anything else? ;P
15:58 <Oksel> :D
15:58 <uriel> Oksel: I guess that means you wont get stoned to dead if you send a patch for it ;P
15:58  * __20h__ gets a stone
15:59 <quintile> "but all I said was that that piece of halibut was good enough for..."
15:59 <uriel> Oksel: come on, I know you have been working on other stuff
15:59 <uriel> quintile: heheheh..
16:00 <Oksel> hum, well, cannot remember it right now?
16:00 <uriel> not me either, oh well
16:00 <uriel> quintile: we skiped you before, so...
16:00 <Oksel> oh, btw, don't know if it is well known already
16:00 <Oksel> http://marc.theaimsgroup.com/?l=9fans
16:01 <Oksel> which uriel made them put up
16:01 <uriel> it's linked from the wiki
16:01 <uriel> quintile: do you have anything to report then? (I hope so :))
16:02 <quintile> well, cifs - adding ntlmv2 auth, message signing, and dfs support,
16:02 <quintile> extracting libasn1 from libsec - leading to ldapfs, snmpfs and kerberos in factotum (one day).
16:03 <quintile> and chatfs as a /net service prtoviding msim, yahoo, jabber etc (ducks stone).
16:03 <uriel> quintile: oh, where is that code?
16:03 <uriel> quintile: I think it's about the third chatfs I hear of..
16:04 <quintile> all of the above are incomplete, if they where finished they would be published.
16:05 <uriel> quintile: it would be nice to have even work-in-progress code in sources/contrib for people to poke at, but well, I know not everyone agrees with that
16:05 <quintile> I would be happy to coperate with anyone who wants help but I am unhappy publishing half finished stuff.
16:06 <uriel> quintile: puting things in sources/contrib is not publishing IMHO, but well..
16:06 <ericvh> quintile: I may ping you on some of the auth stuff.
16:06 <quintile> yes, ntlm, kerberos ?
16:07 <ericvh> dunno.  Looking for more Linux solutions to v9fs auth.  Kerberos was my immediate thought, but it may not be the best path.
16:08 <uriel> you guys looked at inferno auth?
16:08 <quintile> I also had some ideas about xdomain auth but people seemed to dislike my ideas.
16:08 <kuroneko> krb5 might not be a completely meritless idea.
16:08 <tmcm> i agree
16:08 <quintile> kerb5 - are we talking client or server here?
16:09 <kuroneko> in the longer term, I'd say both.
16:09  * uriel dosn't understand why everyone seems to have different xdomain ideas and any kind of consensum or even dialog is impossible..
16:10 <quintile> uriel: Mmmm,
16:11 -!- nigelroles [~nigel@212.44.43.80] has joined #plan9
16:11 <uriel> hey nigelroles!
16:11 <uriel> quintile: anything else?
16:13 <quintile> a quastion: rsc9 sshv2 progress?
16:13 <quintile> hi nigel.
16:13 <uriel> sshv2 is a good question I guess, at least something very often asked by newbies
16:13 <rsc9> will email off-list.
16:14 <rsc9> wkj has an almost working sshv2 that i've done a little with.
16:14 <kuroneko> I have an open field question actually:  mips hardware support...
16:14 <uriel> rmiller: why off-list? if I may ask?
16:14 <kuroneko> has the cpu/term kernel ever run on SGI IP22 (Indy/ChallengeS/Indigo2) or DECStation?
16:14 <uriel> er, rsc9 
16:15 <rsc9> because it's an in-depth discussion.
16:15 <kuroneko> [as in MIPS DECStation]
16:15 <rsc9> list == #plan9
16:15 <uriel> rsc9: ok, could we get the code for that? maybe someone will fix it?
16:15 <rsc9> the code is not in a presentable form.
16:15  * uriel sighs
16:16 <uriel> it's sshv2, who expects it to be presentable?
16:16 <rsc9> steve simon and i will talk off-list.  i've been meaning to email him for a while.
16:16 -!- rminnich [~rminnich@65.242.93.132] has joined #plan9
16:16 <uriel> rsc9: ok
16:16 <uriel> hey ron!
16:16 <rminnich> good morning
16:16 <uriel> you are lucky, seems things are going slowly today :)
16:16 <rminnich> good, I am going slowly too. 
16:16 <ericvh> okay rminnich: give us your status/on-going projects.
16:17 <uriel> :)
16:17 <rsc9> it's the rest of us who are unlucky.
16:17 <rminnich> - making v9fs oops the kernel
16:17  * ericvh wonders if we can wrap this up in under 2 hours
16:17 <rminnich> - port to xen 3.0
16:17 <rminnich> - working with vic zandy'x xcpu
16:17 <rminnich> - strongarm (on hold for a bit)
16:17 <rminnich> - try to work with k8 once jmk releases initial kernel code
16:18 <rminnich> status:
16:18 <rminnich> - v9fs oops on unmount :-)
16:18 <ericvh> rminnich: I have your bug starred in gmail, will be getting to it shortly - RCx focus has been on linux normal support, now that we've got that worked out, I'll be trying to get regressions going for plan9ports.
16:18 <rminnich> - xen 3.0 goes slowly
16:18 <rminnich> - xcpu is really really nice
16:18 <rminnich> - strongarm enet driver has issue (ha ha)
16:18 <ericvh> side topic: what is xcpu? and what happened to vic zandy - he's no longer at the labs, right? 
16:19 <rminnich> zandy got tired of the labs, I think that the labs is more like my old for-profit lab I used to work for, it does not sound fun. 
16:19 <rminnich> So he went to work at CCS in bowie, md, my old haunt. 
16:19 <rminnich> I'm still hoping he will work with plan 9. 
16:19 <rminnich> he did some very neat stuff.
16:19 <kuroneko> and what is xcpu?
16:19 <rminnich> it's the thing everyone on the list hated so much :-)
16:19 <rsc9> ericvh: all signs point to no.
16:20 <rminnich> it's a server for remote execution
16:20 <rminnich> not released yet.
16:20 <rminnich> basically, it's for lightweight cluster nodes and is similar to the linux bproc stuff. 
16:20 <rminnich> so the xcpu server presents 4 files and a dir to you
16:20 <rminnich> the dir is /proc from the machine xcpu runs on
16:20 <rminnich> to exec:
16:20 <rminnich> files it presents are 
16:21 <rminnich> mach -- machine type -- read this file to read machine type (e.g. 'arm')
16:21 <rminnich> exe -- put executable files here
16:21 <rminnich> argv -- put argv here
16:21 <rminnich> ctl -- put commands here 
16:21 <rminnich> so to run a proc on a node
16:21 <rminnich> import the xcpu service from the node
16:21 <rsc9> no in-depth discussions?
16:21 <rminnich> Sorry!
16:21 <kuroneko> yeah, thats probably enough detail. :)
16:21 <rminnich> somebody asked :-)
16:21 <rminnich> I will stop :-)
16:22 <kuroneko> [it does sound nice though]
16:22 <uriel> rminnich: bad, you were right I at least woudln't like it ;P
16:22 <ericvh> what's the status on the 64-bit stuff rminnich? Or is that more of a jmk question?
16:22 <rminnich> xcpu kernels boot in xen in 1 second.
16:22 <rminnich> the compiler works
16:22 <rminnich> I think kernels are kinda happening. 
16:22 <rminnich> but jmk is taking the opportunity to clean up the kernel a bit
16:22 <kuroneko> "a bit"?
16:23 <rminnich> he had choice of 'something soon not as good'
16:23 <rminnich> 'something better later'
16:23 <rminnich> chose later
16:23 <ericvh> I was supposed to setup a ppc64 machine for forsyth to play with and potentially get a ppc64 compiler going for - but that was two months ago and I'm a slacker.  Took forever to get a serial port attachment for the G5.
16:23 <rminnich> well, stuff like the 2 memory regions etc. 
16:23 <uriel> "release early, release often" anyone? 
16:23 <kuroneko> ah
16:23 <rsc9> we're not all esr-wannabes.
16:23 <kuroneko> rminnich: thats going to reduplicate some of my stuff for sparc32 from the sounds of it
16:23 <ericvh> Also, our (IBM's) ppc64 simulator is finally going to get out on alpha-works, so that'll be another potential target.
16:23 <rminnich> I think jmk is doing right thing. It has to get done.
16:24 <uriel> rsc9: heh... *sigh*
16:24 <Major-Willard> nope, release when right
16:24 <rsc9> there is no point in releasing early when the changes people are going to submit are going to be worthless to you because you're going to make significant changes of your own anyway.
16:24 <uriel> kuroneko: oh, duplication of effort, joy! 
16:24 <rsc9> i said to keep jmk and me in the loop </toldyouso>
16:24 <uriel> rsc9: yes, there is point, many points actually, avoiding duplication of effort to begin with
16:25 <uriel> rsc9: leting other pick up half finished stuff that one has no time to finish is another point
16:25 <ericvh> rminnich: any words on what you are going to present at FastOS next week?
16:26 <rsc9> only if there is enough there that if it gets finished properly.
16:26  * ericvh isn't going
16:26 <uriel> rsc9: I think v9fs and Xen are two good examples of things that might not be perfect, but ron did the right thing and got them out as soon as possible so other people can pick them up
16:26 <rsc9> those are much bigger things than xalloc.  xalloc is a few hundred lines of code.
16:26 <rsc9> if that
16:26 <kuroneko> I doubt xalloc is the *only* thing though
16:27 <uriel> rsc9: xalloc is just one bit of the whole amd64 port, and that is just one example, I know rmiller also had problems with things he worked on and then had already been done by someone else, and there have been many such examples over the time
16:27 <uriel> kuroneko: exactly
16:27 <uriel> rsc9: also, there are not many examples of people finishing up stuff that someone else started and left half way, because no one releases anything
16:28 <rminnich> hey guys, just getting a call from someone so will by multiplexing, dammit. 
16:28 <rminnich> but I'm reading. 
16:28 <rsc9> I've released a handful of things and no one has finished any of them.
16:28 <rsc9> This is a silly argument.  People need to *talk* more, not write files more.
16:28 <uriel> rsc9: ok, lets move on... sorry to bring this up
16:29 <uriel> anyone left to talk about what he is doing?
16:29 <uriel> (aside from russ)
16:29 <ericvh> just you.
16:29 <uriel> hah! :)
16:29 -!- jz [~zoli@82.131.232.125.pool.invitel.hu] has joined #plan9
16:29 <uriel> well, I hacked up the wiki a bit, and I'm suposed to get an autogenerated changelog up and running some time...
16:30 <uriel> I have to change patch(1) to move submited patches into their own dir first, as it will simplify some bits a bit
16:30 <uriel> and I think that is about it, been too busy with work(and irc flames? :))
16:31 <uriel> rsc9: your turn now :))
16:31 <rsc9> I've been working on Venti.  It's almost in a releaseable state.  I'm starting to use it again.
16:32 <rsc9> Jmk has ordered parts for a new Venti server and we're going to run the new code on it.
16:32 <uriel> rsc9: when released it will make it into p9p?
16:32 <rsc9> The new Venti is a ton faster than the old one.  On my test system I can sustain about 10MB/s writing ad infinitum, with all the indexing and background jobs running.
16:32 <rsc9> It will be in p9p first, then Plan 9 proper.
16:32 <rsc9> I also have a dump file server for Unix file systems.
16:32 <kuroneko> hurrah!
16:33 <rsc9> The file system images get written to Venti each night, and then a user-level NFS server serves them
16:33 <tmcm> does it address that issue that vt3 was having with 3 day-long dumps?
16:33 <tmcm> (or however long it was)
16:33 <ericvh> awesine
16:33 <uriel> rsc9: very cool
16:33 <ericvh> err...awesome
16:33 <rsc9> It reduces the impact of the problem, but doesn't fix it.
16:33 <rsc9> The real bug there is in fossil.
16:33 <tmcm> good
16:34 <rsc9> venti=; pwd
16:34 <rsc9> /dump/am/2005/0519/usr/local/plan9/font
16:34 <rsc9> venti=; cd /dump/am/2005
16:34 <rsc9> venti=; ls -l
16:34 <rsc9> total 0
16:34 <rsc9> dr-xr-xr-x  3 root root 1024 2005-05-10 16:03 0510
16:34 <rsc9> dr-xr-xr-x  3 root root 1024 2005-05-12 05:01 0512
16:34 <rsc9> dr-xr-xr-x  3 root root 1024 2005-05-13 05:00 0513
16:34 <rsc9> dr-xr-xr-x  3 root root 1024 2005-05-14 05:00 0514
16:34 <rsc9> dr-xr-xr-x  3 root root 1024 2005-05-15 05:00 0515
16:34 <rsc9> dr-xr-xr-x  3 root root 1024 2005-05-16 05:00 0516
16:34 <rsc9> dr-xr-xr-x  3 root root 1024 2005-05-17 05:01 0517
16:34 <rsc9> dr-xr-xr-x  3 root root 1024 2005-05-18 05:00 0518
16:34 <rsc9> dr-xr-xr-x  3 root root 1024 2005-05-19 05:01 0519
16:34 <rsc9> venti=;
16:34 <uriel> cool
16:35 <uriel> rsc9: any plans for fossil? (fixing?)
16:35 <rsc9> Maybe.  It's not such a big deal once you get past the first snap.  Not a high priority.
16:35 <rsc9> I'd like to see cpu for p9p happen first.  Jeff Sickel might be working on it.
16:36 <uriel> ah, that would be great
16:36 <ericvh> this is perhaps a stupid question (shows how much I use venti) -- is there a way to get venti to export a read-only interface as well as a read-write port.  I'd like to have a venti server which only I (and a select few) can write to, but everyone could read-from.
16:36 <kuroneko> cpu for p9p ?...
16:36 <uriel> rsc9: you think that will fix the various problems people has had with things hanging up after install? (during first snap)
16:36 <rsc9> that what?
16:37 <uriel> cpu for p9p
16:37 <rsc9> no
16:38 <rsc9> Just an example of something I'd rather do than fix fossil.
16:38 <uriel> heh, great :/
16:39 <uriel> rsc9: what about ericvh's question, and any plans to provide any kind of security for venti?
16:39 <rminnich> cpu for p9p would be quite nice. We're going to do xcpu for p9p now, but I have to get v9fs to stop crashing on me :-)
16:39 <kuroneko> [did anybody answer my mips question?]
16:39 <rminnich> mips question?
16:39 <uriel> (or, crazy idea, make it talk 9p!)
16:40 <kuroneko> rminnich: I wanted to know if there had been prior ports to SGI IP22 (Indy series) or DECStation MIPS
16:40 <rsc9> I have no real plans.  I like doing it at the network level.
16:40 <rsc9> One could password-protect Venti but why bother.
16:40 <rsc9> Using 9P for Venti does not make a lot of sense to me.
16:40 <rminnich> [mips] don't know 'bout indy but any did get plan 9 running on the wrt54g (or whatever it is called) router
16:41 <quintile> kuroneko: there is a mips port but it is protected by NDAs (I believe)
16:41 <uriel> quintile: uhu? who did that? and how so?
16:41 <uriel> rsc9: why not?
16:41 <kuroneko> rminnich: that sounds decisively wrong. :)
16:42 <uriel> rsc9: this is Plan 9, we speak 9p with everyone, and that gives you auth too...
16:42 <kuroneko> er, decidedly even
16:42 <rminnich> <kuroneko> rminnich: that sounds decisively wrong. :)
16:42 <rsc9> There's only one resource, so it would be a single file, and it would require multiple transactions per current Venti transaction (a write and then a read).
16:42 <rminnich> uh oh, which wrong thing did I say now :0_
16:42 <kuroneko> mips on wrt54g
16:42 <kuroneko> err
16:42 <kuroneko> plan9 on wrt54g :)
16:42 <rminnich> ah, yeah, but it's a port, :-)
16:42 <kuroneko> :)
16:43  * kuroneko adds DECStation and Indy to his port list for after sparc
16:43 <kuroneko> [Indy will hopefully be easy.  hopefully.]
16:43 -!- irc [jpc@guacamole-09.dynamic.rpi.edu] has joined #plan9
16:44 <uriel> rsc9: I guess you are right... oh well, having auth would be nice still..
16:44 <rsc9> What auth?  It's not even well-defined.  You could password protect the server, but beyond that I don't see any coherent authentication story.
16:44 <ericvh> well, I wasn't really saying security for venti, just a read-only port...that's a bit different.
16:44 <uriel> rsc9: well, you could use the same mechanism you use to auth against any other 9p server...
16:45 -!- plalonde [~plalonde@d66-183-189-46.bchsia.telus.net] has joined #plan9
16:45 <uriel> ericvh: yup
16:45 <rsc9> But then all my apps have to deal with it, and I don't want to close it off from Unix.  I still don't see that it matters much.
16:46 <ericvh> The idea behind a read-only port being I can firewall the read-write port from the world, but leave the read-only open.
16:46 -!- lantis [~lantis@p548746A8.dip.t-dialin.net] has joined #plan9
16:46  * ericvh appologizes for the delays between messages, multitasking at the moment.
16:46 <uriel> rsc9: and I thought that one of the great things about Plan 9 is that we had control over the whole system so we did things right and integrated them well...
16:47 <kuroneko> uriel: I'm not sure about this "do things right" bit... :P
16:48 <nashi> do you assign ownership to every venti blocks and permission checking it?  no authentication is necessary wrt venti, i guess.
16:48 <ericvh> rminnich: can you send me a more detailed oops report?
16:48 <rminnich> yeah, I'm trying to narrow it all down. 
16:48 <rminnich> question: for my purposes I use u9fs for export, and 9fs to mount. 
16:48 <uriel> kuroneko: well, I'm quite sure about the "fix things in the whole system and do them consitently without having to worry about compat with junk", it's even mentioned in rsc9's overview
16:48 <ericvh> rminnich: it's likely in the flush code.
16:48 <rminnich> YOu guys only using amount nowadays? 
16:48 <rsc9> I just don't have any idea about what "right" is.  Everyone clamors for authentication but no one can tell me how it should be done.
16:48 <ericvh> rminnich: a slab leak in true interrupt cases.
16:49 <ericvh> rminnich - no, I principally use mount, I only use amount to get to sources.
16:49 <ericvh> v9fs discussion -> #v9fs
16:49 <rminnich> ok.
16:49  * ericvh appologizes to the plan9 meeting.
16:49  * rminnich too, ron still is not sure what the meeting is for.
16:50 <uriel> rsc9: ok, I thought someone at the labs would have had some idea about it
16:50 <kuroneko> rminnich: "I'm doing this" it seems.
16:50  * kuroneko is tempted to wrap up the notes since we seem to be in random chatter now
16:50 <rminnich> oh, so, who's doing acpi :-)
16:50 <rsc9> There were ideas about Venti auth originally but it was little more than a public key p9sk1.
16:50 <ericvh> Okay, I think we are done with the principal meeting anyways.  venti auth/whatever is obviously an extended discussion, although I may hack in read-only ports.  rsc9: is the venti CVS your up-to-date working copy?
16:50 <uriel> kuroneko: random chater is usually more productive ;)
16:50  * kuroneko cringes
16:51 -!- rsc9 [rsc@tux.lcs.mit.edu] has left #plan9 []
16:51 <kuroneko> rminnich: how bout we put in a hardware tree/bindery first ?
16:51  * uriel blinks
16:51 <kuroneko> and remove the hard ties from drivers that should be arch independant and their architectures?
16:51 <kuroneko> and if we haven't scared/offended all the other kernel hackers by then...
16:52 -!- jz [~zoli@82.131.232.125.pool.invitel.hu] has left #plan9 []
16:52 -!- nigelroles [~nigel@212.44.43.80] has left #plan9 []
16:52 <kuroneko> I suspect ACPI is non-trivial
16:52 <__20h__> Having a fossil-venti-only-connection would satisfy my needs. This means that only the hostowner of the server running fossil should be able to access the venti.
16:52 <uriel> kuroneko: I have heard nemo was working on it at some point
16:52 <vt3> so what I learnt from this is that the participants should update their profiles on the wiki.
16:53 <uriel> vt3: I think someone will have to write a list of profiles
16:53 <vt3> have fun
16:53 <uriel> vt3:  I will try to do that with help of kuroneko's notes :)
16:53 <nashi> oh, you are still awake, vt3?
16:53 <vt3> nashi, yeah. 
16:53 <kuroneko> uriel: I swear, if I survive the sparc port, I will be gutting a lot of the device driver code
16:54 <nashi> what's your report? it took some time to come to "v" :
16:54 <uriel> kuroneko: :)
16:54 <nashi> :)
16:54 <kuroneko> the amount of duplicated code in the drivers would be plain stupid otherwise.
16:54 <vt3> i'll tell you on #acme
16:54 <uriel> kuroneko: cool
16:54 <uriel> ok, for next time we use a dedicated channel...
16:55  * kuroneko sticks the report up on http server.
16:55 <uriel> kuroneko: please, put it on the wiki?
16:55 <nashi> okay.  but i almost sleep.  please mail me. sorry.
16:55 <uriel> nashi: I'm also almost asleep
16:55 <uriel> :/
16:55 <uriel> well, should we continue a bit?
16:56 <nashi> 20h: for the last shot, what if venti post to /srv with the mode 0600 and fossil talk to it?
16:56 <uriel> anyone wants to at least sugest how we set procedure/time for next time?
16:56 <__20h__> Nashi, that's the Plan 9 way.
16:56 <ericvh> -> 9fans
16:56 <uriel> #9fans? :)
16:56 <ericvh> meaning, we should discuss how to manage the conferences on the mailing list.
16:56 <kuroneko> http://nekohako.xware.cx/plan9devmeet/Notes-20050519.txt
16:56 <uriel> ericvh: ok, you moderate next time
16:57 <uriel> ericvh: well, my idea was to use this first meeting to discuse how to manage the next one..
16:57 -!- nashi [none@mordor.tip9ug.jp] has left #Plan9 []
16:58 <ericvh> ugh..meetings to talk about meetings.  Sounds like IBM
16:58 <uriel> ericvh: for next time at least we got a list, and we can go over the topics fast
16:58 <ericvh> thanks for taking notes kuroneko.
16:58 <uriel> ericvh: no, just to bootstrap things
16:58 -!- vt3 changed the topic of #plan9 to: Postmortem conversations=> 9fans list | off topic talk -> #acme | trolls -> /ignore    Python for Plan 9 at http://www.tip9ug.jp/who/moroo/python2.4p9.tgz
16:58 <kuroneko> anyway, I do feel the kernel needs overhauling and it'll be on my mind once I get sparc working
16:58 <rminnich> well keep in sync with jmk then.
16:58 <kuroneko> since I should have a better idea how to seperate drivers from hardware bindings by then
16:59 <uriel> kuroneko: _please_ keep jmk in the loop
16:59 <uriel> vt3: I wanted to talk about python too :(
16:59 <ericvh> Its clear we all need to do a better job of keeping everybody in the loop about what everyone is working on ;)
16:59 <kuroneko> if I knew who jmk was, and/or had contact details for him...
16:59 <ericvh> jmk@plan9.bell-labs.com
16:59 <__20h__> Communism!
16:59 <uriel> ericvh: the question is what is the best way to acomplish it..
17:00 <gdiaz> communismfs 20h :-D
17:00 <uriel> kuroneko: jmk is the only person left at the Labs working on Plan 9, *sigh*
17:00 <ericvh> well, IRC works for getting things out.  It would have been nice to hear from Vita about what they are working on.
17:00 <kuroneko> uriel: ah
17:00 <uriel> kuroneko: talk about transparency, eh?
17:00 <uriel> ericvh: how do we set agenda then for next time?
17:00 <uriel> ericvh: you mod, so I guess you can coordinate that, I got a long list of items on my own agenda..
17:00 <gdiaz> see you all :-)
17:01 <uriel> (which i was hoping to bring up today...)
17:01 <ericvh> I think the best approach is monthly IRC to get things out that people don't want to post about, wiki to set agendas and post notes, and mailing list for extended discussions.
17:01 <__20h__> cya gdiaz
17:01 <ericvh> uriel: long discussions may be best handled in sub-meetings.
17:01 <uriel> ericvh: I don't think that really works, but well..
17:01 <__20h__> I must admit: I hate bureacracy.
17:01 <kuroneko> the other thing is, the right media for the right discussion
17:01 <uriel> __20h__: me too, that is why there was no agenda, and it was a disaster :(
17:01 <ericvh> Another thing that wouldn't be a bad idea is some sort of monthly newsletter, but I doubt anyone will really take the time to put it together.
17:02 <__20h__> uriel, it was no disaster.
17:02  * kuroneko has been recently bombarded with media convergence theory and other related learning/teamwork stuff
17:02 <uriel> ericvh: and a news page
17:02 -!- heikoo [~heiko@82.139.199.253] has joined #plan9
17:02 <uriel> ericvh: that is in my list of top priority to do, forgot to mention it
17:02 <uriel> hey heikoo 
17:02 <heikoo> hello there
17:02 <kuroneko> for fledgling ideas, IRC is probably considerably better than having people take it to the list
17:02 <uriel> I would like help/sugestions about how to keep a news wiki page
17:02 <__20h__> tach Heiko
17:03 <heikoo> hello there
17:03 <kuroneko> whereas for ideas which are well formed and well on their way, the list is more conveniant/appropriate
17:03 <uriel> (and probably an "anouncements" list where such posts would go too
17:03 <ericvh> kuroneko: agreed.
17:03 <uriel> kuroneko: 9fans seems rather dead lately
17:03 <kuroneko> and we should probably encourage that sort of patterning
17:03 <quintile> sorry, I was in another meeting whilst typing: re mips port.
17:03 <kuroneko> ericvh: its all part of MCT
17:03 <__20h__> glendaforge.net
17:03 <uriel> __20h__: we got sources already
17:03 -!- heikoo [~heiko@82.139.199.253] has quit [Client Quit]
17:03 -!- plalonde [~plalonde@d66-183-189-46.bchsia.telus.net] has left #plan9 []
17:03 <kuroneko> divergence and convergence phases in teamwork
17:03  * kuroneko cringes
17:04 <Major-Willard> well it made my mind up
17:04 <__20h__> uriel, that's where it is redirecting to. ;)
17:04 <ericvh> Major-Willard: kill them all?
17:04 <uriel> hehe
17:04 <Major-Willard> nope
17:04  * kuroneko is currently being paid to do stuff related to team learning environments
17:04 <Major-Willard> that's had work
17:04 -!- heikoo [~heiko@82.139.199.253] has joined #plan9
17:04 <Major-Willard> hard
17:05 <uriel> kuroneko: just what we need :)
17:05 <quintile> kuroneko: whats your email?
17:05 <kuroneko> uriel: its not my area to be honest.
17:05 <heikoo> hello, sorry, i'm new to 20h's client ;-/
17:05 <kuroneko> quintile: chris@collins.id.au
17:05 <Major-Willard> doing nothing is easier
17:05 <uriel> kuroneko: can you add yourself to the comunity page in the wiki
17:05 <quintile> kuroneko: you will have mail :-)
17:05 <kuroneko> thanks
17:06 <uriel> kuroneko: and lets take your notes and make a "Developers" page with contact info for everyone, so if someone starts to work on something they can get in touch with someone that is working already in that are
17:06 <uriel> a
17:06 -!- rminnich [~rminnich@65.242.93.132] has quit ["BitchX: stays crunchy in milk!"]
17:07 <ericvh> be back in a bit.  Would folks who raised questions that got tabled because they were in-depth discussions please start threads on 9fans?
17:07 -!- ericvh [~ericvh@pixpat.austin.ibm.com] has quit ["Download Gaim: http://gaim.sourceforge.net/"]
17:08 <uriel> good idea, anyone was keeping track of things that were shot down because things were "in depth"?
17:08 <uriel> anyone has anything else to say?
17:09 <vt3> I don't have anything besides saying thanks for everyone for showing up.
17:09 <uriel> any comments on trying again in one month  in a separated chanel with ericvh as moderator and with an agenda set somehow?
17:10 <uriel> yes, I also want to thank everyone that showed up, and I'm sorry for not managing things better :(
17:11 -!- vt3 [~vt3@m016020.ppp.asahi-net.or.jp] has quit ["Leaving"]