log☇︎
83700+ entries in 0.056s
diana_coman: ofc if dd never chokes, dunno, will look at how they do it
phf: mircea_popescu: well, we had conversations about esoteric societies in the past, and there's a reason for why the logs are public and everything that follows
a111: Logged on 2014-11-30 06:31 mircea_popescu: like the stuff discussed above re usg agency redhat, fuycking up linux. EXACTLY the stiuation of the giant ruining a chair.
mircea_popescu: phf my problem is this : on one hand i'm trying, in jules' words REALLY REALLY HARD, to not be the fatass in http://btcbase.org/log/2014-11-30#938314 snuffing the life out of everything ; on the other i just can't manage to distinguish the proposed "x without y" from the broad scheme that ruined western civilisation, "have wife without beating her". ☝︎
phf: unfortunately the secret societ of illuminated fraudsters managed to stay secret all 5 minutes, before being publically exposed in the logs
a111: Logged on 2018-06-20 20:33 ben_vulpes: diana_coman: why does it need to be wholly separate machine? i think something might have flown over my head
diana_coman: mircea_popescu, well, it *does* answer that question: http://btcbase.org/log/2018-06-20#1827889 ☝︎
phf: in this particular case though, it's a joke
phf: mircea_popescu: it's an adam wieshaupt quote, and i take its meaning to be in line with the stereotypes about his organization, control through influence rather than direct domination
mircea_popescu: aren't i glad we tested all this.
diana_coman: basically if I don't manage to reproduce it on any other machine, it would seem it's potentially to do with that specific system
diana_coman: rather: it read 3 times (it was 4 octets each time )
diana_coman: so, the set_usb_attributes was commented out; I cleaned everything and did a fresh build; ran the tests and... it read 3 octets and then it blocked
diana_coman: right, machine is freshly up;I'll first run the .sh script just in case and try it with dd
asciilifeform: (~= 'for erry smart-arse, a threaded cock will be found' ) ☟︎
mircea_popescu: phf if i may be so bold, why "control" without "dominate" ? seems these be terms of art, what do they mean ?
mircea_popescu: apparently this just happened.
mircea_popescu: * Topic for #fraudsters set by phf!~phf@unaffiliated/phf at Tue Jul 31 10:12:25 2018
mircea_popescu: * Topic for #fraudsters is: The order of the day is to put an end to the machinations of the purveyors of injustice, to control them without dominating them.
asciilifeform: and ought to ring all of the alarm bells.
asciilifeform: a FG that produces , under normal conditions, 0 output for, say, 30 seconds, is indicative of dead iron.
diana_coman: asciilifeform, it does sound like I'll have to
asciilifeform: this being said, if you implement a timeout for the blocking reads, you will not have zombie problem.
asciilifeform: ( asciilifeform did not write the linux i/o subsystem ; nor the pl2303 kernel mod ; and will readily admit that they are sad. and if anyone has idea for some other means to connect a 115200 baud box to machine, that does not suffer from the weakness of these, i'm as always all ears )
asciilifeform: well not each time, but to see if the 'init breaks the dongle' hypothesis is troo.
diana_coman: omfg resetting the test server each time
diana_coman: so uhm, just resetting the tty is not enough?
asciilifeform: to properly debug this item , you will sadly have to restart the box .
asciilifeform: unix i/o is retarded, if blocking read blocks, it gives you a zombie process , and the next process you start that tried to read same tty, will also become zombie ☟︎☟︎
asciilifeform: i think we have the answer
asciilifeform: diana_coman: when these are stuck, how do you kill'em ?
diana_coman: right you are; not that it ever went there
asciilifeform: if tty ever produces interrupt, ipso facto FG init was not successful
asciilifeform: http://btcbase.org/patches/eucrypt_manifest/tree/eucrypt/smg_rsa/truerandom.c#L65 << incidentally this is erroneous. a correctly-inited FG will never produce interrupt ( the tty ~must not~ interpret 0x03 as control char, it must return all octets verbatim )
diana_coman: asciilifeform, I commented out the set_usb_attributes so basically it opens and calls fcntl to make it blocking but that's it; it took a bit longer to get stuck but it still did
asciilifeform: btw you will probably want to make a timeout mechanism, to ring alarm if FG ever does die, rather than hanging
asciilifeform: diana_coman: comment out the init, and fire a shot.
diana_coman: phf, ah, might be, thanks
asciilifeform: diana_coman: can almost certainly rule out iron problem then
diana_coman: well, 1st test: changed to 2nd FG on musl-system; checked and it reads fine with dd from console; ran the tests of eucrypt , it read 4 and then it got stuck
asciilifeform: ( nobody's yet reported a wedged FG on the standard dd-powered test. )
asciilifeform: from my current reading of diana_coman's code, the only major diff b/w the official manual's test scenario, and diana_coman's, is the init thing.
asciilifeform: diana_coman: i agree, this kind of thing is absolutely impermissible, and gotta get to the bottom of it.
diana_coman: yes, and at any rate if this can /will happen on various cables or simply at 100th setting
asciilifeform: BingoBoingo: before you go to swap cabling, let's first see if the known sadness of pl2303 driver is the culprit.
BingoBoingo: diana_coman asciilifeform: We did recieve a pile of new USB ttl cables. Swapping the cables for fresh ones is a troubleshooting option.
diana_coman: anyway, let's see: you suggest I take out the init, just open and read; set it up outside and then try; can't hurt giving it a try at least
diana_coman: asciilifeform, I even have the .sh + set it in cron, yes; the thing is that code has no idea so it would logically set it up as it wants it but...
asciilifeform: ( the exact pattern is in the nosuchlabs.com and printed manual )
asciilifeform: generally you want to init it once, on coldboot.
diana_coman: asciilifeform, ugh; it *can* be, because yes, it gets initialised many times
asciilifeform: http://btcbase.org/patches/eucrypt_manifest/tree/eucrypt/smg_rsa/truerandom.c#L84 << seems like you re-init the usb dongle every time you read. this is not recommended, i've encountered a chinese ttl plug that wedges if you init it one too many times
diana_coman: will go and try 2nd fg and other boxes
diana_coman: asciilifeform, fwiw I am trying to get it on my local box (non-musl) and so far it's working perfectly fine
asciilifeform: ( i have yet to witness this wonder. but there's always a first time. )
asciilifeform: gotta rule out the possibility of a dead FG.
asciilifeform: and , while you're at it, from the other FG in the musl box.
asciilifeform: diana_coman: see if you get same horror on the old, non-musl box
diana_coman: it should be, yes; as far as I can tell at a quick look at truerandom.c it is too
asciilifeform will look there.
diana_coman: asciilifeform, smg_rsa/truerandom.c does the whole stuff really
diana_coman: for the other, I had the FG init already
diana_coman: uhm, for one thing: it's init in c code as well so..uhm
asciilifeform: i suspect buggy tty init ( e.g. wrong baud ) , in which case the data returned is also rubbish
diana_coman: ah, quickly, no need to read 2-3 GB really
diana_coman goes to read that code again maybe something is messed up there
diana_coman: so far it's been driving me crazy on that particular box, haven't had it/tried it somewhere else yet
asciilifeform: i.e. does this reliably happen on both of your FG boxen ?
asciilifeform: just how often is 'at times' ?
diana_coman: fwiw I have this on smg testing server, proto-cuntoo
diana_coman: at times it gets stuck and not even in same place or anything
diana_coman: asciilifeform, yes, get eucrypt and run the tests for smg_rsa, something like ./tests 11 11 (i.e. 11 times test no 11) ☟︎
asciilifeform: diana_coman: is this using the code currently published in dianacoman.com ?
diana_coman: asciilifeform, hm, that suggests maybe one read remains somehow hanging? ugh
asciilifeform: diana_coman: this is immediately interesting and i'd like to replicate
diana_coman: hm, now the reading of octets from FG via EuCrypt randomly gets totally stuck and I can't even quite understand *where* ; wtf; I seem to recall someone else had some similar problem but I can't seem to find it atm; ave1 ? phf ? asciilifeform ?
a111: Logged on 2018-07-31 12:47 asciilifeform: !Q later tell esthlos in e.g. http://summaries.logs.esthlos.com/#2016-03-28 you link to kako's log ; i recommend against this , it is not a faithful record of the actual text ( last yr he took to monkeying with it via perlism and possibly also manually )
asciilifeform: right, the inbandism is in the old vdiff layer, rather than unix diff proper
a111: Logged on 2018-07-31 13:17 asciilifeform: but folx attempting to reverse-grind ch11 with old vdiff.sh will inevitably see barf, and there is not currently any fix other than the above.
asciilifeform: ( i'd hope that new vtron format will abolish all inbandism. )
asciilifeform: but folx attempting to reverse-grind ch11 with old vdiff.sh will inevitably see barf, and there is not currently any fix other than the above. ☟︎
asciilifeform: this has no effect on any extant vtron ( the resulting patches are correctly formatted ) .
asciilifeform: ( instead of the old awk 'm = /^(---|\+\+\+)/ ... , uses awk 'm = /^(--- a\/|\+\+\+ b\/)/ ... )
asciilifeform: btw i oughta mention , i had to resort to a modified vdiff.sh : http://p.bvulpes.com/pastes/rB9AD/?raw=true for ch11 , as the ada comment syntax causes inbandism barf with classic vdiff.sh when deleting or modifying the comment headers at the start of ffa modules
asciilifeform: did i ever mention how phf's viewer makes patches a joy to reread !
asciilifeform: http://btcbase.org/patches/ffa_ch11_tuning_and_api << for the l0gz.
asciilifeform: phf: ty!
asciilifeform: d00d moved on to the 'smear shit on the walls' stage of his disease a while ago.
lobbesbot: phf: Sent 10 hours and 49 minutes ago: <asciilifeform> plox to eat ch11 into btcbase .
a111: Logged on 2016-03-28 13:11 mircea_popescu: and so, this is the end for this particular irc channel as a venue for tmsr. the irc festivities are moving over to #trilema ; with a more selective lordship list and improved tools all around. you're welcome to join - but leave the fiat mind behind, lest it drag you too back down into the swamp.
phf: in fact particular line http://btcbase.org/log/2016-03-28#1440677 has been changed in kako's log, hxxp://log.bitcoin-assets.com/?date=28-03-2016#1440677 spot the difference! ☝︎
lobbesbot: asciilifeform: The operation succeeded.
asciilifeform: !Q later tell esthlos in e.g. http://summaries.logs.esthlos.com/#2016-03-28 you link to kako's log ; i recommend against this , it is not a faithful record of the actual text ( last yr he took to monkeying with it via perlism and possibly also manually ) ☟︎☟︎
a111: Logged on 2018-07-29 16:12 mircea_popescu is actually quite curious if esthlos managed to do two days yest :D
esthlos: http://btcbase.org/log/2018-07-29#1838186 << 2016-03-23 may be the longest log I've read yet. these old logs are swamping me ☝︎
lobbesbot: asciilifeform: The operation succeeded.
asciilifeform: !Q later tell phf plox to eat ch11 into btcbase .
asciilifeform: ^ the largest patch since genesis ( >80kB ) but unfortunately could not be avoided.
deedbot: http://www.loper-os.org/?p=2547 << Loper OS - Finite Field Arithmetic. Chapter 11: Tuning and Unified API.
a111: Logged on 2014-03-18 01:19 asciilifeform: ninjashogun: suggested experiment. take a radio transmitter (a household walkie-talkie will do) and transmit, with a computer sitting nearby.