What, are ideals and perfections not *things* to work with? No? Why not, after all, they'd be great to work with by definition! And in all probability, they would also reduce "work" to entirely pure pleasure since it would all become just a matter of sliding one perfection on top of another and through the needle hole of just a few ideals scattered about for a pleasing effect. No more stables to clean, no more swamps to drag one down, no more towers of shit and no more uncertainties either, only hard guarantees of goodness, wouldn't you like that?
At first pass the enthusiasm still carries me over and I would too, I can tell you. But then that's the thing with me, there's always a second pass1 and in this second pass the air-headed enthusiasm is killed savagely, eviscerated and spread all around for good measure and only *after that*, merely left to rot. The first easy blow is that I'm no perfection myself and nothing in this world ever is, so that image of gliding perfections between ideals is more likely to turn in practice for anyone-less-than-perfect into something akin to trying non-existence while still alive. Not that some won't try or look for exactly that but this particular quest doesn't appeal to me, as imperfect and as grounded in this here life as I find myself.
The second and much harder blow though comes from experience really. That first-pass enthusiasm keeps popping up again and again it would seem, no matter how well spread it found itself *last time* so there's quite an accumulated pile of various sad recognitions for memory to throw at me on each new occasion of first-pass entertainment of this particular folly. And so it did today yet again after spending much of yesterday and quite a few hours this morning going through past logs and collecting the history2,3 of
working trying to work with one whose knowledge I still admire, whose products I still find pearl-like and whose dedication to theoretical ideals and perfection4 has him turning in circles on trajectories that palpably and instantly recoil as soon as they touch even just tentatively the mundane line of imperfect and even downright filthy at times reality that an actual business in this world is bound to follow.
For a balanced view and as usual, I still want at any rate to mention Stanislav's own assessment - the one that at least makes some sense really as otherwise there is a lot of spew - of the situation, as stated in his chan:
asciilifeform: diana_coman: i dun expect any resolution to 'mexican standoff' where mp wants to isolate self from asciilifeform's 'charlatanry', and asciilifeform wants (imho reasonably) to isolate self from mocky-style suicide missions.
Even regardless of anything else really, the assessment above is to my mind rather indicative of the fact that this is another one of those irreconcilable differences, coming (finally!) into sharp focus and inevitable clash. The moment you perceive and state the other party as asking for "suicide missions", there is certainly no way left to work together, how would that even be? So here's this rift gaping and you can stare at it as much as you like for as long as you can afford to further remain stuck really. I don't think though that there's any solution other than precisely what is currently happening: Stanislav will do what he wants to do, released of the burden of contributing-while-isolating-self. I hope even that he'll be more productive and successful for it, certainly healthier to be in actual isolation rather than attempt to isolate while at the very centre of it all. And on the other side, TMSR will be also released of the burden of this conflict at the very least, if nothing more. For all the state of sadness, there is at least clarity gained and on this burnt soil, growth can start anew, unencumbered by the old conflicts and fixations. I truly hope it will, too, and I will do whatever I can to help it along.
As to the impact of all the above on matters closer to me, it is indeed precisely as noted only recently: time packs a lot of punch those days and the recent S.MG board room meeting certainly did. For all the calmness of the surface, the waters had to stir deep down because, as Hannah aptly points out there is the most practical aspect of it, if nothing else: just how would you go about getting the salt back out of a bread that's been baking already for quite a few years? And even more so, the question facing me at this juncture is just how do you go about figuring out in any certain way whether there is salt in your bread and of what sort exactly, given that you've been eating it all this time? Because it comes to more than just reconsidering the solutions and the code for correctness (as I did already prior to signing them) - it all comes now to *also* assessing them for essentially political merits, along the lines of vouching that "there is no barb." Or is there and I just don't see it (yet), perhaps because of previous familiarity with it, perhaps because of current blindness, perhaps?
Setting aside for a bit the doubts about the real possibility of even giving an answer to the question above, I can of course still commit to go through the list of items that S.MG imported - software, hardware and perhaps more importantly design choices - so far and look at them in the light of the new situation: are those sane business choices that help S.MG thrive or are they dangerous ideal choices that will sink S.MG in the end, all the more painfully for the prolongued agony that existing resources can allow? I tell you that I don't quite see what *else* can I do but at the same time, I also don't quite see how can this can be done with any guarantees.
The only tiny sliver of light I can see in this is perhaps an approach from the other side to help change the perspective and maybe provide from that end a better focus for such an evaluation. If that's even possible, of course.
And a few more than 2 actually but here the second pass is already quite enough, I'm not 18 anymore. ↩
The whole is in the logs really but looking at it all now in one go, it was rather painful and most probably on both sides, basically forcing that circle to a line it abhors. I'll leave just a few revealing (at least to me) examples, mainly to find them faster next time:
Getting the sane-MPI provided v-tree to actually press reveals in the end an issue but only after quite a struggle:
diana_coman: mod6 or asciilifeform, can you help? I'm trying to press asciilifeform's second patch for sane-mpi and V complains that it can't find the vpatch file although it is there (and I checked the sig too and it's all fine); I'm running your V, version thebitcoin.foundation/v/V-20170317.tar.gz.mod6 ; I have the following folder structure: http://p.bvulpes.com/pastes/1ZwgW/?raw=true; Here's the error when I run v press verbose . mpi_second_cut.vpa
diana_coman: tch: Error! Could not find vpatch "mpi_second_cut.vpatch" ; when I run v a mpi_second_cut.vpatch I get: Error! Could not find vpatch "mpi_second_cut.vpatch"
asciilifeform: diana_coman: is it in your patches dir ?
diana_coman: yes; see folder structure above
diana_coman: ftr it finds the genesis patch fine
diana_coman: but it seems to think there are no descendants on it (so v d mpi-genesis.vpatch returns empty)
BingoBoingo: No pictures of quality this time, but have located mall, mall casino, and place where sleeping
diana_coman: v f shows only the genesis
asciilifeform: diana_coman: are you using mod6's vtron ?
diana_coman: yes,as stated
asciilifeform: pretty strange, mine and phf's vtrons ate it up without complaint, e.g. http://btcbase.org/patches?patchset=mpi
diana_coman: ok, let me try with yours too then, can't hurt
asciilifeform: sounds like a bug in mod6's vtron, thus far
asciilifeform: where it silently barfs on a signature and doesn't say why
asciilifeform: where did you get asciilifeform's key, diana_coman ?
mircea_popescu: diana_coman possibly you have old ver of alf sig ?
diana_coman: ftr I used mod6's vtron on ch1 of ffa and it worked perfectly fine
mircea_popescu: (expired at some point)
asciilifeform: sigs dun change tho
mircea_popescu: had alt paths there
asciilifeform: diana_coman: then can rule out bad pubk
diana_coman: mircea_popescu, nope, I just downloaded it again today so it's the new one
mircea_popescu: a ok\
diana_coman: asciilifeform, got it from your website
asciilifeform: i redownloaded own item just now, and verified the sig successfully
diana_coman: a gpg --verify here worked perfectly fine for me too on both patches
asciilifeform: so it ain't hoster shenanigans, unless quite elaborate and patch-dependent
diana_coman: (did that before even running v anyway)
asciilifeform: fwiw sha512(mpi_second_cut.vpatch) : 594052a750c3ab2ad16bbd73c578df9d99a98cc9811e6537e452dc2386b58c24555918e8d02e9e8d35c25808ac31a10babf0614e2d647afdf4f58b38059af118
asciilifeform: sha512(mpi_second_cut.vpatch.asciilifeform.sig) : 7b14150fd5100dc90f7130a491214fceda5984fdad20491487d45727c4be88885dc9d9245e7f1bee30fa236e1e774e03f6cba8f34ccc4508eaed0df53af329a0
diana_coman: anyways, will try with asciilifeform's v for now; maybe mod6 has some idea on this later
diana_coman: asciilifeform, same sha512 here
asciilifeform: hmm possibly mod6's v requires 'vpatch' extension
asciilifeform: my mpi genesis had 'vdiff'
asciilifeform: ( but otherwise conformant )
diana_coman: ah, that might be it, makes sense
asciilifeform: what i did :
asciilifeform: mv patches/mpi-genesis.vdiff patches/mpi-genesis.vpatch ; mv .seals/mpi-genesis.asciilifeform.sig .seals/mpi-genesis.vpatch.asciilifeform.sig
asciilifeform: or hm
asciilifeform: still fails to recognize that mpi_second_cut.vpatch exists
asciilifeform: this VERY POSSIBILITY of silent failure is a bug, mod6
asciilifeform: at least oughta have a verbose mode one can optionally enable, wtf
asciilifeform: silently ignoring bad input by-default can be permissible, but to do it ~always~ is not The Right Thing , gotta give something to debug with.
asciilifeform: ./v.pl d mpi-genesis.vpatch returns nothing
asciilifeform: and neither does
asciilifeform: ./v.pl a mpi_second_cut.vpatch
asciilifeform: otoh the flow,
asciilifeform: ./v.pl f
asciilifeform: mpi_second_cut.vpatch (asciilifeform)
asciilifeform: mpi-genesis.vpatch (asciilifeform)
asciilifeform: returns both.
asciilifeform: this happens only in mod6's vtron, the bug is replicated by asciilifeform just now ( however yet unexplained. )
asciilifeform: and persists still if the filename is fixed, so it wasn't the cause.
diana_coman: myeah, I had done the renaming
diana_coman: asciilifeform, v99 (taken from here: http://therealbitcoin.org/ml/btc-dev/2015-August/000160.html ) complains that "No roots found!" -> what am I missing?
diana_coman: these are my files: http://p.bvulpes.com/pastes/oXdqh/?raw=true
diana_coman: and I ran it : v99 --wot .wot --seals .seals patches a mpi_second_cut.vpatch
asciilifeform: ok now ~that~ is odd
asciilifeform: diana_coman: do me a favour, tar up the entire thing
asciilifeform: vtron, patches, seals, all.
asciilifeform: i unfortunately will not be able to touch this in next few hrs.
asciilifeform: but will before nightfall.
ben_vulpes: and in "fiddling while rome burns" http://ul.vave.pw.s3-us-west-1.amazonaws.com/_/17/12/75b4d27.jpg
diana_coman: asciilifeform, http://p.bvulpes.com/pastes/mINB0/?raw=true encrypted .tar.gz of whole dir with everything
asciilifeform: ty diana_coman , i'ma check it out as soon as hands free
diana_coman: thank you
asciilifeform: diana_coman: post plaintext one, possibly ben_vulpes or mod6 or someone else, will notice what is the cause before i do
asciilifeform knee deep in saecular liquishit atm
diana_coman: asciilifeform or anyone else: http://ossasepia.com/available_resources/testmpi.tar.gz
asciilifeform: thx diana_coman
asciilifeform: now i recall also that phf had some trouble at first eating the thing, http://btcbase.org/log/2017-11-15#1739113 and elsewhere. but i can't seem to find in the log whether he ever said what the problem was, and how fixed.
a111: Logged on 2017-11-15 18:23 mircea_popescu: maybe his thing didn't eat it for some reason.
mod6: hi, looks like you've had some issues with my v : asciilifeform & diana_coman, I'll have to take a look at this later when I can. thx.
phf: asciilifeform: i had issues specifically with an older, genesis-less version. my system doesn't require antecedents to be there, but for some reason when there's only one, antecedent-less patch it gives me a 404. i've not actually investigated, since you produced a genesis since
asciilifeform: genesis was posted from the day my article was written, phf
asciilifeform: it is in the tarball
asciilifeform: ( supposing this makes a difference )
asciilifeform: or, to be absolutely pedantically correct, it was posted when the article first written, whereas 'second cut' was added later.
asciilifeform: both can be seen at http://www.loper-os.org/?p=1533 .
phf: asciilifeform: something like that. my btcbase vpatch grepper is dumb (it's my own eyes, but not the brain) and it's mostly just looking for things that look like a vpatch/vdiff. i definitely didn't unpack the first post tgz
asciilifeform: makes sense
asciilifeform: since that item i've avoided stuffing'em into tarballs, it doesn't help but often trips up various automated items like phf's
trinque: http://btcbase.org/log/2017-12-06#1747237 << I saw, first reaction was "AH SHIT, WHY IS THE BALANCE OFF"
a111: Logged on 2017-12-06 14:10 mircea_popescu: http://btcbase.org/log/2017-12-05#1746620 << pretty sure i "accidentally"-ed a hundy or so at some point, look carefully through the couch cushions.
asciilifeform: let plain text, stay plaintxt
trinque: notbad cushion money
asciilifeform: i considered to ask 'a hundy of what' but decided not to
mod6: where is the de-facto mpi tarball?
asciilifeform: meanwhile in world of thick people, http://www.loper-os.org/?p=1927&cpage=1#comment-18402
mod6: are we trying to get this one going then? http://www.loper-os.org/pub/mpi/sane-mpi.tar.gz
asciilifeform: i prolly oughta remove that link
asciilifeform: it contains simply a press
mod6: it sounds to me like diana_coman was using that one.
diana_coman: mod6, no
asciilifeform: ( at the time i was not yet ready to say properly fuckyou to my heathen readers, who had nfi what is v and did not want to )
diana_coman: yes but the vpatch, not the press itself
asciilifeform: i think diana_coman has the actual vpatch
asciilifeform: from the genesis tar
diana_coman: mod6, this is what I have and on which it failed: http://ossasepia.com/available_resources/testmpi.tar.gz
diana_coman: basically this "sane-mpi" tar.gz: www.loper-os.org/pub/mpi/mpi-genesis.tar.gz
asciilifeform: oooh aaaah
asciilifeform: looks like i found the boojum
asciilifeform: this was one of those pieces i cooked using obsolete vdiff
asciilifeform: that included timestamps
asciilifeform: the genesis, that is
mod6: that'll do it
asciilifeform: the secondcut was proper.
asciilifeform: who wants to recommend The Right Thing for an item like this ?
asciilifeform: i can sign a vpatch of ~the genesis~ per se
asciilifeform: or alternatively sign a cleaned genesis
asciilifeform: but would rather preserve the chronology.
asciilifeform: hey mircea_popescu do you wanna make the call ?
mircea_popescu: sign a new genesis, abandon this one.
asciilifeform: fwiw the secondcut requires no change
asciilifeform: the file hashes from the fixed genesis will be same.
mircea_popescu: asciilifeform just as soon as someone puts a patch on top of it, the trees will diverge and then phf can exclude the legacy one or w/e it is he does to them
asciilifeform: they won't diverge though
mircea_popescu: oh, it's a clerical problem only ?
asciilifeform: think about it. aha.
asciilifeform: it's a straight formattingbug.
mircea_popescu: so then why doesn't it press ? there's something amiss here.
asciilifeform: it doesn't press because vtron chokes on the timestamps.
asciilifeform: they should not be in the hashlines.
BingoBoingo opting out of major decisions until getting in a full sleep in. But, Haz uruguayan numero de telefono
mircea_popescu: so then why is it on eg phf's site
asciilifeform: ( they however were in there, in asciilifeform's ~original~ vtron . and vdiff . )
mircea_popescu: im guessing we're just about ready to tighten format here
asciilifeform: phf's vtron apparently is clever, and able to eat both types.
mircea_popescu: SOFT FORK!
asciilifeform: mircea_popescu: the crapola was formally abolished in v proper.
asciilifeform: phf's is 'too liberal'.
mircea_popescu: aite then.
asciilifeform: mod6's is actually correct, though i'd prefer it barf loudly and with pomp, rather than silently.
mircea_popescu: aaanyway, suppose diana_coman wants to add a patch to mod6's vtron, to better error messages
mircea_popescu: (because complaining of absent-present file is no good)
mircea_popescu: WHERE does she put it ?
mircea_popescu: mod6 wanna genesis your vtron ?
asciilifeform: i tried it with diana_coman's copy of asciilifeform's last vtron, and it has correct barfola
asciilifeform: says 'are you sure this is a vpatch'
asciilifeform: which immediately took me to the culprit
mircea_popescu: asciilifeform and how about you./
asciilifeform: pretty sure i did ?
mircea_popescu: i dun see it in btcbase
asciilifeform: having to comb l0gz to find these, is becoming painful. any chance of deedbot learning to eat vpatches+sigs, trinque ?
mircea_popescu: atm there's bot, lam-par (terrible name), fg, mpi and ffa.
asciilifeform: mircea_popescu: lol i'm all ears if you have better name for lam-par
mircea_popescu: asciilifeform why deedbot ? should be a111.
asciilifeform: traditionally deedbot is the one who eats signed matter
mircea_popescu: asciilifeform : "Lamport Parachute (a crypto identity bootstrap solution)"
mircea_popescu: asciilifeform you misunderstand teh tradition!
mircea_popescu: !#s ".sig"
a111: 217 results for "\".sig\"", http://btcbase.org/log-search?q=%22.sig%22
mircea_popescu: !#s ".patch"
a111: 111 results for "\".patch\"", http://btcbase.org/log-search?q=%22.patch%22
mircea_popescu: asciilifeform phf pluriously said he's doing it by hand for now ; i see no problem with this. correct procedure would thereby be to ping him with items
asciilifeform: > > http://www.loper-os.org/?p=1533 < < updated
asciilifeform: ^ mod6 , diana_coman , mircea_popescu , phf , et al
asciilifeform: clean ( in terms of not actually having any effect on pressed hashes and the descendant patch 'second cut' ) fix.
asciilifeform: diana_coman: plox to verify that this worx as described above, when you get a chance.
asciilifeform: i tested with my vtron, as pictured in diana_coman's tarball, and it worx.
asciilifeform: fwiw asciilifeform has purged afaik all copies of old-style vdiff.sh from his boxen, so this headache should not recur.
asciilifeform: i recommend other folx to look at their vdiff, and see that it does not suffer from timestampism.
asciilifeform: ( pretty sure asciilifeform is not the only one who has committed this sin. )
asciilifeform: phf: if you had some code in your patch viewer to eat this type of horror, as 'special case', it is now a good time to throw it out
asciilifeform: afaik i dun have any other unfixed vpatches.
asciilifeform: ( aside from some obsolete matter on trb ml )
trinque: http://btcbase.org/log/2017-12-06#1747462 < < don't want to step on phf's toes here; he's operating the logger and v-patch viewer
a111: Logged on 2017-12-06 19:48 asciilifeform: having to comb l0gz to find these, is becoming painful. any chance of deedbot learning to eat vpatches+sigs, trinque ?
asciilifeform: let me also demonstrate for the record:
asciilifeform: grep "+++" mpi-genesis.vdiff | cut -f5 -d' ' | sort > sad.txt
asciilifeform: grep "+++" mpi-genesis.vpatch | cut -f3 -d' ' | sort > happy.txt
asciilifeform: diff sad.txt happy.txt
asciilifeform: ^ null
asciilifeform: ( one is, if it isn't clear, the 2015 sad genesis; the other -- the fixed, in http://btcbase.org/log/2017-12-06#1747474 . )
a111: Logged on 2017-12-06 19:59 asciilifeform: > > http://www.loper-os.org/?p=1533 < < updated
asciilifeform: http://www.loper-os.org/pub/mpi/mpi-genesis.vpatch http://www.loper-os.org/pub/mpi/mpi-genesis.vpatch.asciilifeform.sig for the l0gz.
asciilifeform: ^^^ mod6 , diana_coman , mircea_popescu , phf , et al ^^^
mircea_popescu: ok ok simmar down
asciilifeform: the issue is as fixed as it gets. i posted the grep item as example of how to verify, without even a vtron, that nothing has been slipped in from under the table.
diana_coman: asciilifeform, thank you, I'll look in a minute; (had all hands full a minute here with all sorts)
asciilifeform: ( a working vtron will immediately barf if encountering a file mismatching the claimed hash )
mod6: alright, im about to check your new ones here. i can confirm that the original 'mpi-genesis.vpatch' (f254bedf1e3241eb9de17232b630a0614f1cc54ff9c5407d87d79174e211833bcfc0135c89b4abcab2446acd93137a8e1b0798704ad7e4d498cc52c836c82c2b) gets dropped on the floor because of the addtional timestamps.
diana_coman: I can confirm that the new genesis & the old second_cut vpatch are now at least recognised by mod6's v
diana_coman: asciilifeform, did you take out the second_cut patch link from the updated http://www.loper-os.org/?p=1533 ? or am I just not seeing it/not getting something?
asciilifeform goes to see
mod6: now, on the other hand, yeah, i saw the second_cut vpatch link removed from loper... but I went ahead and updated my sandbox to have alf's latest & greatest mpi-genesis.
mod6: when i went to press, bzzzt.
mod6: looks like second_cut might need a re-grind.
asciilifeform: diana_coman: fixed
asciilifeform: mod6: show me the eggog ?
asciilifeform: it SHOULD NOT NEEED REGRIND FFS
diana_coman: asciilifeform, here it seems to barf on the ...README file?
asciilifeform: paste ?
asciilifeform: considering that i made the new genesis by pressing and re-vdiffing, there should be no differences aside from the timestamp cut.
diana_coman: 2 out of 5 hunks FAILED -- saving rejects to file mpi/README.rej and contents of README.rej are here: http://p.bvulpes.com/pastes/J8ESM/?raw=true
mod6: yup, unhappy with README
diana_coman: aha, seems to be same here, confirmed
asciilifeform: diana_coman, mod6 that text only appears in 'second cut'
asciilifeform: not in genesis
asciilifeform: it does not appear in either the original genesis, nor the regrind, see for yourself.
asciilifeform: ( i.e. the text in 'UPDATE #1' )
diana_coman: asciilifeform, there is something I don't understand: shouldn't I be able to press the second cut now with the new genesis present?
diana_coman: so then : I try to press and I get...that
diana_coman: is there now a problem with second_cut?
diana_coman goes to take it again
asciilifeform: whereas i just now 'pressed' the old and the new genesis with plain old patch -p1 < old and patch -p1 < new
asciilifeform: and diffed the READMEs
asciilifeform: and they are bitwise identical
asciilifeform: just as they ought to be
asciilifeform: and so is the rest of it!
diana_coman: uhm, something is weird
mircea_popescu admires how the "finished" mpi managed to take a whole day of 3 people's time and shakes his head displeasedly.
mircea_popescu: this can't be what finished ever means.
asciilifeform: what means 'finished', it's a spoil of war artifact.
asciilifeform: ( and fwiw phf pressed and built the demo year+ ago )
asciilifeform: diana_coman, mod6 , both of you appear to be suffering from mod6's barfolade-leaving vtron
asciilifeform: it stops mid-press and leaves liquishit
asciilifeform: which it itself afterwards fails on
asciilifeform: make a fresh working set, with no failed-press residue, and you will get a working press.
diana_coman: asciilifeform, this was FRESH
asciilifeform: plox to tar it up and post ?
diana_coman: wiped previous dir, took everything out with curl etc
asciilifeform: whole thing, as before.
asciilifeform brb, teatime.
diana_coman: I'll wipe again and try your v too for completeness at least
mod6: <+asciilifeform> diana_coman, mod6 , both of you appear to be suffering from mod6's barfolade-leaving vtron << wut
mod6: <+mircea_popescu> mod6 wanna genesis your vtron ? << at this rate, doesn't look like it.
mod6: Despite 2 years of development, we still arn't there yet.
trinque: genesis doesn't have to mean perfect.
mod6: I had started a new V in Ada, had to stick it in the drawer for a while. Not getting to exactly where I wanted to go (easy to read, fits in head, no perl/perlisms) with it at this time.
trinque: nobody's going to come for you with pitchforks
mod6: Anyway, the hope was that it would replace my other PoC.
trinque: ircbot's genesis features me writing CLOS like it's Java classes.
mod6: <+mod6> <+asciilifeform> diana_coman, mod6 , both of you appear to be suffering from mod6's barfolade-leaving vtron < < wut < < my V pukes exactly when it can.
mod6: during the press process, it finds that shas do not match the expected, and DIES.
trinque: will at some point release vpatches with sane method names. but thing works, and I'm not going to obscure history because I knew less in the past.
mod6: it can't check the expected sha of a patch BEFORE its DONE patching.
mod6: s/patch/patched file/
asciilifeform: now where's that tarball
asciilifeform: either diana_coman's or mod6's barfamatic set
asciilifeform: at this point i'm quite curious re what gives
mod6: everytime we have this problem (note it's not the first) where we have someones vpatch with garbage in it....
mod6: then it gets re-generated
mod6: then we have to regrind stuff.
mod6: goto regrind;
asciilifeform: mod6: in this case asciilifeform is quite puzzled why it appears to need a regrind; none of the file hashes should have changed
asciilifeform: ( patches themselves are never hashed , aside from by gpg when verifying sig )
asciilifeform: confirmed barf on readme
asciilifeform: now trying to find why !
asciilifeform: ( the two README are bitwise-identical )
mod6: ok. i'll see what i can dig up
diana_coman: asciilifeform, mk, so no need for the tar I gather since you can easily reproduce it anyway
asciilifeform: ok this is pretty sad
asciilifeform: how come nobody bothered to look at second_cut with naked eye ?
mircea_popescu: asciilifeform> what means 'finished', it's a spoil of war artifact. < < that's entirely not related to the discussion.
asciilifeform: phf how the hell did this get eaten by your vtron
asciilifeform: the second_cut on my www -- is not a proper patch at all
asciilifeform: but a genesis . all of the antecedents are 'false'
mircea_popescu: asciilifeform that's the smaller problem.
mircea_popescu: the larger problem is that to arrive to this conclusion, you first bitched at everyone else.
asciilifeform: the bigger problem is that nobody noticed.
mircea_popescu: now stop doing this inane shit, it's a significant drag on resources.
mod6: fwiw, i've never even looked at this!
asciilifeform: mircea_popescu: 9 of 10 occasions it is somebody else's bug!1
mircea_popescu: 2 of 2 here.
asciilifeform: mircea_popescu: at any rate, mod6 is right , i'ma have to regrind the 2nd patch. and also stuck , deservedly, with the chore of demonstrating that the payloads are unaltered.
asciilifeform: serves me right.
mircea_popescu: observe that after bitching about the quality of work in empire, along the lines of "everything works for as long as you don't use it", our pile of stuff exhibits the same exact property.
asciilifeform: if not tried -- wrong to say that it worx.
asciilifeform: 'schrodinger's worx'
asciilifeform: now i'ma go and get the mop, pick up the liquishit, brb.
a111: Logged on 2017-12-05 17:47 asciilifeform: ( lessee if i properly ate & shat, 'i do not consider myself a programmer, for i have another craft. let's say i am an amateur programmer. and yet though i am an amateur, i find myself having written tens of thou. of loc in this-here life. and at least a min of 10k loc for web. but wanna hear sumthing ? never have i created a security hole in any. never. do you suppose i simply had good luck ? possibly luck. or possibly i wrote the c
mod6: I should have examined/tested your mpi vpatches, alf. I'll continue to try to be a second pair of eyes, reading them. There's no substitute for reading. For those following along, take note.
asciilifeform: and i oughta properly read yer vtron, mod6 .
mod6: Additionally, if someone in the republic wishes to create a vpatch/genesis and have a second pair of eyes look it over, by all means, send it to me.
mod6: I'll do what I can to vet it.
trinque respectfully points out that at least by his eyes, V forces personal responsibility, not a pretense to being immaculately conceived.
mod6: never hurts to have someone measure for the n'th time for you before you cut, however.
trinque: no argument here.
asciilifeform: this is not the 1st time i plugged a finger into 220v. the breaker, i will however point out -- worked
asciilifeform: now to see which finger...
mod6: <+trinque> genesis doesn't have to mean perfect. <+trinque> nobody's going to come for you with pitchforks << no one expects a spanish something or other either...
mod6: but furthermore, i tend to agree. if i thought that my V would stay in perl forever, i'd probably already have created the genesis. however, i'd like to see if I can get the Ada version off the ground.
asciilifeform: ok this is pretty strange:
asciilifeform: i broke 'second cut' into patchons, and found :
asciilifeform: AND http://wotpaste.cascadianhacker.com/pastes/tpDxG/?raw=true
trinque: mod6: makes sense, not vpatching a prototype
mod6: because what i don't want to do is have a perl genesis, then some vpatch that deletes everything and inflates a bunch of ada stuffs. prolly be better to start in the lang you expect to say within for the lifetime of the application.
asciilifeform: or hm nm
mircea_popescu: mod6 it's not a crime to have a perl vtron. however, if you plan as your own strategy to move away from perl and you're judging it more of a liability than anything, then by all means, eschew.
mircea_popescu: original mod6 perl vtron was important prototype in the early life of v, made all sorts of latter things possible. exactly like original bitcoin. nobody said you have to marry it now though ; or divorce it for that matter.
mod6: It /is/ a bit worrysome that I believe that I'm the only person who knows how it works. And since it's the only version in existence that encompasses all of the rules arbitrated in our chamber, that a new version that is easier to understand is warranted.
mircea_popescu: what language(s) you work in is your own, entirely personal, choice.
mircea_popescu: i'm not going to pick a wife for you, "here, THIS is the woman you should be comfortable with". pick your own. languages idem.
mircea_popescu: on a long enough timeframe, there's going to exist a vtron in ~any language anyway, i expect.
asciilifeform: hey folx
mod6: mircea_popescu: that's kinda neat really
mod6: asciilifeform: werd
asciilifeform: i'ma double-chexk this before running mouth...
asciilifeform: because i think i may have found a bug in diff
asciilifeform: i'ma tar it up and let people replicate
mircea_popescu: inb4 ffa.diff reimpl
asciilifeform: there was no mistake in asciilifeform's procedure for baking the item. second_cut is in fact a patch, not a genesis, asciilifeform spoke hastily. there is also no bug in mod6's vtron, or in asciilifeform's. diana_coman did not make a mistake.
asciilifeform: i will not spoil the surprise , folx who look in the tarball will see what the caltrop was.
asciilifeform: the sad part is that i have nfi how to cure this , it is a consequence of using unix diff ( with in-band signal ) to begin with.
asciilifeform: ( observe that the sha512 sums of the readme in 'a' and 'b' match the ones given in the vpatch. but unix patch cannot actually make the patch happen. )
mod6: crap, just a sec, haven't even looked yet. bbs.
asciilifeform: i recall a similar boojum in my 1st attempt at the FG release, that time it was a '+++' inside a uuencoded blob
asciilifeform: some texts cannot be (!) vdiffed, for so long as we use unix diff; these appearently include gpg sigs
asciilifeform brb, fresh air
asciilifeform: ( clearsigs, to be exact . )
asciilifeform brb forrealz
mod6: <+asciilifeform> i recall a similar boojum in my 1st attempt at the FG release, that time it was a '+++' inside a uuencoded blob < < lol, ok i see the problem too. you're right, this similar thing happened before.
mircea_popescu: lol check it out, diana got split with the bots.
BingoBoingo recalls diff being an issue, forgets the context
mircea_popescu: we'll end up with a s/-/=/ intermediate step or wtf.
mircea_popescu: alternately, of course... "no clearsigned material within patches". this may even be a right thing independently of the actual bug.
mircea_popescu: in that there's no reason to have them, and their presence is in itself sign of babbage's braindamage, much like say a canister for light, or a faucet for patience.
Ben Vulpes plays Cassandra:
ben_vulpes: not indefinitely postpone releasing this vpatch while i wait for stan to release an ada cryptor and link that from cl
S.NSA consultancy turns out to not work for S.MG and so I have to start on implementing EuCrypt as there's no other option available.
diana_coman: asciilifeform, I'm currently looking at eulora rsa and I'm a bit foggy (I know and followed the bits posted in the logs but it's a long trail): what is available/ready to use atm?
asciilifeform: diana_coman: ffa arithmetic stack is theoretically available. however until i have barrett reduction going, it's a ~30 second modular exponentiation ( i.e. per rsa op )
asciilifeform: i.e. per 4096-padding -bit payload
asciilifeform: and a ~week -long keygen.
asciilifeform: http://btcbase.org/log/2017-09-20#1716110 << latest, iirc, thread
a111: Logged on 2017-09-20 16:25 asciilifeform: in other noose, ACHTUNG, panzers, http://wotpaste.cascadianhacker.com/pastes/BAjEK/?raw=true < < 27.2 sec (4096b modexp)
mircea_popescu: not actually usable for eulora as such, is it.
asciilifeform: certainly not as-is, no
asciilifeform: mircea_popescu: is a barrettian ( theoretically 1s/4096 ) rsatron, usable ?
asciilifeform: that's still quite slow vs. heathen rsa.
mircea_popescu: well, players are problematic. they might download the game and wait for a few hours to get a key going. then again they might not. nobody's waiting for a week tho, i don't expect.
asciilifeform: this is a fundamental headache, innit. 'wanna use actual rsa, or that thing you've been fraudulently introduced to as rsa, that leaks key, but runs fast'
mircea_popescu: in any case the problem is that i'll have to design some kind of extender, can't do pure rsa throughout because of the sheer load. there's multiple messages/sec
asciilifeform: fwiw it parallelizes.
mircea_popescu: asciilifeform in any case the implementation will be isolated, so that one can swap his preferred item in.
asciilifeform does not know ~anything about how eulora goes together, cannot comment in detail
mircea_popescu: but basically, the only practical approach here is to actually import the gpg implementation, warts and all, but modularily, and see later maybe it can be swapped out.
asciilifeform: imho using a nonfixedtime rsatron in realtime, is worse than not using any crypto at all
asciilifeform: you will leak key.
mircea_popescu: since the client is intended to dissolve into competing community-driven implementations anyway, i don't expect to even be involved in weighing that maybe.
mircea_popescu: asciilifeform i guess we'll be having this problem demonstrated in practice. what can i do ?
asciilifeform: openssl already demonstrated quite satisfactorily.
asciilifeform: ( you can ~trivially extract most privkeys, if you spend a coupla months )
mircea_popescu: need was correctly identified year+ in advance ; the fact work is ongoing is no solace -- something must go in, and it will go in now.
mircea_popescu: the only item ready to go in is in fact koch's, and so he gets imported.
asciilifeform: if hiring fortune teller - hire cheapest. but ftr i dun get how this beats not having crypto.
mircea_popescu: at least it makes the community failure plain to the community.
mircea_popescu: i ~tried~ to have crypto.
mircea_popescu: what i got is what i got, and that's what the community in turn gets, and when it has a better idea -- implementation it is one comment out away.
asciilifeform continues the very slow and painful walk through most of undergrad number theory that leads, possibly, to usable nonleaking rsa on pc.
He'll deny this, running circles around it too, I know. I rather wish I didn't, too. ↩
Comments feed: RSS 2.0