Show Idle (>14 d.) Chans

← 2022-02-17 | 2022-02-19 →
crtdaydreams: << Fugg. I can't tell if I'm being milked for lulz or you were serious.
dulapbot: Logged on 2022-02-15 14:32:08 asciilifeform: crtdaydreams: reiser
crtdaydreams: The more I read the more I'm inclined to the former.
vex: I checked your mum cdd. My forklift isn't big enough
vex: protip. noone gives a fuck about you
vex: That actually comes off harsh. you might be nice
dulapbot: Logged on 2022-02-18 05:17:53 vex: protip. noone gives a fuck about you
crtdaydreams: Just another fucking cancer in this hellhole that will ultimately contribute nothing.
vex: shit. you're gonna make me hang myself
crtdaydreams: I've fucked up, that's all. Big time.
vex: dyareckon your mum'll let you go wardriving?
vex: I could ask her very nicely
crtdaydreams: sure. go ahead.
vex: got any sploits?
crtdaydreams: who am I kidding? I can't code ofc not.
vex: I'm also not gonna try to sex your mom
crtdaydreams: k, she's a virgin anyway.
vex: now i feel bad for chatting shit
crtdaydreams: I'm joking mate
vex: me too. i'll totally fuck ur mum
crtdaydreams: swap numbers?
vex: yeah nah you spooky little thing
crtdaydreams: deals a deal
vex: ok then
crtdaydreams: that was a joke ftr, I don't wanna be doxxed.
vex: i probabbly dont wanna orgasm ur mum
vex: if she worked on her diet & fitness. mebbe
crtdaydreams: what % ya drinkin?
vex: yeah. nah
vex: ipa
crtdaydreams: nah fuck nah
vex: is ur mum hot tho?
dulapbot: Logged on 2022-02-18 05:42:35 crtdaydreams: nah fuck nah
crtdaydreams: I ain't into that oedipal complex shit.
crtdaydreams: Wouldn't know.
vex: totes innapropes
crtdaydreams: hydrate.
vex: fuck off cunt
crtdaydreams: gonna trigger a winter soldier episode?
crtdaydreams: fuck me, that's enough shittalk, got any music?
vex: yep. i'VE GOT A DANISH DOOSIE FROM 1992
vex: whoops. hit capslock
crtdaydreams: aw yip?
crtdaydreams: Here's a banger for ya.
vex: seriously. do you have a daddy?
crtdaydreams: No. I have a father.
vex: fair cop
vex: I might've undersestimated your age
crtdaydreams: What's that supposed to mean?
vex: I thought you were like 20. ur prolly 29
crtdaydreams: I literally told you the other day.
vex: I can't rmember shit
crtdaydreams: Doesn't matter.
vex: right
crtdaydreams: You'll forget I even existed in a few weeks from now anyway.
vex: if the courst ever ask. never heard of the cunt
crtdaydreams: time to zap you with one of those men in black forgettamathingies
cgra: << mech hdd with the bdbmay prove unfeasible, while still an interesting experiment
dulapbot: Logged on 2022-02-17 23:42:13 jonsykkel: its a 15yo laptop with mech hdd
asciilifeform: height 216141 nao & no apparent stalls
asciilifeform: at this height already heavier, some take 1-2s to verify
asciilifeform: the experiment worx, to the extent asciilifeform expected it to -- i.e. noad syncs at ~same pace as it would have via 'eatblock'.
asciilifeform: at some pt asciilifeform will cut some of the gnarl from the patch and bake a 'final' on top of the 'draft'.
asciilifeform encourages folx to test the current item
cgra: << does 'level-by-level' here also mean 'branch-by-branch'? ie. can validate transactions one by one, as they stream from peer, if provided with enough related higher-level merkle hashes
dulapbot: Logged on 2022-02-17 13:37:43 asciilifeform: would've been entirely possib. to send the header, then the 1st level of merkelisms, then n+1st, etc.
cgra: << asciilifeform prolly agrees that, strictly speaking, block hash is derived from the 80-byte block header, while the 'merkle root' hash is ~embedded~ in the same header. but i don't grasp how would merkleism allow tx reordering without the merkle root changing
dulapbot: Logged on 2022-02-17 13:38:52 asciilifeform: (for n00bz: block hash is a 'merkle tree', i.e. permits reordering tx and get same hash)
cgra: see CBlock::BuildMerkleTree() here, which returns the merkle root hash
asciilifeform: cgra: level by level.
cgra: example: lv 3: tx hashes A B C D E; lv 2: merkle hashes AB CD EE; lv 1: merkle hashes ABCD EEEE; lv 0, merkle root: ABCDEEEE.
asciilifeform: asciilifeform oughta have said concretely -- obv. cannot reorder arbitrarily; but possible in principle to send by level.
cgra: asciilifeform: how do txes divide into levels?
cgra: can only see branch division
asciilifeform: come to think of it, cgra is right, can't send by level
asciilifeform not sure where got this notion
asciilifeform: !w poll
watchglass: Polling 14 nodes...
watchglass: : ( Alive: (0.081s) V=99999 (/ Jumpers=0x1 (TRB-Compat.) Return Addr= Blocks=723899
watchglass: : ( Alive: (0.082s) V=70001 (/ Jumpers=0x1 (TRB-Compat.) Blocks=723899
watchglass: : ( Alive: (0.112s) V=99999 (/ Jumpers=0x1 (TRB-Compat.) Blocks=723899
watchglass: : Alive: (0.145s) V=99999 (/ Jumpers=0x1 (TRB-Compat.) Blocks=723899 (Operator: asciilifeform)
watchglass: : ( Alive: (0.155s) V=99999 (/ Jumpers=0x1 (TRB-Compat.) Blocks=723899 (Operator: asciilifeform)
watchglass: : Alive: (0.154s) V=99999 (/ Jumpers=0x1 (TRB-Compat.) Return Addr= Blocks=723899 (Operator: whaack)
watchglass: : Alive: (0.204s) V=99999 (/ Jumpers=0x1 (TRB-Compat.) Blocks=723899
watchglass: : ( Alive: (0.259s) V=88888 (/ Jumpers=0x1 (TRB-Compat.) Blocks=723899
watchglass: : ( Alive: (0.308s) V=99999 (/ Jumpers=0x1 (TRB-Compat.) Blocks=723044
watchglass: : ( Alive: (0.328s) V=99999 (/ Jumpers=0x1 (TRB-Compat.) Blocks=723899
watchglass: : ( Alive: (0.654s) V=99999 (/ Jumpers=0x1 (TRB-Compat.) Blocks=723899
watchglass: : Alive: (0.477s) V=99999 (/ Jumpers=0x1 (TRB-Compat.) Blocks=723899
watchglass: : Busy? (No answer in 100 sec.)
watchglass: : Busy? (No answer in 100 sec.)
cgra: asciilifeform: why are gapped cements supported in your draft patch?
cgra: a minor point: for consistent only-public-methods-with-lock, would move cs_cement from currentEntry() to getExpected()
asciilifeform: cgra: for experiments where a .. b blox cemented, b+1 ... c not, c+1 .. d -- are
asciilifeform: cgra: currententry aint even needed, lotsa gnarl in there, will clean up
asciilifeform: not even convinced the lock is needed
cgra: asciilifeform: right (re lock likely unnecessary as cement now is)
asciilifeform: cgra: other thing is, orig. asciilifeform wrote this where only supported cements of 0..n. then realized that often enuff will want to use cement to 'catch up' a mostly-synced noad, and 0 .. max is pretty heavy (>50MB atm) , would like to be able to cement a .. b for arbitrary a<b height.
asciilifeform: cgra: hypothetically w/out lock could get inconsistent behaviour if loading cement takes place while cement's 'verify' or 'expectcement' happening
cgra refrains from further lock comments until has pressed item to look at
asciilifeform: there's at least 1 place where asciilifeform forgot to remove a lock and it gets invoked from inside same. surprisingly worx.
asciilifeform: (evidently trb's locks lib makes this a noop)
asciilifeform: testbed at height 221646 just nao.
cgra: asciilifeform: cement segment makes sense for catch-up yeah, not yet come up with a case where gapped beneficial
asciilifeform: cgra: prolly oughta eggog on multiple cements that aint consecutive.
asciilifeform: (conceivably sumbody may want to load cement in batches, esp. if e.g. we post'em in batches on tbf. but these oughta be consecutive.)
cgra: asciilifeform: trb's locks are recursive, yeah. sätöshi's been doing nested same-locks too
cgra: ("sätös", btw, in finnish, means "a haphazard, poorly designed or built creation")
asciilifeform: cgra: was thinking re parallelism -- can't think of how to even attempt it on the current turd, what with its single db cursor, ocean of locks, and the fact that block n might contain tx where inputs in anywhere 0 .. n-1
cgra: asciilifeform: the only part i was thinking the parallelization for, was that now it alternates between downloading and verifying, these don't overlap other than perhaps worth a 64k tcp buffer
asciilifeform: cgra: where decent (e.g. 1g/s) pipe on both sides, block downloads in 8msec. so not 100% certain this is worth the moving parts/complexity
cgra: asciilifeform: yeah, true. depends on whether can lock-in to a 100kb/sec node as well a 1gb/sec node, depending on the phase of the moon
asciilifeform: cgra: interestingly, as-written it seems to gravitate to pulling blox from fastest (at given time) peer
asciilifeform: given as how that tends to be the one who responds 1st
asciilifeform: an entirely accidental win
asciilifeform: w/out any purposeful coad to this end
cgra: asciilifeform: what signs of gravitation you've seen? not just the first node it started with, and still going with the same?
asciilifeform: cgra: seems to switch erry coupla hrs, but at no point thus far 'stuck with slow'
asciilifeform: granted this'll need plenty moar empirical test to say that in fact never happens
cgra: right
asciilifeform: so far all asciilifeform knows is that the sync is carrying on at ~same pace as does w/ 'eatblock' from disk in earlier experiments.
asciilifeform: however obv. these so far are the 'lighter' blox
asciilifeform does suspect that 'fastest' peer in fact delivers the asked block 1st, to the degree that the 'ask' in fact takes place in parallel
asciilifeform: ... and consequently moar likely to be the 1 who answers the ~next~ ask, etc
asciilifeform: the peculiar thing is that asciilifeform sees virtually no dupes from the lagging peers
cgra: asks, more or less, schedule with 2min intervals
cgra: no dupes prolly cuz always download and verification from first giver succeeded under 2min
jonsykkel: << cud be. havent looked into trb and its diseases too much yet, maybe cementing changes the equation, dunno. if run into wall ill rip out either db or hdd
dulapbot: Logged on 2022-02-18 08:46:58 cgra: << mech hdd with the bdbmay prove unfeasible, while still an interesting experiment
asciilifeform: jonsykkel: cement dun affect the verification time of valid blox, but does cut down on the cycles wasted on unwanted ones during sync
jonsykkel: from where does all the unwanted blox come from anyway?
asciilifeform: jonsykkel: inv responses
asciilifeform: normally you end up getdataing for whatever new items yer noad saw in incoming inv's
asciilifeform: in hopes that 1 of'em is 'next' block
jonsykkel: would think these invs are requested based on blokheight+1 or smth
jonsykkel: barely looked at code tho so dunno how it works
asciilifeform: jonsykkel: there's no involvement of blockheight in inv's or getdata's
asciilifeform: i.e. you get sent a block , and noad attempts to fit it as the next one, and succeeds or not
jonsykkel: how does peers know wat blok to send then?
asciilifeform: (in ancient pre-trb, incoming blocks were buffered, asciilifeform abolished this, see the 'orphanage' vpatches / discussions)
asciilifeform: jonsykkel: see the coad, there are 2 ways of requesting blox
asciilifeform must bbl
jonsykkel: ye ill read relevant parts
asciilifeform: ... 230k.
asciilifeform: cgra: was thinking, anuther (if ugly) form of 'parallel' would be to load'em 1st, ~then~ verify sequentially. imho not req'd tho, would likely save very little time on a reasonably-connected box
cgra: asciilifeform: prolly just gotta take time to see experimentally/think through staring at the code, whether significantly still could lock-in to a slomo-peer
cgra: hmm, i remember as if some trb peer used to be a slow-link one. could try making cement-mode start off with such a peer, and see if makes operator sad or not
asciilifeform: cgra: i'ma leave mine going for at least coupla wks or until fully syncs
asciilifeform: cgra: did try it w/ buncha randomly-picked peers, did not manage to get it stuck thus far
asciilifeform: prolly worth moar deliberate efforts if folx have time ( asciilifeform sadly does not atm )
cgra: asciilifeform: did you hit a slow node, or not sure?
cgra: i mean, random shots could've all hit on fast nodes, unless otherwise clearly didn't
asciilifeform: absolutely not sure
asciilifeform: if anyone has a 'known slow' noad -- plox to write in.
asciilifeform: cgra et al : revised draft vpatch for cement.
asciilifeform: (on top of yest.'s)
asciilifeform: currently running on testbed in place of previous. ~same logic, slightly less gnarl as discussed in cgra's earlier thrd.
asciilifeform: ... 250k+
asciilifeform: ( ~23 hrs since start )
crtdaydreams: wish I never ``upgraded''
asciilifeform: crtdaydreams: so don't upgrade it, wat.
whaack: do upgrade, by downdating, don't up_date_
whaack: upgrade<->update synonym is ~psyop
asciilifeform: wb whaack
asciilifeform: whaack: can do e.g. this, when you've the cycles.
dulapbot: Logged on 2022-02-16 00:31:42 whaack: so it'd be mighty nice to get the cement vpatch running in the near future
asciilifeform testbed at 263+k, no stalls thus far
crtdaydreams: << ``rolling release'' distro. a la void lincox
dulapbot: Logged on 2022-02-18 20:25:38 asciilifeform: crtdaydreams: so don't upgrade it, wat.
crtdaydreams: so not much choice. want to do LFS but dun want dep. hell.
crtdaydreams: dunno if /g/entoo is what it was cracked up to be, only installed it once and couldn't wrap my head around the package manager
signpost: gentoo isn't measured by whether you bothered to learn how to use it, lol
signpost: also inspect your wants; they're tangled in contradictory directions
dulapbot: Logged on 2022-02-17 21:39:04 jonsykkel: verisimilitude: red now, good shit
verisimilitude: I wanted to demonstrate the idea well, and so went with a design that minimized the number of tables and composition rules. This served me well when I realized I could turn the same tables into a parser, whereas with this design it's not so clear. The point is to minimize the code in favor of data.
dulapbot: Logged on 2022-02-17 21:39:12 jonsykkel: tho i fail to see why u didnt just do smth greek like
verisimilitude: I didn't review my words so carefully. I loathe parsing.
verisimilitude: Still, I turned the same tables into the inverse translator, say.
verisimilitude: This style of programming is particularly good at handling edge cases; compare it favorably to Common Lisp's EQL methods.
verisimilitude: Also, my program minimizes the total computation: there are divisions by one hundred and ten, and a modulo by fifty.
← 2022-02-17 | 2022-02-19 →