IRC log for #utah on 20080821

00:16.57romanovichaha
00:26.41romanovicThat site is entertaining
00:26.55romanovichttp://failblog.files.wordpress.com/2008/08/fail-owned-geography-fail2.jpg
00:44.05*** join/#utah macnewbold (n=mac@166.70.178.114)
01:14.30herloHeartsbane: something strange is going on with my phone...
01:15.33Heartsbaneoh I just got back from the funeral
01:18.01herlok
01:20.43herlohttp://www.ted.com/index.php/talks/nellie_mckay_sings_clonie_1.html
01:21.25herlohttp://www.ted.com/index.php/talks/nicholas_negroponte_on_one_laptop_per_child_two_years_on.html
01:22.57herlohttp://www.ted.com/index.php/talks/ken_robinson_says_schools_kill_creativity.html
01:23.48herlohttp://www.ted.com/index.php/talks/alan_kay_shares_a_powerful_idea_about_ideas.html
01:39.25*** join/#utah elg (n=fugalh@216.31.27.110)
01:39.25*** mode/#utah [+v elg] by ChanServ
01:44.44*** join/#utah Supaplex_ (n=infotron@166.70.62.200)
02:01.10*** join/#utah ibot (i=ibot@pdpc/supporter/active/TimRiker/bot/apt)
02:01.10*** topic/#utah is http://plug.org/irc | Channel log @ http://ibot.rikers.org/%23utah/ | UTOSC disccode POUNDUTAH 2008.utosc.com | Squid Pancakes: It's what's for breakfast.
02:01.10*** mode/#utah [+o ibot] by ChanServ
02:13.01*** join/#utah Supaplex (n=infotron@166.70.62.200)
02:33.24leviGood evening.
02:36.26Sargun_screenUgh.
02:36.30Sargun_screenI have vendors at LUGs
02:36.36Sargun_screenI hate vendors who talk down to you.
02:37.22*** join/#utah elg (n=fugalh@216.31.27.110)
02:37.22*** mode/#utah [+v elg] by ChanServ
02:37.59*** join/#utah Sargun (n=xbmodder@atarack/staff/sargun)
02:51.07Sargun_screenhttp://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=%2Fnetahtml%2FPTO%2Fsearch-adv.htm&r=3&f=G&l=50&d=PTXT&S1=(Fast+AND+scale)&OS=Fast+and+scale&RS=(Fast+AND+scale)
02:51.12Sargun_screeninteresting.
03:05.22*** join/#utah findlay (n=justin@65-100-213-208.slkc.qwest.net)
03:05.28findlayhello
03:05.39findlay-chat about hello
03:06.10Sargun~kill findlay
03:06.10ibotACTION shoots a inverse pseudograviton gun at findlay
03:08.50*** join/#utah wps (n=wps@208.53.47.251)
03:25.47*** join/#utah Sargun (n=xbmodder@atarack/staff/sargun)
04:26.46eightyeighthttp://space.newscientist.com/article/dn14573-galactic-spaghetti-monster-powered-by-magnetic-fields.html
04:41.59Supaplexoh nice. this so called sealed battery leaked.
04:42.01Supaplexo.O
04:49.18leviSupaplex: What kind of battery?
04:50.01Supaplexups. 7ah 12v
04:53.46Supaplex~test
04:53.46ibotFailed!
04:55.43*** join/#utah wps (n=wps@208.53.47.251)
05:46.59*** join/#utah romanovic (n=romanovi@coffeeconnection.dsl.xmission.com)
06:23.15*** join/#utah romanovic (n=romanovi@c-67-166-100-141.hsd1.ut.comcast.net)
06:38.03*** join/#utah Aliosa27_ (n=Aliosa27@c-98-202-78-163.hsd1.ut.comcast.net)
06:38.39*** join/#utah Sargun (n=xbmodder@atarack/staff/sargun)
07:31.02*** join/#utah Supaplex_ (n=infotron@166.70.62.200)
07:47.30*** join/#utah infotron (n=infotron@166.70.62.200)
12:09.08*** join/#utah neybar_home (n=jalance@thelances.net)
12:35.37*** join/#utah sinuhe (n=user@206.83.88.66.ptr.us.xo.net)
12:43.43*** join/#utah redbeard2 (n=jphall@63-148-163-200.dia.static.qwest.net)
13:32.08*** join/#utah ^Migs^ (n=Migs@wsddevdude.weber.k12.ut.us)
13:37.34tensaiputs peanut butter in jsmith's hair
13:38.09jsmithtensai: Now why would you do a thing like that?!?
13:38.47tensaiwho doesn't like peanut butter?
13:38.59jsmithisn't a big fan
13:42.52Sargun_screenHow many people here have been a john?
13:43.10Sargun_screenerrr..wrong channel
13:54.30Sargun_screenAmazon is :-D compared to ebay who is :-(
14:15.25*** join/#utah thaddeusq (n=thaddeus@216.49.181.128)
14:34.49*** join/#utah wps_ (n=wps@64.0.193.183)
14:37.56*** join/#utah gabegundy (n=gabe@57.251.sfcn.org)
15:09.48*** join/#utah neybar (n=jalance@204.228.142.225)
15:40.04*** join/#utah elg (n=fugalh@dhcp25.cs.nmsu.edu)
15:40.04*** mode/#utah [+v elg] by ChanServ
15:41.32*** join/#utah brasto (n=brasto@97-117-71-212.slkc.qwest.net)
15:42.53unumum that's a really bad comment it get in the wrong channel....
15:43.04unumhave you been a john?
15:45.51elglevi: i'm seeing some interesting results here
15:50.53Tenehttp://www.photobasement.com/wp-content/uploads/2008/08/watchforbikes.jpg
15:59.49*** join/#utah bonez46 (n=scott@mail.FYRENICE.COM)
16:01.43levielg: Results relating to what?
16:01.53elgmutliply by zero
16:02.04leviBTW, this looks like design principles for a window manager I'd like to use: http://chneukirchen.org/blog/archive/2008/08/thoughts-on-window-management.html
16:02.13elgi am comparing a dot product of two 20 million element arrays
16:02.19levielg: Sorry, I'm lacking context here. :)
16:02.25elgwhere they're both random
16:02.31elgthen comparing it where one has 90% zeros
16:03.30elgand then where you only do the multiplication 10% of the time with if statements
16:03.47elgor rather, where you test for zero before multipliying
16:03.56leviOh, this is comparing the speed of conditional vs. multiplication by zero?
16:04.00elgyup
16:04.09leviOkay, I'm caught up now.  What are you seeing?
16:04.56elgin octave, just doing the dot product is fastest by far
16:05.12elgif statements and for loops are insanely slow compared to vector operations
16:05.20leviRight.
16:05.38gabegundyJust were are these squid pancakes being served?
16:05.39leviIt stands to reason that they got the micro-optimizations correct.
16:05.41elgin C, the multiplications by non-zero and by zero are roughly the same
16:05.47elgand if statements slower
16:06.01elgso far no surprsies
16:06.14leviThat sounds like what I'd expect.
16:06.19elgbut when I compile with optimizations, the if statement is no slower
16:06.35elgand i'm seeing weird things, but it's probably just because i'm using a wallclock timing method
16:06.35leviHmm.  Have you looked at the asm output?
16:07.05elgno, but I don't see how it could possibly compile it in. I determine which elements are zero at run time
16:07.06jsmithelg: Tried unrolling some of your loops?
16:07.14leviIt's hard to know what an optimizer is going to do to your C code.
16:07.14elg-O3 probably does that
16:07.36leviUnless you know the optimizer pretty well, anyway.
16:07.37elganyway, I doubt it would unroll it to 20 million statemetns, though who knows, maybe it does.
16:07.45elgeven if it does, though, it can't optimize away the if statement
16:07.57elgor the logical equivalent
16:08.03jsmithelg: Happen to have a copy of something like vTune handy? :-p
16:08.37elgwhat's even odder though is I get statistically relevant results that the first test, x dot y where x and y are random 20million element vectors (doubles)
16:08.49elgis faster than x dot z where z is the one with 90% zeros
16:08.51levihttp://www.wired.com/gaming/virtualworlds/commentary/games/2008/08/gamesfrontiers_0811
16:09.05levi(Weight Watchers as RPG)
16:09.07elgand the one with if statements is the same speed as the z thing
16:09.23elgso I thought that was odd, so I ran each test in its own loop 100 times
16:09.27*** join/#utah Jayce^ (n=jayce@office.bluehost.com)
16:09.27*** mode/#utah [+o Jayce^] by ChanServ
16:09.28elgsame (but scaled) results
16:09.50elgso I ran the first test twice, once before starting the timer
16:10.12elgnow the timed versions are all the same. so you gotta watch it when you get the optimizer involved
16:10.51elgmy hypothesis is it's unrolling loops for awhile and then hits some threshold where the program is getting so big it decides it's not such a good idea to unroll these loops so aggressively.
16:11.20elganyway, with -O3 it doesn't seem to make a difference whether you multiply by zero or use an if statement (test against 0)
16:11.41*** join/#utah tiwula (n=lane@65.197.250.50)
16:11.56levielg: Can you come up with some sort of microbenchmark program that exhibits this behavior so we can look at the generated code?
16:11.58Sargun_screenelg: x86?
16:12.04elghttp://pastie.org/257324
16:12.13elgyeah, intel core duo (macbook)
16:12.39elgif you see anything wrong with it, please do tell. :)
16:12.54elgif you want to run it and see how it performs on your box, i'm interested
16:13.03elgwrites a ruby benchmark now
16:14.23Sargun_screenit might be cheaper to statically allocate
16:14.36elgit segfaulted when I did that
16:14.43elgthe malloc isn't relevant to the benchmark anyway
16:14.49Sargun_screenusing rand() isn't fair
16:14.58elgit doesn't haev to be fair
16:15.04elgit has to give me a bunch of zeros
16:15.08elgbut not all zeros
16:15.25leviSargun_screen: You don't seem to be comprehending what elg's trying to measure here.
16:16.25Sargun_screenwell, let me read the codein whole ina tiny bit
16:16.49Sargun_screenim reading it ona screen where that's three pages
16:18.36Sargun_screenwhere be ^migs^
16:19.07^Migs^bwah?
16:20.35leviWow, I'm totally not following the optimized assembly.
16:23.15*** join/#utah sjansen (n=sjansen@148.87.66.56)
16:25.25*** join/#utah Sargun (n=xbmodder@atarack/staff/sargun)
16:28.54elg~lart sjansen
16:28.54ibotshoots sjansen in the head
16:29.45*** join/#utah lnchntdsl (n=lnchntds@206.251.250.219)
16:29.47Sargunelg, mind repasting?
16:29.54elg-urls
16:30.06elg-chat i'm so
16:30.12elg-lart emcnabb
16:30.14elgstupid bot
16:30.20elghttp://pastie.org/257324
16:30.24*** join/#utah dedebkgrn (n=dedebkgr@206.251.250.223)
16:30.27elg~seen brac
16:30.32ibotbrac <i=fugalh@falcon.fugal.net> was last seen on IRC in channel #utah, 17h 53m 39s ago, saying: '[Data-Driven Enhancement of Facial Attractiveness]'.
16:30.55elghere's the ruby results
16:30.55elg<PROTECTED>
16:30.55elg<PROTECTED>
16:30.56elg<PROTECTED>
16:30.56elg<PROTECTED>
16:30.56elg<PROTECTED>
16:31.13elgthe longest time is compare against 0, the last time is compare against 0.9
16:31.29elgthe first two are using NArray native operations, which are implemented in C
16:31.39Sargun_screenIt should be 0
16:31.58Sargun_screenbecause it should just optimize out the loop.
16:32.12Sargun_screenelg: Have you tried Java?
16:32.18elgno, why would I try java?
16:32.34Sargun_screenOptimization is Java's strong point
16:33.21dataw0lfelg: 1.8?
16:33.49sjansenelg: 42?
16:34.12elgwell the purpose of the exercise is A to see whether multiply by zero is faster than jump if zero (without going hardcore and writing the assembly, cuz i'm lazy)
16:34.29elgand B to see how that translates into the languages relevant to my task at hand
16:34.40elgi'm working from a couple of papers from the early 90s
16:34.52Sargunx,y   : 25.785381
16:34.53Sargunx,y if: 35.916363
16:34.53Sargunx,z   : 25.872602
16:35.07elgthe second paper describes a fast algorithm to do the algorithm in the first paper
16:35.37elgbut that faster algorithm depends heavily on not doing the multiplications where one array is 0 (which it is most all the time)
16:35.53dataw0lfelg: what version of Ruby did you benchmark that on?
16:36.03elgthe naive implementation, a for loop with a test if zero conditional, would seem to be no faster or very slower depending on your language
16:36.27elgdataw0lf: oh, yeah, 1.8
16:36.30elglet me run it on 1.9 too
16:36.41dataw0lfcoo'
16:36.58elg<PROTECTED>
16:36.58elg<PROTECTED>
16:36.58elg<PROTECTED>
16:36.58elg<PROTECTED>
16:36.58elg<PROTECTED>
16:37.21Sargunelg, try Haskell.
16:38.13elgthat would be interesting if I were interested in how haskell performed at this task
16:38.13levielg: So, gcc -O3 generates exactly the same code for the first two loops.
16:38.13elginteresting.
16:38.31elgSargun: thanks for the numebrs, now try it with -o3
16:38.34leviIn fact, all three loops are pretty much the same code.
16:38.34elg-O3 even
16:38.44elginteresting, so it's not the optimizer to blame
16:38.46elgsomething at run time
16:39.16leviAnd it's mostly done with xorl instructions.
16:41.20Sargun_screenelg: with O3:
16:41.20Sargun_screenx,y   : 0.000003
16:41.20Sargun_screenx,y if: 0.000002
16:41.20Sargun_screenx,z   : 0.000002
16:41.32leviThe unoptimized code looks pretty much like you'd expect it to.
16:41.44elgyou might want to increase M so that you get useful numbers sargun
16:43.15Sargunelg, I increased it and I'm getting the same numbers
16:43.28elgM = 1000?
16:44.10levihttp://pastie.org/257343
16:44.18elgfor the interested, http://pastie.org/257344 is the ruby benchmark
16:44.22leviThat's what the optimized code looks like for each of your loops.
16:44.23Sargun4f5d405139c5e22ccfa935c3c9d314c4  elg-fast.S
16:44.23Sargun4f5d405139c5e22ccfa935c3c9d314c4  elg-norm.S
16:44.27goozbachok I am starting to hate dell
16:44.27elgthe last benchmark is interesting too
16:44.41elgSargun: awesome, so your gcc defaults to -O3?
16:44.52elggoozbach: congrats
16:45.01goozbachit appears that someone uploaded this binfile (bash shell with zip encoded) in ascii mode
16:45.08levielg: It's the gentoo soooper-optimized gcc!
16:45.11goozbachit's totally corrupted
16:45.11Sargunelg, No, assembly code is the same, it does something while going from ASM -> ELF
16:45.19Sargungoozbach, what is it
16:45.26goozbachhardware diags
16:46.06elgSargun: the assembly shouldn't be the same
16:46.14elgtry -O1 vs -O3
16:46.21Tenegoozbach: I refer you to the comments in vsftpd.conf
16:46.26Sargunelg, Uhm, post disassembly the code is the same.
16:46.34leviSargun: Try passing -g, which should turn off optimization.
16:46.38SargunIt looks like the linker is doing something clever.
16:46.48leviSargun: Dude, your compiler is doing -O3 by default.
16:46.50elglevi: my gcc manpage says it can combine -g and -O
16:46.53goozbachfor a company which claims to be uber linux friendly neither of their linux-based diag tools they've sent me today has worked
16:47.05elgdon't remember which optimization levels
16:47.15Sargungcc -o norm.S -O1 elg.c; gcc -o fast.S -O3 elg.c; gcc -g -o debug.S elg.c
16:47.20Sargunfast and norm are the same.
16:47.25Sargundebug is totally different
16:47.49elgSargun: congrats, your gcc is hosed
16:47.52Sargunhaha
16:47.53Sargunthough once I compile to ELF
16:47.54elgpwned maybe
16:48.00Sargunit comes out totally different.
16:48.36leviWhat's with adding .S to the end of the output?  Does it parse that and output asm instead of a binary?
16:48.44Sargunlevi, yah.
16:48.52elggcc is pretty clever about extensions
16:48.54leviThat's dumb.
16:48.59SargunUnless gcc does optimization after it puts it into ASM.
16:49.05Sargunwhich would be annoying.
16:49.54leviYour gcc setup is hosed anyway, since it seems to be doing -O3 even when you ask it not to.
16:50.23levielg: Could you make any sense out of the asm chunk I pasted?
16:50.51elgno, but i didn't try very hard
16:51.25Sargunlevi, no it isn't...
16:51.31Sargunits doing -O2 by default
16:52.12Sargunlevi, why would it perform differently then? and why would it be different post disassembly?
16:52.22Sarguneven compiling with -Os makes it faster
16:52.29Sargunelg, you need a better benchmark
16:53.00elgwhy do you say that?
16:53.23leviSargun: What's this 'disassembly' phase you're referring to?
16:53.30elgi agree, to really know whether jump if zero is faster than multiply by zero, I'd need to do it in asm
16:53.50elgbut to know whether this algorithm in C would be faster one way or the other, I need to know exactly what I just measured
16:55.32levielg: Hah.  You know what?  The optimized code doesn't *do* anything in any of the loops because you never ask for the value of sum. :)
16:56.57elgawesome :)
16:57.23leviI'm not sure why it bothers to loop at all, but it does.
16:58.13leviThere's just no code operating inside the nested loops.  It's completely excised.
16:59.19leviI thought it was a pretty unbelievable that it'd know what you were trying to do in all three cases and get it right with the same code.
17:00.22bonez46where could I find reviews and commentary about phones? My buddy just got an iphone.. and then I watched a review of Instinct.. from Sprint.. curious where to find other reviews
17:01.00elgthat's hilarious
17:01.28dataw0lfbonez46: http://www.youtube.com/watch?v=QQlzX7EyIwU
17:01.52leviAh, I imagine the loops still work because whatever intermediate code gets generated is testing the loop variables.  The optimizer doesn't appear to realize it's a loop, just some incrementing and comparing of variables and some conditional jumps.  The stuff relating to sum, however, it knows is unneccesary because sum is never accessed.
17:02.38elgok, this gives more reasonable times
17:02.38leviI imagine delcaring sum to be volatile or printing sum after each run would fix the problem.
17:02.42elgthe if statement definitely slower
17:03.01leviBranch prediction failures FTL!
17:03.51elgx,y   : 9.763754
17:03.51elgx,y if: 11.181786
17:03.51elgx,z   : 9.795153
17:04.43leviThe branch predictor probably works well in the case of the for loops, and I would bet that the pipelining would benefit from a bit of unrolling, so you don't have a prediction failure every M cycles through the loop.
17:05.23leviBut the predictor will fail consistently with the if check, and hose your pipeline in those cases.
17:05.42leviMystery solved!
17:06.17leviNow I need to get back to somewhat more mundane things.
17:08.13Sargunlevi, objdump -d
17:11.21sjansenSo, in summary, we have learn to be naive because compilers are much smarter these days?
17:11.41SargunNot exactly..
17:13.11leviWe have learned that Sargun doesn't know how to run his compiler properly. :P
17:13.38Sargunlevi, oh, that's hilarious
17:13.55bonez46dataw0lf: the Omnia looks pretty cool, all except the Windows Mobile it's running..
17:14.11bonez46The omnia isn't out yet for the US is it?
17:14.21dataw0lfI dunno, I just like that video
17:14.35leviAnd that I'm too easily distracted by interesting technical questions.
17:15.03SargunA human is far better than the compiler
17:15.14Sargunbecause they would just remove the code
17:15.14bonez46it's interesting..
17:18.10dataw0lfhttp://algebraicthunk.net/~dburrows/blog/entry/package-management-sudoku/
17:23.53*** join/#utah Aliosa27_ (n=Aliosa27@209.90.88.194)
17:29.22*** join/#utah wps_ (n=wps@64.0.193.183)
17:30.49*** join/#utah Supaplex (n=infotron@166.70.62.194)
17:44.46*** part/#utah peno (i=peno@slacknet.com)
17:45.07*** join/#utah peno (i=peno@slacknet.com)
18:11.08*** join/#utah Supaplex_ (n=infotron@166.70.62.200)
18:16.25*** join/#utah romanovic (n=romanovi@c-67-166-100-141.hsd1.ut.comcast.net)
18:17.25*** join/#utah ScytheBlade1 (n=Death@smtp.mail.averageurl.com)
18:31.25sjansenhttp://lwn.net/Articles/294994/
18:31.51sjansenTranslation:
18:31.51sjansenWe paid a bundle of money for AppArmor 'cause we thought SELinux was too hard.
18:31.51sjansenBut AppArmor is stupid so we fired all the developers.
18:31.51sjansenSo we're getting ready to switch to SELinux eventually.
18:31.51sjansenBut we're just to ashamed to admit we made a mistake.
18:31.51sjansenSo we'll claim AppArmor is better for most customers, but some asked for SELinux.
18:31.53sjansen(And who can blame them? SELinux is better.)
18:31.55sjansenA couple years from now we'll stop shipping AppArmor.
18:31.57sjansenWhen we do, please forget all about AppArmor.
18:31.59sjansenBut until then, please pretent AppArmor is good.
18:32.01sjansen<PROTECTED>
18:32.03sjansen   Novell
18:54.33elghaha
19:26.20elgtried to fool the library. the library won
19:27.10elgi have this book checked out that's due in a little over a week. just renew, right? fine, but next week is still dangerously close to the beginning of the semester and this book is a textbook in a class (don't know if it's being taught)
19:27.21elgso I tried returning it a couple of days ago and then checking it out again
19:27.38elgand the due date is the same as the old due date, e.g. a little over a week from now
19:49.14^Migs^http://www.ksl.com/?nid=148&sid=4063846
19:49.24^Migs^read the last two paragraphs
19:52.45*** join/#utah amcnabb (n=amcnabb@c-76-23-8-238.hsd1.ut.comcast.net)
19:53.27maquiselg: i'm surprised that their system checks for that
19:54.21elgme too
20:05.42tensaielg: return it and have your wife check it out
20:05.54tensaithen you put it on hold
20:06.01elgshe's not a student
20:06.16tensaiah, school library. didn't think of that.
20:06.19elgthe fact it was there to recheck out today gives me hope
20:06.27elgthat maybe that class isn't being taught this semester
20:07.15tensaiphotocopy the entire book. that'll teach 'em.
20:07.59tensaifriend of mine used to work at a copy/ship place. every month or so an oriental guy would come in with some book he checked out at the library.
20:08.10tensaihe would have her copy the entire thing and then mail it overseas
20:08.17tensai(the copy, not the book)
20:08.41tensaiwhich cost far more than buying a copy of the book would have. but he kept doing it.
20:09.30elghaha
20:14.46*** join/#utah ^Migs^ (n=Migs@wsddevdude.weber.k12.ut.us)
20:27.02^Migs^http://www.someguywithawebsite.com/blogarchive/week_2008_08_17.html#002614
20:36.05*** join/#utah gshipley (n=gshipley@nat/redhat/x-737b835c6957333c)
20:37.40goozbach^Migs^: that has to be the *BEST* url you have *EVER* posted in this channel
20:37.51goozbachthat is AWESOME!!!
20:38.26Jayce^http://i162.photobucket.com/albums/t271/orpheus76/dajfgaabf1.jpg    just for you goozbach
20:39.14^Migs^see, I knew that if I just kept posting, I'd eventually get it right
20:39.14goozbachusually I ignore the links you post
20:39.26goozbachbut this time my migs-uri filter wasn't working
20:39.33goozbachso I clidked
20:39.38goozbachI'm glad I did
20:40.38^Migs^if you usually ignore my links, how do you know that's the best?  I could've been posting comedy gold all this time and you've been missing it.
20:41.00sjansenBig companies suck.
20:41.02^Migs^in fact, I think that's one of my LAMER links
20:41.54sjansenIn fact, I hearby declare Stuart's Law of Corporations: The suckiness of a company is directly proportional to the size of the company.
20:42.19sjansenI'm sure I'm not the first to invent said law. But it's mine now and I need something to make me happy.
20:42.29sjansencrawls off to his happy place for a bit
20:43.35tensai^Migs^: next time I run for president, I promise to rickroll everybody
20:44.23^Migs^I'd vote for you just to see that
20:48.25goozbachsjansen: tell us a story?
20:48.40goozbachwe all know large corporations suck, but why in this case
20:48.41goozbach?
20:49.09sjansenReally big partner. Two little problems with the roster.
20:49.28goozbachahh
20:49.34sjansenI ask how to respond. Still no response. Will try again when I find the intestinal fortitude.
20:49.43goozbachequals hours of fun
20:49.55goozbachI see
20:49.55unumhttp://www.snopes.com/cokelore/acid.asp
20:50.22goozbachwait, sjansen is teaching? who let him out of his xiphias cage? HERLO! is this your doing!?
20:50.26sjansenMeanwhile, suddenly the corporate machinery is revving up. Klaxons are sounding. Emails are being send. Phone messages are being received.
20:51.13sjansenThere must be around ten people involved in this whole thing. Only two or three of them are really needed. None of them has the information they need, though.
20:51.18unumsorry I posted that link in the wrong channel
20:51.24sjansenThe company is too big to effectively communicate.
20:53.27sjansenThankfully, I've got a paper trail. So A is C'd.
20:53.49sjansens/A/my A/
20:55.30sjansenwonders if ^Migs^ links don't work because $HUGECORP is filtering DNS to block sites
20:57.17maquissjansen: i think my company's reasonably large... and it doesn't suck
20:57.56sjansenhttp://royal.pingdom.com/?p=340  <-- Perhaps we can help them understand why Linux and Utah go together like peanut butter and chocolate.
20:58.21unummy company is puny and it doesn't suck
20:58.28unumunless you consider who work for
20:58.37unumor are one of our many many part timers...
21:00.05goozbachunum: your company sucks because of what it does... :)
21:00.25unumwell ya there is the fact that we call people during dinner
21:00.30sjansenmaquis: You've probably adapted. Or you're only exposed to only a tiny cross section.
21:00.38unumthough I'm more bothered by the fact that we do it for the RIAA
21:00.53sjansenAlthough, I bet if I checked, $HUGECORP is probably much, much bigger than Amazon.
21:04.01maquissjansen: very likely
21:04.13maquisbut... just saying that we're moderately sized, and totally do not suck :)
21:04.24sjansenNope, looks like $HUGECORP isn't filtering. They just can't keep DNS reliable.
21:08.32sjansenmaquis: I can't find employee numbers, but I did find revenue. Looks like Amazon is about $3 billion behind $HUGECORP. (Which is actually pretty close for companies this size.)
21:08.59maquisi havent' the slightest idea how big we are...
21:09.00maquis:)
21:09.09maquisbut i know we're not particularly small
21:10.49sjansenmaquis: Enjoy it while you can. That also means you're probably pretty sucky.
21:10.58sjansenEven if you've been lucky enough not to see it.
21:11.53maquis*shrug*
21:12.04TeneI've had students from other parts of maquis' company, and they told me it was pretty sucky.
21:12.08Tenefwiw
21:12.19maquishmmm
21:12.26maquismaybe it's dependent on where you are...
21:12.33maquismy part and my husband's part are pretty good
21:12.43Tenethey weren't in WA, at least.
21:13.59*** join/#utah dilvie (n=chatzill@c-67-166-126-92.hsd1.ut.comcast.net)
21:14.26elglol. "it is assumed that as of press time, Mr. Doctorow is still talking."
21:18.12fozzmoohttp://blog.utos.org/2008/08/21/kick-off-utosc-with-eggs-sausage-and-techy-talk/
21:21.08goozbachwants sausage and techy talk!
21:21.18goozbachwants family day!
21:21.27goozbachwants utosc2008!
21:22.19jsmithYou should quit your job and come work for me, then you could (hopefully) come to UTOSC!
21:22.22Jayce^poor poor goozbach
21:22.27Jayce^sounds like a plan
21:22.39jsmithis hiring, for what it's worth
21:23.24*** join/#utah bbeattie (n=bbeattie@208.53.57.89)
21:24.55Jayce^gee jsmith, too bad you dont' need me :-p
21:25.09Jayce^bbeattie, eagerly anticipating your presentation :)
21:25.16bbeattieyup, working on slides now
21:25.32bbeattie.. but which, media or surveillance?
21:25.58Jayce^both, of course :)
21:26.01bbeattie;)
21:26.27bbeattieSpeaking of the presentation, did anyone put together some UTOSC branded template slides?
21:27.44Jayce^uh, will soon :)
21:29.04jsmithJayce^: C'mon now... Don't gimme none of that...
21:31.05*** join/#utah TimRiker (n=timr@72-62-216-179.area2.spcsdns.net)
21:31.08*** mode/#utah [+o TimRiker] by ChanServ
21:31.59Jayce^:-D
21:32.16Jayce^we still gotta plan some time to get you playing munchkin
21:33.29jsmithJayce^: Yeah... we need to do that.
21:33.56*** join/#utah jlp_work (n=jlp@gateway.FREECAKENETWORKS.COM)
22:01.08*** join/#utah brasto (n=brasto@97-117-71-212.slkc.qwest.net)
22:15.30*** join/#utah redbeard2 (n=jphall@63-148-163-200.dia.static.qwest.net)
22:15.56elgJayce^: what was that bread book you were reading?
22:17.54Jayce^lemme look, I started, then it got borrowed...
22:17.56nick125BREAD!
22:20.28Jayce^Artisan Bread in Five Minutes a Day: The Discovery That Revolutionizes Home Baking
22:20.42elgthanks
22:21.00elgi'm prepping to edacate the homemaking ladies
22:21.57Jayce^edacate 'eh?
22:22.10elgyup. gonna learn them sumthin fierce
22:22.49elgbut as simple as I like to make it I think it's not quite simple enough to teach well in one eve
22:22.56elgso I'm looking to simplify even further
22:28.58leviMmm, simple bread.
22:31.52leviHey, Second Life finally got their Mono-based VM working.
22:36.39harleypigdid they take it out of beta?
22:50.59leviApparently they're rolling them into production service, but because the increased performance can break time-sensitive scripts, you get a choice of some sort as to whether to use them.
23:08.55*** join/#utah elg (n=fugalh@216.31.27.110)
23:08.55*** mode/#utah [+v elg] by ChanServ
23:21.47harleypigSister Sledge!
23:24.00*** join/#utah peno (i=peno@slacknet.com)
23:24.00*** join/#utah tristanbob_ (n=tristanr@ubuntu/member/tristanbob)
23:24.00*** join/#utah jessestay (n=jstayii@ec2-67-202-2-62.z-2.compute-1.amazonaws.com) [NETSPLIT VICTIM]
23:24.00*** join/#utah herlo (n=clints@209.41.92.72)
23:24.00*** join/#utah Tadaka (n=Tadaka@c-67-169-241-41.hsd1.ut.comcast.net) [NETSPLIT VICTIM]
23:24.00*** join/#utah trixtur (n=trixtur@166-70-62-135.ip.xmission.com)
23:24.00*** join/#utah unum (n=unum@li32-229.members.linode.com)
23:24.00*** join/#utah tristanbob (n=tristanb@ubuntu/member/tristanbob)
23:24.01*** join/#utah spr (n=spr@mahonri5.net) [NETSPLIT VICTIM]
23:24.01*** join/#utah synic (n=squish@pdpc/supporter/student/synic)
23:24.01*** mode/#utah [+vv herlo unum] by irc.freenode.net
23:24.09harleypigSister Mary Elephant!
23:24.09Jayce^heheh...
23:24.37Jayce^you did hear that they are doing another tour/movie now?
23:24.37harleypigyeah, but it's nowhere near as good as it was
23:24.37harleypigtommy chong is almost completely burnt out
23:24.55Jayce^any surprise there?
23:25.17harleypigonly that cheech marin agreed to do it
23:25.45Jayce^think he's finally established himself enough outside of C&C, and with his age, that he can without destroying everything else
23:26.34harleypigThat's not my surprise ... his falling out with chong was almost epic
23:27.03harleypigI'm surprised that they were able to patch up their differences enough to do it
23:41.57harleypig8675309
23:44.15*** join/#utah undertakingyou (n=will@undertakingyou.dsl.xmission.com)
23:54.13*** join/#utah herlo_ (n=clints@209.41.92.72)

Generated by irclog2html.pl Modified by Tim Riker to work with infobot.