2008-10-16 00:00 wayback? 2008-10-16 00:01 http://web.archive.org/web/20080128190254/http://www.sandeepranade.com/html/ComputerScience/time-travelling-file-manager.html 2008-10-16 00:01 yeah 2008-10-16 00:01 ext3cow, the obvious tool to test it with 2008-10-16 00:02 that was it, not NILFS as I said 2008-10-16 00:02 and I wonder when the ext3cow guys are going to go for kernel merge 2008-10-16 00:02 when they are able to rm again? :-) 2008-10-16 00:02 they can rm, it just doesn't go away 2008-10-16 00:03 btw, a few months ago I briefly looked into adding previous versions support to DolphinPart (which is what KDE uses these days, both in Dolphin and in Konqueror) and it did not look too hard 2008-10-16 00:03 should be integrated with a generic time shifter 2008-10-16 00:03 I like the zoom buttons on the link above 2008-10-16 00:04 the other thing needed on such a slider is little marks where significant changes actually happened 2008-10-16 00:04 I don't know how you'd do that 2008-10-16 00:04 anything at all, to show where the activity was 2008-10-16 00:05 a little squashed histogram of activity instead of linear time scale, maybe 2008-10-16 00:06 adding little marks where significant changes actually happened should not be difficult, but how to find significant changes? a change which affects many files (and how many is "many"?) ? a change which affects a large amount of data (is deleting a DVD-ripped movie actually a big change?) ? 2008-10-16 00:07 exactly 2008-10-16 00:07 well there we have an advantage in tux3, you see all the changes at the same time, at least for one file 2008-10-16 00:08 some kind of out of band activity report 2008-10-16 00:08 we need that actually, for the new generation of filesystems 2008-10-16 00:08 like git and hg have 2008-10-16 00:09 do git and hg have heuristics to tell you "hey, this was a HUGE change"? I didn't know 2008-10-16 00:09 they don't report that 2008-10-16 00:10 it's interesting stuff, we should be mining that data out of our filesystems somehow 2008-10-16 00:10 something to think about 2008-10-16 00:17 ACTION turns in early 2008-10-16 00:17 got to get back in the coding saddle tomorrow, plus post a new post 2008-10-16 00:20 see you! 2008-10-16 00:20 pgquiles_, I hope somebody picks up that time travel interface work again, most practically with ext3cow I think 2008-10-16 00:20 I hope I have time to do that 2008-10-16 00:20 :-) 2008-10-16 00:20 gnight 2008-10-16 01:56 -!- pranith(ca4bcee2@webchat.mibbit.com) has joined #tux3 2008-10-16 02:09 -!- tim_dimm(~timothyhu@cpe-76-90-98-247.socal.res.rr.com) has joined #tux3 2008-10-16 07:56 -!- tim_dimm(~timothyhu@cpe-76-90-98-247.socal.res.rr.com) has joined #tux3 2008-10-16 08:29 -!- MaZe(~MaZe@216-239-45-4.google.com) has joined #tux3 2008-10-16 09:45 -!- Bobby_(~Bobby@122.162.71.144) has joined #tux3 2008-10-16 12:31 -!- bushman(~marcin@c-76-23-106-132.hsd1.sc.comcast.net) has joined #tux3 2008-10-16 13:28 -!- tim_dimm(~timothyhu@cpe-76-90-98-247.socal.res.rr.com) has joined #tux3 2008-10-16 15:00 need a catchy subject line for the follow up post to thinking about syncing 2008-10-16 15:34 -!- flips(~phillips@phunq.net) has joined #tux3 2008-10-16 15:58 -!- tim_dimm(~timothyhu@cpe-76-90-98-247.socal.res.rr.com) has joined #tux3 2008-10-16 16:52 title for the next post is set 2008-10-16 16:52 "Of Phases, Quanta, and Episodes" 2008-10-16 16:54 nearly sk8 oclock 2008-10-16 16:57 -!- ChanServ changed mode/#tux3 -> +o flips 2008-10-16 16:57 -!- flips changed topic to "http://tux3.org ~ Tux3 U, right here Tuesdays and Thursdays at 8 pm Pacific Time ~ Next session: page locking and IO life cycle" 2008-10-16 16:58 -!- ChanServ changed mode/#tux3 -> -o flips 2008-10-16 16:58 -!- ChanServ changed mode/#tux3 -> +o flips 2008-10-16 16:59 -!- flips changed topic to "http://tux3.org ~ Tux3 U, right here Tuesdays and Thursdays at 8 pm Pacific Time ~ Next session: IO life cycle of a page" 2008-10-16 16:59 -!- ChanServ changed mode/#tux3 -> -o flips 2008-10-16 16:59 scans better 2008-10-16 18:00 -!- tux3bot(~tux3bot@yzf.shapor.com) has joined #tux3 2008-10-16 18:03 -!- tim_dimm(~timothyhu@cpe-76-90-98-247.socal.res.rr.com) has joined #tux3 2008-10-16 19:45 -!- FelipeS(~Felipe@r77h15.res.gatech.edu) has joined #tux3 2008-10-16 19:48 -!- RazvanM(~RazvanM@pool-151-196-118-156.balt.east.verizon.net) has joined #tux3 2008-10-16 19:48 Hi! 2008-10-16 19:52 hi 2008-10-16 19:52 ACTION has 8 minutes to shower after the sk8 2008-10-16 19:53 -!- RalucaM(~ral@pool-151-196-118-156.balt.east.verizon.net) has joined #tux3 2008-10-16 19:53 hi 2008-10-16 19:57 lhi raluca 2008-10-16 19:59 2 days into life with its fan disconnected and the eee is happy and healthy 2008-10-16 19:59 recommended imho 2008-10-16 19:59 :-) 2008-10-16 19:59 what are you using it for? 2008-10-16 19:59 now I just need to do the spacebar mod and it will be a fine machine 2008-10-16 19:59 use it for a laptop 2008-10-16 19:59 much nicer to carry around than the thinkpad 2008-10-16 20:00 doesn't bend your shoulder 2008-10-16 20:00 :-) 2008-10-16 20:00 in fact, fits in the _flap_ of my camera backpack, and it isn't a big backpack 2008-10-16 20:00 mine is ;-) 2008-10-16 20:00 what kind of camera in it? 2008-10-16 20:00 whoops 2008-10-16 20:00 usually the canon 10d 2008-10-16 20:01 I can't know that, it's tux3 u kind 2008-10-16 20:01 ah 2008-10-16 20:01 20d here 2008-10-16 20:01 old but awesome camera :D 2008-10-16 20:01 oh yes 2008-10-16 20:01 even better :P 2008-10-16 20:01 40d will replace it as soon as I get clearance from my wife 2008-10-16 20:01 :D 2008-10-16 20:01 this is entirely justified by the 11000 baby pictures I took in the last two years 2008-10-16 20:01 ACTION is ready for tux3 2008-10-16 20:02 :-) :-) :-) 2008-10-16 20:02 ok, let's go 2008-10-16 20:02 today will be nittier and grittier 2008-10-16 20:02 let's go look at block_read_full_page 2008-10-16 20:03 ACTION listens to the sound of browsers revving up 2008-10-16 20:03 http://lxr.linux.no/linux+v2.6.26.6/fs/buffer.c#L2086 2008-10-16 20:04 beat me ;) 2008-10-16 20:04 on entry to this function the page must be locked 2008-10-16 20:05 or this task will oops with a BUG 2008-10-16 20:05 so where does the page get unlocked? 2008-10-16 20:05 see if you can find it, max 3 minutes 2008-10-16 20:06 ACTION takes the chance to snag a glass of vino 2008-10-16 20:07 ACTION is searching 2008-10-16 20:08 talk about your reasoning as you go if you like 2008-10-16 20:09 ok, hint: we've seen the mechanism before 2008-10-16 20:09 right now I'm searching for unlock_page usage 2008-10-16 20:09 I looked for block_read_full_page first 2008-10-16 20:09 didn't get to far 2008-10-16 20:09 when _should_ the page taht is being read be unlocked 2008-10-16 20:09 ? 2008-10-16 20:10 I mean, if you were designing your own os 2008-10-16 20:10 when will be evicted 2008-10-16 20:10 sorry 2008-10-16 20:10 when is not in use anymore 2008-10-16 20:10 apology accepted ;) 2008-10-16 20:11 when it has been successfully read 2008-10-16 20:11 that is when it should be unlocked 2008-10-16 20:11 aaa... 2008-10-16 20:11 I was very wrong :P 2008-10-16 20:11 then all tasks blocked trying to get the page lock will be unlocked, and can then read the data on the page 2008-10-16 20:11 sure, but you thought about it 2008-10-16 20:11 that's the important step 2008-10-16 20:11 ok, so the locking is only for waiting, right? 2008-10-16 20:12 locking is always only for waiting 2008-10-16 20:12 true 2008-10-16 20:12 locking enforces synchronized access to data by making tasks wait 2008-10-16 20:13 in this case, tasks must wait because the page does not contain valid data yet, the data has to be read from disk 2008-10-16 20:13 ack 2008-10-16 20:13 the very first task that needs the data will grab the lock and then be responsible for launching the read 2008-10-16 20:13 http://lxr.linux.no/linux+v2.6.26.6/fs/buffer.c#L2154 2008-10-16 20:14 that's one unlock location 2008-10-16 20:14 not the common one 2008-10-16 20:14 so it makes perfect sense to check if the lock is on 2008-10-16 20:14 if there is none then nobody is waiting 2008-10-16 20:14 what about read ahead? :P 2008-10-16 20:15 whole nuther topic 2008-10-16 20:15 in fact, this page could be being read as part of readahead 2008-10-16 20:15 the locking logic doesn't change 2008-10-16 20:15 the unlock happens in the bio endio 2008-10-16 20:15 does it make sense to wait for a read ahead? 2008-10-16 20:16 much as maze implemented in junkfs 2008-10-16 20:16 yes, it is mandatory to wait for the readahead 2008-10-16 20:16 any task waiting on the lock intends to use the data on the page 2008-10-16 20:16 it could be a parallel task reading at a different place in the file 2008-10-16 20:17 or a page fault caused by memory access to mmap region 2008-10-16 20:17 we don't care why somebody is trying to read the page, only that the read is happening 2008-10-16 20:17 now, where does the page get locked? 2008-10-16 20:17 3 minute search 2008-10-16 20:17 :D 2008-10-16 20:18 reason out loud 2008-10-16 20:18 hint: we've been in the neighbourhood before 2008-10-16 20:18 the locking should happen in somebody that needs a page 2008-10-16 20:19 grab_page or some of the friends :P 2008-10-16 20:19 right, and what piece of code might? 2008-10-16 20:19 grab_page doesn't actually read a page 2008-10-16 20:19 it's part of the mechanism for doing file write 2008-10-16 20:19 (that was another hint) 2008-10-16 20:20 well... we need the data from the page so to me it make sense to look in the read part 2008-10-16 20:20 yes 2008-10-16 20:20 what read part should be look at? 2008-10-16 20:21 get_block? checking now... 2008-10-16 20:21 get_block just performs the mapping between a logical block number and a physical block number, it doesn't actually do IO on the block 2008-10-16 20:22 (though in the tux3 user space code, our equivalent does) 2008-10-16 20:22 http://lxr.linux.no/linux+v2.6.26.6/mm/filemap.c#L1170 2008-10-16 20:23 generic_blah_read 2008-10-16 20:23 it is actually the responsibility of the application, in most cases a filesystem, to lock the page 2008-10-16 20:23 go_generic_file_read? 2008-10-16 20:23 maybe 2008-10-16 20:23 because I still don't see the locking :P 2008-10-16 20:24 let's find the actual call to lock_page here 2008-10-16 20:24 yes, do_* 2008-10-16 20:24 you see the for loop 2008-10-16 20:24 something interesting: http://lxr.linux.no/linux+v2.6.26.6/mm/filemap.c#L61 2008-10-16 20:25 http://lxr.linux.no/linux+v2.6.26.6/mm/filemap.c#L894 yes... 2008-10-16 20:25 yes, that's a message to you straight from akpm 2008-10-16 20:25 the first to actually bother to write this stuff down 2008-10-16 20:25 in fact, what we are covering here today is written in no book 2008-10-16 20:26 http://lxr.linux.no/linux+v2.6.26.6/mm/filemap.c#L1003 2008-10-16 20:26 one day maybe we will write the book, can you write well? 2008-10-16 20:26 ACTION writes very badly 2008-10-16 20:26 but a book about FS is a great idea! :D 2008-10-16 20:26 really-really great 2008-10-16 20:26 research well then? 2008-10-16 20:26 that I already know 2008-10-16 20:27 good researcher 2008-10-16 20:27 ok, that is one important place the page gets locked 2008-10-16 20:27 but I don't think it's the main one, let me check 2008-10-16 20:28 oh yes it is 2008-10-16 20:28 you nailed it 2008-10-16 20:28 ok, do_blah_read is far from the only place a page can be read 2008-10-16 20:29 it's the not up to date branch so it make some sense to be the main one 2008-10-16 20:29 the _get_block method may have to read one or more pages to figure out what the physical mapping for a file page is 2008-10-16 20:29 yes, it is 2008-10-16 20:30 the other big branch is the not present branche 2008-10-16 20:30 we're not going over those details today, though we should later 2008-10-16 20:30 ack 2008-10-16 20:31 ok, what else do we need to know about page locking? 2008-10-16 20:31 what we didn't do is the buffer locking, which is mixed together with the page locking in block_read_full_page 2008-10-16 20:31 I think we will leave that for later, we've done enough buffers recently 2008-10-16 20:32 suffice to say, that that part is an unholy mess 2008-10-16 20:32 :-) 2008-10-16 20:32 (I don't see the buffer locking in block_read_full_page :() 2008-10-16 20:32 I should mention that the locking path we just looked at used to be the main path for file reading in the past 2008-10-16 20:33 it isn't any more 2008-10-16 20:33 which one is it? 2008-10-16 20:34 first, take a look at this: http://lxr.linux.no/linux+v2.6.26.6/mm/filemap.c#L1021 2008-10-16 20:35 error = mapping->a_ops->readpage(filp, page); 2008-10-16 20:35 looks like the main read, correct? 2008-10-16 20:35 right 2008-10-16 20:36 the truth is, the fs does not have to limit itself to reading just this page 2008-10-16 20:36 it must read the page asked for, or you see we return EIO here 2008-10-16 20:36 but it can also read a bunch more pages at the same time 2008-10-16 20:37 which new incarnations of ext3 does 2008-10-16 20:37 we will take a look at that another time 2008-10-16 20:37 it's the multipage path 2008-10-16 20:37 a whole, big, much messier topic 2008-10-16 20:37 just a quick q: there is a generic implementation for readpage somewhere, right? 2008-10-16 20:37 yes, we started with it today 2008-10-16 20:38 block_read_full_page 2008-10-16 20:38 aaaaaa :D 2008-10-16 20:38 ok 2008-10-16 20:38 look for all occurrences, you will find about one/fs 2008-10-16 20:38 tux3 will have one too 2008-10-16 20:38 (the romfs implements it :P) 2008-10-16 20:38 well 2008-10-16 20:38 sorry 2008-10-16 20:38 tux3 is going to ignore block_read_full_page and do the io by a different method I think 2008-10-16 20:39 as you can see, the block_read_full_page function is rather more convoluted that you would expect 2008-10-16 20:39 mpage_readpage 2008-10-16 20:39 that costs cpu, and worse, does operations a page at a time, at best 2008-10-16 20:39 right 2008-10-16 20:39 I haven't really looked at that in depth myself 2008-10-16 20:40 we'll do it as a group, in fact that can be homework for next time 2008-10-16 20:40 ack 2008-10-16 20:40 :D 2008-10-16 20:40 read the mpage path 2008-10-16 20:40 noted 2008-10-16 20:40 ok, that is only half the story of page locking lifecycle 2008-10-16 20:40 the other half is on the write side 2008-10-16 20:41 so lets start similarly by looking at block_write_full_page (again) 2008-10-16 20:41 http://lxr.linux.no/linux+v2.6.26.5/fs/buffer.c#L2801 2008-10-16 20:41 :) 2008-10-16 20:41 and then http://lxr.linux.no/linux+v2.6.26.5/fs/buffer.c#L1645 2008-10-16 20:42 same locking check :P 2008-10-16 20:42 right 2008-10-16 20:42 good 2008-10-16 20:42 io is by nature symmetric 2008-10-16 20:42 in linux you often have to see past a lot of cruft to see that 2008-10-16 20:43 what would be the equivalent of read ahead for write? :P 2008-10-16 20:43 aaa... flushing 2008-10-16 20:43 write_garbage_ahead? 2008-10-16 20:43 sure 2008-10-16 20:43 I should have though more before asking :P 2008-10-16 20:43 flushing 2008-10-16 20:43 me too 2008-10-16 20:43 couldn't resist the temptation to make a joke 2008-10-16 20:44 write_garbage_ahead is funny :P 2008-10-16 20:44 locking strategy is assymetric in a surprising way here 2008-10-16 20:44 many loops in this functions... 2008-10-16 20:45 ...reading code here... 2008-10-16 20:45 function 2008-10-16 20:45 yes, it's going steadily cruftier over time 2008-10-16 20:45 has reached a truly startling stage by now 2008-10-16 20:45 we can skip the first one, right? :D 2008-10-16 20:45 sure, and look at this: http://lxr.linux.no/linux+v2.6.26.5/fs/buffer.c#L1748 2008-10-16 20:46 unlock_page(page); 2008-10-16 20:46 :D 2008-10-16 20:46 symmery, we haz it! 2008-10-16 20:46 that interesting thing is, this is done right after the submit_bh, which doesn't wait for the actual IO to take place 2008-10-16 20:46 this is the asymmetric part 2008-10-16 20:46 the page is unlocked during the actual write, but for a read it is locked 2008-10-16 20:47 why do you suppose that might be? 2008-10-16 20:47 for read we need the content so we need to wait for the result 2008-10-16 20:47 right, and why can we drop the lock for the write? 2008-10-16 20:47 for write we don't need to wait if we don't care if it fails :P 2008-10-16 20:48 and what advantage is there to dropping the lock for write? 2008-10-16 20:48 stupid q: the locks are counting locks? 2008-10-16 20:48 the truth is, I don't really know the advantage, it is always a racy bug to write to a page that is in process of being written to media 2008-10-16 20:49 no, the locks are nonrecursive 2008-10-16 20:49 good guess though 2008-10-16 20:49 in some cases, there is no way to prevent the race of writing to a page that is currently being transferred to disk 2008-10-16 20:49 actually, this unlock will wakeup somebody... 2008-10-16 20:50 true, which will do a racy, useless write the the page 2008-10-16 20:50 who will be wake up? 2008-10-16 20:50 good question 2008-10-16 20:50 some buggy application probably 2008-10-16 20:50 there much be a lock somewhere... 2008-10-16 20:51 we check for the lock to be on at the start of the function 2008-10-16 20:51 the reason this is always a race is, a write to this memory location while the page is in flight could easily take pace at exactly the same time as the dma transfer 2008-10-16 20:51 so we can't predict whether the page will have new or old data or part of each on disk 2008-10-16 20:51 the dma will use the same lock? 2008-10-16 20:51 dma uses no lock 2008-10-16 20:51 hmm... 2008-10-16 20:52 really? 2008-10-16 20:52 once we have sent a page down to the block layer, dma can be initiated at any time 2008-10-16 20:52 really 2008-10-16 20:52 before starting the dma the page is not locked? 2008-10-16 20:52 scary? 2008-10-16 20:52 if you're scared by that you're starting to get it 2008-10-16 20:52 dma doesn't care a bit about page locks 2008-10-16 20:52 hmm... 2008-10-16 20:52 look through all the dma code, you will find no synchronization there 2008-10-16 20:52 I though the OS will take some care... 2008-10-16 20:52 except with the disk hardware 2008-10-16 20:53 the filesystem should take care all right, but it can't do anything about mmaped writes for example 2008-10-16 20:53 tux3 will take a great deal of care there 2008-10-16 20:53 because we can also be writing out metadata here 2008-10-16 20:54 and it is always a bug to have a racy write to metadata 2008-10-16 20:54 in other words, the synchronization is performed by caller 2008-10-16 20:54 ack :D 2008-10-16 20:54 the vfs/block library can't possibly know enough to do the synchronization itself 2008-10-16 20:55 ok, the rest is just a reading exercise 2008-10-16 20:55 the page locks will be found in generic_* like as for the read case 2008-10-16 20:55 though in some cases they will be buried in filemap functions like grab_cache_page 2008-10-16 20:56 what would you like to look at for next tuesday? 2008-10-16 20:56 my deadline for 22 was canceled so I'll have some time to work on the fs stuff again :P 2008-10-16 20:56 :) 2008-10-16 20:57 well tomorrow I'll probalby get back in the hacking chair 2008-10-16 20:57 maze would know better to answer to that question 2008-10-16 20:57 fix some filemap bugs and maybe that readdir thing 2008-10-16 20:57 let's take a run at mpage 2008-10-16 20:57 what's the question? 2008-10-16 20:57 "what next" 2008-10-16 20:57 flips: what would you like to look at for next tuesday? 2008-10-16 20:57 MaZe: where have you been?? 2008-10-16 20:58 mpage.c I think 2008-10-16 20:58 unfortunately, working since 8am today 2008-10-16 20:58 flips: you are working on tux3 only your free time? 2008-10-16 20:58 so we can see how akpm goes about bypassing what looks like the main IO paths in the kernel 2008-10-16 20:58 I've read through till 8:30 pm 2008-10-16 20:58 razvanm, indeed 2008-10-16 20:59 wow... 2008-10-16 20:59 MaZe: reading? 2008-10-16 20:59 ok, you mentioned my name, so it pinged me and I looked, but I'm not sure what exact question and how to answer it 2008-10-16 21:00 (reading? trying, but not having the time to do it well really) 2008-10-16 21:00 MaZe: the questions was what to talked about next tuesday 2008-10-16 21:00 maze is busy handling a large fire in a google data center 2008-10-16 21:00 at the moment 2008-10-16 21:01 ACTION lies through his teeth 2008-10-16 21:01 fire?!? 2008-10-16 21:01 standard goog joke 2008-10-16 21:01 :-) 2008-10-16 21:01 disk drive caught fire 2008-10-16 21:01 flames leaping into the statosphere 2008-10-16 21:02 causing your gmail to lag by tens of seconds 2008-10-16 21:02 nothing beats the waiting time for loading gmail the first time 2008-10-16 21:02 so about that 10d... 2008-10-16 21:02 when I first noticed the progress bar I though it's a joke :P 2008-10-16 21:03 we got the 10d after a rebel xt :P 2008-10-16 21:03 that's mainly crappy javascript parsing in firefox 2008-10-16 21:03 because I had the chance to hold a 10d in my hand and I fall in love :P 2008-10-16 21:03 rebel xt is a nice machine in its own right 2008-10-16 21:03 there is no time for the progress bar in chrome? 2008-10-16 21:03 but when you get a real camera the difference is obvious 2008-10-16 21:04 I really like that big wheel 2008-10-16 21:04 and the way you can very quickly change the settings 2008-10-16 21:04 chrome's big deal is a faster javascript parser 2008-10-16 21:04 and the much lower shutter lag 2008-10-16 21:04 and the heft 2008-10-16 21:04 that's a big one for me 2008-10-16 21:04 really helps in framing shots 2008-10-16 21:04 you really noticed the diffence in shutter speed? 2008-10-16 21:05 shutter lag 2008-10-16 21:05 lag sorry... 2008-10-16 21:05 faster data path from the sensor etc 2008-10-16 21:05 faster focus setup (though still sucks) 2008-10-16 21:05 faster motor drive, that's a big one for me 2008-10-16 21:05 changing the focus points is not my main strength :P 2008-10-16 21:06 200 ms on the 20d 2008-10-16 21:06 bigger controls, also a big deal 2008-10-16 21:06 the funny thing, the eye tracking in and old A2E I have is really working :-) 2008-10-16 21:06 a2e? 2008-10-16 21:06 looks similar with the 10d but it's on film 2008-10-16 21:07 I only dabbled in real film a little bit 2008-10-16 21:07 I like being able to take thousands of shots at $0/shot 2008-10-16 21:08 I shoot film after I did on digital 2008-10-16 21:08 is nice 2008-10-16 21:08 in a different way :P 2008-10-16 21:08 yes, I can see that, I don't like waiting to see the results though 2008-10-16 21:08 :D 2008-10-16 21:08 well by now on digital I usually know whether I've got a good shot without looking 2008-10-16 21:08 I also use a ricoh GX100 almost daily 2008-10-16 21:09 digital is awesome when you use flashes :D 2008-10-16 21:09 that fixes a lot, true 2008-10-16 21:09 http://www.canon.com/camera-museum/camera/film/data/1991-1995/1992_eos5_qd.html the A2E 2008-10-16 21:09 about time for me to get a real flash 2008-10-16 21:10 yup! :D 2008-10-16 21:10 I'm goint to take my camera down to the boardwalk tomorrow 2008-10-16 21:10 in abovementioned backpack 2008-10-16 21:10 boardwalk? 2008-10-16 21:10 the sunsets are beyond belief, with the fires going on up the valley 2008-10-16 21:10 venice beach 2008-10-16 21:11 http://www.imagekandi.com/photo/images/Venice-Beach-Board-Walk.jpg 2008-10-16 21:11 aaa 2008-10-16 21:11 awesome :D 2008-10-16 21:11 saw exactly that tonight, except much redder 2008-10-16 21:11 skate through that spot every day 2008-10-16 21:11 stop! :D 2008-10-16 21:12 there was a movie being shot just north ;) 2008-10-16 21:12 I skated into the middle of it, the security guy assumed I must be with the crew 2008-10-16 21:12 :-) 2008-10-16 21:12 funny 2008-10-16 21:12 could have gotten myself a free helping at the buffet 2008-10-16 21:12 -!- konrad(~konrad@D-128-208-53-208.dhcp4.washington.edu) has joined #tux3 2008-10-16 21:12 but had to get home for tux3 u 2008-10-16 21:13 aaa 2008-10-16 21:13 so later would be better? :D 2008-10-16 21:13 it's fine 2008-10-16 21:13 there will be another shoot 2008-10-16 21:13 and more free food 2008-10-16 21:13 (we had to come home earlier to catch it :P) 2008-10-16 21:13 it was already dark by that time 2008-10-16 21:13 I was asking about the tux3 u :P 2008-10-16 21:13 current time for tux3 u works fine for me 2008-10-16 21:14 do you have flickr stream? :P 2008-10-16 21:14 now, is it good? 2008-10-16 21:14 oh 2008-10-16 21:14 (thanx for the lesson tonight) 2008-10-16 21:14 you mean for for the skate 2008-10-16 21:14 I'll get pix tomorrow 2008-10-16 21:14 funny I never thought of doing that before 2008-10-16 21:14 take it for granted 2008-10-16 21:14 but last few days have been way over the top 2008-10-16 21:15 everybody just stopping and staring with their mouths open 2008-10-16 21:15