Show Idle (>14 d.) Chans
← 2018-11-18 | 2018-11-20 → ↓
ben_vulpes: mod6: why does the net change in pizarro's cash account for august not equal the difference between the sum of incoming and outgoing cash transactions?
ben_vulpes: BingoBoingo: why does mod6's ledger show a transaction for 0.1 btc to you on august 12th and then back from you on august 17th? it doesn't affect the accounting, but i am perplexed as you both stated that your ledgers in these shared notes contained all of your pizarro transactions with noted exceptions that do not include that transaction.
ben_vulpes: amend that question to include the detail that *your* submitted ledger does not contain either of those transactions.
ben_vulpes: asciilifeform, mod6, BingoBoingo: http://p.bvulpes.com/pastes/tHcxD/?raw=true (these missives have not been encrypted, only signed. if any would like to read, please do.)
ben_vulpes: asciilifeform: i believe this report settles the reported discrepancies. i will have to respond to queries asynchronously, as i'm traveling for the next week.
ben_vulpes: asciilifeform: i've sketched out a set of tables that could hold all pizarro data accounting data and generate statements; the only remaining puzzlers are modeling subscriptions, prepay, and asset depreciation. would you like me to complete the design, put sql to disk and turn this into an accounting spreadsheet for pizarro?
bvt: mircea_popescu: i understand that empty genesis (well, it's not precisely empty, there is a manifest file) is suboptimal, however:
bvt: 1. x86 and arm trees will diverge pretty much from the start, i can't see how anything useful and complete can be packed into genesis.
bvt: 2. i seem to remember but can't find right now a discussion (around time spyked published adalisp) that making such a genesis should be ok. perhaps i am confused about the context of that discussion and did something stupid.
mircea_popescu: bvt i dunno that it's a huge deal, but maybe dig up the log reference ?
mircea_popescu: i mean, it certainly has the virtue of signalling, "Hey guise, i intend to do this" sorta thing
diana_coman: phf, I wanted to sign your vtools patches but I realised that they are using sha so I don't really know: do you plan to regrind them with keccak?
diana_coman: bvt, while I don't see a big problem per se with an empty genesis, the question for your specific situation is why glue together 2 trees if they diverge right from the start anyway?
mircea_popescu: something like that.
bvt: ok, so the discussion seems to be here: http://btcbase.org/log/2018-06-25#1829429 , and unlike me, spyked did publish the code.
a111: Logged on 2018-06-25 16:40 mircea_popescu: spyked> I think there's great benefit in the ffa chapter-based approach << that ~started with a genesis~.
bvt: i want the platform-specific branches to be glued together because API for users should be the same in all of them. so that user can press a branch for aarch64 or x86 without changing anything in his code.
diana_coman: bvt, that sounds like you want to start then the tree with ..the API? otherwise at any rate, the user CAN use the same API with whatever provides it, no?
mircea_popescu: bvt this is laudable, provided of course it actulaly works out.
mircea_popescu: experience kinda seems to indicate trying to have the same model for two things is a recipe for tears in this "industry" of apes and aping, but then again... man gotta try.
deedbot: http://bimbo.club/?p=83 << Bimbo.Club - TMSR Log Summary - 11/05/2018
deedbot: http://trilema.com/2018/the-keks-of-all-time/ << Trilema - The keks of all time...
asciilifeform: http://btcbase.org/log/2018-11-19#1873558 << got it; loox like it is ready to mechanize, ben_vulpes ..?
a111: Logged on 2018-11-19 06:31 ben_vulpes: asciilifeform, mod6, BingoBoingo: http://p.bvulpes.com/pastes/tHcxD/?raw=true (these missives have not been encrypted, only signed. if any would like to read, please do.)
a111: Logged on 2018-11-19 07:09 ben_vulpes: asciilifeform: i've sketched out a set of tables that could hold all pizarro data accounting data and generate statements; the only remaining puzzlers are modeling subscriptions, prepay, and asset depreciation. would you like me to complete the design, put sql to disk and turn this into an accounting spreadsheet for pizarro?
asciilifeform: ben_vulpes: i assumed the worst, that asciilifeform would have to somehow fit whole thing on his already packed conveyor.
asciilifeform: http://btcbase.org/log/2018-11-19#1873561 << here is where i admit that i dun see wtf is the point of an empty genesis
a111: Logged on 2018-11-19 07:54 bvt: mircea_popescu: i understand that empty genesis (well, it's not precisely empty, there is a manifest file) is suboptimal, however:
asciilifeform: genesis, in my conception, oughta at the very least set the flavour of a tree, with ~some~ semblance of a working item
asciilifeform: ( e.g. ffa genesis, is very small, but contained all of the basic fundamental moving parts for simple arithm )
mod6: http://btcbase.org/log/2018-11-19#1873558 << Thanks for the audit report ben_vulpes. Looks like you figured out this (http://btcbase.org/log/2018-11-19#1873555) from your report notes.
a111: Logged on 2018-11-19 06:31 ben_vulpes: asciilifeform, mod6, BingoBoingo: http://p.bvulpes.com/pastes/tHcxD/?raw=true (these missives have not been encrypted, only signed. if any would like to read, please do.)
a111: Logged on 2018-11-19 05:06 ben_vulpes: mod6: why does the net change in pizarro's cash account for august not equal the difference between the sum of incoming and outgoing cash transactions?
asciilifeform: ohai mod6
mod6: http://btcbase.org/log/2018-11-19#1873556 << As for this, BingoBoingo began doing a cut-down of the notes file, so more recent editions have not had older-months notes contained. I have went back and found the notes around the 0.1 BTC sent between us from august. Here is that specific snippit: http://p.bvulpes.com/pastes/CEgRj/?raw=true
a111: Logged on 2018-11-19 05:30 ben_vulpes: BingoBoingo: why does mod6's ledger show a transaction for 0.1 btc to you on august 12th and then back from you on august 17th? it doesn't affect the accounting, but i am perplexed as you both stated that your ledgers in these shared notes contained all of your pizarro transactions with noted exceptions that do not include that transaction.
mod6: ben_vulpes: In case you are curious, here is the full notes file from the end of august, just for posterity: http://p.bvulpes.com/pastes/5ZN91/?raw=true
mod6: I won't speak for BingoBoingo as to why his ledger copy does not show the 0.1 BTC sent from me to him, and then back from him to me. I'll let him speak to that.
mod6: Hope this helps. Cheers.
mod6: hai asciilifeform, hope all is well
asciilifeform: http://btcbase.org/log/2018-11-18#1873480 << this is entirely ok, diana_coman , there is not a burning hurry ( tho i expect that anybody who intends on firing ffa on battlefield will first take the time to properly eat it )
a111: Logged on 2018-11-18 20:52 diana_coman: http://btcbase.org/log/2018-11-18#1873291 - noted and added to the list though it might still take some time to get up to speed with ffa again
mod6 bbl
asciilifeform: mod6: errything well, ( tho asciilifeform as always during weekdays is knee deep in heathen rubbish )
BingoBoingo: tyvm ben_vulpes
BingoBoingo: mod6: I started my ledger in the Pizarro notes on September 1st.
mod6: Ah, ok BingoBoingo. Then that'd be it, since the 0.1 BTC back and forth took place in mid-August.
mod6: Thanks.
mod6 bbl
BingoBoingo: Yeah, it was in case of a price swing while getting an SSD order ready
mod6: Yeah, makes sense to me. I remember that.
asciilifeform: BingoBoingo: ftr i still dun have anything like a working hypothesis re why the miners let segshitness live for as long as it has
asciilifeform: tho i think mircea_popescu had one, iirc it was 'they're letting the sow fatten for table', approx
asciilifeform: anybody recall whether there's a handy gauge somewhere re just how fat is the sow presently ? ( it ain't particularly hard to calculate , simply add up the coinz presently sitting in 'anyone-spends' )
a111: Logged on 2017-08-24 14:23 mircea_popescu: http://btcbase.org/log/2017-08-24#1702759 << eventually this will necessarily happen, yes. "segwit" transactions are stored on the bitcoin network as "anyone can spend", so eventually miners will unroll the segwit chain. how soon is not easily predicted (which is why the idea is stupid/usg-like, introduces impredictability in the currency)
a111: Logged on 2016-11-07 18:26 mircea_popescu: well, it slowly builds, until the miners defect.
a111: Logged on 2016-11-07 18:27 mircea_popescu: im sure nobody had the sense to create a "total payout to defecting miners" watch, because hey, they're "developers" not thinkers.
asciilifeform: !#s prikoke
asciilifeform: ^ oblig.
asciilifeform: lobbes: it's a riff on h. c. andersen ( who prolly lifted it from yet-elsewhere, i dun immediately recall from where )
asciilifeform: prolly tale is as old as pig-keepin'.
deedbot: http://qntra.net/2018/11/pantsuit-lolsuit-against-russia-stumped-by-sovereign-immunity/ << Qntra - Pantsuit Lolsuit Against Russia Stumped By Sovereign Immunity
asciilifeform: BingoBoingo: ru foreign ministry, not ministry of justice
asciilifeform: or hm, nm, loox like 1 of each
BingoBoingo: ty fxd
bvt: hello
bvt: http://btcbase.org/log/2018-11-19#1873573 << i will have to think more about vtree organization. if i use api as the foundation for the tree, adding new system calls would cause regrind; in this case, the api should be complete from day one.
a111: Logged on 2018-11-19 11:46 diana_coman: bvt, that sounds like you want to start then the tree with ..the API? otherwise at any rate, the user CAN use the same API with whatever provides it, no?
bvt: for example, ftruncate is also useful for mmaptron, should it go in?
bvt: otoh, if system call asm packages are at the tree foundation, the api uniformity will be enforced by convetion only, and the branches will diverge right after genesis.
diana_coman: bvt, from experience I can tell you that "complete from day one" is not likely to ever happen
diana_coman: basically it's just a way to cause yourself trouble, I wouldn't recommend
diana_coman: the only case in which such a thing makes sense is if it's already a fixed /known /set in stone set
bvt: yes, i can definitely see that. scope of the tree must be fixed at the moment of creation. which is not necessarily a bad thing.
diana_coman: anyway, the purpose of V is not to force something onto the user
bvt: ftr, i don't expect that i will make this tree without a single regrind
bvt: http://btcbase.org/log/2018-11-19#1873575 << this is why i'd like to work on struct stat (well, it is also required for mmap): fairly complex structure, which differs across architectures.
a111: Logged on 2018-11-19 11:50 mircea_popescu: experience kinda seems to indicate trying to have the same model for two things is a recipe for tears in this "industry" of apes and aping, but then again... man gotta try.
bvt: i hope that for tmsr.os most of these things will become unnecessary; lower levels of libc/libada are not the right place to fix the underlying problem.
diana_coman: bvt, precisely because it can't be fully clear in advance I'd suggest to choose the more flexible v-structure rather than something with set in stone requirements (such as API as root of the v tree sort of thing); this is NOT to say or guarantee you won't regrind but simply to not make ~surely needed
diana_coman: regrinds are not evil or anything of the sort but they do have a cost ; and if you get others to sign your patches, the cost increases since you lose the original signatures basically
diana_coman: so if you are not sure, I'd even keep the trees separately, I still don't quite see the problem with this (the benefit being that it doesn't force you to decide NOW on something you don't yet ...know)
diana_coman: keeping the trees in sync is probably cheaper than regrinding the whole thing anyway; and if /when it's not, then...regrind it as a single tree and that's that
bvt: i totally agree with all these points. tree diverging after empty genesis is separate enough in my view.
bvt: http://btcbase.org/log/2018-11-19#1873583 << this is unfortunate, i won't have possibility to work on this code in coming days; there will be a vtree stump for ~2 weeks.
a111: Logged on 2018-11-19 15:18 asciilifeform: http://btcbase.org/log/2018-11-19#1873561 << here is where i admit that i dun see wtf is the point of an empty genesis
bvt: and also i got useful feedback (thanks, diana_coman!)
a111: Logged on 2018-11-19 20:45 bvt: http://btcbase.org/log/2018-11-19#1873573 << i will have to think more about vtree organization. if i use api as the foundation for the tree, adding new system calls would cause regrind; in this case, the api should be complete from day one.
asciilifeform: why would it 'cause regrind' ??
asciilifeform: i've added all kindsa 'new api' in ffa, but the only regrind was when we took up new hash type for vtrons
asciilifeform: i suspect bvt fundamentally misunderstood how v mechanics work, oughta review
asciilifeform: http://btcbase.org/log/2018-11-19#1873641 << entirely agrees with my pov, which is why i had the .c in udp lib ( http://www.loper-os.org/?p=2557 ) instead of five kilometres of 'let's try to parse the c struct of 17 diff cpus in ada'
a111: Logged on 2018-11-19 20:52 bvt: i hope that for tmsr.os most of these things will become unnecessary; lower levels of libc/libada are not the right place to fix the underlying problem.
asciilifeform: imho the minimal .c glue is actually The Right Thing while we're still stuck on unix
diana_coman: asciilifeform, in my understanding he wanted to cement "common api" hence possibly root since that's the only common part for the 2 trees, hence "regrind" if new (because not in root etc)
asciilifeform: diana_coman: consider, if i'd done 'api first' for udp, would have ended up with ~same thing as ave1's hairball, i.e. 'just like gnat.sockets but maybe slightly less sad'
diana_coman: asciilifeform, read on, not as if recommended for the task, no
asciilifeform: it is quite impossible to say entirely in advance what api for glue layer on buncha unix garbage, will be, until fully grasped at least the outer surface of said garbage
asciilifeform still eating log
bvt: http://btcbase.org/log/2018-11-19#1873650 << well, if i do common part (api) first, then diverging system-specific branches, i still could add new functionality on top of *each* of these branches. i don't like this option.
a111: Logged on 2018-11-19 21:21 asciilifeform: http://btcbase.org/log/2018-11-19#1873629 << waiiiwaaaat ?!
bvt: alternatively, i could add new functions at common tree part if i don't touch any files included in later vpatches (so adding entries to manifest would be not possible). seems like some quite unnatural acrobatics to me.
bvt: but i would agree that one's understanding of vtronics is determined by ones toposorter implementation.
asciilifeform: bvt: when you absolutely must publish mutually-exclusive variants of a thing, they oughta be v leaves, yes
asciilifeform: ( and if you extend on one such, and want to propagate into the others, then must regrind -- but strictly the piece in question )
asciilifeform: !#s ifdefism
asciilifeform: ^ the heathen barbarism that goes counter to this formulation, that we're thankfully rid of
asciilifeform: http://btcbase.org/log/2018-11-19#1873666 << much of what seems to n00bs as 'unnatural acrobatics' in vtronics is in fact the actual and inevitable cost of writing proggies ~honestly~ -- i.e. without pretending, as the heathens do, that 'i only changed this one little thing, whatddayamean it's a new program now'
a111: Logged on 2018-11-19 21:44 bvt: alternatively, i could add new functions at common tree part if i don't touch any files included in later vpatches (so adding entries to manifest would be not possible). seems like some quite unnatural acrobatics to me.
asciilifeform: arguably v is a labour-saving device ~specifically for readers~, rather than writers, of programs -- if we were passing signed tarballs around, as we did prior to v, reader would be stuck determining exactly what changed, after manually verifying sig.
asciilifeform: v makes it possible to sign a compartmentalized change , so reader is not stuck having to manually diff contents of signed_foo.today.tar.gz against signed_foo.tomorrow.tar.gz to see where the changes were. but what it deliberately does ~not~ do is to enable the pretense ( carried on in git & other heathen abominations ) that a proggy where something semantically upstream of $place were changed, is ~same~ proggy ~but for $place~ .
asciilifeform: the 'one little thing' is only 'little' when ~nothing depends on it~ -- i.e. is an extension of a leaf node, graph-theoretically speaking
diana_coman: bvt> http://btcbase.org/log/2018-11-19#1873650 << well, if i do common part (api) first, then diverging system-specific branches, i still could add new functionality on top of *each* of these branches. i don't like this option. -> perhaps unsurprisingly, the part that one doesn't like is however actually correct i.e. yes, you'll have to maintain the two separately if they are separate; hence my original "they are 2 trees" - because that's
a111: Logged on 2018-11-19 21:21 asciilifeform: http://btcbase.org/log/2018-11-19#1873629 << waiiiwaaaat ?!
diana_coman: what they are anyway, until/unless you cement the API
asciilifeform: if it is an item which conceivably affects the meaning of other text in unpredictable ways, then the patch must reflect this ( and we get 'reground' code. )
asciilifeform: diana_coman has it ( i'm expanding pedantically specifically for n00bs, but same point )
asciilifeform: to put it in mircea_popescuine terminology -- the scenario that v makes specifically and rightfully impossible is 'hey, i changed 'wife' to 'dog' in your marriage contract, but yer still just as married, you signed all the downstreams'
asciilifeform: bvt: it's in fact exactly the same thing that e.g. bitcoin does -- you cannot go back and flip a bit in block 100, and expect to be on the same chain as other folx, it'll correctly invalidate 101--present from your node's pov ( and your entire existence from other's pov )
asciilifeform: v is just about exactly same thing as bitcoin's chain, with the difference that it seals with manually-crafted operator signatures, rather than 'proof of work' gymnastics
asciilifeform: bvt: if you understand why bitcoin does not tolerate 'yes i'm on the same chain as you! except that i flipped a single bit in block 100, and really, honestly, nuffin ever depended on the tx where i flipped it!' -- you will also understand why v does not tolerate this either
asciilifeform: the fact that it feels to noobs like 'unnatural acrobatics' is an artifact of writer suddenly having to pay that actual cost of the complexity inflicted on reader. and yes folx whined, just like in ex-ussr folx whined when they started having to pay for mains current .
bvt: http://btcbase.org/log/2018-11-19#1873678 << what i did not like was following: specifically going for 'api at the tree root' variant, and then bolting on new (platform-independent) apis later.
a111: Logged on 2018-11-19 22:42 diana_coman: bvt> http://btcbase.org/log/2018-11-19#1873650 << well, if i do common part (api) first, then diverging system-specific branches, i still could add new functionality on top of *each* of these branches. i don't like this option. -> perhaps unsurprisingly, the part that one doesn't like is however actually correct i.e. yes, you'll have to maintain the two separately if they are separate; hence my original "they are 2 trees" - because that's
bvt: but i see how this is the correct process, and just a bit more optimized case of what i planned with branches diverging at the genesis (saves reader some labour of reading same vpatches in each branch). and if tree becomes to messy, can regrind.
bvt: http://btcbase.org/log/2018-11-19#1873686 << this part is crystally clear
a111: Logged on 2018-11-19 23:03 asciilifeform: bvt: if you understand why bitcoin does not tolerate 'yes i'm on the same chain as you! except that i flipped a single bit in block 100, and really, honestly, nuffin ever depended on the tx where i flipped it!' -- you will also understand why v does not tolerate this either
asciilifeform: bvt: platform variants belong exclusively in leaves.
asciilifeform: so i can e.g. 'press arm64' , 'press x86'
bvt: no disagreement/misunderstanding here
asciilifeform: and yes it is true that if you write 6 platform variants today, and want to change the common trunk tomorrow, you will need to regrind all 6. but this is 'not a bug, but a feature'
asciilifeform: it forced you to proclaim that the 6 are in fact new programs, because you turned a common knob and potentially changed their meanings, of all 6
asciilifeform: *forces
asciilifeform: this is the reason why asciilifeform is saving the optional asm subroutines in ffa for ~dead last~ ( per http://www.loper-os.org/?p=2735 proclamation ) rather than given in beginning of series
asciilifeform: if i had offered them in beginning, the architecture-specific pressable leaves will be gargantuan in size
asciilifeform: and reader would be stuck manually diffing'em, which defeats most of the win from using v vs signed tars etc
asciilifeform: given as i'd have to release N almost-completely-identical patches each time i release a chapter
trinque croaks cheeeeeap coiiiins
asciilifeform: 20 $ when!111
bvt: i do understand the philosophy behind v (definitely not complaining), but i lack practical experience working with it, so it was useful to get explanations re tree structure.
asciilifeform: bvt: you will find, i think, that with experience comes 'ooooh, that's why, it was Right Thing all along'
bvt: thanks for discusion, asciilifeform, diana_coman. i'm off to bed.
asciilifeform: goodnight bvt
asciilifeform: trinque: i admit that i sometimes miss the days when the amt of shit i gave re what the heathen exch rate is, was the size of a hamster's . pizarro is the 1 bone in throat on that score, it runs on heathenbux and consequently sensitive to the weather, like a bad knee
asciilifeform: 'volatility is a tax' or how did mircea_popescu phrase it in the old days.
asciilifeform: prolly the only biz that dun have this problem at all, is s.mg, which of oct '18 broadcast reports '8`484.51538878', i.e. capitalized until the sun burns out
asciilifeform: even if exch rate moves 2 orders of magnitude erry other tuesday
asciilifeform: maybe in the end entire planet will end up as vertically-integrated suppliers for s.mg...
asciilifeform: ( and woe be unto those who dun have what to supply to it.. )
asciilifeform bbl,meat
trinque still accumulates when the weather's nice
mircea_popescu: o look at deese logs!
mircea_popescu: http://qntra.net/2018/11/forkcoin-that-split-from-bitcoin-now-struck-by-contentious-hardfork/#comment-120500 << srsly the usg tards are pushing that wright imbecile as their spearhead ? what, nobody thinking left in the "think" fishtanks ?!
mircea_popescu: http://btcbase.org/log/2018-11-19#1873621 << ohohoh check it out, he translated it & made reference point. NICE!
a111: Logged on 2018-11-19 18:49 lobbes enjoyed >> http://thetarpit.org/posts/y04/073-prikoke.html
mircea_popescu: anyway, mefi because "mefiance" not mephistopheles.
mircea_popescu: http://btcbase.org/log/2018-11-19#1873632 << i confess i entirely dun understand what you think a vtree is/does. none of your statements seem to be either relevant or correct, which...
a111: Logged on 2018-11-19 20:46 bvt: otoh, if system call asm packages are at the tree foundation, the api uniformity will be enforced by convetion only, and the branches will diverge right after genesis.
asciilifeform: wb mircea_popescu !
mircea_popescu: http://btcbase.org/log/2018-11-19#1873669 << why, could just patch the others.
a111: Logged on 2018-11-19 22:24 asciilifeform: ( and if you extend on one such, and want to propagate into the others, then must regrind -- but strictly the piece in question )
mircea_popescu: http://btcbase.org/log/2018-11-19#1873675 << hey, not like you're not still doing it :D
a111: Logged on 2018-11-19 22:41 asciilifeform: arguably v is a labour-saving device ~specifically for readers~, rather than writers, of programs -- if we were passing signed tarballs around, as we did prior to v, reader would be stuck determining exactly what changed, after manually verifying sig.
asciilifeform: i did sign a tarball fulla regrindolade last wk. but largely so folx know they get what i put in, rather than ball fulla patches + usg gnutar 0day impregnated in flight etc
asciilifeform: ( btw these are imho a luxury. i simply hate having to click 9000 links to get a tree , and assume other folx do also )
a111: Logged on 2018-11-12 06:36 BingoBoingo: Kinda why I'm excited about breaking down and killing the legacy notes file
asciilifeform: aa that was much worse
mircea_popescu: tarball passed back and forth, nobody even knows what changed, gotta diff, it has all the blessings you describe.
asciilifeform: BingoBoingo: plz lemme know btw if you need any inout from asciilifeform to clean those ughstables
mircea_popescu: you did this. /smh
asciilifeform: mircea_popescu: was linear tape of changes.
asciilifeform: i.e. crapola glommed to end erry day.
mircea_popescu: at least most of the time.
mircea_popescu: judging by how unsure all participants are as to contents, it seems evident to me it worked exactly like github program, ie "crapola glommed to end erry day and random shit changed deeper inside at impredictable intervals we might remember or not".
asciilifeform: nao i hear hypertext exists, lessee if can make less of bowel-loosening horror
asciilifeform: mircea_popescu: nuffin was changed 'inside' on my watch, but seems like there were arithmetical howler at some pt, so i suppose effectively same
asciilifeform: ( record keeping dun do any good if you write down wrong num )
asciilifeform: while we're on subj, mircea_popescu do you think it'd make sense to keep books vtronically? or would it be a case of 'take the rifle to fishing'
mircea_popescu: seems to me way too much infrastructure for what's still less than a dozen accts with less than a dozen movements / interval in there. but hey, your corp, can't exactly say you don't learn from mistakes, so, if in a position to try things out this is a thing to try like many others.
asciilifeform: point was not 'it's too big'
asciilifeform: but that vtronic record would make certain classes of ugh, impossible
asciilifeform: whether the item being recorded is elephant or mouse size
mircea_popescu: yeah, but because large machinery and no proper domain-restricted walkatrons available, it'd make new classes of ugh available.
asciilifeform: also tru
mircea_popescu: kinda the logic informing my http://btcbase.org/log/2018-11-11#1871164 : if you give policeman gun, you now have set of problems resulting from policeman-gun interaction. if you do not give, you do not have.
a111: Logged on 2018-11-11 16:10 ben_vulpes: and i never used a program because, (again cannot find the log link in reasonable-response time) at one point i was working on a schema for tracking customers and what they were paying for and mircea_popescu said something along the lines of "wtf this is a simple text file and accounting problem"
asciilifeform: i suspect that mircea_popescu is right, esp re 'dun have domain-restricted walker', tech aint there yet
mircea_popescu: or i suppose construction crew better example. if you issue them pickaxes, you can at the end of the day look at damage "as men with pickaxes could have produced". if you issue backhoe...
asciilifeform: but imho a vtronic acct system would rock
mircea_popescu: certainly well adapted to each opther, problem and solution. v is masterful at truth and accounting is all about numeric truth. so yes, in principle. but it'll take some doing, dunno if you've got the doers rightnao, and seems more pressing fires.
asciilifeform: on both pts
a111: Logged on 2018-11-19 23:22 trinque croaks cheeeeeap coiiiins
mircea_popescu: http://btcbase.org/log/2018-11-19#1873714 << that'd be partricularly cool, considering it is a... virtual reality producer
a111: Logged on 2018-11-19 23:43 asciilifeform: maybe in the end entire planet will end up as vertically-integrated suppliers for s.mg...
mircea_popescu: drop-in replacement for teh dmc ?
asciilifeform: i hear it bakes some pretty good virtualities , heh
asciilifeform dun presently have time, sadly , to play mud, but if lives to see peacetime would much rather play mircea_popescu's than anybody's
mircea_popescu: that's nice :)
asciilifeform went as far as building a new box, with 3d card etc, to 'i'ma finally play that thing', then... realized he gotta write a numeric lib
asciilifeform: laugh, i ended up giving it to my brother, now it runs neuralnetwork thing for go game move-tree variants, 'what if played x' etc
asciilifeform: ( apparently game did not die under the thrust of alphagoism, but mutated into a kind of motor sport )
asciilifeform: http://btcbase.org/log/2018-11-20#1873721 << ha , here i was thinking that d00d were finally in australian jail..
a111: Logged on 2018-11-20 02:12 mircea_popescu: http://qntra.net/2018/11/forkcoin-that-split-from-bitcoin-now-struck-by-contentious-hardfork/#comment-120500 << srsly the usg tards are pushing that wright imbecile as their spearhead ? what, nobody thinking left in the "think" fishtanks ?!
asciilifeform: apparently recycled back into circulation from lack of what else to do ?
asciilifeform: trinque: is deedbot box under artillery fire or wat
mircea_popescu: i have nfi, it's pretty fucking lulzy though. i mean, there's a long list of these defeateds by "fate", but he's one of the most hysterically humiliated humbugs.
asciilifeform: 2nd only to gavin, possibly
mircea_popescu: then again, the menagerie's pretty well stocked... recall the gay for pay tard with delusions of oligarchy ? or those two wrestler morons, 100% retired boxer encephalopathy ?
asciilifeform: last i heard those were still 'in biz'
asciilifeform admits, doesn't follow subj in realtime
asciilifeform: iirc those boxers were some hybrid of scammer and scammee , they sank whatever $maxint into goxolade
mircea_popescu: i'm personally waiting for the return of the meni rosenfeld / jonathan ryan owens lulzpair. bitdaytrade, segwit, cash-whatever... what the fuck's the difference.
asciilifeform: i.e. 'their' coinz are 'theirs' while 'they agree' to further reich interest
mircea_popescu: asciilifeform in the sense of what, after usg took overt the piggy it declared some clients as principal victims ?
mircea_popescu: sank my ass.
asciilifeform: i dun know the specifics; supposing simply that retired boxer aint gonna run a node. therefore goxism.
asciilifeform brb,foods
mircea_popescu: the way british empire intervention worked was that http://trilema.com/2010/general-sir-charles-james-napier-gcb/ got sent with some army and clear orders to not take singh ; then he takes singh ; then some "british merchants" are invented whose "interests were being protected", retroactively. then all this is published back home in the times, and then the empire croaks under the weight of trying to administer afghanistan.
mircea_popescu: 4 stroke engine.
mircea_popescu: suffices it for trilema to quote a verse, be it howsoever famous or popular...
BingoBoingo: http://p.bvulpes.com/pastes/YSdg7/?raw=true << In local finds, cultural collision
BingoBoingo: asciilifeform: Will let you know
BingoBoingo: Further downthread http://p.bvulpes.com/pastes/ElDFJ/?raw=true "Caballos muertos jajajaa la mierdaaa"
trinque: asciilifeform: "disconnected by services" would appear to be freenode doing it
← 2018-11-18 | 2018-11-20 → ↑
Random(trilema) | Download hourly DB snapshot | Get Source Code