THM 2005-05-19 Log
D1116531352
Auriel (82.182.149.46)
#! 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"]