mircea_popescu: http://btcbase.org/log/2018-11-13#1872032 << hey, sinology very valid topic of study at republican ministry of foreign relations.
a111: Logged on 2018-11-13 19:48 asciilifeform: it's evidently very diff animal than the zimbabwe that got its arse handed to it in '30s
mircea_popescu: http://btcbase.org/log/2017-11-29#1744472 << heh. aaanyway, it's not that g_l had necessarily a bad grasp of priors, but he did take them to strange, sometimes contorted conclusions.
a111: Logged on 2017-11-29 21:12 gabriel_laddel: MP is the MP of our generation
mircea_popescu: http://btcbase.org/log/2018-11-13#1872093 << i utterly don't understand this "stealing" mindset. http://btcbase.org/log/2013-09-13#307975
a111: Logged on 2018-11-13 22:22 asciilifeform: said only 1 thing, sumthing like 'motherfucker, you stole my name'
a111: Logged on 2013-09-13 08:59 mircea_popescu: not like she's made of soap, to wear out...
mircea_popescu: ahh, but what a productive monday this has been!
a111: Logged on 2018-11-14 00:18 mod6: 1) My toaster has a cancel button
mircea_popescu: http://thebitcoin.foundation/v/ << i suppose looking there would have made it obvious (check it out btw, 20th feb 2016, july 207, 22nd feb 2018!) ; but
mircea_popescu: diana_coman where;d you end up with ye 2017 version from ? just used local copy, missed update ?
mircea_popescu: "GDPR" heh,.
mircea_popescu: who the fuck would even consider such shaite.
BingoBoingo: The same sort who'd upgrade without knowing why
BingoBoingo: Anyways: Blog update - I think I've found a Rockchip friendlier mysql config. Not expanding to eat all the RAM at the moment. Compiling the rest of the moving parts.
BingoBoingo: Finding seems to be Innodb is a poor default
BingoBoingo: Setting MyISAM seems to bring Mysql's RAM usage closer in line with the size of the db
BingoBoingo: The pain comes in settin MyIASM as a default without doing the instictive right appearing thing which is disable Innodb completely.
diana_coman: mod6, I've put the vpatch, neh?
BingoBoingo: Completely disabling Innodb pisses off the "emerge --config dev-db/mysql" script
diana_coman: the genesis IS on 99994K yes, the next vpatch upgrades it to 99993K and only THEN my own vpatch changes it to use Keccak and vtools
diana_coman: http://btcbase.org/log/2018-11-14#1872169 -> as ^ ; now I'm not sure if anyone actually look at the 2nd vpatch and hence it really is an old version that's there or just got hang up on the fact that I kept to preserve some history and hence genesis+vpatch to version 3
a111: Logged on 2018-11-14 05:23 mircea_popescu: diana_coman where;d you end up with ye 2017 version from ? just used local copy, missed update ?
diana_coman: fwiw the keccak-version of v (i.e. pressing the tree I published all the way to its leaf) IS the corrected one re pressing order ; later today I'll do a diff with precisely the versions mod6 has at http://thebitcoin.foundation/v/ but going by version number I really don't see what "old version" are you saying
diana_coman: if anything, I suppose I could have gotten the genesis with an earlier version
diana_coman: mod6, I don't see any comment from you on my blog, what happened? (re http://btcbase.org/log/2018-11-14#1872143 )
a111: Logged on 2018-11-14 00:20 mod6: 2) http://btcbase.org/log/2018-11-13#1872126 << diana_coman I tried to leave you a note on your blog. But seems that you've based the genesis off of my vtron version 99994K, but there is a newer version: http://thebitcoin.foundation/v/V-20180222.tar.gz http://thebitcoin.foundation/v/V-20180222.tar.gz.mod6.sig Which is denoted as version 99993K.
diana_coman: right, doing the diff with the archived versions at http://thebitcoin.foundation/v/ yields: my genesis is precisely http://thebitcoin.foundation/v/V-20170317.tar.gz; the version 3 aka after applying the .vpatch http://ossasepia.com/vpatches/v_mod6_99993.vpatch does bring in the code modifications of http://thebitcoin.foundation/v/V-20180222.tar.gz, but not the docs changes
diana_coman: so to keep this fully aligned, I'll regrind the last 2 patches so that the docs changes are carried over as well; as a result: genesis = http://thebitcoin.foundation/v/V-20170317.tar.gz; 1st patch => http://thebitcoin.foundation/v/V-20180222.tar.gz; 2nd patch => using vtools & keccak instead of sha
diana_coman: and done: the updated .vpatch files and starter_v.zip + sigs are all up; I've checked them on my RK; genesis is the same and result is identical to V-2017; the result of 99993 .vpatch is identical to V-2018; the result of keccak_vtools vpatch is to update BOTH docs and code; re docs, I've nuked the user manual as I won't maintain it and it's becoming confusing due to being out of date; I've updated the quick_guide however, mainly for 1st t
diana_coman: ime users really; re .zip file: the v in there is precisely what one gets by pressing my v_keccak_vtools.vpatch
diana_coman: and yes, my test went precisely on this path: get the .zip first and then use that to press the vpatches and then check results + whether they are the very same
diana_coman: hopefully this is now finally clearly set for future maintenance of any sort, but let me know if there is any other trouble you see with it
bvt: asciilifeform: have you seen https://github.com/Componolit/libsparkcrypto ? their modexp code looks sad, but other components may be interesting
asciilifeform: bvt: https://github.com/Componolit/libsparkcrypto/blob/componolit/src/shared/generic/lsc-bignum.adb << holyfuq, obfuscated ada contest !
asciilifeform: i am impressed with the sheer volume of liquishit
asciilifeform: i think just his bigendian vs littlendian speshulcases (why he has any?! ffa doesn't..! ) weigh moar than all of ffa together
asciilifeform: https://github.com/Componolit/libsparkcrypto/blob/componolit/src/shared/generic/lsc-bignum.ads << even the declarations suffer from advanced elephantiasis
asciilifeform: tldr : yet-another nonconstanttime , notfitinhead piece of shit, valuable exhibit for kunstkammer of 'how not to ada'
asciilifeform: and 'how not to crypto', pretty good illustration of the tension between 'machine proofs' and 'fits in head' (author resolved wholly in favour of the former and took a tall shit on the latter)
asciilifeform: bvt: in all srs, thx for digging it up, and if anybody finds another , plox to also post, there is room in the kunstkammer .
mircea_popescu: asciilifeform oh i see, you redid the whole tree, that was a patch
mircea_popescu: BingoBoingo trilema is mostly on myisam.
mircea_popescu: i meant diana_coman ah i see, you redid the whole tree, that was a patch.
mod6: tarting MDMCommandQueueMonitor through JMX
mod6: 2018-11-13 15:35:03,098 [INFO ] [0.101.22.52] [MDMCommandQueueMonitor ] - Cancelling existing run of MDMCommandQueueMonitor
mod6: ah jeeze
mircea_popescu: o hai mod6
a111: Logged on 2018-11-14 07:55 diana_coman: the genesis IS on 99994K yes, the next vpatch upgrades it to 99993K and only THEN my own vpatch changes it to use Keccak and vtools
mod6: http://btcbase.org/log/2018-11-14#1872187 << no worries, I tried to post a comment on your blog post from the train, it may have not went through.
a111: Logged on 2018-11-14 08:05 diana_coman: mod6, I don't see any comment from you on my blog, what happened? (re http://btcbase.org/log/2018-11-14#1872143 )
mod6: http://btcbase.org/log/2018-11-14#1872191 << Totall get it that you don't want to maintain the user docs, I do disagree that they were are out date tho. I did a diff between them from the 99994K and 99993K versions and I did update it for the Feb release.
a111: Logged on 2018-11-14 10:54 diana_coman: and done: the updated .vpatch files and starter_v.zip + sigs are all up; I've checked them on my RK; genesis is the same and result is identical to V-2017; the result of 99993 .vpatch is identical to V-2018; the result of keccak_vtools vpatch is to update BOTH docs and code; re docs, I've nuked the user manual as I won't maintain it and it's becoming confusing due to being out of date; I've updated the quick_guide however, mainly for 1st t
mod6: Anyway, *nod* looks good. I'll try to test it one of these days when I have a spare minute.
mod6: lol, o hai mircea_popescu
mod6: anyway, srsly bb.
diana_coman: mod6, I meant out of date wrt to my vpatch i.e. keccak hashes
diana_coman: if you notice, I said out of date at 3rd vpatch, NOT before; and yes, 2nd vpatch includes them precisely because they are at that point still perfectly fine
diana_coman: the out of date also refers to the fact that meanwhile V has a broader scope really than trb code
diana_coman: onth I kept the quick guide and updated it to point users to a. use the bloody help of V as it's quite useful as it is! b. ask if they get stuck, wtf
diana_coman: anyway, if anyone wants to maintain the full & detailed manual, I will happily sign their .vpatch with it,sure
mod6: <+diana_coman> mod6, I meant out of date wrt to my vpatch i.e. keccak hashes << ahh, gotcha
mod6: thanks for doing all this work diana_coman, I appreciate it. it's long over do for a v'ing. :]
asciilifeform: ohai mod6 , diana_coman , mircea_popescu
BingoBoingo: <mircea_popescu> BingoBoingo trilema is mostly on myisam. << ty
diana_coman: mod6, re comment, it seems it got lost, I could not find it anywhere so not in queue nor anything
diana_coman waves to asciilifeform
asciilifeform: ohai diana_coman
diana_coman: the table with FFA patches looks great; I'll look into carving again some space to re-start on it
asciilifeform: diana_coman: lemme know if you run into anyffing to any degree confusing.
asciilifeform: ( iirc you already ate the most difficult material )
diana_coman will come and complain loudly if confused
asciilifeform: so far conveyor is on schedule.
diana_coman: but it might still take a while to get back to it
asciilifeform: i in turn am working through diana_coman's oaep articles
asciilifeform: ch. 10 in particular
asciilifeform: it's 1 of the coupla items i dun have yet
diana_coman: meanwhile the oaep got sorted better as part of smg comms really (i.e. only ada calling c, no back and forth dance and that gets rid of a LOT of confusion)
asciilifeform: fortunately i dun have ~that~ problem ( instead i have others, lol )
asciilifeform: i was hoping to avoid baking hashing into ffa/p , but loox like it isn't escapable if we're doing oaep
diana_coman: problems are never in short supply, certainly
asciilifeform: the fixed structure elements in oaep bother asciilifeform . ( initially was gonna do destructurization differently : each bit of payload turned into 4 via rng xor, then fisher-yates shuffle, then the 'deshuffling' binarysort code is appended to message. you can prove that the output is 'all or nuffin' transform. )
diana_coman: my understanding was that nobody actually LIKES oaep all that much but it's (again! another one of those!) the thing we have (as opposed to the thing we might wish for)
diana_coman will go afk too
asciilifeform: diana_coman: correct
asciilifeform: diana_coman: it's the most economical, at the very least, algo that sorta does the job
asciilifeform: ( that is, oaep )
asciilifeform: in s.mg's incarnation, carries 245 octets of payload per 512 rsablock, i.e. ~48% efficient
asciilifeform: and hence prolly also is The Right Thing for other space-constrained applications, e.g. udptronic gossipd
asciilifeform: but for general-purpose pgp replacement, conceivably could use something 'hungrier' but with 0 fixed structural bits. i'ma invite mircea_popescu et al to consider the subj.
asciilifeform: ideal algo imho would carry at least 5 bit of entropy for erry bit of payload, and in such a way that all bits are 0/1 with exactly 0.5 prob.; and such that flipping one bit of ciphertext flips at least 1/2 of the output bits.
asciilifeform: ( i.e. when ciphertext passed through e.g. 'dieharder' it would be indistinguishable from FG )
mod6: <+diana_coman> mod6, re comment, it seems it got lost, I could not find it anywhere so not in queue nor anything << not a problem at all. we've resolved it anyhow. thanks for looking.
deedbot: http://qntra.net/2018/11/us-our-military-edge-has-eroded/ << Qntra - US: Our 'Military Edge' Has Eroded
BingoBoingo: In local news, Prison Mall had a fire. Apparently happens on a roughly annual basis https://www.elobservador.com.uy/nota/incendio-en-shopping-punta-carretas-obligar-interrupcion-del-transito--20181114983
deedbot: http://bingology.net/2018/09/03/hello-world/ << Bingology - BingoBoingo's Blog - Hello world!
BingoBoingo: ^ Restoring content, apologies for any noise
lobbes: "el incendio anual" heh
trinque: BingoBoingo: should I null-route your feed for a bit?
BingoBoingo: trinque: Please do, will ping when shit is restored
trinque: can't get to it immediately, in about an hour or two can
BingoBoingo: trinque: ping me at your leisure to announce the silence
trinque: BingoBoingo: done, let 'er rip
BingoBoingo: <lobbes> "el incendio anual" heh << Mind that before becoming a mall in a more expensive neighborhood than the Datacenter's, a good chunk of the present legislature or their parents were locked up there for being commie scum
asciilifeform: BingoBoingo: didja end up having to glue yer blog back together from archived pages ?!
BingoBoingo: asciilifeform: Some parts, yes
asciilifeform: i did say 'let's errybody move to new rk disks asap' , neh
asciilifeform: dunno why BingoBoingo felt compelled to tempt the fates
BingoBoingo: On the plus size, I did learn that using MyISAM instead of Innodb actual RAM available on the Rockchip for not MySQL
asciilifeform: mod6 pleez let me know when we can swap yours, iirc you're the last rk fella on old disk
asciilifeform: also folx, pleeez make backups! i should not even have to remind. there is not such a thing known presently as an immortal disk.
asciilifeform: !Q later tell ben_vulpes didja find the eggog ? you estimated 'wednesday', and the day is nearly at end..
lobbesbot: asciilifeform: The operation succeeded.
asciilifeform: BingoBoingo: if we ever build a rk-like board from the ground up, i'ma give it at least mirror raid. but presently afaik no such thing can be had.
asciilifeform: i was almost gonna say 'we're the first to put arm64 in a dc rack' but then recalled that jurov, years ago, saw such a thing somewhere
asciilifeform: jurov do you recall what it was they used ? ( or was it custom )
asciilifeform: btw for many yrs i've searched for the obvious simple gadget, a y-shaped thing that'd turn 2 or moar usb sticks into an iron raid. but still not found, dun seem like anybody ever made.
asciilifeform: ( plenty of folx made 'soft' raid, but those imho are worse than useless )
asciilifeform: http://btcbase.org/log/2018-11-15#1872279 << currently i know veeery little about mysql ( always used postgres, and at this point know embarrassingly much re the internals and tuning knobs ) -- but iirc mp's-wp requires specifically mysql, so prolly doomed to study it at some point
a111: Logged on 2018-11-15 02:09 BingoBoingo: On the plus size, I did learn that using MyISAM instead of Innodb actual RAM available on the Rockchip for not MySQL
asciilifeform: he did pick it for a logical reason, but i cannot currently recall what it was ( prolly detailed in l0gz )
BingoBoingo: asciilifeform: It's what wordpress expects. Otherthings can be forced into place at substantial cost.
asciilifeform: phuctor ( and in particular, some of the 'heavier' / unusual pheatures, like search ) i baked specifically around postgres.
asciilifeform: possibly 1 of these days i oughta publish my kludge for making ancient wp go on postgres; but it isn't half as polished as mp's and i dunno that anyone would win from cribbing it
asciilifeform: i view it rather like (i picture) mircea_popescu views his 'mpb' item
BingoBoingo: Changing the storage engine has resulted in a more than 10x reduction in RAM used
BingoBoingo: From eating more than half the Rockchip's 2gigs to ~130 megs
asciilifeform: BingoBoingo: fwiw postgres doesn't, 'out of the box', have the runaway ram problem. ( it had exact opposite -- i had to coax it into actually making constructive use of dulap III's very plentiful ram )
BingoBoingo: Consider Phuctor is a sorta bespoke thing. DB software architect can't antipate a Phuctor and how its filled. On the other hand most mysql installs power wordpress.
asciilifeform: imho people should not default to runaway-ram
asciilifeform: it's unseemly
asciilifeform: erry proggy should at the very least take a param for max ram guzzle
asciilifeform: ( and behave gracefully when limit hit )
asciilifeform: esp. a wwwtronic thing, where there is a readily-available graceful failure mode ( make connector wait a few sec for a free slot )
BingoBoingo: The failure mode under stress was an attractor to lighttpd, but... configuring it is a pain
asciilifeform: BingoBoingo: have you found approx how much ram it eats per request ?
asciilifeform: ( seems , at least by my lights, uncharacteristically hungry... does it really take a coupla MB of working ram , per GET , to serve up a blog ? )
asciilifeform: also iirc diana_coman and hanbot both have mp's-wp on rk , and i dun recall either of'em ever reporting OOM
BingoBoingo: I have not. My understanding of how it worked was it sat in a failry consistent RAM footprint as a running process and played goalie shoving the blog to php-fpm
BingoBoingo: hanbot is on the shared machine
asciilifeform: pretty sure that diana_coman is on rk tho
BingoBoingo: Yeah, lobbes as well.
BingoBoingo: Anyways, figuring out chron is now high on the todo list
asciilifeform: BingoBoingo: cron ?
BingoBoingo: Yeah, timed mysql dumps
asciilifeform: i dun expect it'll be esp painful in your case, yours wont be 30+GB
asciilifeform: ( current mass of compressed phuctor snapshot )
BingoBoingo: Several orders of magnitudes less
BingoBoingo: Thankfully Qntra has a backup button, but with mp-wp I gotta dogfood it, because it is what I will be asked about