[00:47] *** ballen is now known as ballen|away
[05:11] *** heavysixer has joined #arpnetworks
[05:14] *** heavysixer has quit IRC (Client Quit)
[05:34] *** heavysixer has joined #arpnetworks
[07:08] *** visinin has joined #arpnetworks
[07:22] *** heavysixer has quit IRC ()
[09:30] *** heavysixer has joined #arpnetworks
[09:36] *** timburke has quit IRC (Remote closed the connection)
[09:36] *** timburke has joined #arpnetworks
[09:38] *** timburke has quit IRC (Client Quit)
[09:39] *** timburke has joined #arpnetworks
[09:43] *** heavysixer has quit IRC ()
[09:49] *** timburke_ has joined #arpnetworks
[09:49] *** timburke_ has quit IRC (Read error: 104 (Connection reset by peer))
[09:54] *** timburke_ has joined #arpnetworks
[09:55] *** timburke has quit IRC (Read error: 145 (Connection timed out))
[10:06] *** timburke_ is now known as timburke
[11:19] *** ballen|away is now known as ballen
[11:32] *** heavysixer has joined #arpnetworks
[12:26] <ballen> up_the_irons: are you doing authentication in your Sinatra app?
[12:40] <up_the_irons> ballen: no
[12:41] <ballen> hmm looking for the best auth lib for Sinatra
[12:41] <up_the_irons> yeah, dunno
[12:41] * up_the_irons reads scrollback
[12:41] <ballen> one that I can rip apart and make it work on a key/value db
[12:44] <up_the_irons> mhoran: ballen: I could hotplug a drive, sure, but it'll look like USB.  Would rather attach it permanently
[12:44] <up_the_irons> ballen: mhoran: KVM supports memory ballooning
[12:44] <ballen> ah, was just thinking of a case where running a site that couldn't be brought down
[12:44] <ballen> and running out of storage
[12:44] <up_the_irons> ballen: for a live migration, the host and target must be running the exact same VM parameters
[12:45] <ballen> yea I figured that out after I said it
[12:45] <up_the_irons> ballen: it doesn't make sense for the HD to be larger anyway, b/c all live migration implementations require the disk to actually be shared (same disk)
[12:46] <ballen> ah right
[12:47] <ballen> bleh be so much easier than designing an app to be able to migrate live across servers
[12:47] <up_the_irons> mhoran: ballen: I'm working on live migrations across regions as well (first step: migrate into a different data center within the same city, then try into a different metro region)
[12:49] <ballen> thats hot
[12:50] <up_the_irons> the hardest part, actually, i just getting the live migration from machine to machine;  once that is done, data center to data center is not that hard, b/c if it is seen as the same network anyway, the servers don't care that they are in the same cabinet 2 ft away, or thousands of feet away
[12:50] <ballen> right
[12:51] <up_the_irons> fyi, you wouldn't use a single VM for a site that couldn't experience a lot of downtime, that'd be scaling vertically; which is generally bad.  if your site really can't be down, you'd build a cluster for it
[12:51] <ballen> yes yes
[12:52] <ballen> just alot easier to program for scalling vertically
[12:52] <ballen> but much more expensive
[12:52] <up_the_irons> sure, cause we've all grown up programming for vertical platforms
[12:52] <up_the_irons> we're "used" to it
[12:53] <ballen> yea
[12:53] <up_the_irons> i imagine the next generation will have an easier time w/ clustering, or building an app that scales horizontally
[12:53] <ballen> I hop so
[12:53] <ballen> hope*
[12:53] <ballen> assuming education adapts
[12:53] <ballen> which it is normally slow todo
[12:54] <up_the_irons> most coders don't learn their chops through formal education anyway though
[12:54] <up_the_irons> i didn't either
[12:54] <up_the_irons> but i still stayed in school
[12:54] <ballen> yea likewsie
[12:54] <ballen> likewise
[12:54] <up_the_irons> cuz it's important on so many levels
[12:54] <up_the_irons> :)
[12:57] *** timburke has quit IRC (Read error: 54 (Connection reset by peer))
[12:57] *** timburke_ has joined #arpnetworks
[12:57] <ballen> http://gist.github.com/40246
[12:57] <ballen> If i rip datamapper out and replace it with Redis goodness that'll due
[12:59] <up_the_irons> looks promising
[13:09] *** ballen is now known as ballen|away
[13:51] <up_the_irons> i hate rspec
[13:51] <up_the_irons> i used to like it, but now, i fucking hate rspec
[13:52] <up_the_irons> it won't run any specs
[13:52] <up_the_irons> nothing
[13:52] <up_the_irons> nada
[13:52] <up_the_irons> just returns to the prompt silently
[13:57] <mhoran> up_the_irons: Cool, cool and cool.
[13:57] <up_the_irons> heh
[13:58] <mhoran> They're building out some cool clusters at my alma mater.
[13:58] <mhoran> There's actually one there now which just idles. Unfortunate.
[13:59] <mhoran> But there's a new prof working in bioinformatics, they had to buy a new CRAC unit to accomodate his cluster.
[13:59] <mhoran> Pretty exciting. They also were planning to hire a dedicated cluster sysadmin, but I think they ran out of money.
[14:00] <mhoran> Unfortunately, all but two people on that staff, including the manager, are idiots.
[14:11] <up_the_irons> cool, and not cool
[14:11] <up_the_irons> cd $food
[15:03] *** heavysixer has quit IRC ()
[16:05] *** heavysixer has joined #arpnetworks
[17:05] *** heavysixer has quit IRC ()
[17:28] *** heavysixer has joined #arpnetworks
[17:33] *** ballen|away is now known as ballen
[18:37] *** ballen is now known as ballen|away
[19:18] *** ballen|away is now known as ballen
[19:27] *** heavysixer has quit IRC ()
[19:58] *** heavysixer has joined #arpnetworks
[20:00] *** ballen is now known as ballen|away
[20:07] *** heavysixer has quit IRC ()
[20:53] *** ballen|away is now known as ballen
[22:50] *** timburke_ has quit IRC ("Leaving")
[22:55] *** timburke has joined #arpnetworks
[23:10] *** visinin has quit IRC ("sleep")
[23:27] <ballen> http://ohm.keyvalue.org/
[23:27] <ballen> only the most freaking cool library ever
[23:27] <ballen> going to save me sooo much time on this project
[23:37] <up_the_irons> ballen: nice
[23:37] <ballen> don't have to figure out all my key/value schema now
[23:37] <ballen> even though I already do have that figured out
[23:37] <ballen> it'll take less code now
[23:38] <ballen> also trying to get authlogic to work with Sinatra
[23:39] <up_the_irons> is what you're building online anywhere?
[23:40] <ballen> nah just starting to plan it out
[23:40] <ballen> really should be working on my thesis
[23:40] <ballen> but meh
[23:42] <up_the_irons> haha
[23:43] <ballen> seems like authlogic depends on active_record a little bit
[23:43] <ballen> which sucks
[23:43] <up_the_irons> eeeww
[23:43] <up_the_irons> f that
[23:44] <ballen> yea
[23:44] <ballen> so I may just stick with home brew auth
[23:44] <ballen> for now
[23:44] <ballen> and build it out if needed
[23:44] <up_the_irons> ballen: so does this Ohm basically let you store ruby objects inside Redis?
[23:44] <ballen> umm
[23:44] <ballen> its basically lets you work with models as you would in Rails
[23:45] <up_the_irons> gotcha
[23:45] <ballen> class User < Ohm::Model
[23:45] <ballen>   attribute :login
[23:45] <ballen> end
[23:45] <ballen> now the User model has an login attribute
[23:45] <ballen> when you save the model
[23:46] <ballen> you can only access it by id
[23:46] <ballen> say you want to access it by login
[23:46] <ballen> you add index :login
[23:46] <ballen> now you can do User.find(:login, 'name')
[23:47] <ballen> index creates a Set
[23:47] <ballen> where attribute is just a single hash in the db
[23:48] <ballen> also could add something like set :admins, Admin
[23:49] <ballen> and now you'd have @user.admins
[23:49] <up_the_irons> interesting
[23:49] <ballen> similar to rails
[23:49] <ballen> all its doing its creating new sets in the backgroud so it can index the data in a way that lets you search for it
[23:50] <ballen> so each time you add an index or set its add a decent amount of duplicate db to db
[23:50] <ballen> duplicate data to the db*
[23:50] <ballen> but such is life with key/value db's
[23:51] <up_the_irons> right
[23:51] <up_the_irons> so like "index :login", creates a key that is "login" with value that is an id, that then let's you look up "User"
[23:52] <ballen> exactly
[23:52] <ballen> theres also list and counter
[23:53] <up_the_irons> ah
[23:53] <ballen> list is not indexable
[23:53] <ballen> either FIFO, FILO, etc
[23:53] <ballen> counter is just a serial data type
[23:54] <ballen> cool thing about counters in redis is that they're atom, you don't have to worry to much about multiple clients incr or decr
[23:59] <ballen> SHA512 enough for password hashing?