log☇︎
60900+ entries in 0.035s
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
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: 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. ☟︎
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: 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' ☝︎
asciilifeform: ^ the heathen barbarism that goes counter to this formulation, that we're thankfully rid of
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: bvt: when you absolutely must publish mutually-exclusive variants of a thing, they oughta be v leaves, yes
bvt: but i would agree that one's understanding of vtronics is determined by ones toposorter implementation.
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: 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. ☝︎
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
diana_coman: asciilifeform, read on, not as if recommended for the task, no
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, 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: imho the minimal .c glue is actually The Right Thing while we're still stuck on unix
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: 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' ☝︎
asciilifeform: i've added all kindsa 'new api' in ffa, but the only regrind was when we took up new hash type for vtrons
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.
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: 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. ☝︎
bvt: i totally agree with all these points. tree diverging after empty genesis is separate enough in my view.
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
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: 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: 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
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. ☟︎
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: 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. ☝︎
bvt: ftr, i don't expect that i will make this tree without a single regrind
diana_coman: anyway, the purpose of V is not to force something onto the user
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: the only case in which such a thing makes sense is if it's already a fixed /known /set in stone set
diana_coman: basically it's just a way to cause yourself trouble, I wouldn't recommend
diana_coman: bvt, from experience I can tell you that "complete from day one" is not likely to ever happen
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. ☟︎
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: 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: prolly tale is as old as pig-keepin'.
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.
a111: Logged on 2016-11-07 18:26 mircea_popescu: well, it slowly builds, until the miners defect.
asciilifeform: ( or the earlier http://btcbase.org/log/2016-11-07#1563526 , & elsewhere ) ☝︎
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)
asciilifeform: ( ex. thread, http://btcbase.org/log/2017-08-24#1702787 ) ☝︎
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' )
asciilifeform: tho i think mircea_popescu had one, iirc it was 'they're letting the sow fatten for table', approx
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
mod6: Yeah, makes sense to me. I remember that.
mod6: Ah, ok BingoBoingo. Then that'd be it, since the 0.1 BTC back and forth took place in mid-August.
BingoBoingo: mod6: I started my ledger in the Pizarro notes on September 1st.
asciilifeform: mod6: errything well, ( tho asciilifeform as always during weekdays is knee deep in heathen rubbish )
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
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 ) ☝︎
mod6: Hope this helps. Cheers.
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: 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
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: 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: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?
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.)
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. ☝︎☝︎
asciilifeform: ( e.g. ffa genesis, is very small, but contained all of the basic fundamental moving parts for simple arithm )
asciilifeform: genesis, in my conception, oughta at the very least set the flavour of a tree, with ~some~ semblance of a working item
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: 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 ☝︎☟︎
asciilifeform: ben_vulpes: i assumed the worst, that asciilifeform would have to somehow fit whole thing on his already packed conveyor.
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?
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.)
asciilifeform: http://btcbase.org/log/2018-11-19#1873558 << got it; loox like it is ready to mechanize, ben_vulpes ..? ☝︎
deedbot: http://trilema.com/2018/the-keks-of-all-time/ << Trilema - The keks of all time...
deedbot: http://bimbo.club/?p=83 << Bimbo.Club - TMSR Log Summary - 11/05/2018
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. ☟︎
mircea_popescu: bvt this is laudable, provided of course it actulaly works out.
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: 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.
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: ok, so the discussion seems to be here: http://btcbase.org/log/2018-06-25#1829429 , and unlike me, spyked did publish the code. ☝︎
mircea_popescu: something like that.
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?
diana_coman: phf, also, perhaps snarf the V.pl tree from in http://ossasepia.com/2018/11/13/v-with-vtools-keccak-hashes-and-its-own-tree/ ?
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?
mircea_popescu: i mean, it certainly has the virtue of signalling, "Hey guise, i intend to do this" sorta thing
mircea_popescu: bvt i dunno that it's a huge deal, but maybe dig up the log reference ?
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.
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: mircea_popescu: i understand that empty genesis (well, it's not precisely empty, there is a manifest file) is suboptimal, however: ☟︎
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? ☟︎
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, 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: amend that question to include the detail that *your* submitted ledger does not contain either of those 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: 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? ☟︎
mircea_popescu: bvt but i mean... what's the logic of an "empty genesis" ?
BingoBoingo: mircea_popescu: I'll give it a play with as I work through more punch list items
mircea_popescu: BingoBoingo not bad, though i prefer the fully formatted style, with dates etc, like in http://trilema.com/category/bitcoin/ or http://trilema.com/2017/06/ etc.
BingoBoingo: What else can you expect from the prototypical Pantsuit slave society
deedbot: http://qntra.net/2018/11/brexit-set-to-break-britains-government-and-theresa-may/ << Qntra - Brexit Set To Break Britain's Government And Theresa May
mod6: I do appreciate the wake up call, and I take your words to hard. I'll do better to take a long rest/break and stop spinning my damn brain so hard.
mircea_popescu: well so take it easy.