--- Log opened Mon Nov 25 00:00:06 2013
00:41 < gavinandresen> cfields: hmm?
00:42 < cfields> gavinandresen: I have a working POC for deterministic dmgs built from linux. I need a bit of group-think on how to proceed. Suggestions?
00:43 < cfields> POC in that the process is ugly. The result seems stable.
00:43 < gavinandresen> what makes the process ugly?
00:44 < cfields> gavinandresen: mainly patching the shit out of qt/boost to get it built cross-arch cross-platform
00:44 < gavinandresen> mmm. That IS ugly.
00:44 < gavinandresen> Hard to review, hard to be sure the patches are correct....
00:45 < cfields> gavinandresen: well, they're 99% taken from macports...
00:45 < cfields> so the argument really isn't valid, it's just been covered up until now
00:45 < cfields> so before going further, i'd like some kind of concensus on the goal. Namely: Should it aim to be useful for everyday building? Or aim for gitian release builds only?
00:46 < gavinandresen> release builds only, in my opinion.  And maybe pull-tester builds.
00:46 < gavinandresen> I'm certainly not going to cross-compile in a linux VM to develop
00:46 < warren> I test gitian builds in dev all the time, personally.
00:46 < cfields> sure, pull-tester was the main target i had in mind
00:47 < warren> cfields: are all the static libs built into a deterministic deps tarball to use as an input?
00:47 < cfields> warren: not currently, but it'd be simple to get em to that point
00:48 < warren> cfields: that would help substantially
00:48 < gavinandresen> cfields: if it helps, I think it is time to drop 32-bit and OSX 10.5 support.
00:48 < gavinandresen> Maybe even drop 10.6 support.
00:49 < cfields> I'd be pretty opposed to dropping 10.6, but 10.5 and 32bit i would agree with
00:49 < cfields> but that's tangential to this discussion, neither of those added any complication to this process
00:49 < gavinandresen> ok
00:50 < gmaxwell> cfields: I am advised that 10.9 has been backported to * and was also advised that if we wanted anyone at apple to care we'd need to be on at least 10.7 and building in 64 bit.
00:50 < warren> * ?
00:51 < cfields> gavinandresen: i suppose i'm just looking for a bit of guidance as to how to proceed. It works, but it's ugly. If it's only for gitian, ugly doesn't really matter.
00:51 < cfields> I suppose I should re-define ugly. qt/boost are heavily patched either way. It's either macports or homebrew or us.
00:52 < cfields> so ugly means: a nasty build-script that either completes or fails gloriously
00:52 < gavinandresen> … and relies on a very specific version of boost/qt, I assume?
00:52 < cfields> well I used the versions that macports use, so we could borrow their patches
00:53 < gavinandresen> That doesn't sound horribly ugly…  just document the process of upgrading.
00:54 < cfields> Sure. It's the same as upgrading any other gitian deps. Just on a bigger scale for osx.
00:55 < cfields> gavinandresen: this probably explains better than me rambling about it: https://github.com/theuni/bitcoin/commit/8a64fb98370ccc299d73111bbf97cdde23f681b1
00:55 < jgarzik> is there an OSX that works in VM?
00:55 < jgarzik> that would be useful
00:55 < cfields> jgarzik: none legally, so it tends to be avoided if it's done publicly
00:55 < cfields> (build-slave, pull-tester, etc)
00:56 < gavinandresen> cfields: can we avoid putting all those patches in our tree?  Maybe run a script to fetch them from macports ? (with just the macports public key in our tree)
00:58 < cfields> gavinandresen: if that's what you'd prefer, but seems that would only make it more complicated?
00:58 < cfields> I suppose your goal is to differentiate between our changes and theirs?
00:59 < gavinandresen> yes, if we are going to extend trust to MacPorts then better to make it explicit.
00:59 < gavinandresen> (if we are going to CONTINUE to extend trust....)
00:59 < cfields> i wasn't going to say it ;)
01:00 < warren> jgarzik: older versions of osx run in a heavily hacked kvm
01:00 < warren> jgarzik: it's quite a pain
01:00 < warren> jgarzik: I found it easier to buy an old macbook with a broken screen, put it into a data center and ssh->vnc in
01:00 < gavinandresen> I asked Apple developer support about building in a VM, and they basically said "No."
01:01 < cfields> gavinandresen: ok. I'm happy to clean up and document the patching process. Atm it's just one hammer after another, just wanted to get the thing built/working
01:01 < jgarzik> heh
01:02 < cfields> gavinandresen: but ofc that hinges on whether or not you think the goal is useful. If it's deemed not worth the hassle, obviously there's no sense in continuing
01:03 < gavinandresen> cfields: we're on the ragged edge of what we can support with the developers we've got right now, in my humble opinion.
01:03 < gavinandresen> Adding another build environment…. mmmm.
01:03 < cfields> hehe, my writing makes me sound so dickish. the above translates to: "think it's worth pursuing?"
01:04 < cfields> gavinandresen: well there is no new environment really. It's just existing environments doing cross-builds
01:04 < gavinandresen> In the grand scheme of things, gitian building gives geeks the warm fuzzies, but doesn't matter diddly-squat to end users.  Who are using lightweight wallets anyway.
01:07 < cfields> gavinandresen: given that line of reasoning, there's no need to do linux releases if distros are handling them.
01:07 < phantomcircuit> cfields, oh god no
01:08 < gavinandresen> A good test for whether it is worth continuing:  I think we should switch to qt5 for the 0.9 release.  How much extra work to get the osx gitian build working?  Could anybody besides you do it in a reasonable amount of time?
01:08 < cfields> Not arguing one way or another, but that seems at odds with current development
01:08 < phantomcircuit> the distros are NOT handling them
01:08 < warren> cfields: the distros are really messing it up
01:09 < cfields> heh, just evaluating data-points. I'm not suggesting anything at all
01:09  * gavinandresen notices there is no qt5-mac yet in macports….
01:10 < cfields> gavinandresen: i have qt5 up and running on my macbook somewhere
01:10 < cfields> taken from the binary release
01:10 < gavinandresen> cfields: me too!  Not using it because autotools.....
01:11 < cfields> gavinandresen: heh, 9235th hint received
01:11 < cfields> gavinandresen: i was planning to knock that out after the dmg. seems i got my priorities reversed.
01:11 < warren> cfields: there's a 200 unit bounty!
01:11 < gavinandresen> mmm.  It is always a question of priorities:  gitian-built OSX is a would-be-nice for me, not a priority.
01:12 < gavinandresen> qt5 is a priority, because there's a nasty bug in the payment protocol on Windows that is fixed by qt5
01:12 < cfields> gavinandresen: well i resigned from my job and there's a sizeable bounty for the dmg. So in this case the priority was food and shelter :)
01:13 < cfields> gavinandresen: what's the timeline for .9 release?
01:13 < gavinandresen> cfields: Release candidate sometime in January… I hope
01:13 < jgarzik> 1 day
01:13 < jgarzik> +/- 100% error factor
01:14 < jgarzik> headers-first sync doesn't seem to be moving?
01:14 < jgarzik> or did I miss something
01:14 < gavinandresen> headers-first sync isn't a showstopper feature for 0.9
01:14 < gavinandresen> … it is on my 'nice-to-have' priority list, too.
01:14 < gavinandresen> (way up near the top of that list)
01:14 < gmaxwell> this should probably be in #bitcoin-dev
01:15 < cfields> gavinandresen: if qt5 is that much of a necessity, i can switch gears and get it knocked out this weel
01:15 < gavinandresen> yup
01:15 < cfields> *week
01:15 < cfields> i was under the impression it was just a shiny new toy to play with
01:17 < gavinandresen> cfields: yes, please! qt5 is necessary for 0.9....
01:20 < cfields> gavinandresen: ok. I suppose win32 is top priority, then?
01:21 < cfields> gavinandresen: given that it may cause headaches in linux/osx due to it being new and relatively unpackaged, it'd probably be best to attack it in chunks
01:21 < cfields> meaning: push in support for win32 before it's supported across the board
01:34 < gavinandresen> cfields: okey dokey
01:50 < warren> gavinandresen: what in particular about 10.7 and "anyone at apple to care"?
04:09 < michagogo|cloud> 5:14:50 <cfields> ok, great. So if anyone else want to try to build with gitian, i can provide that file to spare you the trouble
04:10 < michagogo|cloud> Erm, is that file legally redistributable?
05:03 < gmaxwell> I noticed something on the latest surprisingly bad Shamir paper.
05:03 < gmaxwell> ... it was also on the other one, but I didn't notice it there.
05:03 < gmaxwell> Acknowledgments. This research was supported by a research grant provided by the Citi Foundation.
05:05 < TD> huh
05:05 < TD> that is indeed what it sounds like
05:38 < gmaxwell> https://news.ycombinator.com/item?id=6793270
05:40 < TD> yes, i've been wondering what happened to shamir  ....
05:45 < TD> makes me wonder if the R and A carried more of the weight than the S
06:02 < Ryan52> heh, a friend of mine was bragging to me the other day that he knows "the S in RSA", in response to the shirt I wore having "RSA" mentioned on it. I guess that may not count for quite as much as he had hoped now. :)
07:18 < Emcy> citi foundation you say
07:18 < Emcy> as in the bank
07:18 < gmaxwell> As in the bank.
07:19 < Emcy> guess were past the laughing at us stage then
07:20 < Emcy> you should see some of the 'papers' on filesharing which various Ass. of America groups have bankrolled
07:21 < gmaxwell> Emcy: did you see me say the same thing on reddit?!
07:21 < Emcy> um no?
07:22 < gmaxwell> Emcy: http://www.reddit.com/r/Bitcoin/comments/1reuwq/vigorous_debate_over_shamirrons_supposedly/
07:22 < Emcy> i stopped going on the bitcoin reddit because it comes across as mainly a huge price pump engine/death to the foundation noticeboard
07:23 < gmaxwell> hah, that about characterizes it, yup.
07:24 < gmaxwell> I'm pretty sure my net karama in that subreddit (and only that one) is negative... because I keep saying edgy things things like "Bitcoin is uncertan and has risks too" :P
07:24 < gmaxwell> Emcy: in any case, see my comment there: http://www.reddit.com/r/Bitcoin/comments/1reuwq/vigorous_debate_over_shamirrons_supposedly/cdmjbze
07:33 < Emcy> nulldc?
07:36 < Emcy> " the existence of a surprising link between the two mysterious figures of the Bitcoin community, Satoshi Nakamoto and DPR."
07:36 < Emcy> oh fuck right off with that shit
07:36 < gmaxwell> yea, its crud.
07:37 < Emcy> this is why satoshi stayed anon, and people still question why
07:37 < gmaxwell> News flash: Two bitcoin users used a common exchange!
07:37 < Emcy> i never knew satoshi ever used an exchange
07:39 < sipa> it's not about satoshi :p
08:15 < wumpus> one of the early adopters used an exchange!
08:16 < gmaxwell> wumpus: someone had to go first!
08:16 < petertodd> Emcy: really remarkable that Satoshi and DPR both used an obscure digital store-of-value system
08:18 < wumpus> hehe
08:18 < Emcy> i bet they both use the toilet too
08:18 < Emcy> half life 3 confirmed
08:19 < petertodd> Emcy: it's going to be sooo weird when it turns out that satoshi was a facehugger
08:19 < gmaxwell> Whats a facehugger?
08:19 < Emcy> what now
08:19 < petertodd> http://static1.wikia.nocookie.net/__cb20080712194334/avp/images/b/bb/Alien-The_Facehugger.png
08:20 < Emcy> and the human is the banks rite
08:20 < petertodd> hehe, yup 
08:20 < Emcy> heh now watch this chatlog get used in congressional testimony as to why bitcoin was designed to be a parasitic force on the great and the good
08:21 < gmaxwell> If the banks were as tough as sigourney weaver they wouldn't need so many bailouts.
08:22 < petertodd> gmaxwell: nah, banks are the alien queen - sigourney weaver is credit unions, and satoshi is the nuke they should have used from orbit...
08:22 < petertodd> ...only way to be sure
08:22 < Emcy> no theyre more like the female lead from the new prometheus film....totally useless but got out of an extremely hairy situation when they really shouldnt have
08:23 < petertodd> Emcy: ha
08:23 < petertodd> Oooooh, there's an alt-coin that hasn't been made yet: HR Giger Coin
08:24 < petertodd> "You're funds are well protected by proof-of-sexual-sacrifice"
08:24 < Emcy> yeah, the logo is an alien dick penetrating some chimera ass
08:24 < petertodd> Brings new meaning to the term "fidelity bond"
08:24 < Emcy> ahuehue
08:36  * gmaxwell checks the channel hes in
09:00 < pigeons> petertodd: sounds like a good additional feature for https://bitcointalk.org/index.php?topic=294383.0;all
09:21 < TD> boggle
09:31 < cfields> michagogo|cloud: by itself, no
09:31 < cfields> michagogo|cloud: you can jump through a series of hoops to get it completely legally
09:31 < cfields> michagogo|cloud: in fact, everyone who has ever built on osx has already done so, it's a requirement
09:50 < jgarzik_> Interesting point by BTC guild op, https://bitcointalk.org/index.php?topic=338452.msg3670185#msg3670185
09:50 < jgarzik_> Makes me want to accelerate my mempool expiration plans
09:53 < TD> or just optimise that algorithm
09:53 < sipa> i started working on a quick patch to use BIP37 full-block-match for block relaying
09:53 < sipa> but it's hard to do know, if we need integration with orphan handling
09:53 < TD> how so ?
09:53 < sipa> implementation reasons
09:54 < sipa> doing that after headers-first is probably much simpler
09:54 < sipa> and safer too, as it will allow validating the header ahead of time
09:54 < TD> maybe you could send the headers-first code you've got to gavin?
09:55 < sipa> the former pull request is public
09:55 < sipa> around christmas i'll have time, i guess :)
10:38 < Emcy> is any pool not capping thier blocks
10:38 < Emcy> i think only eligius?
10:39 < gigavps> my pool caps at 600k with 150k minimum
10:39 < Emcy> why 600
10:40 < gigavps> completely arbitrary
10:41 < gigavps> it was at 350k before, and we rarely create blocks that large
10:41 < gigavps> because of the recent ramp up of the network hashrate and tailing difficulty
10:42 < Emcy> see id have though most miners are actually pools where the node is in hosting of at leat 100mbit
10:43 < Emcy> so surely just pumping out 1mb blocks wont make relatively jack shit difference to orphan rate
10:43 < Emcy> specifically orphan rate due to fat blocks, instead of normal orphan rate due to sods law
10:43 < Emcy> if such a thing can even be measured
10:47 < jgarzik_> You don't just push out the block once, if you are a miner creating one
10:48 < Emcy> well really how many uploads does it take to seed into the network
10:49 < gigavps> Emcy jgarzik is saying that you push the block to every node you are connected to. so if you are connected to 125 nodes, then it is 125 * blocksize
10:49 < Emcy> maybe 3 or 4 to diverse subnets until it flood nicely?
10:49 < Emcy> how many sockets does a pool node usually have
10:51 < gigavps> Emcy we have many pool nodes
10:52 < Emcy> ok say top ten pools youre pushing to
10:52 < Emcy> thats just over a second even at the minimum of 100mbit right
10:58 < Emcy> oh theres something on the list about someone got some actual metrics about it. and im here on irc pulling numbers out of my ass
10:58 < Luke-Jr> gigavps: coming to the meetup?
10:58 < gigavps> what meetup?
10:58 < Luke-Jr> gigavps: same as last year, but in Brooksville!
10:59 < gigavps> probably won't make it, have a lot going on
11:00 < Luke-Jr> aww
11:00 < Luke-Jr> if you leave now you might make it in time!
11:00 < Luke-Jr> <.<
11:01 < gigavps> ahhh
11:01 < gigavps> thanks for letting me know
11:01 < Luke-Jr> XD
11:01 < Luke-Jr> next year we'll have to plan more in advance
11:06 < Luke-Jr> looks like forrestv is MIA anyway
11:53 < cfields> Ryan52: ping
12:30 < Ryan52> cfields: pong
18:22 < gmaxwell> Did I kill the thread here, or what? https://bitcointalk.org/index.php?topic=346008.0
18:25 < gmaxwell> maaku: when you get a chance, please help me understand how you think we can MMR a spent token database. I'm not getting it.
18:25 < gmaxwell> mmring a unspent token database is easy, because its naturally append only.
18:26 < maaku> it isn't append-only like peter's MMR
18:26 < maaku> it's an ordered tree of spent tokens
18:27 < gmaxwell> oh and you know your token ID in advance, so you know what part of the tree you need to maintan a proof for, even before you spend?
18:27 < maaku> to insert, you provide the path to where the spent token would go (demonstrating that the token has not been used)
18:27 < maaku> -- yes
18:28 < maaku> so you watch spends as they go by and update accordingly
18:28 < gmaxwell> Sorry, I don't know why that wasn't obvious to me 10 minutes ago. I've got it now.
18:28 < gmaxwell> Yea, that would work. Okay we really can oursource all these costs.
18:29 < gmaxwell> though we can't shrink the tree, any such system is going to have to be able to cope with a potentially very tall tree. (to some extent thats okay, the ZKP stuff really wants you to set the circuit execution time in advance)
18:31 < gmaxwell> The unspent token side has the nice property that its truly append only and write once, so tracking the proofs is really cheap. Alas we can't get that for the other side.
18:34 < maaku> yeah
18:35 < maaku> There is some small messiness, namely that proofs have to be updated for *every* spend in the series (although, 50% of the time it only requires modifying the top level, 25% the top two levels, etc.)
18:35 < gmaxwell> Is there a way to privately start tracking the required proof up front that doesn't require having the whole spent tree?
18:36 < maaku> Miners would have to do that themselves if there is more than one spend in a block.
18:36 < gmaxwell> maaku: I don't think so: I think you could accept a ... right I was about to say that.
18:37 < maaku> Still thinking about your question.
18:37 < maaku> In general, no, I think you would need to replay history
18:38 < maaku> Or otherwise have access to a whole tree
18:38 < maaku> This successfully moves work out of the validator, but is less than ideal in other respects :\
18:39 < gmaxwell> yea, okay, well thats alright, we basically get back to the MMR argument: there is now an economic incentive for people to keep the whole tree: people can show up and say "here is a transaction, and oh it pays you, but its proof is incomplete. Can you help?"
18:39 < maaku> Yeah.
18:39 < gmaxwell> and if you're worried about getting extorted in the future: keep your own copy of the data.
18:39 < gmaxwell> and it means we can pay people to run archive nodes.
18:40 < gmaxwell> and if you only recover the proof right at spent time there is no loss of anonymity.
18:40 < maaku> I can think of some very dumb ways to avoid that which people will undoubtably do and get themselves in trouble
18:40 < maaku> E.g, choose a secret within a range exposed by a recently seen proof, and start updating from there
18:41 < gmaxwell> well, if your token id is required to be the output of a hash function thats a bit hard.
18:41 < maaku> Ah that's true
18:42 < gmaxwell> I'm imaginging a system where your "token"  is actually  sha256(scriptPubkey),coinvalue
18:42 < gmaxwell> e.g. basically a bare p2sh utxo.
18:44 < maaku> Might as well even do that directly: ripemd160(sha256(scriptPubkey)), coinvalue, (4 bytes for something else?)
18:46 < gmaxwell> well maybe, in thinking about improved systems, I think at some point we should probably go to 256 bit security.   Also the size of the unblinded coin isn't important for communicating to someone who wants to pay you, the only time its seen is on spend.
18:47 < maaku> 256-bit security as in 512 bit key/hash sizes?
18:47 < gmaxwell> maaku: well 256 bit security against second preimages. (which only requires a 256 bit output, so long as the hash's state space is large enough)
18:49 < maaku> Not against that in general, but the rest of the system is only 128-bit security, right? Are you in favor of increasing the security bits of the rest of bitcoin too (if possible)?
18:52 < gmaxwell> maaku: well you can more easily change the other things. E.g. adding another checksig operator is easy.
18:52 < gmaxwell> and non-hardforking.
18:59 < petertodd> maaku, gmaxwell: sounds very much like my TXIN commitment thought experiment - I simply incentivized miners to hold the relevant data by defining mining as some PoW on that data
18:59 < petertodd> maaku, gmaxwell: http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03307.html
19:00 < gmaxwell> I don't even see a reason to incentivize miners to hold it.
19:00 < petertodd> gmaxwell: me neither, just incentivize someone too in such a way that there can never be incentives to withhold
19:01 < petertodd> gmaxwell: though you need to be very careful to ensure that the system can recover if some of the data gets lost
19:02 < petertodd> Note how bitcoin recovers from blockchain data getting lost: this causes a fork which is overtaken sooner or later.
19:03 < maaku> petertodd: you mean permanently, 100% globally lost?
19:04 < maaku> how does bitcoin recover from that?
19:04 < maaku> -- oh wait, i get it
19:04 < petertodd> maaku: lost from the public sphere yes
19:04 < maaku> the new "fork" starts from where the history was lost
19:04 < maaku> not from the current block
19:04 < gmaxwell> petertodd: well if you can get paid helping people complete their proofs, thats a pretty awesome incentive.
19:04 < gmaxwell> way better than mining, IMO
19:05 < petertodd> maaku: mainly I'm more worried that you can easily create systems that give people incentives to withhold data and just broadcast the PoW - bitcoin is way too close to being such a system itself
19:05 < petertodd> gmaxwell: yeah, although be careful it's not the main way to earn income in the scheme - that's a business that naturally centralizes so it must be independent from the PoW security of the system
20:11 < cfields> Ryan52: sorry, missed your pong earlier today
20:11 < cfields> Ryan52: was just curious if you got any further in reproducing the build
22:05 < gmaxwell> I laughed too much at this: http://www.smbc-comics.com/?id=3186#comic
22:15 < petertodd> gmaxwell: Meanwhile the mathematician: "Let I, the Iliad, be a spherical novel of unit radius..."
22:17 < petertodd> wait, no, a mathematician would generize to non-euclidian novels as well...
22:17 < petertodd> *generalize
22:17 < gmaxwell> I suppose an epic poem is isomorpic to a novel upto projection.
22:18 < petertodd> Right! and a "...enter a bar" joke is isomorphic to an epic poem! ah, good, we've reduced this one pretty quickly to something we already know.
22:44 < warren> "mcxNOW is shutting down for a period of time - "Withdraw all your coins before December 20th"
22:44 < warren> anyone surprised?
22:44 < warren> realsolid is very solid
23:10 < gmaxwell> very surprised.
23:10 < gmaxwell> that it wasn't "omg hax, oh look no coins"
23:14 < phantomcircuit> gmaxwell, that's a far more economically effective ploy
23:17 < pigeons> seems weird
23:20 < phantomcircuit> pigeons, what about it seems weird?
23:21 < pigeons> "i'm making money off you, i'm gonna stop now"
23:21 < phantomcircuit> pigeons, accounts that will be unclaimed before december 20th are almost certainly worth more than running it for decades
23:21 < pigeons> ah
23:22 < phantomcircuit> if i pulled that shit with intersango right now i'd be laughing all the way to the bank
23:22 < phantomcircuit> well actually i'd probably be laughing all the way to jail
23:22 < phantomcircuit> but nobody knows who he is
23:24 < gmaxwell> well, as I've lamented before, a friend of mine lost 20 BTC in the tradehill shutdown and hasn't yet been able to recover it
23:24 < gmaxwell> At some point it'll be worth the lawsuit.
23:25 < phantomcircuit> gmaxwell, in general i suspect the best he could hope for is to recover 20 BTC at the time tradehill (version one) was liquidated
23:25 < phantomcircuit> iirc it was actually formally and legally liquidated in chile
23:26 < phantomcircuit> there might be a transfer agreement specifying liabilities... but i doubt it
23:26 < phantomcircuit> it's like there's a guy who owes intersango 511 BTC
23:26 < gmaxwell> phantomcircuit: right, so there you go, time to shut down intersango.
23:26 < phantomcircuit> but it was from when that was worth 4k USD
23:27 < phantomcircuit> there is no way we could get a court to find that he owes us 408k USD instead
23:27 < phantomcircuit> gmaxwell, im going to try changing the business model relatively soon hopefully that will align the costs with the fees
23:27 < phantomcircuit> and people will stop thinking their 10 EUR transfer will be executed immediately
23:36 < pigeons> i met jared and the tradehill folks at the money202 conference in vegas a few months ago and was kind of suprised they show their faces
23:36 < pigeons> the whole san fransisco crows with him, jesse powell, jonathan ryan owens, jared kenna etc
23:36 < pigeons> *crowd
23:36 < pigeons> *money2020
23:53 < phantomcircuit> pigeons, afaict jered himself doesn't intentionally screw people over
23:53 < phantomcircuit> it just kind of happens
23:53 < phantomcircuit> the others though? well that's a different story
23:53 < pigeons> ok, well makes me wary
23:54 < phantomcircuit> total 90degree shift here
23:54 < phantomcircuit> one server with vmware or multiple servers
23:56 < pigeons> probably whatever your admin prefers
23:57 < pigeons> i prefer multiple servers on my own projects, but i for some reason like it all on vmware when its someone else's project, easier for me to keep striaght ofr some reason
23:58 < phantomcircuit> pigeons, im the admin
23:58 < phantomcircuit> yeah i guess individual servers
23:58 < pigeons> of course if you're paranoid there are always break out of the guest and compromise the host bugs that take years to even get leaked
23:58 < phantomcircuit> bleh have to buy switches and shit then
23:59 < pigeons> probably more and more such bugs the way they don't really virtualize the video cards
--- Log closed Tue Nov 26 00:00:08 2013