Current Page -
Last modified Thu May 19 21:35:52 CES 2005
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 [[email protected]] has quit ["Leaving"] 14:43 <__20h__> If ddr.9grid.de gets online again, then only factotum is the part missing. 14:43 -!- haraoka [[email protected]] has joined #plan9 14:44 -!- noselasd [[email protected]] 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 [[email protected]] 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 [[email protected]] 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 [[email protected]] 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 [[email protected]] 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 [[email protected]] 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 [[email protected]] 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 [[email protected]] 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 [[email protected]] 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 [[email protected]] 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 [[email protected]] 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 [[email protected]] 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 [[email protected]] 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 [[email protected]] 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 [[email protected]] 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 [[email protected]] 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 [[email protected]] has left #plan9 [] 16:52 -!- nigelroles [[email protected]] 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 [[email protected]] 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> [email protected] 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 [[email protected]] 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 [[email protected]] has quit [Client Quit] 17:03 -!- plalonde [[email protected]] 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 [[email protected]] 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: [email protected] 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 [[email protected]] 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 [[email protected]] 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 [[email protected]] has quit ["Leaving"]
