log☇︎
58200+ entries in 0.432s
mats: yeah, that sucks. i go to casinos because i enjoy the idea of robbing tourists, retirees, and chumps
mircea_popescu: they're mediocre, neither amazing nor terrible. but they're old, and stupid, and lazy. and not the sort of person i want to be around at all.
mats: i don't follow at all
mircea_popescu: mats i tried to go play at local casino. dumped my chips half hour in because i got this unbearable feeling im at a florida retirement home playing canasta with the inmates.
asciilifeform: i oughta have put this on record yea
asciilifeform: mircea_popescu: i already walked the blox on the node in question, found 0 peculiar orphans
mircea_popescu: anyway, i quoted the blocks by hash so you can check if those are the ones you're struggling with, as opposed to magicalorphans.
asciilifeform: i will readily admit that i dun have a proper model of how bdb liquishit works
mircea_popescu: lol yeah, well, i would put it past "people themselves" to keep archives.
asciilifeform: i wouldn't put it past anybody, to do anything
mircea_popescu: i mean what, they kept 5 years of history ?
mircea_popescu: historically the problem is "o noes, orphan chain", but i have nfi who would be owning or propagating orphan chains at that height.
asciilifeform: yeah i didnt think so
asciilifeform: i've ruled out oom, also
asciilifeform: but in so far as i can see, no satisfactory explanation
mircea_popescu: i don't specifically recall 168000-168002 being a heavy load in that sense
asciilifeform: this thing behaves precisely like trb sans locks patch, i think
asciilifeform: i dun think it is anything to do with that tx per se -- it is the drop that overflowed the barrel in pre-dblockspatch trb
mircea_popescu: see, cuz that's why i said "slow box". cpu starved.
asciilifeform: ( which i thought was mircea_popescu's implication earlier )
asciilifeform: mircea_popescu: prolly i oughta elaborate. sig verify is a blocking process, it doesn't timeoutfail
mircea_popescu: http://btcbase.org/log/2017-08-06#1694478 << i did read the log you pasted. ☝︎
a111: Logged on 2017-08-06 04:40 mod6: Second, I'm not sure how you want to make a Cuntoo out of BSD... we should revisit that later.
trinque: http://btcbase.org/log/2017-08-06#1694394 << portage will sit down on BSD. I plopped it onto openbsd sometime earlier this year. ☝︎
asciilifeform: i still gonna saw open the elf & see if inside is what's expected
a111: Logged on 2017-08-06 04:39 mod6: I'd like to get to the bottom of this!
a111: Logged on 2017-08-05 19:15 asciilifeform: midnight/'fish' dun work with the heathen shell either, i end up having to tar up whatevers and sftp'em in/out , takes 100x as long
a111: Logged on 2017-08-05 09:18 phf: kiss from a rose … this is tmsr radio! i'm waiting from your calls.
mod6: http://btcbase.org/log/2015-07-23#1210236 << I remember that we disagree even as to which block is the problem. ☝︎
mod6: Also, this is a non-deterministic problem, which adds to the frustration. You have a good candidate machine, it seems, to help get this resolved though. I'll dig through your logs a bot.
mod6: Second, I'm not sure how you want to make a Cuntoo out of BSD... we should revisit that later. ☟︎☟︎
mod6: I'd like to get to the bottom of this! ☟︎☟︎
a111: Logged on 2015-07-08 16:36 mod6: <+gernika> mod6 I've attempted syncing on OpenBSD again and am now past block 168000 and have reached 185126. It's going very very slowly though. << good to hear though
mod6: I seem to remember this being specific to BSD, and in non-deterministic form. And looks like gernika for instance just simply resync'd and it seemed to not hit it again, for reasons yet unknown: http://btcbase.org/log/2015-07-08#1193289 ☝︎
mod6: Look. First off, no I don't believe we ever found the cause of this. I remember pulling my hair out trying to figure it out -- there are logs indicating as much.
asciilifeform: i'ma go to bed because if i keep at this, will pop a blood vessel somewhere.
mod6: I'm confused, are you saying that you're not interested in making a Cuntoo then?
asciilifeform: naively thought 'i'll start with the smallest trb node!'
asciilifeform: i'd like to get OFF linux.
mod6: I just rolled in, gimme some time to catch up and figure out whats what.
asciilifeform: if i am mistaken, mod6 et al plox to say when and where it was resolved.
a111: Logged on 2015-07-23 01:10 mod6: we saw stuff like that before with the 168`001 Verify Signature fail too. most of the time it failed for us... the three of us who were independantly testing it. But sometimes, it'd pass. Maybe 30% of the time. I was pulling my hair out.
asciilifeform: i am using literally the same deps dir as for past 2y.
asciilifeform: mod6: i've been 'seeing' for ~3h now
asciilifeform: all this time i thought there were reproducibles. but it is nonsense to speak of reproducibles in 200Mb of liquishit dep that does whatever the fuck it wants
asciilifeform: i am increasingly of the notion that i can't rreason about ANY of it
phf: well, if i were approaching this, i'd replay to 167998 or so, setup a script to ensure that every time i start trb it starts from that state. i would then see if on forward play it would wedge. i would then investigate what is the nature of wedging, and slowly instrument the code along the various paths to tell me where exactly it decides to stop doing the right thing, etc.
phf: i don't remember every suggesting anything remotely similar. my suggestion would be to debug it, and solve the problem, rather than "mp's fix somehow magically resolves it"
asciilifeform: BingoBoingo: i was reading plusminusweek of each of those search res for past 2h
asciilifeform: ( i have 0 instances of wedged bring up on linux since mircea_popescu's bdb patch, in 30 or so shots on machines in various spots )
asciilifeform: i duneven know if to blame bsd ( how..? ) or the imbecile's sync algo where all depends on who first node syphilitically fucks on warmup
asciilifeform: i walked the logs , found no record of a nailed root cause or finalsolution
phf: i remember people wedging around there, but i didn't personally observe it
asciilifeform: i seem to recall.
asciilifeform: and been a while since i synced from empty
asciilifeform: http://btcbase.org/log/2017-08-05#1694293 << i dun like relying on contents of rotten hdd any more than i have to ☝︎
mod6: <+phf> that's because you didn't try to simply use the patch to makefile that i posted on the list << i've had a trb openbsd since you posted this yes.
asciilifeform: also at some point i'ma document this build and put own seal on phf's quite useful bsd fix.
asciilifeform: i do not know of anything that would qualify as a final solution for this.
asciilifeform: however one of the things that i always had ill ease about re pgp challenge-responsetrons , is that enemy who somehow substituted one, can get you to decrypt a message of his choice. (e.g. last year's launch codes.)
phf: which reminds me that i need to regrind my shiva swank patch, which is broken
asciilifeform: incidentally i have nfi how you got bdb to build, bsd libtool seems to be broken , tries to write to /include and barfs ( rather than to the demanded local dir )
asciilifeform: so i assumed it was a dud
phf: of course, why would i suggest it otherwise? :o
phf: that's because you didn't try to simply use the patch to makefile that i posted on the list
asciilifeform: i had a year+ of unsuccess with openbsd
asciilifeform: i have this memory of phf barfing
phf: binds bunch of keys to "users come to expect", including tab completion to ^I
asciilifeform: i have busybox-based linux2.4 shitboxes with 8M of disk that behave better than this.
asciilifeform: midnight/'fish' dun work with the heathen shell either, i end up having to tar up whatevers and sftp'em in/out , takes 100x as long ☟︎
asciilifeform: if i had to pick b/w not having indoor shitter and not having tab completion, i'd pick the former. ☟︎
asciilifeform: i have nfi why anyone still tolerates this sort of thing.
asciilifeform discovers that NOTHING AT ALL works under netbsd for ~building~ ( i had 2yrs ago build a 'stator' FOR netbsd, UNDER linux, worked... )
a111: Logged on 2017-08-05 17:39 asciilifeform: later on i'ma pull the drive & try guessing the magic params and writing'em in on other box.
asciilifeform: lobbes: plz examine what you sent , because i dun see anything of the sort.
lobbes: http://btcbase.org/log/2017-08-05#1694201 << eh? Reread message I sent (maybe I can't word things). There was a mistake that benefits me, not you :) ☝︎
asciilifeform: later on i'ma pull the drive & try guessing the magic params and writing'em in on other box. ☟︎
a111: Logged on 2017-08-04 23:12 asciilifeform: it dun need replacement per se, was dead disk. i took the downtime as chance to try netbsd on same iron, when new disk came. iirc i explained this upstack.
asciilifeform: in other lulz, i DID get netbsd going on http://btcbase.org/log/2017-08-04#1694103 box. but sad part is, it is useless, because 1) no usb 2) nic needs config 3) no way to connect kbd... ☝︎
phf: kiss from a rose … this is tmsr radio! i'm waiting from your calls. ☟︎
phf: a quite type eh, well, it's 4:30am, tmsr, i'm waiting for your calls, meanwhile, .. frankie bones, the man, the legend, on … tmsr radio. https://www.youtube.com/watch?v=tZbogMbh3iM
phf: i had a viewing of olympia couple of days ago at my place.. i mean, it's not any kind of a movie..
mircea_popescu: you might have to go through kgb archives to locate a print. i rather doubt the internet has such doubleplusungood material.
phf: i might watch it at some point, but i'm downloading Caligula right now.
phf: huh, i haven't
mircea_popescu: and since i'm doing a nazi film retrospective, asciilifeform phf ever saw der herr der welt ? 1934 sf! robots! death rays!
asciilifeform: well i have. currently, by expecting 1 fewer trb testbed..
asciilifeform: 'i want a glass of beer' 'here is some sand, a plot of land..'
asciilifeform: which to date i have found impossible in human qties
asciilifeform: ah i thought implication was 'mod the board'
asciilifeform: extra infuriating detail -- i dun specifically need x86 for this , trb runs ok on arm. BUT all extant arms have soldered down (and insufficient) ram.
asciilifeform: it dun need replacement per se, was dead disk. i took the downtime as chance to try netbsd on same iron, when new disk came. iirc i explained this upstack. ☟︎
asciilifeform: possibly, i'ma try it on this here one i've nailed to a plank
mircea_popescu: i thought the problem was the intel bios lock + the inept usb3 combo, rather than the simple presence of usb3 ?
mircea_popescu: yes, but i expect you can turn it off with a proper bios ?
asciilifeform: ( apparently i have one here ..! )
a111: Logged on 2017-08-04 21:13 asciilifeform: i dun even pin this on the netbsd people, they are the dangling corpse in the relationship with wintel
mircea_popescu: i guess.
asciilifeform: realize, i dun have the iron i have because i found it on he sidewalk.
asciilifeform: i'll buy dozen...