| 00:10.47 | maquis | *grumble* |
| 00:11.16 | maquis | if a library is in my LD_LIBRARY_PATH, it shouldn't give me "error while loading shard libraries", right? |
| 00:15.10 | *** join/#utah elg (n=fugalh@falcon.fugal.net) |
| 00:15.50 | *** join/#utah jsmith_ (n=jsmith@dsl017-122-217.mci1.dsl.speakeasy.net) |
| 00:17.59 | levi | maquis: Unless there was an error loading it for some other reason. |
| 00:18.44 | levi | findlay: You think it is a virtue that perl appears to be a mess? |
| 00:25.41 | levi | monk? |
| 00:27.16 | levi | Monk, the TV series? Thelonious Monk? Bulletproof Monk? Sue Monk? |
| 00:27.54 | levi | Here's one: "TwistedMonk.com - The source for the best hand conditioned hemp bondage rope." |
| 00:28.07 | elg | the tv series |
| 00:28.37 | levi | Oh, that's no fun. |
| 00:32.46 | findlay | levi: yes |
| 00:34.37 | levi | findlay: Well, liking the mess and considering it a virtue are two different things, as virtues aim to be objective and must therefore be subject to reason. So, what reasons do you have? |
| 00:35.01 | findlay | English is a mess |
| 00:35.18 | elg | scera is a mess |
| 00:35.38 | levi | It does not follow that messiness is a virtue. |
| 00:35.58 | findlay | I decree that messiness is a virtue |
| 00:36.26 | *** join/#utah graphyx (n=graphyx@205.208.245.105) |
| 00:36.45 | levi | That is a fallacy, argument from authority. Next attempt? |
| 00:37.22 | findlay | I have no more attempts to offer |
| 00:37.27 | findlay | nor need I offer any |
| 00:38.36 | *** join/#utah Sargun (n=xbmodder@atarack/staff/sargun) |
| 00:38.47 | levi | Well, not if you don't mind that your assertion is unfounded. |
| 00:38.50 | Sargun | Hey, anyone understand garage door openers in here better than I? |
| 00:39.05 | elg | you push the button and the garage door toggles |
| 00:39.05 | *** join/#utah jsmith (n=jsmith@dsl017-122-217.mci1.dsl.speakeasy.net) |
| 00:39.15 | mrpull | Sargun: read the instructions :) |
| 00:39.31 | Sargun | mrpull, Its 12 years old, there is a lack of instructions |
| 00:39.38 | findlay | Sargun: it's not a good idea to use garage doors as data storage. The write access is way too slow |
| 00:39.45 | findlay | even slower than flash |
| 00:39.52 | elg | push the button. i'm telling you ya can't go wrong |
| 00:40.03 | Sargun | The house has been sold twice since its original installation |
| 00:40.35 | Sargun | elg, The senors died (the car hit it) |
| 00:40.37 | Sargun | and I need to bypass the sensor |
| 00:41.00 | Sargun | I've tried to short out the contacts, and to keep them separated, but to no avail |
| 00:41.45 | Sargun | I have one working sensor |
| 00:41.50 | Sargun | I'm going to try a mirror |
| 00:41.53 | Sargun | (once I find one) |
| 00:42.00 | levi | Shorting generally means connecting, not disconnecting, two points. |
| 00:42.18 | Sargun | yeah |
| 00:42.22 | Sargun | I've tried both shorting it |
| 00:42.31 | Sargun | and disconnecting the points |
| 00:42.36 | Sargun | So I have no clue |
| 00:42.39 | Sargun | how to do this |
| 00:44.52 | Sargun | I have to buy a new sensor |
| 00:44.53 | Sargun | ugh. |
| 00:50.16 | levi | That's usually what you have to do when you break something. |
| 00:50.17 | *** join/#utah mrpull_ (n=mrpull@205.158.184.112) |
| 00:53.29 | findlay | Sargun: don't get a mirror, get a reflector |
| 00:53.41 | findlay | there's a fundamental difference |
| 00:55.17 | Sargun | ? |
| 00:55.31 | findlay | a reflector can be explained at least partially by Fermat's principle |
| 00:55.45 | findlay | ~wiki Fermat's principle |
| 00:56.22 | findlay | Sargun: you said you were going to try a mirror |
| 00:56.34 | findlay | and I sagely counselled to use a reflector instead |
| 00:58.15 | levi | findlay: "Fermat's Principle can be used to describe the properties of light rays reflected off mirrors..." |
| 00:58.37 | levi | A mirror is a reflector of light rays. |
| 00:58.43 | findlay | truly |
| 00:59.14 | findlay | but this is a reflector: http://en.wikipedia.org/wiki/Retroreflector |
| 00:59.52 | levi | That's a retroreflector. |
| 01:00.07 | findlay | yes |
| 01:00.13 | findlay | whatever, same thing |
| 01:00.28 | levi | Mirrors are not retroreflectors, but they are reflectors. |
| 01:00.40 | findlay | right |
| 01:01.22 | levi | A subclass of a class is not the same thing as the class itself. |
| 01:03.04 | findlay | but if I say 'mirror' and 'reflector' in the same sentence and mean by them that they are different devices you may deduce that by 'reflector' I'm referring by metomymy to something else, the most probable subject being a retroreflector |
| 01:03.09 | findlay | simplicity itself |
| 01:04.03 | levi | findlay: Not if you are unaware of other kinds of reflectors and how they differ from mirrors! |
| 01:04.29 | findlay | indeed that is a crucial assumption |
| 01:05.30 | findlay | where is emcnabb to enjoy this? |
| 01:05.34 | levi | Anyway, a bicycle reflector is probably adequate. |
| 01:05.42 | findlay | a white one |
| 01:06.06 | findlay | or you can go to the street corner and take down the street sign |
| 01:06.17 | levi | Or use a license plate. |
| 01:06.22 | *** join/#utah Newsome (n=sorenson@adsl-75-0-136-70.dsl.chcgil.sbcglobal.net) |
| 01:07.30 | levi | Time for me to head home. |
| 01:08.24 | findlay | on your retroreflecting bicycle |
| 01:10.08 | *** join/#utah jsmith (n=jsmith@dsl017-122-217.mci1.dsl.speakeasy.net) |
| 01:11.00 | levi | In my car with lights. |
| 01:13.02 | ScytheBlade1 | Anyone know of a good, relatively cheap GPS device that'll work with linux? |
| 01:13.17 | vontrapp | ScytheBlade1: manual-entry |
| 01:13.47 | ScytheBlade1 | ... well, that's one way, but it's hard to do that every few seconds while driving. |
| 01:13.52 | vontrapp | look yourself up on a map, get the coords and enter them |
| 01:14.11 | Sargun | ScytheBlade1, Those serial garmin GPS recievers |
| 01:14.13 | vontrapp | remember where you went, and enter the appropriate points |
| 01:14.21 | Sargun | They are about $70 |
| 01:14.34 | vontrapp | gah, serial, what about usb? |
| 01:14.39 | vontrapp | my lappy has no serial |
| 01:14.57 | vontrapp | otherwise i could use my homebrew lirc receiver with it |
| 01:15.08 | ScytheBlade1 | Cheapest Garmin I can find on newegg is $120 |
| 01:21.06 | com4 | OMG, people were stalking me!! |
| 01:21.08 | com4 | crazy bot |
| 01:24.10 | findlay | ~stalk com4 |
| 01:24.46 | findlay | ~hello |
| 01:24.48 | ibot | Howdy Bub |
| 01:24.55 | findlay | ~lag |
| 01:24.56 | ibot | it has been said that lag is very bad here :( |
| 01:26.35 | com4 | heh |
| 01:26.43 | com4 | there really should be a ~stalk command |
| 01:29.50 | findlay | ~stalk com4 |
| 01:29.52 | ibot | ACTION furtively infiltrates com4's shadows and when com4 is turned away jumps out to take a picture with his camera phone! |
| 01:30.06 | com4 | lolz |
| 01:31.59 | findlay | Jayce^: can you run those jobs by me again you were advertising at plug last night, or better yet, paste a link so some/all? |
| 01:32.08 | findlay | s/so/to |
| 01:34.14 | nick125 | Sargun: ping |
| 01:38.04 | Sargun | PONG |
| 01:40.23 | *** join/#utah Craig`afk (n=Craig@AC8DAFB3.ipt.aol.com) |
| 01:40.42 | *** part/#utah Craig`afk (n=Craig@AC8DAFB3.ipt.aol.com) |
| 01:55.25 | elg | -roulette |
| 01:55.25 | brac | elg: chamber 1 of 6 => +click+ |
| 01:55.46 | vontrapp | -roulette |
| 01:55.46 | brac | vontrapp: chamber 2 of 6 => *BANG* |
| 01:56.11 | graphyx | -roulette |
| 01:56.12 | brac | graphyx: chamber 1 of 6 => +click+ |
| 01:59.42 | vontrapp | elg: wesnoth? |
| 03:18.37 | *** join/#utah phinux (n=jamie@128.187.184.29) |
| 03:45.11 | elg | -lart vontrapp |
| 03:45.24 | Sargun | haha |
| 03:47.45 | findlay | when I try to use the heal tool in gimp it says 'Set a source image first.' What is a source image and how do I set it? |
| 03:49.06 | *** part/#utah phinux (n=jamie@128.187.184.29) |
| 03:54.20 | maquis | <-- stupid |
| 03:54.41 | vontrapp | finally, someone agrees with me! |
| 03:55.29 | vontrapp | well what's the heal tool? |
| 03:55.54 | findlay | supposedly it 'heals' image irregularities |
| 03:57.02 | maquis | vontrapp: :) |
| 03:57.12 | levi_home | maquis: What did you do this time? |
| 03:57.14 | vontrapp | maquis: though really, what would make you stupid? oh mighty op |
| 03:57.46 | findlay | maquis: you're not really stupid you know |
| 04:00.25 | levi_home | maquis: If you'd just embrace Scheme programming, you'd be really smart. ;) |
| 04:05.46 | findlay | is there a C tidier out there somewhere? |
| 04:05.52 | elg | indent |
| 04:07.29 | findlay | beautiful |
| 04:07.49 | findlay | this code had the ugliest use of whitespace I've ever seen |
| 04:07.58 | Sargun | haha |
| 04:08.03 | levi_home | It's impossible to make C beautiful. |
| 04:08.14 | findlay | just fixing intentation makes it look so much cleaner |
| 04:08.46 | findlay | ~make C beautiful for levi |
| 04:08.50 | ibot | make: *** No rule to make target `C beautiful for levi'. Stop. |
| 04:14.44 | levi_home | See? No rule to make C beautiful. |
| 04:21.44 | findlay | maybe not a rule but there is a principle |
| 04:23.49 | levi_home | Nope; ugly by design. :) |
| 04:24.05 | findlay | ~make C ugly |
| 04:24.06 | ibot | make: *** No rule to make target `C ugly'. Stop. |
| 04:24.10 | findlay | hm |
| 04:24.26 | levi_home | It doesn't need to be made ugly; it just is. |
| 04:32.57 | maquis | vontrapp: findlay levi_home just remember that i have a tendency to sometimes hit enter before thinking... |
| 04:33.10 | maquis | or... in this case... :wq! |
| 04:35.29 | goozbach | YAY! |
| 04:35.41 | goozbach | I've got a completely decorated christmas tree |
| 04:35.54 | goozbach | it looks good if i do say so myself |
| 04:36.04 | goozbach | and magna is NOT a hle |
| 04:36.10 | goozbach | s/hle/hole/ |
| 04:36.18 | levi_home | Heh. |
| 04:36.31 | goozbach | I blame canada, and pineapple pizza for all my problems |
| 04:36.33 | levi_home | Okay, maybe your corner of Magna isn't a hole. |
| 04:36.51 | goozbach | actually my house might have been in a hole |
| 04:37.15 | goozbach | you could put a basketball right inside the front door, and it would roll out the back door |
| 04:37.46 | goozbach | and the water was chewy |
| 04:38.12 | goozbach | and there was a drunk guy who about drove into my sister's front room |
| 04:38.27 | goozbach | then there was that 4-car pileup last year |
| 04:39.06 | goozbach | but I've got my own christmas tree!!! |
| 04:39.12 | levi_home | Heh. |
| 04:39.14 | goozbach | first time in ~3 years |
| 04:42.04 | goozbach | ohh my bank website HAS to be legit |
| 04:42.19 | goozbach | it showed me a picture that I prevously chose |
| 04:42.29 | goozbach | verified my ear |
| 04:43.38 | goozbach | sleepytime |
| 04:43.41 | goozbach | yup |
| 04:43.42 | goozbach | it is |
| 05:08.18 | com4 | i can probably guess which bank you use since my bank also recently did that |
| 05:08.39 | com4 | no more phishing scams.. MITM, what's that? |
| 05:18.10 | levi_home | A lot of banks recently did that. |
| 05:26.32 | Sargun | lol |
| 05:28.29 | Supaplex | apache, a mitm tool? never. |
| 05:34.26 | *** join/#utah stuporglue (n=stuporgl@c-24-2-92-125.hsd1.mn.comcast.net) |
| 05:44.29 | stuporglue | Anyone know of some good e-book reading software for Linux? Something that can bookmark my position in the book would be great. I'd like to read some of the books from Project Gutenburg. |
| 05:49.54 | Sargun | less? |
| 05:50.58 | stuporglue | Sargun: I don't think less does bookmarking. :-) |
| 05:51.38 | Sargun | Less + VPS + screen |
| 05:51.58 | stuporglue | VPS? |
| 06:27.13 | *** join/#utah pmcnabb (n=peter@c-24-10-165-203.hsd1.ut.comcast.net) |
| 06:52.27 | Supaplex | vim -R |
| 07:00.11 | Supaplex | there went yesterday |
| 07:02.19 | findlay | nooooooooo!!!11 |
| 07:03.51 | Sargun | lol |
| 07:04.19 | Sargun | pmcnabb, Hey |
| 07:04.30 | pmcnabb | hi |
| 07:05.54 | Sargun | Whats up? |
| 07:06.06 | pmcnabb | not much, just finishing some homework |
| 07:16.09 | vontrapp | ~spell agree |
| 07:16.24 | vontrapp | sometimes my brain can't spell this late |
| 13:49.48 | *** join/#utah Newsome (n=sorenson@adsl-68-22-220-206.dsl.chcgil.ameritech.net) |
| 13:57.02 | *** join/#utah elg (n=fugalh@falcon.fugal.net) |
| 14:02.31 | *** join/#utah graphyx (n=graphyx@205.208.245.105) |
| 14:22.25 | *** join/#utah jsmith (n=jsmith@dsl017-122-217.mci1.dsl.speakeasy.net) |
| 14:22.33 | redbeard1 | ~lart vontrapp |
| 14:23.09 | ^Migs^ | http://www.spokesmanreview.com/ap/story.asp?AP_ID=D8M0K6U00 |
| 14:26.50 | elg | -lart redbeard1 |
| 14:27.09 | redbeard1 | ~lart elg |
| 14:28.22 | elg | ~deplastic ^Migs^ |
| 14:35.24 | redbeard1 | elg: you punk |
| 14:40.32 | elg | should I build a flightgear port file? |
| 14:43.19 | elg | or figure out a way to burn whole bunches of cosby show episodes to one dvd (by reducing quality, or rather not upsampling) |
| 14:44.59 | jsmith | elg: Or port twinkle to the mac ;-) |
| 14:45.31 | elg | or that |
| 14:45.33 | elg | :) |
| 14:45.36 | elg | so many options |
| 14:48.53 | graphyx | the vim=emacs wouldn't work on me. I always put vi=vim in there and just type vi |
| 14:52.25 | *** join/#utah herlo (n=herlo@216-110-89-130.static.twtelecom.net) |
| 14:56.39 | redbeard1 | elg: don't you have work to do or something? |
| 15:00.31 | *** join/#utah wps (n=wps@67.108.236.230.ptr.us.xo.net) |
| 15:00.35 | elg | footloose and fancy free today |
| 15:00.43 | elg | which is just how I like my birthday |
| 15:04.53 | *** join/#utah spr (n=spr@c-71-195-212-252.hsd1.ma.comcast.net) |
| 15:05.03 | jsmith | ~gift elg |
| 15:05.09 | jsmith | Happy birthday elg |
| 15:06.08 | goozbach | ij ========== |
| 15:06.22 | goozbach | hmm lsets try tyat with hands on home row |
| 15:06.34 | goozbach | bah, I'll come back after a couple mt dew |
| 15:12.32 | goozbach | ok so I was going to buy a Wii, however I doubt I will until after I can build a plexi cage for my TV |
| 15:22.31 | graphyx | goozbach: afraid that you will lose control and throw your remote? |
| 15:26.25 | goozbach | graphyx: not me so much as most of the people I hang with |
| 15:26.31 | goozbach | and my TV is expensive |
| 15:26.38 | goozbach | I'd hate to replace it |
| 15:27.29 | goozbach | seeing as how it somehow got yogurt into one of the speakers last week I wouldn't put wiiremote incidents past my friends |
| 15:29.15 | graphyx | I see |
| 15:29.43 | graphyx | plexiglass isn't that expensive is it? |
| 15:30.40 | graphyx | just get a projector to play with. Drywall is cheap |
| 15:36.11 | goozbach | graphyx: GOOD IDEA |
| 15:36.27 | goozbach | other than the fact that a projector mounted on the celling is a target as well |
| 15:36.38 | goozbach | esp if you have low celings |
| 15:37.16 | goozbach | the majority of (non remote release) injury is due to breaking light covers and hitting celing fans with your hands/arms |
| 15:37.51 | elg | wow, building flightgear was easier than I anticipated |
| 15:39.47 | maquis | goozbach: can i just interject here that i'm slightly scared of the people you hang out with? |
| 15:45.51 | *** join/#utah vex (n=vex@stutter.prohosting.com) |
| 15:46.03 | goozbach | elg: tell me your secret. |
| 15:46.17 | goozbach | I've been trying to get flightgear running for about 4 days |
| 15:53.14 | graphyx | goozbach: what about a $100 deposit to play? |
| 15:53.24 | dataw0lf | woo, who saw the hawks / 49ers game? |
| 15:53.46 | maquis | dataw0lf: i saw what it did to traffic... |
| 15:53.58 | maquis | and i can currently see people cleaning n the stadium (or doing something in there...) |
| 15:54.09 | goozbach | graphyx: a deposit implies that they'll get it back |
| 15:54.25 | graphyx | if there is no damage. |
| 15:54.38 | goozbach | and $100 is NOT going to cover even a tenth of replacing my TV |
| 15:54.40 | dataw0lf | one of the greatest hits I've ever seen with 50 seconds in the 4th quarter. Branch got creamed. |
| 15:54.44 | dataw0lf | maquis: Oh, you're in Seattle? |
| 15:54.47 | dataw0lf | that's sweet. |
| 15:55.12 | *** topic/#utah by spr -> Channel for OSS discussion | See http://www.plug.org/node/28 | PHP workshop hosted by OALUG & UPHPU Jan 27 in Ogden- Watch http://groups.google.com/group/oalug for details | emcnabb wants a duck for Christmas. |
| 15:55.27 | graphyx | goozbach: just get another tv for playing the Wii |
| 15:55.27 | maquis | dataw0lf: yup... across the street from the stadium |
| 15:55.32 | dataw0lf | nice. |
| 15:55.55 | maquis | dataw0lf: who won? |
| 15:56.06 | maquis | i think i'm rooting for the hawks... :) |
| 15:56.08 | dataw0lf | 49ers |
| 15:56.14 | dataw0lf | unexpectedly |
| 15:56.20 | maquis | interesting |
| 15:56.22 | dataw0lf | division is up for grabs now. |
| 15:56.40 | dataw0lf | hawks defense broke down in the 2nd half and the 49ers offense stepped up |
| 15:56.45 | maquis | it was mighty stormy for them last night... they got lucky not to have the power go out in the stadium :) |
| 15:57.00 | dataw0lf | yea, they were slipping and sliding two minutes in |
| 15:57.07 | dataw0lf | the ball kept on slipping out of fingers |
| 15:57.08 | goozbach | maquis: they have things in place to prevent that |
| 15:57.23 | dataw0lf | it's hard to play when it's raining so hard and the wind is tearing through |
| 15:57.31 | dataw0lf | maquis: actually, some of the power did die, I think. |
| 15:59.17 | maquis | dataw0lf: ah |
| 15:59.17 | maquis | yeah |
| 15:59.26 | maquis | lots of areas around are out of power... |
| 15:59.45 | maquis | i was certain we wouldn't have any power this morning, but we did |
| 15:59.47 | dataw0lf | http://www.newscientist.com/article/dn9979-top-10-weapons-of-the-future-.html |
| 16:00.59 | *** join/#utah Lone_Wanderer (n=chatzill@208-186-98-2.customer.csolutions.net) |
| 16:04.24 | *** join/#utah jsmith (n=jsmith@dsl017-122-217.mci1.dsl.speakeasy.net) |
| 16:17.29 | ^Migs^ | does anyone want to do a PHP project for a friend of mine? I started it but personal problems at home made me unable to finish it |
| 16:17.37 | ^Migs^ | and he's too busy with work and school to finish it himself |
| 16:21.43 | dataw0lf | money involved? |
| 16:21.50 | ^Migs^ | yes, of course |
| 16:21.54 | dataw0lf | what's the project |
| 16:24.17 | ^Migs^ | he's redoing this site here: http://www.ohmania.co.uk/ |
| 16:24.28 | ^Migs^ | It's an advertising site for dance clubs and events |
| 16:24.40 | ^Migs^ | people pay a fee to post their event on the site. That's pretty much it. |
| 16:24.52 | ^Migs^ | then it gets broken down here: http://www.ohmania.co.uk/upload/weeklymail0032/weeklymail0032.php |
| 16:25.07 | ^Migs^ | I already started on all the event submission forms, and made some basic links to Paypal |
| 16:25.14 | ^Migs^ | he just needs the admin side done |
| 16:25.34 | dataw0lf | alright. give him my email std3rr@gmail.com |
| 16:26.11 | ^Migs^ | hang on a minute, I'm making sure this is actually okay with him. |
| 16:26.19 | dataw0lf | alright |
| 16:26.29 | ^Migs^ | He's getting a little desperate, as the client wanted it finished a week ago |
| 16:35.27 | ^Migs^ | Do you have an AIM or MSN screenname I can give him? |
| 16:36.06 | dataw0lf | Nope, not much of an IMer. |
| 16:36.55 | ^Migs^ | hmm, okay |
| 16:44.22 | *** join/#utah mrpull (n=mrpull@205.158.184.126) |
| 16:48.41 | levi | Morning. |
| 16:50.48 | redbeard1 | oog |
| 16:52.09 | levi | ook? |
| 16:55.01 | findlay | ood |
| 16:56.07 | maquis | meep! |
| 16:56.27 | *** join/#utah eco_ (n=eco@gnuk.net) |
| 16:57.54 | redbeard1 | maquis: why do you always have to go against the grain? |
| 16:59.04 | maquis | redbeard1: if i didn't go against the grain, i wouldn't be here |
| 16:59.07 | maquis | :) |
| 16:59.21 | redbeard1 | maquis: you mock my pain |
| 16:59.44 | Jayce^ | life *is* pain! |
| 17:00.49 | redbeard1 | Jayce^: anybody that tells you any different is selling something |
| 17:04.33 | findlay | you can die too for all I care |
| 17:05.30 | vontrapp | ~birthday el |
| 17:05.32 | ibot | ACTION Happy Birthday to you, Happy birthday to you!, HAPPY BIRTHDAY DEEEAARR el, Happy Birthday toooo yoooou! |
| 17:05.36 | vontrapp | ~birthday elg |
| 17:05.37 | ibot | ACTION Happy Birthday to you, Happy birthday to you!, HAPPY BIRTHDAY DEEEAARR elg, Happy Birthday toooo yoooou! |
| 17:05.40 | vontrapp | bah, he's not here |
| 17:09.56 | *** join/#utah neybar (n=jalance@pollux.northsky.com) |
| 17:13.24 | *** join/#utah tiwula (n=lane@208.64.90.18.utahbroadband.com) |
| 17:15.19 | redbeard1 | it's elg's birthday? |
| 17:20.23 | *** join/#utah TimRiker (n=timr@216.49.181.128) |
| 17:20.23 | *** mode/#utah [+o TimRiker] by ChanServ |
| 17:27.35 | *** join/#utah tiwula (n=lane@208.64.90.18.utahbroadband.com) |
| 17:36.50 | *** join/#utah elg (n=fugalh@dhcp37.cs.nmsu.edu) |
| 17:38.42 | vontrapp | ~birthday elg |
| 17:38.46 | ibot | ACTION Happy Birthday to you, Happy birthday to you!, HAPPY BIRTHDAY DEEEAARR elg, Happy Birthday toooo yoooou! |
| 17:39.01 | vontrapp | ~spank elg |
| 17:39.03 | ibot | ACTION bends elg over his knee and tatoos 'ibot' on elg's pasty white buttocks. |
| 17:39.51 | vontrapp | ~no, spank $what ~= s/his/her/ |
| 17:45.30 | *** join/#utah fungus (n=fungus@2001:470:1f00:645:250:8dff:fe71:9a6b) |
| 17:46.49 | elg | how sweet. a bot spanking |
| 17:46.51 | elg | -lart vontrapp |
| 17:48.01 | dataw0lf | elg: happy birthday |
| 17:48.10 | maquis | elg: happy b-day! :) |
| 17:48.19 | elg | thanks |
| 17:48.39 | redbeard1 | ~birthday elg |
| 17:48.40 | ibot | ACTION Happy Birthday to you, Happy birthday to you!, HAPPY BIRTHDAY DEEEAARR elg, Happy Birthday toooo yoooou! |
| 17:48.40 | dataw0lf | dang Tank Johnson, you eeediot. We need you for the TB game! |
| 17:48.45 | redbeard1 | ~lart elg |
| 17:49.25 | [Utah]tristanbob | a dull knife is more dangerous than a sharp one, right? |
| 17:49.42 | vontrapp | hey, halberd was my weapon of choice from that web-quiz thing |
| 17:50.51 | dataw0lf | vontrapp: It's all about the R.A.K. |
| 17:52.47 | redbeard1 | atoponce: levi's the man, but where did that come from? |
| 17:53.06 | dataw0lf | redbeard1: * levi breaks out the combinatorics on atoponce's latest blog entry. |
| 17:53.30 | redbeard1 | ah. i understand. |
| 17:53.38 | atoponce | redbeard1: i was humiliated through a comment on my latest blog entry |
| 17:54.41 | levi | I didn't intend for it to be humiliating. It's a pretty understandable mistake considering the typical suggestions for strengthening passwords. |
| 17:55.34 | levi | The obfuscated password is indeed stronger, since it means you have to go back to the 21-character brute force attack, which has a ridiculously huge search space. |
| 17:55.54 | atoponce | levi: yeah. i felt humiliated though. you are correct evaluating 21^26. i was just thinking from a word point of view |
| 17:56.04 | levi | It's just that it was already reasonably strong beforehand. |
| 17:56.45 | atoponce | good point. i'll clarify in the post |
| 17:57.18 | levi | Did I say 21^26? It's really 26^21. 26 possible characters and 21 choices from those. |
| 17:57.57 | atoponce | no, you were right, i was wrong |
| 17:58.00 | atoponce | 26^21 |
| 17:58.46 | atoponce | can't an automated attack work through that fairly quickly though? i mean, it is only 518131871275444637960845131776 |
| 18:00.07 | levi | That's 5.18*10^29 |
| 18:00.11 | atoponce | although large, it isn't astronomical. and we have had success in breaking 160-bit hashes |
| 18:00.16 | atoponce | which is far larger |
| 18:00.38 | atoponce | 1.46*10^48 |
| 18:01.25 | levi | It /can/ be broken, yes. At significant expense. |
| 18:02.34 | atoponce | would you think it would take significant resources? i would think a small cluster could handle it easily |
| 18:03.39 | dataw0lf | a 10 or 20 node cluster with cheap equipment may be able to do it any a fathomable time. |
| 18:03.44 | maquis | apologies, as i did not read the post, but why are you limiting it to case-insensitive, alphabetical (no numbers, symbols, etc)? |
| 18:04.08 | levi | maquis: You should read the post before commenting. |
| 18:04.19 | maquis | levi: i know... i'm just curious... |
| 18:04.25 | levi | maquis: So read it. |
| 18:04.34 | atoponce | maquis: we're discussing the strength of just lowercase passphrases using a brute force attack |
| 18:04.42 | maquis | ok... |
| 18:05.02 | atoponce | levi suggests that it is far stronger than i load on to be in my post, at which point now, i am agreeing with |
| 18:05.12 | levi | The actual SHA-0 160-bit hash collision was discovered on a 256-node Itanium cluster, apparently. |
| 18:05.13 | atoponce | s/load/lead/ |
| 18:05.47 | levi | And I doubt it was a brute force search. It sounds like exploitation of a weakness in SHA-0. |
| 18:06.05 | dataw0lf | the near collisions before the first found collision were brute forced. |
| 18:07.20 | levi | Anyway, 80,000 cpu-hours is a lot to devote to a single password. It's probably decreased a bit since 2004. |
| 18:07.53 | dataw0lf | levi: was that the time spent on the first real collision? |
| 18:08.05 | dataw0lf | I thought it was significantly less than that. |
| 18:08.07 | levi | dataw0lf: I believe so. |
| 18:08.16 | levi | Perhaps it was refined later. |
| 18:08.21 | dataw0lf | yea, could be. |
| 18:08.46 | dataw0lf | http://www.cs.cmu.edu/~dbrumley/srg/spring06/sha-0.pdf |
| 18:08.53 | dataw0lf | yup, 80k |
| 18:08.57 | dataw0lf | whew |
| 18:10.07 | atoponce | and that is 2^160. this passphrase is considerably weaker |
| 18:10.46 | *** join/#utah SB1-Laptop (n=Death@about/pxe/ScytheBlade1) |
| 18:10.55 | levi | No, that's cpu hours. |
| 18:11.00 | dataw0lf | 2^160? no, no. |
| 18:11.05 | levi | 80k is cpu hours. |
| 18:11.14 | dataw0lf | it's 2^54 or so |
| 18:11.19 | levi | 2^69 steps to break it. |
| 18:11.21 | atoponce | right. but the hash is 160-bit: 2^160 |
| 18:11.36 | levi | No, the hash is supposed to be strong to 2^80. |
| 18:12.01 | atoponce | after collisions? |
| 18:12.40 | levi | No, that was its design strength. |
| 18:13.14 | atoponce | so how about 256/384/512 bit hashes? are they not 2^256/384/512? |
| 18:13.21 | dataw0lf | which means little practically, if you're exploiting an algebraic weakness in the algorithm |
| 18:13.45 | levi | The collision required 2^69 steps, which is weaker than 2^80, so it was considered broken even though it is still stronger than the design strength of MD5. |
| 18:13.48 | *** join/#utah jsmith (n=jsmith@dsl017-122-217.mci1.dsl.speakeasy.net) |
| 18:15.30 | levi | This is different from a password system, though. Those are for hashing algorithms meant to be used in digital signatures. |
| 18:15.47 | atoponce | which shows a problem with the algorithm. but when considering a 256-bit hash, is it not fair to say that it's 2^256 strong? |
| 18:15.59 | levi | atoponce: No, it is not 2^256 strong generally. |
| 18:16.13 | *** join/#utah vex (n=vex@216.194.126.99) |
| 18:16.40 | atoponce | but that is the indended outcome? i'm confused where '256' comes from then, if not 2^256. see what i'm saying? |
| 18:16.46 | levi | Probably closer to 2^128, but you'd have to look it up for the specific outcome. |
| 18:17.11 | levi | The hash itself contains 2^256 bits of data, but not all of those bits contribute to the strength of the algorithm. |
| 18:17.20 | atoponce | i see |
| 18:18.00 | dataw0lf | http://www.keylength.com/ |
| 18:18.32 | levi | Anyway, to crack a password with that kind of operation, one would have to first steal the /etc/shadow file or database containing the hash. |
| 18:18.35 | atoponce | that makes sense then. so going back to our 'ienjoyprognammingperl' example, it contains 5.18*10^29, but it's strength would be calculated differently? or am i comparing apples to oranges? |
| 18:18.45 | levi | atoponce: Apples to oranges. |
| 18:18.57 | levi | atoponce: You have to look at how the password is stored. |
| 18:19.21 | atoponce | right. ok. |
| 18:19.42 | levi | To do a direct attack on the hash of the password, you have to first have the hash. |
| 18:19.54 | levi | Password hashes are generally kept secret. |
| 18:20.29 | dataw0lf | levi: have you ever read Between Silk and Cyanide? |
| 18:20.36 | levi | dataw0lf: Nope. |
| 18:20.50 | dataw0lf | good book about codemaking during WW2 |
| 18:21.20 | levi | It'd be interesting to read, but I'm in the middle of too many books already and cryptography isn't really one of my big interests. |
| 18:21.41 | sleepy_herlo | dataw0lf: I've heard of that book, hsould probably pick it up. I love to hear about WWII cryptography stuff |
| 18:22.11 | dataw0lf | sleepy_herlo: it's excellent |
| 18:22.18 | atoponce | levi: thx. i'll update the post. a lot of things we've discussed, that i didn't think about this morning. |
| 18:22.22 | maquis | there's a movie on amazon about navajo code-talkers |
| 18:22.26 | sleepy_herlo | dataw0lf: I wanna read it, |
| 18:23.03 | *** join/#utah graphyx (n=graphyx@205.208.245.105) |
| 18:23.08 | levi | atoponce: Anyway, passwords are much more secure when the attacker doesn't have direct access to the hash on the server, which should be the normal case for a password! |
| 18:23.12 | dataw0lf | maquis: Windtalkers? |
| 18:23.35 | sleepy_herlo | dataw0lf: good movie |
| 18:23.49 | dataw0lf | when it comes to brute forcing, you should probably have a good password policy and hammer brute force login scripts before they get going. |
| 18:23.53 | maquis | dataw0lf: i don't think that's the one i was looking at... the one i saw yesterday was a pbs documentary, i think |
| 18:24.01 | dataw0lf | if someone gets your hash file, you're probably screwed anyways. |
| 18:24.12 | dataw0lf | maquis: ooh, that's interesting. |
| 18:24.19 | dataw0lf | My Dad speaks Lakota Sioux fluently. |
| 18:24.28 | dataw0lf | pretty wild language |
| 18:24.39 | atoponce | when we're talking basic website passwords, i would assume that 8 characters is strong enough. but when dealing with encrypion, and private keys, i would think you would want something significantly stronger |
| 18:24.42 | maquis | wow... that's cool |
| 18:24.50 | levi | atoponce: And you can get huge increases in security simply by adding one or two non-alphanumeric characters without obfuscating the whole thing. |
| 18:25.02 | atoponce | true |
| 18:25.05 | dataw0lf | maquis: well, he did his thesis on the language itself and the impact of it's dialect on the lakota sioux's culture. |
| 18:25.17 | maquis | dataw0lf: cool! |
| 18:25.30 | dataw0lf | yea, it's pretty sweet. |
| 18:25.33 | maquis | when i was little, i tried to pick up every book i could find at the library on the plains indians.... not sure why.... |
| 18:25.41 | dataw0lf | they're incredibly interesting. |
| 18:25.46 | maquis | i was particularly interested in the blackfoot tribes... |
| 18:26.43 | dataw0lf | I'm obsessed with Sitting Bull |
| 18:27.21 | [Utah]tristanbob | we were talking about CAPTCHA vs anti-SPAM technology - Can we address that? For starters, which is more accurate? |
| 18:28.00 | dataw0lf | 'more accurate' ? |
| 18:28.03 | dataw0lf | or more effective? |
| 18:28.21 | *** join/#utah graphy1 (n=graphyx@205.208.245.105) |
| 18:28.29 | dataw0lf | Captcha technology is just ignoring the real problem. Spam technology will, in nearly all cases, keep up with Captcha. |
| 18:28.33 | levi | atoponce: In any case, a typical skript kiddie doesn't have access to the kind of resources necessary to break a 21-character password in a reasonable amount of time. If you're trying to create serious security against a well-funded attacker, just make your passphrase a capitalized sentence with punctuation. |
| 18:29.47 | [Utah]tristanbob | IenjoyPerlprogramming! |
| 18:30.05 | atoponce | ok. just being the paranoid i am, i can't trust my data with it, but it's probably okay for most |
| 18:30.22 | levi | More like: I enjoy Perl programming! |
| 18:30.30 | [Utah]tristanbob | do most systems allow spaces? |
| 18:30.34 | levi | atoponce: That is silly. |
| 18:30.46 | dataw0lf | or 1 3nj0y P3r1 Pr0gr@mm1ng! |
| 18:31.09 | levi | dataw0lf: If I don't use passwords like that all the time, I forget which characters to replace. |
| 18:31.10 | [Utah]tristanbob | dataw0lf: that looks strong, but it is less strong that mine |
| 18:31.38 | dataw0lf | levi: I like mnemnonic devices |
| 18:31.40 | dataw0lf | like |
| 18:31.56 | atoponce | levi: i know. i'm just not trusting of anything anyone anytime. i've been screwed too much, so that's created the paranoia. but then again, i have ocd, so there you go |
| 18:32.03 | dataw0lf | IrHbWh@TwH! |
| 18:32.11 | dataw0lf | I really hate bush when he's at the white house |
| 18:32.39 | [Utah]tristanbob | pizza is my favorite food in the morning OK? = pimffitmOK? |
| 18:33.00 | dataw0lf | $ItRoAe@tH&lL |
| 18:33.07 | dataw0lf | Money is the root of all evil at the highest and lowest levels |
| 18:33.13 | macnewbold | but how do you remember what to caps and what not? |
| 18:33.37 | dataw0lf | I just do caps on, caps off, most of the time |
| 18:36.49 | [Utah]tristanbob | levi: you have probably seen "http://hotcaptcha.com/" - the statistics of guessing 3 out of 9 people right, is 1/3 right |
| 18:37.30 | [Utah]tristanbob | what if someone built a captcha out of this database of images to word relationships |
| 18:37.36 | [Utah]tristanbob | http://images.google.com/imagelabeler/ |
| 18:37.56 | sleepy_herlo | [Utah]tristanbob: invited you to LinkedIn |
| 18:37.57 | [Utah]tristanbob | "allows you to label random images to help improve the quality of Google's image search results." |
| 18:38.10 | [Utah]tristanbob | sleepy_herlo: already connected :) |
| 18:38.35 | herlo | [Utah]tristanbob: k |
| 18:41.07 | redbeard1 | levi: i just read your response to atoponce's post |
| 18:42.53 | dataw0lf | almost a week without a cigarette, and this JavaScript is making it real hard to not be tempted |
| 18:43.03 | nick125_lappy | what good are captcha when you can hire someone for $2 an hour to crack captchas? |
| 18:50.02 | maquis | wow... weather's really nice today... |
| 18:51.08 | [Utah]tristanbob | dataw0lf: keep it up, man! |
| 18:51.34 | dataw0lf | I'm chewing nicorette like craaaazy |
| 18:51.35 | vontrapp | who needs those weird image things anyways? |
| 18:52.03 | vontrapp | er, of the post title |
| 18:52.31 | vontrapp | i can see how mixing caps would help your password in the case where it's a dictionary word |
| 18:52.54 | vontrapp | that makes it so the naive dictionary attack will miss it or will have to do all capitalization permutations of each word |
| 18:53.10 | vontrapp | but where you're already out of the dictionary, i don't see the point of mixed case |
| 18:54.00 | dataw0lf | it varies the range of characters you're going to have to randomly generate |
| 18:54.24 | vontrapp | but the attacker doesn't know what characters you did or didn't use |
| 18:54.36 | vontrapp | so again, what's the point? |
| 18:54.55 | vontrapp | all i need is for people like atoponce to obfuscate their passwords so i don't have to :p |
| 18:55.00 | dataw0lf | but many random brute force login scripts will restrict to smaller character sets to limit permutations. |
| 18:55.29 | vontrapp | in that case, all it takes is _one_ non-ordinary character |
| 18:55.33 | vontrapp | like an ! at the end |
| 18:55.52 | dataw0lf | Not necessarily. There are lists of the most common non-ordinary characters. ! tops the list. |
| 18:56.04 | vontrapp | ok something else |
| 18:56.45 | atoponce | use unicode. :) |
| 18:56.57 | Supaplex | ^M! |
| 18:57.19 | dataw0lf | I don't see how varying your password as much as possible can be negative in any way, unless you have trouble remembering the password itself, which I don't. |
| 18:57.45 | vontrapp | so how goes it, someone will brute force on just the lowercase, if that fails they start over again with the uppercase included? then if that fails they add the !? |
| 18:57.54 | vontrapp | that seems silly to me |
| 18:58.02 | dataw0lf | well, most brute forcers are not attacking one particular user |
| 18:58.32 | dataw0lf | they'll take a bunch of usernames, and usually a bunch of hosts, and, to increase chances and minimize time, they'll use common characters to attack. |
| 18:59.04 | vontrapp | i find that unlikely |
| 18:59.09 | vontrapp | more likely they use common words |
| 18:59.40 | vontrapp | for one they don't even know the length of the password, and that bumps it up orders of magnitude |
| 18:59.46 | dataw0lf | Well, that'd be your standard dictionary attack. I'm talking about random brute force enumeration. |
| 18:59.59 | vontrapp | i can't say if i have a 6 character password that it has 26^6 strength |
| 19:00.14 | vontrapp | cause they have to try all passwords of length 4 and 5 |
| 19:00.19 | vontrapp | as well |
| 19:00.28 | vontrapp | and even 7 8 |
| 19:00.51 | dataw0lf | they'll usually restrict, again, to common password lengths. 6-8. |
| 19:01.04 | atoponce | well, at least my post prompted an interesting discussion... :) |
| 19:01.25 | vontrapp | well, with all these restrictions the attackers do, it seems i'm safe breaking out of any one of those restrictions |
| 19:01.39 | vontrapp | i put one number in, or make it 10 long... |
| 19:01.41 | vontrapp | or both |
| 19:02.03 | vontrapp | i just don't see the point of case up, case down, case up, ... and things like that |
| 19:02.34 | vontrapp | it it bugs the crap out of me when a password system restricts what I can choose for my own password |
| 19:02.40 | dataw0lf | *shrug* I've seen them broken. I have a tendency to default to stronger security if it has no effect on me whatsoever. |
| 19:02.41 | vontrapp | making me put numbers in or whatever |
| 19:03.20 | vontrapp | i also like my passwords to be easy to type, and shifting is one of the quickest ways to break typability |
| 19:03.42 | dataw0lf | It doesn't have any noticeable effect on. |
| 19:03.44 | dataw0lf | me* |
| 19:04.42 | vontrapp | anyway, i could possibly see myself using such techniques to make my passwords secure if i felt a compelling reason |
| 19:05.39 | vontrapp | but i'm more or less playing devils advocate |
| 19:05.39 | dataw0lf | when you feel a compelling reason, it's usually too late. |
| 19:05.39 | vontrapp | and if we want the average user to be more secure, we have to suggest ways to secure their passwords that are within their reason |
| 19:05.39 | vontrapp | and i think #!@jh1k35h!@ falls out of the average persons 'within reason' |
| 19:05.41 | dataw0lf | Sure. But I'm not talking about a standard password policy, nor am I talking to average users. |
| 19:06.03 | maquis | vontrapp: but there are things we can do to help the average user come up with good passwords |
| 19:06.06 | dataw0lf | I'm talking about myself and what strategies I use. I wouldn't dream of attempting to force users into such a password generation scheme. |
| 19:06.20 | vontrapp | maquis: that's my point, and obfuscated passwords is not one of them |
| 19:06.31 | dataw0lf | but a strong password policy in place is. |
| 19:07.38 | dataw0lf | What I _use_ as my password scheme has no reflection on any enforced user policies. |
| 19:07.44 | vontrapp | a strong password policy means that a) the password is being reviewed by someone or some process and b) it's travelling around somewhere in plaintext form |
| 19:08.02 | dataw0lf | Not necessarily, you just require rules in password generation. |
| 19:08.21 | dataw0lf | 1) no words in the dictionary |
| 19:08.29 | dataw0lf | 2) at least one number or symbol |
| 19:08.41 | vontrapp | ok, but i'm talking about systems that reject the password you chose in the end |
| 19:08.52 | dataw0lf | that's not a good idea. |
| 19:09.16 | dataw0lf | I just enforce the two top, major rules, and then run dictionary attacks on my hash files intermittently. |
| 19:09.24 | maquis | vontrapp: but if the user learns about ways to create a good password (using phrases instead of words, etc), then you can enforce some of the rules withuot problems |
| 19:09.27 | dataw0lf | (in cases where I have regular users) |
| 19:09.29 | vontrapp | and in your argument, if you want a password policy to actually be followed, it has to be 'within reason' to the users that will follow it |
| 19:09.41 | dataw0lf | I just stated my 'within reason' policy. |
| 19:10.03 | maquis | dataw0lf: one password restriction i've seen that honestly made me mad was when they said that my password was rejected because it was too long |
| 19:10.08 | nick125_lappy | thoffmeyer: whats in /usr/local/portage5 |
| 19:10.09 | nick125_lappy | er |
| 19:10.24 | dataw0lf | maquis: well, I've never done that, although I usually put a limit on the minimum amount of characters, usually 6 |
| 19:10.30 | maquis | i've seen systems which say your password must be *exactly* 8 characters... |
| 19:10.40 | vontrapp | maquis: in that case i would guess it's a problem with the hashing algorithm, probably not any set policy |
| 19:10.41 | maquis | most of my passwords are longer than 8 characters |
| 19:10.43 | vontrapp | or lazy code |
| 19:10.45 | vontrapp | who knows |
| 19:10.56 | goozbach | maquis: you password should be exactly 8 charaters and must follow the format: 12345678 |
| 19:11.06 | maquis | goozbach: exactly :) |
| 19:11.10 | vontrapp | haha |
| 19:11.12 | dataw0lf | that's about the worst idea I've ever heard. |
| 19:11.46 | dataw0lf | a set password length multiples your chances of getting successfully attacked by a large order of magnitude. |
| 19:11.53 | vontrapp | anyway, maybe a user adopts one secure password policy |
| 19:12.00 | maquis | i've also seen some where your password can be longer than 8 characters, but if it is, it'll only look at the first 8 characters |
| 19:12.02 | vontrapp | she goes to a site that mandates a different one |
| 19:12.25 | findlay | maquis: that's scary |
| 19:12.28 | vontrapp | it will just frustrate the user, force him to pick a password she's not used to, and break memorability of that password |
| 19:12.56 | vontrapp | s/him/her |
| 19:13.01 | dataw0lf | not if you educate your users and pick a reasonable password policy |
| 19:13.17 | dataw0lf | education of users, in any sense, is your #1 security tool. |
| 19:13.27 | vontrapp | dataw0lf: yours is _not_ the only one your user will come across |
| 19:13.34 | maquis | vontrapp: does your fictitious user plan on never changing her password and using the same password for every system she needs a password for? |
| 19:13.43 | vontrapp | it's the conflicting policies that will frustrate people |
| 19:13.55 | vontrapp | maquis: no |
| 19:14.07 | dataw0lf | vontrapp: Well, any network I'm going to work I'm going to be in control of that, so that's irrelevant ;) |
| 19:14.33 | vontrapp | but said user may have a certain system in place from which he generates different yet similar passwords that he can remember |
| 19:14.41 | maquis | vontrapp: then that isn't an issue... she's going to have to change her password anyways... |
| 19:15.29 | vontrapp | it's not that he changes his password, it's how he's forced to compose his password |
| 19:15.29 | maquis | systems for changing passwords are bad, imho |
| 19:16.22 | maquis | if my password is password32 this month and somenoe finds out what it is, then i change my password to password 33, it's not going to be hard for them to guess it |
| 19:16.39 | maquis | even if i change it to password91, they'll probably guess it reasonably quickly |
| 19:16.46 | dataw0lf | well, imho, this all boils down to user education. |
| 19:16.53 | maquis | dataw0lf: agreed |
| 19:17.08 | maquis | but i don't think we should necessarily trust the user to apply the education without some enforcement |
| 19:17.08 | dataw0lf | most users have no problem sticking to various password policies, if they're educated on the reasons. |
| 19:17.31 | dataw0lf | certainly, I think password policies should be enforced. |
| 19:17.41 | vontrapp | i still disagree with the enforcement |
| 19:18.00 | vontrapp | outside of intermittent dictionary attacks on the hash |
| 19:18.29 | dataw0lf | well, it's hard to enforce beyond that, really. I just do post crack enforcement, most of the time. |
| 19:18.42 | vontrapp | if your education fails to get the user to use good passwords without enforcement, then you've already failed |
| 19:18.50 | vontrapp | like maquis' example password31 |
| 19:18.54 | dataw0lf | talk to a VP, let them know that you will crack their password if they don't stick to the enforced policy, and will be written up if they violate it |
| 19:19.06 | vontrapp | that's a result of enforcing numbers in the password, and failed education |
| 19:19.10 | dataw0lf | vontrapp: well, that's why it has to be good user education. |
| 19:19.22 | vontrapp | and if you have good user education then enforcement is moot |
| 19:19.50 | dataw0lf | as long as I don't crack any passwords, I'm happy |
| 19:20.03 | dataw0lf | I'm not saying that they can't go above and beyond simple password enforcements |
| 19:20.07 | vontrapp | dataw0lf: great, enforcement via cracking is fine |
| 19:20.15 | vontrapp | it's people seeing my password that i'm not fine with |
| 19:20.15 | findlay | cracked passwords don't taste as good as steamed directories |
| 19:20.21 | dataw0lf | but that's why most good password enforcement policies are what NOT to do, not what TO do. |
| 19:20.24 | vontrapp | peope/computers |
| 19:20.38 | dataw0lf | vontrapp: Oh, I agree. I think reviewing passwords is a bad practice. |
| 19:22.11 | dataw0lf | wow, this team's code I'm reviewing is pretty much retarded. |
| 19:22.24 | vontrapp | i just think the more acceptable a policy is to one with weak memory and a lack of desire to be secure, the more it's going to be followed |
| 19:22.26 | dataw0lf | it's almost dailyWTF worthy. |
| 19:22.49 | vontrapp | that's not to say you can't add a '... and if you really want to be secure do this..." |
| 19:23.32 | dataw0lf | ok, ok, so, this team, oh man, haha |
| 19:23.45 | dataw0lf | so they grab all the form fields from this form in javascript |
| 19:23.49 | dataw0lf | then, uh, hehe |
| 19:24.29 | dataw0lf | they pass it to a javascript function that encodes the values as GET values and directs to another page... |
| 19:25.02 | findlay | no, we're not done hashing passwords! |
| 19:25.10 | findlay | I think passwords are redundant! |
| 19:25.19 | findlay | a username should be enough |
| 19:25.29 | dataw0lf | AND A DROP OF BLOOD MUHAHAHAHA |
| 19:25.49 | findlay | my passwords are all Shakespeare sonnets |
| 19:26.04 | dataw0lf | yea, I usually stick to the Gettysburg Address. |
| 19:26.20 | findlay | or the entry on paranoid in the OED |
| 19:26.30 | goozbach | I just use 12345 |
| 19:26.31 | vontrapp | 4^+7<< |
| 19:26.52 | findlay | mine is occasionally ***** |
| 19:27.08 | vontrapp | hehe, that reminds me of the dilbert |
| 19:27.12 | findlay | or * x n, where n is an arbitry integer |
| 19:27.36 | vontrapp | "my password is just ***** no matter what i type!", "then just use **** for your password" |
| 19:28.01 | vontrapp | "OK" |
| 19:28.24 | dataw0lf | reminds me of the bash.org quote |
| 19:28.26 | dataw0lf | http://bash.org/?244321 |
| 19:30.31 | vontrapp | that's a good one |
| 19:30.57 | goozbach | is it just me or is bzr harder to type than baz |
| 19:31.11 | dataw0lf | bzr, definitely. |
| 19:31.26 | findlay | I always thought it was me |
| 19:31.35 | vontrapp | who types bzr? |
| 19:31.57 | vontrapp | bzr is easy in dvorak |
| 19:32.08 | findlay | you can do `alias afasdlkfjhadfblkj=bzr` if you wanted |
| 19:32.11 | dataw0lf | people using Bazaar, for one. |
| 19:32.14 | vontrapp | but baz is still easier |
| 19:33.08 | dataw0lf | http://bash.org/?577451 |
| 19:36.24 | maquis | baz is easier to tab-complete |
| 19:43.44 | *** join/#utah stuporglue (n=stuporgl@c-24-2-92-125.hsd1.ut.comcast.net) |
| 19:43.46 | stuporglue | join #urug |
| 19:47.12 | *** join/#utah findlay (n=justin@67.137.24.115) |
| 19:49.32 | *** topic/#utah by findlay -> Channel for OSS discussion | See http://www.plug.org/node/28 | PHP workshop hosted by OALUG & UPHPU Jan 27 in Ogden- Watch http://groups.google.com/group/oalug for details | emcnabb wants a duck for Christmas. | findlay wants a Strad viola |
| 19:54.24 | *** join/#utah graphyx (n=graphyx@205.208.245.105) |
| 19:56.00 | findlay | great dataw0lf you got me reading bash at work |
| 19:56.10 | nick125_lappy | yeah |
| 19:56.15 | nick125_lappy | thank you very much dataw0lf :( |
| 19:57.49 | atoponce | http://pastebin.ca/280271 |
| 19:57.59 | atoponce | is there a faster way to implement that algorithm? |
| 19:58.23 | atoponce | if each file has 500 lines, no problem, but if they have 500,000, then a problem. very slow |
| 19:58.45 | atoponce | arrays would seem to be faster, then sorting, but that could be too memory intensive. any ideas? |
| 19:59.27 | redbeard1 | if each file has 500 lines, and one is in texas and one is in cuba, how long would it take for the trains to meet? |
| 19:59.34 | atoponce | basically, i'm just looking to optimze the algo |
| 20:00.34 | findlay | easy |
| 20:00.44 | findlay | you find the critical points in the derivative |
| 20:01.09 | atoponce | findlay: oh? and how is that done? |
| 20:01.27 | findlay | atoponce: I was answering redbeard1's posit |
| 20:01.31 | atoponce | ahh |
| 20:01.34 | findlay | (: |
| 20:01.50 | findlay | I don't know much about data algorithms |
| 20:02.08 | findlay | I suggest The Art of Computer Programming (-: |
| 20:02.37 | atoponce | i want to increase my search speed, while keeping memory usage minimal as well as hdd reads. |
| 20:03.33 | atoponce | any ideas? |
| 20:04.37 | Tene | atoponce: sort them both? |
| 20:05.33 | atoponce | would sorting increase my overall overhead or time? |
| 20:08.47 | Tene | There's a pretty simple way to find out. |
| 20:09.07 | atoponce | Tene: have you taken a look at the pastebin? |
| 20:09.09 | levi | atoponce: You have a O(nm) algorithm there. Not so good. |
| 20:09.25 | atoponce | levi: yeah. i'm looking to make it better |
| 20:09.37 | levi | Sorting is generally a O(log n) operation, which is relatively cheap. |
| 20:09.51 | levi | Er, n log n? |
| 20:10.13 | levi | Yeah, quicksort is average n log n. |
| 20:10.35 | atoponce | ok |
| 20:10.36 | levi | Which is not as cheap as log n, of course. |
| 20:10.56 | levi | Anyway, are you optimizing for time or space? |
| 20:11.33 | atoponce | both, as much as possible. probably time more than space thogh |
| 20:11.44 | atoponce | s/thogh/though/ |
| 20:12.49 | Tene | then sort the two fiels first. |
| 20:12.50 | levi | You can cache the lookup in the second list fairly easily, which should improve lookup time significantly for large lists. |
| 20:13.38 | atoponce | thinking out lound, what sorts do i have available? quick, merge, heap, bubble... |
| 20:13.44 | atoponce | *loud |
| 20:15.01 | atoponce | problem, is these files are LARGE. 500+ columns in most cases. so sorting the file could be intensive. |
| 20:15.06 | levi | Store the larger one in a hash, and then you have a O(n + m) instead of O(nm). |
| 20:15.43 | atoponce | i would think i would just want to load the text that i am comparing into an array, then sort the array, then search? |
| 20:16.10 | atoponce | if i find matches, i could print the matching line to another file? |
| 20:16.39 | Jayce^ | you could also look at loading into a dbm/mldbm/etc and let them do some of the work |
| 20:16.55 | levi | The hash could use the phone number as the key and the line number as the value. |
| 20:18.31 | levi | I think your algorithm is also broken as it stands. |
| 20:18.44 | atoponce | how do you mean? |
| 20:18.50 | levi | The inner loop never resets. |
| 20:18.59 | Jayce^ | levi, you're just full of good news for atoponce today, aren't you :) |
| 20:19.07 | atoponce | Jayce^: :) |
| 20:20.33 | Jayce^ | and substr probably isn't the best way to get your data... well it definately isn't |
| 20:21.08 | levi | It will match the first entry of file1.txt against all the entries of file2.txt, and then for all subsequent entries in file1.txt, it will check them against nothing. |
| 20:21.43 | levi | Jayce^: That's the least of his worries right now. :) |
| 20:21.56 | Jayce^ | even for 500k entries, you would likely be better working in memory instead of iterating the file |
| 20:21.57 | atoponce | levi: i see. open and close file1.txt in my outer loop |
| 20:21.59 | Jayce^ | levi, yeah, true |
| 20:22.07 | atoponce | ? |
| 20:22.28 | levi | He needs to get from a broken naive algorithm to a working reasonable algorithm before worrying about constant factors. |
| 20:22.39 | Jayce^ | levi, true.. |
| 20:24.13 | Jayce^ | could do this as a quick map |
| 20:24.25 | levi | So, you are doing a search. The best ways to search are hash lookup, which is O(1) with a significant space overhead and possibly a significant constant factor, or a binary list search for O(log n) lookup time. |
| 20:24.40 | levi | With less space overhead. |
| 20:25.07 | Jayce^ | just how concerned are you about the space atoponce? |
| 20:25.48 | Jayce^ | if you, as levi suggested, store a simple hash, with only that data you care about, you could keep it small, still holding your whole dataset |
| 20:26.00 | atoponce | Jayce^: well, it'll be running on a production server. not sure of what's available. i would guess not too much, but i shouldn't overlook it |
| 20:26.35 | Jayce^ | are you actually just planning on 'saving' your results by printing, or do you need them in another manner? |
| 20:26.41 | levi | The downside to binary search is that it requires a sort first. Subsequent searches become much faster, though. |
| 20:27.01 | atoponce | Jayce^: at most, i would need to print the results to a file |
| 20:27.57 | atoponce | meaning, printing the matching line |
| 20:28.52 | levi | Since hashing is so simple in perl, I'd start with that and measure the overhead to see if it's acceptable. |
| 20:29.14 | atoponce | ok. i've never done it, but i can give it a try |
| 20:29.14 | Jayce^ | yeah, you could do this with a map block, and just put results in a hash, tally as it maps them... |
| 20:29.37 | Jayce^ | if space becomes a concern, tie the hash to a dbm... you'll be writing it out then, not all in memory |
| 20:29.44 | Jayce^ | very simple that way |
| 20:29.46 | graphyx | hey, can anyone give me a hand? |
| 20:29.59 | graphyx | I have a script that was compiled on debian using glibc2.0 |
| 20:30.08 | graphyx | I have debian running glibc2.4 |
| 20:30.09 | levi | Jayce^: Touching disk could possibly make the efficiency even worse than a linear search. |
| 20:30.12 | graphyx | how can I compile it? |
| 20:30.33 | atoponce | do i need to sort before the hash? |
| 20:30.37 | levi | atoponce: Nope. |
| 20:30.51 | levi | Hashes have an undefined order. |
| 20:30.52 | ^Migs^ | I swear, this new guy has no idea how to Google for anything |
| 20:30.53 | Jayce^ | levi, just mentioning it as an option if the memory becomes a primary concern... |
| 20:31.04 | findlay | if you got your fingerprint on the disk you'd be worrying about more than atimes |
| 20:31.07 | Jayce^ | but even with 500k records, there shouldn't be... just phone numbers.. |
| 20:31.09 | levi | Jayce^: Yeah, this is true. |
| 20:31.32 | levi | Jayce^: Although each line of file2.txt seems to have at least 1394 characters. |
| 20:31.36 | Jayce^ | and you can use an IXhash to enforce order |
| 20:31.51 | Jayce^ | levi, yeah, but he doesn't seem to care about that data, he's not storing that.. |
| 20:31.57 | atoponce | levi: yeah. these text files get huge |
| 20:32.01 | Jayce^ | you can parse that out, dealing with a line at a time... |
| 20:32.10 | levi | atoponce: Just be sure you only store the information you need in the hash, not the whole line. |
| 20:32.18 | Jayce^ | just don't parse with substr... bad idea |
| 20:32.22 | atoponce | levi: yeah. that's what i would think |
| 20:33.07 | Jayce^ | tonight |
| 20:33.10 | Jayce^ | mt |
| 20:33.19 | atoponce | Jayce^: what other parsing options do i have? |
| 20:33.37 | Jayce^ | regex, unpack.. |
| 20:33.44 | atoponce | ahh. okj |
| 20:33.53 | Jayce^ | since you are doing a specific width, unpack would be very fast for you |
| 20:33.57 | Jayce^ | the best option in that case |
| 20:34.05 | levi | Jayce^: Why is perl's substr so bad? |
| 20:34.35 | Jayce^ | it's not *so* bad, just compared to other options.. |
| 20:34.51 | Jayce^ | buffers, checkpoints, etc.. |
| 20:35.26 | Jayce^ | with unpack you have a compiled fixed pattern that doesn't need as many saves/checks.. would run very fast.. |
| 20:35.34 | atoponce | levi: Jayce^: thx for your help. i think i know where to go from here. when finished, i'll pastebin, and see how i did |
| 20:35.45 | atoponce | if you don't mind |
| 20:35.47 | Jayce^ | k |
| 20:35.47 | levi | atoponce: Sounds good. |
| 20:36.14 | Jayce^ | we'll show you a version then too, I've been too busy jumping channels for work to do one here.. |
| 20:36.17 | levi | Jayce^: Why would substr be slow? |
| 20:37.56 | Jayce^ | optimization of the underlying code.. |
| 20:38.11 | Jayce^ | substr is designed for data modification in essence.. |
| 20:38.14 | atoponce | use the phone as the key and the line #, not the whole line itself, as the value? |
| 20:38.22 | Jayce^ | unpack is just pulling the data you want. |
| 20:39.06 | levi | atoponce: If the line number is all you need to keep, then yes. |
| 20:39.25 | Jayce^ | do you need the line number, or just the phone number and a count? |
| 20:39.56 | atoponce | well, in that case, just a count. but in most cases, the whole line |
| 20:40.01 | levi | Jayce^: substr is generally used for assignment? |
| 20:40.06 | Jayce^ | yes |
| 20:40.26 | levi | substr($_, 0, 5) = "12345" ? |
| 20:40.39 | Jayce^ | no... |
| 20:41.53 | atoponce | $myHash{'$phone'}='$_'; ? |
| 20:42.11 | levi | atoponce: That's storing the whole line. |
| 20:42.29 | atoponce | right. if i wanted to do that |
| 20:42.34 | Jayce^ | and don't have the single quotes in there |
| 20:43.02 | Jayce^ | non-interpolated |
| 20:43.02 | atoponce | ahh. ok |
| 20:43.26 | levi | Jayce^: I'm still trying to figure out what you meant about substr being used for assignment. |
| 20:44.28 | Tene | i thought that substr *could* be an lvalue... |
| 20:46.54 | levi | Now that I've looked it up, the perldocs think so too, though one of the examples of such is listed as a fatal error. |
| 20:47.56 | levi | I guess that's since it's trying to assign to a value outside of the original string. |
| 20:48.28 | levi | Anyway, I guess that extra machinery could indeed make it less efficient. pack and unpack are so darned ugly, though. :/ |
| 20:48.42 | levi | Bleah, perl. |
| 20:50.35 | Tene | Hmm. |
| 20:50.37 | Jayce^ | I think unpack can be very easy given what he would be doing.. |
| 20:50.51 | *** join/#utah pmcnabb_ (n=peter@128.187.160.214) |
| 20:50.52 | Jayce^ | he wouldnt' be doing any fancy extended format tests/etc |
| 20:50.59 | Tene | What's the reason for having a minimum username length? |
| 20:51.31 | Tene | I sometimes run into sites that think a four-letter username is too short. |
| 20:51.45 | ^Migs^ | security |
| 20:52.06 | levi | Before you can start guessing passwords, you have to guess usernames. |
| 20:53.21 | Tene | bah. |
| 20:53.36 | ^Migs^ | uh, no, not "bah." |
| 20:53.41 | *** join/#utah elg (n=fugalh@falcon.fugal.net) |
| 20:53.41 | ^Migs^ | It's a good security feature. |
| 20:54.10 | Tene | Your face is a good security feature. |
| 20:55.29 | ^Migs^ | Your mom is my security feature |
| 20:55.47 | Tene | My mom's face. |
| 20:55.57 | tensai | your face is a good punching bag |
| 20:56.05 | levi | Jayce^: It seems unfortunate to me that one would have to rely on a complex function like unpack just to efficiently get a substring. |
| 20:56.11 | Tene | I don't have a face. |
| 20:56.57 | Jayce^ | levi, as I said, substr isn't bad, just not as efficient as readonly, especially in a looped readonly matter |
| 20:57.15 | Jayce^ | s/readonly/unpack |
| 20:57.22 | Jayce^ | often use those two together |
| 20:59.52 | atoponce | what would be the syntax for unpack in that example? |
| 21:05.03 | levi | Beats the heck out of me. I don't want to read a 10-page manual for a single function in a language I don't even like. ;) |
| 21:05.18 | ^Migs^ | http://news.yahoo.com/s/nm/20061215/od_nm/usa_government_survey1_dc |
| 21:05.21 | ^Migs^ | WASHINGTON (Reuters) - In news bound to surprise absolutely no one, a survey released on Friday found that the U.S. government agency that prints money is better liked than the agency that collects it. |
| 21:05.29 | ^Migs^ | who tf gets paid to do these surveys? |
| 21:05.41 | levi | atoponce: But, hint, you'll find the actual documentation in the perldoc for pack, not unpack. |
| 21:07.47 | SB1-Laptop | I'm convinced that the further north you drive on I-15 (read: Ogden area), the worse the drivers become |
| 21:07.47 | atoponce | levi: yeah. wast just looking at it. i'm not 100% sure that's what i want. i would think substr() would be okay. after all, regex would be a nightmare, and pack/unpack may be more than what i need |
| 21:07.54 | *** join/#utah jsmith (n=jsmith@dsl017-122-217.mci1.dsl.speakeasy.net) |
| 21:08.02 | levi | atoponce: Just use substr and worry about optimizing later if it's not fast enough. |
| 21:08.19 | atoponce | SB1-Laptop: i won't argue with that. especially logan area... :) |
| 21:08.41 | levi | atoponce: It's going to be a small constant factor anyway; not a big deal. |
| 21:08.41 | SB1-Laptop | atoponce, I had to drive a check from basically 33rd south and I-15 up to .... |
| 21:08.49 | SB1-Laptop | City, begins with an S, north of Layton.. |
| 21:08.55 | ^Migs^ | seriously, what insight can you glean from that kind of survey? |
| 21:09.10 | atoponce | SB1-Laptop: :) |
| 21:09.19 | SB1-Laptop | Either way, with every passing mile as I went north, it got progresively worse |
| 21:09.31 | SB1-Laptop | On the way back, I got back on I-15 |
| 21:09.41 | atoponce | and to think that i make the commute from ogden to slc and back every day... :) |
| 21:09.53 | SB1-Laptop | Second onramp I passed, I watched four cars accelerate to 80mph, move all the way over to the left lane, and then drop down to 60mph |
| 21:10.01 | SB1-Laptop | And the far right lane was _completly empty_ |
| 21:10.09 | ^Migs^ | they probably got hundreds of thousands of dollars to conduct that survey, and pocketed 90% of it |
| 21:10.16 | Jayce^ | atoponce, my $record_layout = '@1384 A10'; # a format to read from position 1384, 10 characters ascii |
| 21:10.16 | ^Migs^ | <PROTECTED> |
| 21:10.37 | Jayce^ | then just 'my $var = unpack $record_layout, $data; |
| 21:11.11 | SB1-Laptop | atoponce, I'm not sure if I should feel sorry for you, or question your intellect :) |
| 21:12.35 | ^Migs^ | maybe some senators had some sort of debate one night at a bar |
| 21:12.43 | atoponce | Jayce^: is $data special in that example? |
| 21:13.02 | ^Migs^ | that sounds like SNL sketch potential |
| 21:13.26 | Jayce^ | atoponce, no, just a variable,, $_, $a_value, $stuff |
| 21:13.26 | levi | atoponce: $data is just $_ from your example. |
| 21:13.38 | atoponce | ah. i see |
| 21:13.40 | atoponce | ok |
| 21:14.26 | atoponce | 0-based, i'm assuming |
| 21:26.32 | levi | Here's some art for you guys: http://www.sandysmith.co.uk/artwork/computers/sunset.htm |
| 21:29.18 | atoponce | wow. talk about fire hazard |
| 21:30.06 | atoponce | i can't even begin to imagine the amount of the electricity bill. :) |
| 21:30.12 | atoponce | cool though |
| 21:31.41 | ^Migs^ | probably no more than your average junior high school computer lab |
| 21:34.19 | levi | Lawrence Livermore Nat'l Lab spends over $1mil per month on electricity. |
| 21:37.10 | ^Migs^ | wow no one cares |
| 21:37.20 | ^Migs^ | nah, just kidding |
| 21:37.23 | ^Migs^ | that's INTERESTING |
| 21:43.46 | findlay | heh |
| 21:43.53 | findlay | I wonder what Fermilab spends |
| 21:43.55 | findlay | or CERN |
| 21:46.40 | ^Migs^ | I wish we worked 7 days a week, and never got a day off, but we just worked shorter days. |
| 21:46.58 | findlay | although CERN probably doesn't have the computational power of LLNL, they have the worlds largest *and* most powerful particle accelerator *and* the world's largest data farm |
| 22:21.58 | levi | Oh, geez, this is totally insane: http://www.intelib.org/intro.html |
| 22:28.34 | ^Migs^ | ur face is insane |
| 22:29.32 | ^Migs^ | actually, that IS insane |
| 22:31.43 | mrpull | ^migs^: i like what some shift workers do. 3 12's on, 4 days off, 4 12's on 3 days off |
| 22:32.22 | Jayce^ | levi, it's as if Damian was back doing C++ |
| 22:32.53 | levi | I should show that to calvarez. ;) |
| 22:34.06 | ^Migs^ | see, now, I could do that |
| 22:34.38 | mrpull | just the time saved commuting would add up quickly |
| 22:34.55 | mrpull | which reminds me of some nerd that used his vacation based on traffic conditions |
| 22:34.58 | findlay | no way, not me |
| 22:35.09 | mrpull | he figured he could save a day or so a year |
| 22:35.13 | findlay | unless it's something I enjoy doing |
| 22:35.57 | mrpull | here is it is: http://www.omninerd.com/2006/04/21/articles/50 |
| 22:37.22 | mrpull | The best bet appears to be moving my schedule out a half-hour to 8:30AM and 6:00PM, bringing significant savings (about 7.5 minutes of commute time per day) without getting too far from normal business hours. Spread out over 50 work weeks, that results in a total savings of over 30 hours a year - the equivalent of about a 38% boost to my existing 80 hours of vacation. |
| 22:37.45 | mrpull | i like that guy. how much time did he spend on this study? |
| 22:37.52 | mrpull | probably more than 38 hours |
| 22:40.20 | findlay | how does the time he saves from commuting add to his vacation time? |
| 22:40.39 | mrpull | it doesn't |
| 22:40.45 | mrpull | but he has more free time |
| 22:40.49 | mrpull | and he values that |
| 22:41.10 | findlay | but why does he say it boosts his existing vacation time? |
| 22:41.32 | mrpull | he says it is equivalent to a 38% boost |
| 22:41.44 | findlay | non-commute,non-work time == vacation time? |
| 22:42.12 | macnewbold | or in some jobs, extra time working rather than commuting == more vacation time when you want to take time off of work |
| 22:42.41 | mrpull | macnewbold: true. i used to accrue vacation based on hours worked. |
| 22:42.52 | macnewbold | that's how it works in my office too |
| 22:43.16 | mrpull | macnewbold: unfortunately I only work "40 hours" every week now :( |
| 22:43.42 | mrpull | for various definitions of 40 hours |
| 22:44.12 | macnewbold | then working >8 hrs on some days means you can try to arrive a little late or leave a little early once or twice a week and still get "40 hours" in |
| 22:44.13 | levi | Yow, someone is singing long really poorly with the music in their headphones. |
| 22:44.26 | findlay | haha |
| 22:44.39 | maquis | levi: you could walk up to them and tell them... |
| 22:44.53 | macnewbold | or cat /dev/urandom > /dev/audio on their machine... |
| 22:44.58 | macnewbold | or for more fun, |
| 22:45.06 | macnewbold | cat /dev/mouse > /dev/audio & |
| 22:46.19 | findlay | or `ssh root@singer: "/sys/sound/mixer/volume = 1024"` |
| 22:46.43 | macnewbold | nice |
| 22:47.07 | ^Migs^ | <mrpull> ^migs^: i would have pegged you as an anti-christmas guy |
| 22:47.07 | ^Migs^ | <mrpull> esp anti-christmas-music guy |
| 22:47.26 | ^Migs^ | okay, I just noticed that from yesterday. Imo, you have to be a real jerk not to like Christmas music |
| 22:47.35 | ^Migs^ | thank you, that is all |
| 22:47.38 | findlay | ~jerk |
| 22:47.40 | ibot | well, jerk is someone who needs something to do. |
| 22:48.01 | findlay | ibot: no jerk is the derivative of acceleration with respect to time |
| 22:48.02 | ibot | okay, findlay |
| 22:48.22 | redbeard1 | ~no |
| 22:48.23 | ibot | YES |
| 22:48.28 | redbeard1 | ~jerk |
| 22:48.30 | ibot | jerk is, like, the derivative of acceleration with respect to time |
| 22:48.34 | findlay | ibot: jerk is also da/dt |
| 22:48.35 | ibot | ACTION suddenly yanks on the leash around is also da/dt's neck |
| 22:48.43 | findlay | whatever |
| 22:49.13 | redbeard1 | ~yes |
| 22:49.14 | ibot | You don't say! |
| 22:49.34 | findlay | ibot: in uniform circular motion the jerk is constant as are all derivatives of s with respect to t |
| 22:49.35 | ibot | that's too long, findlay |
| 22:49.45 | findlay | ibot: no it isn't |
| 22:49.58 | findlay | ibot: no it is not |
| 22:49.59 | ibot | findlay: I think you lost me on that one |
| 22:50.04 | findlay | ~no it |
| 22:51.56 | *** join/#utah [phoenyx] (n=tthorley@64.147.152.13) |
| 22:52.39 | mrpull | ^migs^: whoa... how's that for IRC latency? |
| 22:52.55 | findlay | ^Migs^ is latent? |
| 22:53.01 | findlay | ~dict latent |
| 22:56.32 | mrpull | ^migs^: Even with your assertion that only jerks don't like Christmas music... I still figure you wouldn't like Christmas music :) |
| 22:56.50 | ^Migs^ | well, I do like Christmas music |
| 22:57.20 | ^Migs^ | granted, I'm getting a little tired of hearing it right now since it keeps starting earlier and earlier each coming year, but I think Christmas music is one of the best genres |
| 22:58.48 | ^Migs^ | I just mentioned it because I had gone home for the day but didn't bother shutting down my IRC client. Like I'm about to do now. |
| 22:59.25 | *** part/#utah ^Migs^ (i=Migs@205.122.50.21) |
| 23:04.17 | *** part/#utah SB1-Laptop (n=Death@about/pxe/ScytheBlade1) |
| 23:06.20 | atoponce | does the hash key have to be unique? |
| 23:10.03 | macnewbold | that often helps |
| 23:10.10 | macnewbold | otherwise you need some collision resolution policy |
| 23:12.24 | atoponce | ok. cool. i was trying to figure out how to handle it otherwise. |
| 23:12.25 | atoponce | thx |
| 23:13.16 | macnewbold | there are many ways to handle collisions |
| 23:13.24 | macnewbold | it depends how you're making your hash |
| 23:13.27 | macnewbold | and how likely collisions are |
| 23:13.43 | macnewbold | generally, if you use something like md5, you can just barf if you ever get a collision |
| 23:13.52 | macnewbold | cause it isn't likely to happen in your lifetime |
| 23:14.18 | macnewbold | if you're using something else, where collisions will happen, one strategy is to make each bin in the hash table a list of item |
| 23:14.19 | macnewbold | s |
| 23:14.29 | macnewbold | all of which have the same hash |
| 23:16.40 | atoponce | oh, hehe. i'm referring to an associated array |
| 23:16.42 | atoponce | :) |
| 23:16.52 | atoponce | in perl |
| 23:17.54 | macnewbold | nice |
| 23:18.03 | macnewbold | they'll be unique then |
| 23:18.14 | macnewbold | if you try to put in something else with that key, it will overwrite it |
| 23:18.28 | macnewbold | so if you don't want that, make each entry in %hash be a @list |
| 23:18.32 | atoponce | ok. makes sense. |
| 23:18.35 | macnewbold | hopefully most of which will have only one $value in them |
| 23:18.45 | atoponce | right |
| 23:22.37 | levi | Very interesting use of OCaml: http://www.venge.net/graydon/talks/mkc/html/mgp00001.html |
| 23:37.49 | *** join/#utah RedHatJR (n=al@c-24-10-187-164.hsd1.ut.comcast.net) |
| 23:50.07 | *** join/#utah Sargun (n=xbmodder@atarack/staff/sargun) |