2008-09-26 01:28 folks 2008-09-26 01:28 -!- pranith(ca4bcee2@webchat.mibbit.com) has joined #tux3 2008-09-26 01:28 hello 2008-09-26 01:28 anyone here? 2008-09-26 01:52 -!- pgquiles(~pgquiles@42.Red-83-39-60.dynamicIP.rima-tde.net) has joined #tux3 2008-09-26 02:04 -!- pranith(ca4bcee2@webchat.mibbit.com) has joined #tux3 2008-09-26 02:04 hello 2008-09-26 02:44 -!- pgquiles(~pgquiles@42.Red-83-39-60.dynamicIP.rima-tde.net) has joined #tux3 2008-09-26 03:58 hola 2008-09-26 04:49 anyone here? 2008-09-26 05:17 -!- pranith(ca4bcee2@webchat.mibbit.com) has joined #tux3 2008-09-26 05:17 hmm 2008-09-26 05:23 well, i am here, but i will not be able to answer any questions :) 2008-09-26 05:23 and the rest is probably asleep. it's 5 am there or something like that 2008-09-26 05:25 hehe 2008-09-26 05:25 ok 2008-09-26 05:25 hmm 2008-09-26 06:06 -!- pranith(ca4bcee2@webchat.mibbit.com) has joined #tux3 2008-09-26 06:06 reading yesterday's logs 2008-09-26 06:06 since no one posted the tux u proceedings... 2008-09-26 06:06 i think im going to do that 2008-09-26 06:23 could you post those from tuesday too? 2008-09-26 06:23 i think they are still missing 2008-09-26 07:13 hmm 2008-09-26 07:13 wait 2008-09-26 08:03 hmmm 2008-09-26 08:49 hola 2008-09-26 08:49 sad to hear the feature drop from tux3 2008-09-26 08:50 was hoping we could blow away zfs 2008-09-26 08:50 that was an awesome idea of dynamically increasing your fs across multiple hds 2008-09-26 08:56 pranith: well, lvm3 will be used for that, hopefully 2008-09-26 08:57 _hopefully_ 2008-09-26 08:57 yeah, the argument for not doing that is reasonable 2008-09-26 09:12 will tux3 be having plugins?? :D 2008-09-26 09:12 we can implement this as a plugin if possible 2008-09-26 09:12 ;) 2008-09-26 09:30 -!- RazvanM(~RazvanM@dazzler.isi.jhu.edu) has joined #tux3 2008-09-26 09:31 ACTION is sorry he missed the class from last night :-( 2008-09-26 09:37 -!- tim_dimm(~timothyhu@cpe-76-90-98-247.socal.res.rr.com) has joined #tux3 2008-09-26 10:20 -!- flips(~phillips@phunq.net) has joined #tux3 2008-09-26 10:22 nah, plugins for this are pretty much as implementing it to begin with 2008-09-26 10:22 as hard ;-) 2008-09-26 10:48 -!- Kirantpatil(~kiran@122.167.222.6) has joined #tux3 2008-09-26 10:48 -!- Kirantpatil(~kiran@122.167.222.6) has left #tux3 2008-09-26 10:59 -!- hirofumi(~hirofumi@210.171.168.39) has joined #tux3 2008-09-26 12:24 -!- MaZe(~MaZe@216-239-45-4.google.com) has joined #tux3 2008-09-26 12:42 -!- pgquiles(~pgquiles@42.Red-83-39-60.dynamicIP.rima-tde.net) has joined #tux3 2008-09-26 14:38 -!- pgquiles(~pgquiles@82.Red-81-33-103.dynamicIP.rima-tde.net) has joined #tux3 2008-09-26 14:53 -!- tim_dimm(~timothyhu@cpe-76-90-98-247.socal.res.rr.com) has joined #tux3 2008-09-26 15:21 -!- tim_dimm(~timothyhu@cpe-76-90-98-247.socal.res.rr.com) has joined #tux3 2008-09-26 15:35 -!- pgquiles(~pgquiles@82.Red-81-33-103.dynamicIP.rima-tde.net) has joined #tux3 2008-09-26 15:36 maze, plugins? 2008-09-26 15:36 hmm? 2008-09-26 15:36 moment 2008-09-26 15:36 MaZe> nah, plugins for this are pretty much as implementing it to begin with 2008-09-26 15:37 earlier on talk of plugins for multi-disk 2008-09-26 15:37 I must have been d/c for that 2008-09-26 15:37 filesystem plugins? 2008-09-26 15:38 something like that 2008-09-26 15:38 implementing support for plugins in tux3 2008-09-26 15:38 and then implementing support for multi-disk as a plugin 2008-09-26 15:38 If I understood correctly 2008-09-26 15:38 I was commenting about 2-3 hours later 2008-09-26 15:38 plugins make me think if reiserfs 2008-09-26 15:39 (08:49:58 AM) pranith: sad to hear the feature drop from tux3 2008-09-26 15:39 (08:50:09 AM) pranith: was hoping we could blow away zfs 2008-09-26 15:39 (08:50:36 AM) pranith: that was an awesome idea of dynamically increasing your fs across multiple hds 2008-09-26 15:39 (08:56:11 AM) RzM|Away left the room (quit: Quit: Computer goes to sleep!). 2008-09-26 15:39 (08:56:47 AM) data: pranith: well, lvm3 will be used for that, hopefully 2008-09-26 15:39 (08:57:04 AM) pranith: _hopefully_ 2008-09-26 15:39 (08:57:31 AM) pranith: yeah, the argument for not doing that is reasonable 2008-09-26 15:39 (09:12:00 AM) pranith: will tux3 be having plugins?? :D 2008-09-26 15:39 (09:12:10 AM) pranith: we can implement this as a plugin if possible 2008-09-26 15:39 if there are plugins, they will certainly not land before initial merge 2008-09-26 15:39 and there will be no aborbing the volume manager into tux3 2008-09-26 15:40 when designing lvm3 we need to figure out some sort of fs-bdev interface which provides more info than currently available 2008-09-26 15:40 what tux3 will do is work more closely with the volume manager 2008-09-26 15:40 which we will also develop 2008-09-26 15:40 maze, did you know you were going to be developing a volume manager? 2008-09-26 15:40 heh 2008-09-26 15:40 serious 2008-09-26 15:40 see comment above 2008-09-26 15:40 which one? 2008-09-26 15:40 the fs driver in order to schedule some stuff 2008-09-26 15:40 needs to know more about bdev disk layout for non disk bdevs 2008-09-26 15:40 ie. raid multi-disk etc 2008-09-26 15:41 exactly 2008-09-26 15:41 the fs is going to be able to specify the volume map 2008-09-26 15:41 and to retrieve it from the lvm 2008-09-26 15:41 very important 2008-09-26 15:41 a driver for this is already sketched out 2008-09-26 15:41 it's called "table block device" 2008-09-26 15:42 and will be a plugin for lvm3 2008-09-26 15:42 which we are going to develop 2008-09-26 15:42 hmm interesting 2008-09-26 15:42 -!- pgquiles(~pgquiles@82.Red-81-33-103.dynamicIP.rima-tde.net) has joined #tux3 2008-09-26 15:42 covered stuff like this in my berlin talk 2008-09-26 15:43 and should probably get it on the agenda for some upcoming linux confab 2008-09-26 15:43 though sometimes I feel like I'm showing television to the family dog as far as understanding from other kernel devs goes 2008-09-26 15:43 hopefuly repeated impressions makes a difference 2008-09-26 15:44 that's one reason why we need to make some new kernel devs 2008-09-26 15:44 heh 2008-09-26 15:45 I'm being pulled in 4 directions here 2008-09-26 15:46 bio is pulling strongest I think 2008-09-26 15:46 and not having enough time to devote myself fully to any of these 2008-09-26 15:46 just don't get distracted by mm 2008-09-26 15:46 no, not even talking about in-kernel 2008-09-26 15:46 regard it as an interesting, funny little friend with occasionally curious opinions and you will be ok 2008-09-26 15:47 talking about my team at work, another team (kernel), and a 3rd team in the process of being created (networking), plus pure kernel as fourth 2008-09-26 15:47 fuck real life ;) 2008-09-26 15:48 anyway, the key is not to get the idea you have to understand the whole kernel at once 2008-09-26 15:48 even linus doesn't 2008-09-26 15:48 or akpm, though he probably gets closest 2008-09-26 15:51 of course you don't 2008-09-26 15:51 but it's best to understand as much as possible 2008-09-26 15:52 and preferably at least one level down from where you muck around 2008-09-26 15:52 true 2008-09-26 15:52 if the kernel internal apis were clean and well documented, this wouldn't be that needed 2008-09-26 15:52 with the total lack of docs, it's not possible to write non-buggy code 2008-09-26 15:52 sometimes you are just plain forced to proceed on induction though 2008-09-26 15:52 without knowing what it will actually do 2008-09-26 15:52 it depends on what you're trying to do of course 2008-09-26 15:53 anyway 2008-09-26 15:53 lxr is the answer 2008-09-26 15:53 write bug-less code is easy, if and only if, there is no undocumented code in the layers beneath (and to a lesser extent above) you 2008-09-26 15:53 right, hence I've been reading code as a passtime 2008-09-26 15:53 knowing everything in advance helps you design, but is not strictly necessary for developing or debugging 2008-09-26 15:53 true 2008-09-26 15:54 but browsing code requires less commitment 2008-09-26 15:54 in other words, you can pick up the info on-demand for the latter two 2008-09-26 15:54 and that's something I have time for 2008-09-26 15:54 right 2008-09-26 15:54 also: taking in too much at once can lead to burn out and drop out 2008-09-26 15:55 true 2008-09-26 15:55 what does NPI mean? 2008-09-26 15:55 NFI 2008-09-26 15:55 <- "no fscking idea" 2008-09-26 15:56 heh 2008-09-26 15:56 it's a TLA thought up by a SFI 2008-09-26 16:08 -!- pgquiles(~pgquiles@82.Red-81-33-103.dynamicIP.rima-tde.net) has joined #tux3 2008-09-26 16:14 -!- pgquiles(~pgquiles@82.Red-81-33-103.dynamicIP.rima-tde.net) has joined #tux3 2008-09-26 16:21 Settlement-Free Interconnect 2008-09-26 16:21 apparently SFI is a valid TLA in networking 2008-09-26 16:21 just hit on it in a doc 2008-09-26 16:38 -!- pgquiles(~pgquiles@82.Red-81-33-103.dynamicIP.rima-tde.net) has joined #tux3 2008-09-26 17:00 -!- tim_dimm(~timothyhu@cpe-76-90-98-247.socal.res.rr.com) has joined #tux3 2008-09-26 17:01 -!- pgquiles(~pgquiles@82.Red-81-33-103.dynamicIP.rima-tde.net) has joined #tux3 2008-09-26 17:06 -!- pgquiles(~pgquiles@82.Red-81-33-103.dynamicIP.rima-tde.net) has joined #tux3 2008-09-26 17:37 -!- pgquiles(~pgquiles@82.Red-81-33-103.dynamicIP.rima-tde.net) has joined #tux3 2008-09-26 20:02 -!- ajonat(~ajonat@190.48.119.128) has joined #tux3 2008-09-26 20:30 -!- ajonat(~ajonat@190.48.119.128) has joined #tux3 2008-09-26 21:16 maze, in my lexicon a SFI is a stupid fscking idiot ;) 2008-09-26 21:16 somebody who likes to invent TLAs to be leet 2008-09-26 21:17 I suppose that would now include me 2008-09-26 21:18 course we could consider an exemption for those who only make them up as satire 2008-09-26 22:12 -!- tim_dimm(~timothyhu@cpe-76-90-98-247.socal.res.rr.com) has joined #tux3 2008-09-26 22:32 hey tim_dimm