2008-10-30 01:19 -!- vcgomes[away](~vcgomes@li17-238.members.linode.com) has joined #tux3 2008-10-30 03:54 -!- pgquiles_(~pgquiles@62.43.226.52.static.user.ono.com) has joined #tux3 2008-10-30 04:01 -!- pgquiles__(~pgquiles@19.Red-83-44-236.dynamicIP.rima-tde.net) has joined #tux3 2008-10-30 07:27 -!- tim_dimm(~timothyhu@cpe-76-90-98-247.socal.res.rr.com) has joined #tux3 2008-10-30 09:29 -!- mingming(~mingming@32.97.110.51) has joined #tux3 2008-10-30 12:08 -!- RazvanM(~RazvanM@dazzler.isi.jhu.edu) has joined #tux3 2008-10-30 12:15 -!- tim_dimm(~timothyhu@cpe-76-90-98-247.socal.res.rr.com) has joined #tux3 2008-10-30 12:56 -!- MaZe(~MaZe@216-239-45-4.google.com) has joined #tux3 2008-10-30 12:57 -!- MaZe(~MaZe@216-239-45-4.google.com) has joined #tux3 2008-10-30 13:12 flips: cabal is today right ? 2008-10-30 13:50 bh, postponed due to me having a cold 2008-10-30 13:51 ok 2008-10-30 13:51 when ? 2008-10-30 14:09 stay tuned for further developments 2008-10-30 14:11 we having the 8pm u today? 2008-10-30 14:19 ok 2008-10-30 14:19 flips: I was going to drive up Friday possibly so that's why I asked 2008-10-30 14:27 oh, it will be next week 2008-10-30 14:37 -!- tim_dimm(~timothyhu@cpe-76-90-98-247.socal.res.rr.com) has joined #tux3 2008-10-30 14:41 ok 2008-10-30 14:41 I might be in the SF bay area by then 2008-10-30 16:42 -!- tim_dimm(~timothyhu@cpe-76-90-98-247.socal.res.rr.com) has joined #tux3 2008-10-30 16:53 -!- ajonat(~ajonat@190.48.117.217) has joined #tux3 2008-10-30 17:52 -!- ajonat(~ajonat@190.48.124.161) has joined #tux3 2008-10-30 18:33 -!- mlankhorst(~m@fw1.astro.rug.nl) has joined #tux3 2008-10-30 19:50 -!- RazvanM(~RazvanM@pool-151-196-126-202.balt.east.verizon.net) has joined #tux3 2008-10-30 20:00 ping... 2008-10-30 20:00 -!- RalucaM(~ral@pool-151-196-126-202.balt.east.verizon.net) has joined #tux3 2008-10-30 20:00 hi 2008-10-30 20:00 ACTION is warming up the lxr 2008-10-30 20:01 ACTION is also very sleepy because he has an uptime of about 17h 2008-10-30 20:02 ACTION looks around... 2008-10-30 20:02 ACTION is not particularly sleepy today because he had a decent maintenance downtime window this time around... 2008-10-30 20:02 flips is not around? 2008-10-30 20:03 ACTION searches around for flips 2008-10-30 20:03 ACTION is also back on macbook :P 2008-10-30 20:03 ACTION me on a macbook as well 2008-10-30 20:03 :D 2008-10-30 20:03 macbook is good... 2008-10-30 20:03 hi 2008-10-30 20:03 ups that wasn't a correct action 2008-10-30 20:03 hey 2008-10-30 20:03 on the other hand I did some progress on PPC while the macbook was away ;-) 2008-10-30 20:03 RazvanM: running Mac or linux on the macbook? 2008-10-30 20:03 MaZe: Mac OS 2008-10-30 20:04 ok, let's look at the block io library today, a little more 2008-10-30 20:04 ah, well, I'm running linux, I like the hardware, but couldn't get used to the OS and switched to running progressing versions of fedora 2008-10-30 20:04 see what's there, and why we call it the library 2008-10-30 20:05 there are actually two layers of block library functions 2008-10-30 20:05 the top layer being the generic_* routines 2008-10-30 20:05 let's start with the which linux ver question 2008-10-30 20:05 2.6.27 2008-10-30 20:05 I slipped last time 2008-10-30 20:06 the generic_* are all called through hooks, which we have seen 2008-10-30 20:06 of the form "if this hook (e.g., ->write) is nonzero then call the function supplied by the filesystem" 2008-10-30 20:07 otherwise the vfs calls a generic function 2008-10-30 20:07 grep generic * | grep EXPORT | wc -l 2008-10-30 20:07 26 2008-10-30 20:07 all in buffer.c and filemap.c? 2008-10-30 20:07 (in fs/) 2008-10-30 20:07 why not have the hooks point to the default and not have to the the if check every time? 2008-10-30 20:08 because we're lame 2008-10-30 20:08 grep generic * | grep EXPORT | cut -d ':' -f 1 | sort | uniq | xargs 2008-10-30 20:08 buffer.c fs-writeback.c inode.c libfs.c locks.c namei.c namespace.c open.c read_write.c splice.c stat.c super.c xattr.c 2008-10-30 20:08 changing it would require a big spam edit to dozens of filesystems, if you can show a benefit such a patch is sometimes accepted 2008-10-30 20:08 50/50 chance, assuming it actually deletes code or makes something more efficient 2008-10-30 20:09 razvanm, so generics are splattered all over the place 2008-10-30 20:09 in keeping with how they came to be: they all started life as specific code used by some filesystem, typically ext2 2008-10-30 20:10 really it would be better if they were all in libfs.c 2008-10-30 20:10 I wonder what's in locks.c 2008-10-30 20:11 ACTION looks 2008-10-30 20:11 libfs.c:EXPORT_SYMBOL_GPL(generic_fh_to_dentry); 2008-10-30 20:11 libfs.c:EXPORT_SYMBOL_GPL(generic_fh_to_parent); 2008-10-30 20:11 libfs.c:EXPORT_SYMBOL(generic_read_dir); 2008-10-30 20:11 locks.c:EXPORT_SYMBOL(generic_setlease); 2008-10-30 20:11 only one is in locks.c 2008-10-30 20:11 libfs.c would appear to be half an idea 2008-10-30 20:12 what do you mean - half an idea? 2008-10-30 20:12 having only those three minor generics in it doesn't fit the name well 2008-10-30 20:12 fh_to dentry is an nfs function by the way 2008-10-30 20:13 (beside the 26 in fs/ there are 10 more in mm/; 9 in mm/filemap.c and one in mm/page-writeback.c) 2008-10-30 20:13 I suppose we could look at how nfs works one session some time down the road 2008-10-30 20:13 ok, I see 2008-10-30 20:13 that will be scary 2008-10-30 20:13 fh - filehandle? 2008-10-30 20:13 so basically nfs cookie? 2008-10-30 20:13 yes 2008-10-30 20:14 we say opaque filehandle and reserve cookie to mean directory cookie 2008-10-30 20:14 how large is it? 2008-10-30 20:14 it? 2008-10-30 20:15 a fh? 2008-10-30 20:15 yup 2008-10-30 20:15 lots of bytes 2008-10-30 20:15 64 I seem to recall 2008-10-30 20:15 don't quote me 2008-10-30 20:16 one way to find out is to look at the slab cache 2008-10-30 20:16 cat /proc/slabinfo 2008-10-30 20:16 another is to printk(... sizeof(struct fh)); 2008-10-30 20:16 in junkfs 2008-10-30 20:17 ok, we're not going to replace the top layer of fs library functions 2008-10-30 20:17 5*4 bytes it would seem (at least) 2008-10-30 20:17 assuming struct fid is what it is 2008-10-30 20:18 it's defined by the rfs of course 2008-10-30 20:18 rfc 2008-10-30 20:18 v2 fh is 32 bytes 2008-10-30 20:18 v3 is variable up to 64 2008-10-30 20:19 so I recalled sort of correctly 2008-10-30 20:19 anyway 2008-10-30 20:19 ;-) 2008-10-30 20:19 nfs is a whole huge messy topic 2008-10-30 20:19 and is interesting to tux3 only to the extent that we have to do a few things to make that mess work 2008-10-30 20:19 what the fs needs to obey in order to support nfs exporting is probably worth going over 2008-10-30 20:19 doesn't nfs work with any fs? 2008-10-30 20:19 oh, and is interesting to tux3 because one of the prime uses of tux3 will be exporting nfs 2008-10-30 20:20 the fs has to obey some rules in order to support nfs 2008-10-30 20:20 maze, yes it would be worth a homework assignment: "all the places nfs causes pain for a regular fs" 2008-10-30 20:20 isn't that more like a dissertation? 2008-10-30 20:21 for example, there has to be a way to supply stable directory cookies across reboots that fit in 31 bits to support v2 2008-10-30 20:21 that relaxes to 64 bits in v3 2008-10-30 20:21 still painful 2008-10-30 20:21 maze, not really, it's mostly googling 2008-10-30 20:22 there are only a few places filesystems have to do something bizarre and unnatural 2008-10-30 20:22 the directory one is the one I'm directly familiar with because of the pain it caused in htree development 2008-10-30 20:23 btrfs guys are currently going through equivalent pain 2008-10-30 20:23 trying to get their directory scheme to work with nfs 2008-10-30 20:23 reiser never played well with nfs 2008-10-30 20:23 ok 2008-10-30 20:23 hi 2008-10-30 20:23 question: nfs2, is it still widely used? 2008-10-30 20:23 hi hirofumi 2008-10-30 20:24 (seeing as nfs4 is long out...) 2008-10-30 20:24 maze, I haven't seen one for a long time 2008-10-30 20:24 i wake up now 2008-10-30 20:24 and a brand new filesystem could possibly ignore it 2008-10-30 20:24 but since we know how to support it properly, why not? 2008-10-30 20:25 well, 31 vs 64 bits is a bit off a difference 2008-10-30 20:25 the directory index planned for tux3 doesn't care 2008-10-30 20:25 the original htree would have benefitted 2008-10-30 20:26 ok, we could spend one session on just that: how ext3 dirops handle nfs v2/f3 2008-10-30 20:26 it's rather complex 2008-10-30 20:27 now, let's move on down to the second layer of fs library calls in the read/write path 2008-10-30 20:27 when we looked at generic read/write, we saw that the filesystem does all its work in the ->readpage/->writepage calls 2008-10-30 20:27 at least in the non-mpage forms 2008-10-30 20:28 today, more of the work, by volume, gets done in the unspeakably messy but faster mpage stuff 2008-10-30 20:28 we will look at both 2008-10-30 20:29 but let's consider the _2copy generic function first 2008-10-30 20:29 and follow it into ext3 2008-10-30 20:29 anybody got a url for the ->writepage call in _2copy? 2008-10-30 20:29 ACTION is searching 2008-10-30 20:30 (my standard trick when I need to get up and get my cup of tea for example) 2008-10-30 20:30 generic_perform_write_2copy? 2008-10-30 20:30 uhm it doesn;t? 2008-10-30 20:31 that's the one 2008-10-30 20:31 http://lxr.linux.no/linux+v2.6.27/mm/filemap.c#L2216 2008-10-30 20:31 http://lxr.linux.no/linux+v2.6.27/mm/filemap.c#L2331 2008-10-30 20:32 http://lxr.linux.no/linux+v2.6.27/mm/filemap.c#L2345 ? 2008-10-30 20:32 2312 status = a_ops->prepare_write(file, page, offset, offset+bytes); 2008-10-30 20:32 there's commit_write a little bit down as well 2008-10-30 20:32 2345 status = a_ops->commit_write(file, page, offset, offset+bytes); 2008-10-30 20:32 right 2008-10-30 20:32 it's a two-prong plug 2008-10-30 20:32 for no good reason 2008-10-30 20:32 :-) 2008-10-30 20:33 hmm, not sure 2008-10-30 20:33 maybe it's needed for partial page writes 2008-10-30 20:33 so if all the filesystem does is supply those two functions, then standard buffered write will just magically work 2008-10-30 20:33 let's see how ext2 supplies them 2008-10-30 20:34 maze, no, there's no good reason 2008-10-30 20:34 as attested to by them being scheduled for eradication 2008-10-30 20:34 finally 2008-10-30 20:34 alway were just a messy wart 2008-10-30 20:35 -!- madhu(~chatzilla@122.252.226.161) has joined #tux3 2008-10-30 20:35 hey all 2008-10-30 20:35 hi bobby 2008-10-30 20:35 hirofumi, what time is in in japan? 2008-10-30 20:35 long time no see 2008-10-30 20:35 I think really early in the morning 2008-10-30 20:35 12:35 2008-10-30 20:35 oh 2008-10-30 20:36 its 9:05 in india :) 2008-10-30 20:36 http://lxr.linux.no/linux+v2.6.27/fs/ext2/inode.c#L783 2008-10-30 20:36 ok, that's fine 2008-10-30 20:36 11:36 in baltimore ;-) 2008-10-30 20:36 midnight is the best time to hack 2008-10-30 20:36 that is true! 2008-10-30 20:36 yes 2008-10-30 20:37 ext2 doesn't implement those functions 2008-10-30 20:37 yup ;-) 2008-10-30 20:37 exactly 2008-10-30 20:37 actually most fs don't 2008-10-30 20:37 RazvanM: when is the next tux3 U? 2008-10-30 20:37 because they are using the ->writepage interface instead 2008-10-30 20:37 looks like: cifs afs gfs2 ecryptfs impement prepare_write 2008-10-30 20:38 which does prepare_ ... comit_ 2008-10-30 20:38 ext2 uses ->write_begin and ->write_end 2008-10-30 20:38 bobby: it's right now right here 2008-10-30 20:39 ohk 2008-10-30 20:39 bobby: and flips is the teacher :D 2008-10-30 20:39 and the next one is on tuesday at 8 pm pdt 2008-10-30 20:39 (see topic) 2008-10-30 20:39 hmm, the timings are a bit difficult :( 2008-10-30 20:39 although really the next session should be updated 2008-10-30 20:39 hirofumi, yes, new things 2008-10-30 20:40 the replacement of prepare... commit 2008-10-30 20:40 yes 2008-10-30 20:40 wtill pointlessly a two-prong plug 2008-10-30 20:40 still 2008-10-30 20:40 bobby, the current time seems to work out fine 2008-10-30 20:40 means you have to get up early ;) 2008-10-30 20:40 those are introduced for bug fix 2008-10-30 20:40 flips: yeah :( 2008-10-30 20:41 bug fix? 2008-10-30 20:41 yes 2008-10-30 20:41 hirofumi, got a url? 2008-10-30 20:41 hirofumi: care to elaborate? 2008-10-30 20:41 $ grep prepare_write *.c | grep EXPORT 2008-10-30 20:41 buffer.c:EXPORT_SYMBOL(block_prepare_write); 2008-10-30 20:41 libfs.c:EXPORT_SYMBOL(simple_prepare_write); 2008-10-30 20:41 race condition iirc 2008-10-30 20:42 $ grep commit_write *.c | grep EXPORT 2008-10-30 20:42 buffer.c:EXPORT_SYMBOL(block_commit_write); 2008-10-30 20:44 fs: introduce write_begin, write_end, and perform_write aops 2008-10-30 20:44 2008-10-30 20:44 These are intended to replace prepare_write and commit_write with more 2008-10-30 20:44 flexible alternatives that are also able to avoid the buffered write 2008-10-30 20:44 deadlock problems efficiently (which prepare_write is unable to do). 2008-10-30 20:44 commitid of git is afddba49d18f346e5cc2938b6ed7c512db18ca68 2008-10-30 20:45 so this is how stuff get added without the removing the old ones :P 2008-10-30 20:45 http://lxr.linux.no/linux+v2.6.27/mm/page-writeback.c#L974 <- ok, here is the generic writepage call, as opposed to the prepare/commit interface in _2copy 2008-10-30 20:46 http://lxr.linux.no/linux+v2.6.27/mm/page-writeback.c#L991 <- generic_writepages 2008-10-30 20:46 http://lxr.linux.no/linux+v2.6.27/mm/page-writeback.c#L866 <- write_cache_pages 2008-10-30 20:47 936 ret = (*writepage)(page, wbc, data); 2008-10-30 20:47 so... I retract the claim about _2copy, and now assert that if all you implement is ->writepage, that the vfs will use it via write_cache_pages to implement buffered file write 2008-10-30 20:48 so now let's look at how ext2 implements it 2008-10-30 20:49 http://lxr.linux.no/linux+v2.6.27/fs/buffer.c#L2859 2008-10-30 20:49 http://lxr.linux.no/linux+v2.6.27/fs/ext2/inode.c#L707 <- ext2_writepage 2008-10-30 20:49 way ahead of me ;) 2008-10-30 20:50 so all ext2 does is pass its ext2_get_block back to the vfs block io library 2008-10-30 20:50 we have looked at that call before 2008-10-30 20:50 no need to again right now, correct? 2008-10-30 20:50 and block_write_full_page is part of the vfs block io library 2008-10-30 20:51 right 2008-10-30 20:51 it does prepare... commit 2008-10-30 20:51 maybe now has been changed to begin...end 2008-10-30 20:51 let's see 2008-10-30 20:52 well know 2008-10-30 20:52 it's basically prepare and commit grafted together 2008-10-30 20:52 with a call to get_block sandwiched in between 2008-10-30 20:53 arguably a candidate for conversion to use the new functions 2008-10-30 20:53 let's look at the ext2 part 2008-10-30 20:53 ext2_get_block 2008-10-30 20:53 we've looked at it briefly before, right? 2008-10-30 20:54 http://lxr.linux.no/linux+v2.6.27/fs/ext2/inode.c#L694 2008-10-30 20:55 this is the one that traverses the file index starting at an inode and given a logical offset, to find a physical block number which is returned by filling in a b_blocknr field in a supplied buffer_head 2008-10-30 20:55 there are a few decorations on that interface, such as telling the caller that the block was newly allocated and thus the buffer needs to be zeroed by some callers 2008-10-30 20:56 now, this is where we want to do things differently in tux3 2008-10-30 20:56 how? 2008-10-30 20:57 are we going to have readpage/writepage? 2008-10-30 20:57 instead of calling back into the fs lib from ->block_write_full_page, tux3 will just go on to write out the page 2008-10-30 20:57 by calling submit_bio 2008-10-30 20:57 we will implement ->readpage/->writepage, but they won't call the library routines 2008-10-30 20:58 and we maybe won't have to write a tux3_getblock 2008-10-30 20:58 i see 2008-10-30 20:58 that's the interesting question I wanted to address today: can we get away with no tux3_getblock at all, but instead just initiate io ourselves where the vfs calls ->writepage and similar 2008-10-30 20:59 we'll not have a tux3_getblock at all or it will be exposed to the outside of tux3? 2008-10-30 20:59 I'd like to have none at all, though we need something similar to implement bmap 2008-10-30 21:00 (midnight) 2008-10-30 21:00 however that doesn't have to implement all the slightly wierd semantics of typical ->get_block 2008-10-30 21:00 razvanm, did you turn into a pumpkin? 2008-10-30 21:00 getblock is pretty weird, because what it could/should return may depend on the future and whether we want to read or write 2008-10-30 21:00 and where's raluca? 2008-10-30 21:00 :D 2008-10-30 21:00 she's here :P 2008-10-30 21:01 actually, we have a small pumpkin made of plush ;-) 2008-10-30 21:01 maze, it's a braindamaged interface imho, not least because it works at cross purposes with delayed allocation 2008-10-30 21:01 we don't actually need to allocate physical disk blocks (besides reserving them) until we actually wish to flush to disk 2008-10-30 21:01 ;-) 2008-10-30 21:01 here and quiet :) 2008-10-30 21:01 [not reserving them - reserving space for them 'somewhere'] 2008-10-30 21:01 I was able to make use of the minix_get_block to fill a page ;-) 2008-10-30 21:02 maze, yes, and we always are going to send something to disk when we get a ->writepage call, though it may not be the page we got the ->writepage for 2008-10-30 21:02 right 2008-10-30 21:02 ->writepage also comes to us from deep in vm 2008-10-30 21:02 in shrink_caches 2008-10-30 21:02 wait 2008-10-30 21:02 why will we always send something to disk? 2008-10-30 21:03 we're doing write-through? 2008-10-30 21:03 because either the user or vmm told us we should 2008-10-30 21:03 not write-cache and flush on close 2008-10-30 21:03 ? 2008-10-30 21:03 it's bad behavior for a fs to cache write stuff for a long time 2008-10-30 21:04 generic behavior is to start the IO transfer inside sys_write 2008-10-30 21:04 yes, it's writethrough 2008-10-30 21:04 uhm, I'd argue that 2008-10-30 21:04 if the disk is idle - sure start writeing something 2008-10-30 21:04 otherwise... 2008-10-30 21:05 ok, let's start next time by considering the question of where we do _not_ immediately initiate writeout in sys_write 2008-10-30 21:05 very useful exercise 2008-10-30 21:05 :-) 2008-10-30 21:06 how did we do today, what ground did we cover 2008-10-30 21:06 since there are huge benefits to clumping writes and reads up, we shouldn't write to aggressively 2008-10-30 21:06 ACTION this today's lesson was also short ;-) 2008-10-30 21:06 felt short, true 2008-10-30 21:06 it was an hour 2008-10-30 21:06 went by fast 2008-10-30 21:06 true :D 2008-10-30 21:08 I have to start implementing the write part for minix so today's lesson was informative for me 2008-10-30 21:09 also the area I'm working in at the moment, kind of 2008-10-30 21:09 minix? 2008-10-30 21:09 no, writeout 2008-10-30 21:09 for tux3 2008-10-30 21:10 ah, yes 2008-10-30 21:10 atomic commit, and just exactly what our cache behavior will be 2008-10-30 21:10 RalucaM, are you writing minix? 2008-10-30 21:10 flips, i see 2008-10-30 21:10 hirofumi: I'm trying to use the minix fs from macos ;-) 2008-10-30 21:10 nope 2008-10-30 21:11 i see 2008-10-30 21:11 razvanm, do you talk to the ext3cow guys? 2008-10-30 21:11 I've mostly been going through various primitives in the kernel and trying to familiarize myself with them 2008-10-30 21:11 (atomic ops, mutexes, etc...) 2008-10-30 21:11 flips: the guy graduated and left before I had a chance to benefit from his knowledge :( 2008-10-30 21:11 maze, if you try to do them all you will never do anything but ;) 2008-10-30 21:12 razvanm, it was just one guy? 2008-10-30 21:12 no, not all - just the ones I run into 2008-10-30 21:12 flips: I think so :D 2008-10-30 21:12 ext2cow still seems to be an active project 2008-10-30 21:12 and it still seems to be centered in JHU 2008-10-30 21:13 http://www.ext3cow.com/Developers.html 2008-10-30 21:13 zach left 2008-10-30 21:13 Randal is the prof 2008-10-30 21:13 http://www.ext3cow.com/Blog/Blog.html 2008-10-30 21:13 I hope he'll sign my project when I'm done :D 2008-10-30 21:13 last entry is june 2008-10-30 21:14 indeed 2008-10-30 21:14 hmm, last patch is 2.6.20.3 2008-10-30 21:15 does seem like some loss of momentum 2008-10-30 21:15 I should email randal burns and see if there are plans 2008-10-30 21:16 do you meet him? 2008-10-30 21:16 never 2008-10-30 21:17 not so far 2008-10-30 21:17 but maybe eventually 2008-10-30 21:17 http://hssl.cs.jhu.edu/pipermail/ext3cow-devel/2008-October/000064.html 2008-10-30 21:17 last post is today 2008-10-30 21:17 :D so the world is not yet _that_ small 2008-10-30 21:17 nearly that small 2008-10-30 21:19 how working for ise inc 2008-10-30 21:19 yup 2008-10-30 21:19 a bunch of people are there now 2008-10-30 21:22 looks like ext3cow is dead in the water without zachary 2008-10-30 21:23 http://hssl.cs.jhu.edu/pipermail/ext3cow-devel/2008-July/000048.html <- somebody from france forward ported to 2.6.25.3 2008-10-30 21:23 did they have something more to add to it? 2008-10-30 21:23 deletion? 2008-10-30 21:23 kernel merge? 2008-10-30 21:24 that is, snapshot deletion 2008-10-30 21:24 deletion inside a snapshot? 2008-10-30 21:24 seems to me, as it is it will run and make snapshots until the volume is full 2008-10-30 21:24 then game over 2008-10-30 21:24 I will be amazed if they don't have a way to delete a snapshot :D 2008-10-30 21:25 that's what the thread is about 2008-10-30 21:26 > > There are some limitations : 2008-10-30 21:26 > > -The oldest version of a file cannot be deleted with this method. 2008-10-30 21:26 > > -Old versions of directories cannot be deleted. 2008-10-30 21:26 > 2008-10-30 21:27 Nicolas ENG is doing it 2008-10-30 21:27 hmm... 2008-10-30 21:27 anyway I do not expect it is easy 2008-10-30 21:27 but it's not dead 2008-10-30 21:27 that's good 2008-10-30 21:27 I have a question 2008-10-30 21:28 will the economic downturn improve the amount of work in open source communities? 2008-10-30 21:28 or it will be the other way around 2008-10-30 21:30 probably won't change it much 2008-10-30 21:30 hasn't in the past 2008-10-30 21:30 what it does tend to do is accelerate adoption 2008-10-30 21:30 why is that? 2008-10-30 21:30 other factors are way more important 2008-10-30 21:30 like who happens to be inspired at the time 2008-10-30 21:30 and what kind of tools are used 2008-10-30 21:31 a lot of the work comes from universities 2008-10-30 21:31 which are sheltered from the economy pretty well 2008-10-30 21:31 are they? 2008-10-30 21:31 even for this one? :D 2008-10-30 21:32 as long as you can convince dad to keep sending money ;) 2008-10-30 21:32 brb 2008-10-30 21:33 -!- RazvanM(~RazvanM@pool-151-196-126-202.balt.east.verizon.net) has joined #tux3 2008-10-30 21:33 back 2008-10-30 21:33 during economic booms, high tech companies tend to raid the universities 2008-10-30 21:33 call that cradle robbing 2008-10-30 21:34 that should cool down noticeably this year, in fact it already has 2008-10-30 21:34 lets students concentrate on a more well round education 2008-10-30 21:35 :-) 2008-10-30 21:35 enrollment in grad school will probably go up :) 2008-10-30 21:36 the undergrad enrollment was pretty low at JHU for some years 2008-10-30 21:37 pretty expensive isn't it? 2008-10-30 21:37 indeed... 2008-10-30 21:37 >30K 2008-10-30 21:38 yeah thats rediculous 2008-10-30 21:38 -!- data(~data@echo489.server4you.de) has joined #tux3 2008-10-30 21:39 wow 37700 according to their site 2008-10-30 21:40 the univ could be hit hard if people will not be able to afford this anymore 2008-10-30 21:40 per year? 2008-10-30 21:40 yes! 2008-10-30 21:40 thats over 150k for a 4 yr undergrad degree 2008-10-30 21:40 plus books 2008-10-30 21:40 as a business proposition... marginal 2008-10-30 21:40 unless it comes with scholarships 2008-10-30 21:41 which why the grad is attractive ;-) 2008-10-30 21:41 not so attractive when to watch the advisors writing proposal after proposal to get the funding :| 2008-10-30 21:41 to = you 2008-10-30 21:42 so how do you manage if you don't mind saying in public? 2008-10-30 21:43 I do my part as best as I can while the advisors are doing the same 2008-10-30 21:44 I come from Ro where research is a luxury that schools doesn't have 2008-10-30 21:44 so this is heaven from that perspective :P 2008-10-30 21:45 considering the super low number of American students this is something that doesn't look the same for them 2008-10-30 21:46 I certainly appreciated the opportunity to get to university 2008-10-30 21:46 almost didn't leave ;) 2008-10-30 21:46 how is that? 2008-10-30 21:46 got bitten by the computer hacking bug 2008-10-30 21:46