log☇︎
21600+ entries in 0.13s
asciilifeform: iirc i suggested this lul yrs prior, but would be hilarious if there were a parallel #trilema consisting simply of bots, 1 for each of us, fed with corpus of log lines + shannonizer
asciilifeform: mircea_popescu: i suspect one prolly ~could~ carry on a lengthy thread sewn strictly from trilema titles.
mircea_popescu: i shall now carry the entirety of this conversation in trilema titles.
asciilifeform: PARRY: You should pay more attention. ELIZA: Suppose you should pay more attention. PARRY: You're entitled to your own opinion. ELIZA:What makes you think I am entitled to my own opinion? .. ☟︎
mircea_popescu: minutes ; and the timing not so strictly relevant. clusters of 3 reboots hours apart seem suspicious to me, is what i said.
asciilifeform: ( did i misread , or weren't those dead times in sec. )
mircea_popescu: i don't follow ?
asciilifeform: i've lost count tbh
asciilifeform: trinque: funnily enuff , i was ~just about~ to buy a 'it is tempting fate to put ERRYTHING in 1 rack' box in singapore !
asciilifeform looks on dulap-III, 'up 210 days' -- i.e. ever since i taught BingoBoingo how to not elbow the mains plug
trinque: haven't a damned at the present. I'm just going to redeploy the thing clean elsewhere.
a111: Logged on 2018-11-19 23:39 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
trinque: I can. The box is also in singapore, not known for its perfect internet connections
asciilifeform: i dun know the specifics; supposing simply that retired boxer aint gonna run a node. therefore goxism.
asciilifeform: i.e. 'their' coinz are 'theirs' while 'they agree' to further reich interest
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: last i heard those were still 'in biz'
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: http://btcbase.org/log/2018-11-20#1873721 << ha , here i was thinking that d00d were finally in australian jail.. ☝︎
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 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: i hear it bakes some pretty good virtualities , heh
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: i suspect that mircea_popescu is right, esp re 'dun have domain-restricted walker', tech aint there yet
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: 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: nao i hear hypertext exists, lessee if can make less of bowel-loosening horror
asciilifeform: i.e. crapola glommed to end erry day.
a111: Logged on 2018-11-12 06:36 BingoBoingo: Kinda why I'm excited about breaking down and killing the legacy notes file
mircea_popescu: i mena http://btcbase.org/log/2018-11-12#1871429 ye dorks! ☝︎
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 )
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
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... ☝︎
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: 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
bvt: thanks for discusion, asciilifeform, diana_coman. i'm off to bed.
asciilifeform: bvt: you will find, i think, that with experience comes 'ooooh, that's why, it was Right Thing all along'
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: given as i'd have to release N almost-completely-identical patches each time i release a chapter
asciilifeform: if i had offered them in beginning, the architecture-specific pressable leaves will be gargantuan in size
asciilifeform: so i can e.g. 'press arm64' , 'press x86'
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
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.
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: 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. ☝︎
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: 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: diana_coman has it ( i'm expanding pedantically specifically for n00bs, but same point )
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 ☝︎☟︎
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
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' ☝︎
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: 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'
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 suspect bvt fundamentally misunderstood how v mechanics work, oughta review
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.
bvt: and also i got useful feedback (thanks, diana_coman!)
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: 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: 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. ☟︎
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
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: 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: 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: lobbes: it's a riff on h. c. andersen ( who prolly lifted it from yet-elsewhere, i dun immediately recall from where )
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.
BingoBoingo: mod6: I started my ledger in the Pizarro notes on September 1st.
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: 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.
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 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?
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~.
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, 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: 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. ☟︎
mircea_popescu: bvt but i mean... what's the logic of an "empty genesis" ?