a111: Logged on 2017-12-13 23:17 mircea_popescu: it's true that women also have the avenue of not-being-animals anymore, but this happens to have opened just as most "jobs" got destroyed. so yes that works for a 5% of them, and another 10% or so could pretend and convincingly hope. the majority however, very much confront the pork bellies are $2 problem.
a111: Logged on 2017-12-12 23:58 mircea_popescu: <30yo females don't need a hundy.
mircea_popescu: fun fact : if 1960s vietcong invaded, the us could not muster a defense.
mircea_popescu: well... 3x as many whippers as zeks. no idea where you'd get the whippers, but perhaps try china before naganting ?
mircea_popescu: slave labour works in the sense of education ; not very productive as extraction.
mircea_popescu: it IS better soap than synthetic, but it also doesn't keep as well. so...
mircea_popescu: corndiesel marginal, and corn is a lot more uniform than man
mircea_popescu: asciilifeform yeah, i always wondered. the insanity of the eg panzer 4 GASOLINE engine still harrows my mind.
mircea_popescu: and note that the ~most used armored item (stug) ALSO fucking maybach gasoline engine
a111: Logged on 2017-12-13 23:18 mircea_popescu: pretty much all of the mental pathology we call ustardianism directly derives from this fundamentally economic problem.
a111: Logged on 2017-12-13 22:28 mod6: mircea_popescu: yeah, we've been pretty thrifty thus far.
a111: Logged on 2017-12-13 22:50 mircea_popescu: fun fact : total land area on this planet being 510 mn sqkm ; and bitcoin cap being 21 mn, it therefore follows that the absolute maximal average price for land is a dime per square km.
mircea_popescu: ok, fine. about 40% of the 148mn or so land sqkm are actually farmed.that's still 60mn.
a111: Logged on 2017-12-13 20:43 diana_coman: aha; well, depending on whose vrednic it is...
a111: Logged on 2017-12-13 20:44 diana_coman: although to be honest I wouldn't have defined it as notable, hmm
a111: Logged on 2017-12-13 22:00 diana_coman: mod6, more FFA tests sounds good to me; slightly related: is there any protocol/preferred approach for publishing signatures to someone else's patches?
a111: Logged on 2017-12-13 22:11 mod6: For other non-trb projects, perhaps the author can designa how that should work.
mircea_popescu: "not hosting your sigs" is therefore a low level "can't be bothered to rate but still dun like you" sorta hostility
a111: Logged on 2017-12-13 18:23 mircea_popescu: honeslty i much preferred the density. made all sorts of буржуй bullshit untenable and plain-evidently not desirable.
mircea_popescu: joke works just as well in either approach. but the буржуй bullshit consists of building an extra-tower of cvasi-funny bolted on the wall of the joke.
mircea_popescu: and if they were hungarian, it'd just mean she got married.
a111: Logged on 2017-12-14 00:41 mircea_popescu:
http://btcbase.org/log/2017-12-13#1751176 << nah, too complex and therefore frail system like that. simply : host ALL sigs for ALL things yourself ; let the urls be known publicly and don't change them.
a111: Logged on 2017-12-11 19:56 asciilifeform: incidentally folx: each of you who considers himself 'graduate' of an ffa chapter, consider signing
a111: Logged on 2017-12-13 23:34 asciilifeform for 1st time in long time, sits down to mega-l0g, eats
mircea_popescu: i dunno if im getting old or the thing is changing or what, but anyway.
a111: Logged on 2017-12-13 22:28 mod6: mircea_popescu: yeah, we've been pretty thrifty thus far.
mod6: <+mircea_popescu>
http://btcbase.org/log/2017-12-13#1751176 << nah, too complex and therefore frail system like that. simply : host ALL sigs for ALL things yourself ; let the urls be known publicly and don't change them. << This works. Having the redundancy is a good thing too.
☝︎ a111: Logged on 2017-12-13 22:11 mod6: For other non-trb projects, perhaps the author can designa how that should work.
ben_vulpes: concretely, trying to figure out what it would take to prototype a tuneable phase locked loop channel
☟︎ a111: Logged on 2017-12-07 16:51 asciilifeform: mircea_popescu: you can: diff ~the patch~
jhvh1: BingoBoingo: Bitstamp BTCUSD last: 16651.45, vol: 14908.84943855 | Bitfinex BTCUSD last: 16600.0, vol: 59781.18472423 | Kraken BTCUSD last: 16550.0, vol: 3279.47747035 | Volume-weighted last average: 16607.7349007
shinohai: But the concept of a UBI is hilarious period.
☟︎ BingoBoingo: But it would piss of walmart customers: "Whaddya mean the help is taking home more money because they work AND get muh welfares!
jhvh1: asciilifeform: The operation succeeded.
diana_coman: asciilifeform, I need to create a vpatch that performs the change of dir structure from a/mpi to b/eucrypt/mpi where the contents of the mpi folder in both cases are identical; or more specifically for the task at hand: I want to create a vpatch that has as antecedent my previous sane_mpi_eucrypt.vpatch (whose output is an mpi folder with all sorts) and results in eucrypt/mpi where this new mpi folder has precisely same contents
diana_coman: fwiw I managed to do this to some extent, but I don't like this "to some extent"
diana_coman: asciilifeform, it does the move BUT it requires post-cleaning (i.e. leaves some stuff behind) + works only with mod6's v; so something is wrong somewhere and hopefully it's just on my side i.e. I can correct it quickly following your explanation of how it should be done
diana_coman: mind telling me how you see it done? it's hopefully faster than debugging a wrong approach; once I have it working I'll write up the failure too if that's the thing
phf: diana_coman: it's not going to be pretty. it'll be twice the amount of text: once to delete the old file with - - - - and once to create a new file with + + + +
phf: presumably she doesn't want to compromise the resultant press because of poor tooling
phf: well, the project is called eucrypt, presses into eucrypt directory, inside it has support infrastructure like mpi
phf: if she decides to replace bignum backing, presumably mpi will get nuked and replaced with something else
jhvh1: BingoBoingo: Current Blocks: None | Current Difficulty: 1.590896927258E12 | Next Difficulty At Block: 499967 | Next Difficulty In: None blocks | Next Difficulty In About: 3 days, 17 hours, 55 minutes, and 40 seconds | Next Difficulty Estimate: None | Estimated Percent Change: None
mod6: your example will not work with my vtron, for one simple reason: the new rules state that we do not do ANYTHING with vpatches that do not have a corresponding signature - we IGNORE WILD vpatches and drop them on the floor.
mod6: That is fine; if it has a valid corresponding signature.
mod6: I understand that sentiment. We discussed this at length. Which is why I actually have a test-vpatch pgp key for that purpose only.
mod6: sure, thanks for posting the sample for diana_coman
phf: i didn't necessarily need the illustration, because i understood what you were saying, my point was merely that it's sad state of things
phf: well, the nature of v is that you're pressing into a global namespace. in fact that was a property of the original idea to a great extent (hence mp and his insistence on there being only one genesis). we compromised that already by having multiple projects, but you still run into the same issue when you're trying to combine multiple projects together. you're basically saying that the press namespace doesn't matter as long as there's no collision. ~othe
phf: rs~ might a little bit more meaning out of the press namespace. one pill to satisfy later group of people would be to come up with a filesystem hierarchy standard, i.e. you always press at the same root, but you're pressing into a tmsr namespace. so it'll be /bin/bitcoin/... /lib/mpi/...
☟︎ phf: sure, but you can't avoid namespacing issue. you're pressing files by name.
phf: actually, i think fg is the only exception
phf: but yeah in that model your press is / and you have /mpi and /eucrypt, so if you want to link against /mpi you do ../mpi/... in your makefile
phf: no what's shown is eucrypt ~inside~ mpi
phf: ah yeah you're right
phf: well, then we're on the same page
phf: it is to some extent a bsd model (that slackless os also follows it), where you have baseline system, where the source is owned by a cabal of maintainers/developers
phf: err, yes, i was going to say slackware, but they are sloppier than bsd
a111: Logged on 2017-12-14 05:08 ben_vulpes: canvassing the low bandwidth radio space
a111: Logged on 2017-12-14 05:14 ben_vulpes: concretely, trying to figure out what it would take to prototype a tuneable phase locked loop channel
ben_vulpes: hardware for broadcasting and receiving data over low bandwidth radio links
ben_vulpes bbl, teaching human 101, will return later
ben_vulpes: apparently mike_c's new gig has now banned messages to girls from users they haven't "liked" yet
ben_vulpes: they show up on the sender's "profile" instead
ben_vulpes: which is kind of impressive because bumble was already a shitty tinder, providing a cover for short-term coy behavior in online dating.
BingoBoingo: ben_vulpes: Well, maybe it's part of mircea_popescu's vast conspiracy to push people into more crowded spaces?
BingoBoingo: ben_vulpes: Aqui es "Buen dia" en la manana. Otra veces "Buenas" (tardes o noche not specified)
BingoBoingo first 3 days heard it as "Bom dia" though they adopted portuguese greeting from Brasil.
a111: Logged on 2017-12-14 13:49 shinohai: But the concept of a UBI is hilarious period.
mircea_popescu: (humor necessarily feeds of contradiction of expectations ; hope is always and no matter how disguised continuation of expectation. the contradiction between the two is absolute and a matter of definition.)
mircea_popescu: that's also why poor people, stupid people (but i repeat myself) and socialists, "democrats", pantsuits etc are so fucking unfunny. too hope-y, or rather, their intellects are too dysfunctional to handle contradiction, of whatever kind.
a111: Logged on 2017-12-14 15:38 asciilifeform: the 1 thing i still don't fully understand is why diana_coman's subdir gotta move
a111: Logged on 2017-12-07 16:52 mircea_popescu: so then why can't she simply move the mpi/ dir into eucrypt/mpi/ and proceed ?
ben_vulpes: always entertaining to watch "just wanted"s rack their nuts on the handrail of reality
BingoBoingo will have to add that to hosting menu. How many nuts per RU?
a111: Logged on 2017-12-14 15:39 asciilifeform: i.e. why can't 'eucrypt' be a ~sibling~ dir to 'mpi'
mircea_popescu: mpi is a SUB. and if it can't act the sub part it's getting cut out with hot irons and the ground where it stood salted.
mircea_popescu: exactly like ANY OTHER piece of fucking useless heathenry
a111: Logged on 2017-12-14 15:51 asciilifeform: phf: given example works with my vtron, oughta equally work with mod6's. and does the job (both from vtronic genealogy pov, and gnumake's -- the latter (see the makefile of my faux 'eucrypt') recurses updir ) the 1 down-side is aesthetics.
a111: Logged on 2017-12-05 15:11 asciilifeform: and in general i dun expect any of it to be paid for, there is no tradition of any such thing. but i do have the possibly naive expectation of the work not to be shat on.
mircea_popescu: this isn't work, what you're doing. this is anti-work.
mircea_popescu: and it's not the first time ; it's the fucking third. every time she tried to get some sort of support from you, you acted the retarded usarmy desk flier, cost her 10x the time it'd have taken if she were camping in the desert.
mircea_popescu: this is me opting out. now go read thefucking logs ; copy BY HAND on a notebook what you did wrong, in fucking gothic longhand, a dozen times, and get it in your thick skull.
mircea_popescu: the world's not some sort of wide open grazing range where we can just randomly produce useless nonsense.
mircea_popescu: so now that problem is solved ; go do something else, there shall be no more of this.
jhvh1: BingoBoingo: Kraken BTCGBP last: 8031.0, vol: 0.03649989 | Volume-weighted last average: 8031.0
jhvh1: BingoBoingo: Bitstamp BTCUSD last: 16349.16, vol: 13907.27801175 | Bitfinex BTCUSD last: 16382.0, vol: 51961.20651967 | CampBX BTCUSD last: 13350.0, vol: 0 | Kraken BTCUSD last: 16395.0, vol: 3078.69426607 | Volume-weighted last average: 16375.9563592
a111: Logged on 2017-12-14 16:13 phf: rs~ might a little bit more meaning out of the press namespace. one pill to satisfy later group of people would be to come up with a filesystem hierarchy standard, i.e. you always press at the same root, but you're pressing into a tmsr namespace. so it'll be /bin/bitcoin/... /lib/mpi/...
mircea_popescu: yes we don't have a gns yet, but this doesn't excuse us from... doing the same computations by hand as if we had it! it's not suddenly allowable to go "well since i have no running water i therefore do not wash". no bitch -- since you have no running water, you walk fifty miles uphil each way to GET water in a bucket. still wash.
mircea_popescu: that could've meant tmsr-diff. what it means practically is that there's going to be a "new" mpi in eucrypt, textually identical to the genesis one ; and people will be re-reading and re-reading and RE-READING whole lots of the same exact code as if new, resulting in a situation where instead of the problem being pushed into "a filesystem hierarchy standard" it'll be pushed into a "code standard". which happens to be exactly
☟︎ mircea_popescu: like how oral culture worked, the concept of a trope, as found in folk tales, is really simply equivalent to "and this is how mpi goes, and this is how bubblesort goes..." and so on.
mircea_popescu: over time it'll actually get systematized, as in the aaerne-thompson system for folk takes, or as in the tmsr-diff here. but that day is far into teh future.
mircea_popescu: contrary to naive intuition, there is no damage in re-reading old code as if it were new.
mircea_popescu: in fact, i expect it will be the MAJORITY of work for humans in the future.
a111: Logged on 2017-12-14 19:22 mircea_popescu: that could've meant tmsr-diff. what it means practically is that there's going to be a "new" mpi in eucrypt, textually identical to the genesis one ; and people will be re-reading and re-reading and RE-READING whole lots of the same exact code as if new, resulting in a situation where instead of the problem being pushed into "a filesystem hierarchy standard" it'll be pushed into a "code standard". which happens to be exactly
a111: Logged on 2017-12-06 22:51 mircea_popescu: once we have keccak.
mircea_popescu: kinda open matter yet ; but procedurally one takes the diff source code, genesises it, patches the differences and produces a drop-in diff replacement.
mircea_popescu: i'm letting him contribute, what. he understands what the problems are.
mircea_popescu: maybe he bites the bullet and makes special files. or who the hell knows. i'm curious.
mircea_popescu: you ~could have a diff format whereby first line is x y z with x = total line count, y notation line count z data line count, and then instead of +++ --- bs you just have line count references in the notation part.
☟︎ mircea_popescu: can EVEN KEEP the +++ --- style separators, but in the DATA segment
mircea_popescu: making your file comvertible to old style patch through a truncation op.
a111: Logged on 2017-01-03 21:14 mircea_popescu: v is really only as powerful as the underlying differ is.
a111: Logged on 2017-01-05 00:49 mircea_popescu: i do not wish to live in a world where people can make patches consisting of 512kb lines of a
a111: Logged on 2017-01-05 00:24 mircea_popescu: lines are good!
deedbot: nocko voiced for 30 minutes.
a111: Logged on 2017-12-10 21:23 nocko: I was linked to FFA guide, started looking around and am now here. I cannot say that I yet have half an idea what's going on... but hello.
phf: take existing stuff, strip it down to just what we already have -ruN functionality. i think that the actual tools should be vdiff and vpatch, that is they do shasuming themselves and produce proper vpatches/apply proper vpatches, but without chain or signature validation.
phf: well, signature validation is done by gnupg, i don't see any reason to bring that whole thing in, and there's very little reason to system("gnupg ...")
phf: chain validation needs to only go as far as "does the hash on the file that i'm about to patch corresponds to what i expect"
mircea_popescu: and why would diff/patch be outside of vtroner is the larger design question
phf: mpi is a fraction of what gnupg is, are we then moving away from pgp keys and signatures?
phf: this then is entirely unscoped
mircea_popescu: in principle we could do incremental builds ; but only if they can be cleanly upgraded later, that's a major point.
phf: in my thinking vtroner is a larger beast, that's responsible for the management of the entire press chain. patch/diff are dealing with a specific problem of comparing two states, producing a difference of those two tays, and then taking a state into a next state according to differences
mircea_popescu: can you imagine any other context besides pressing this new diff/patch would be used in ?
phf: from that perspective both vdiff and vpatch ~could~ also produce a corresponding sig, in which case the protocol is that patch/diff produce an always valid vpatch (i.e. vpatch/sig combination)
phf: i thought that's what you were talking about?
phf: or the thinking that vdiff doesn't sig, but then vpatch expects a sig never the less?
phf: i don't think that's a good idea, but i can't articulate an objection. vpatch now needs to know about your wot and wot management, or else the process of patching now becomes explicitly providing a pub key, a corresponding sig and a vpatch itself.
phf: well, this goes back to the threads about whether or not it makes sense to patch sigs on your workbench. i use patch in my workflow frequently outside of pressing a tree to bring things from one state into another. i might have a dozen of unsigned patches, that i'm working with that won't see the light of day
phf: in this case the value of proper vpatch/vdiff is that they never produce fuzzy patches and always validate the shasum for you, but they don't do the v-tronic management
mircea_popescu: you're absolutely right. patch process must be much looser than this.
phf: actually phf-shiva-swank is still broken in the experimental patchset, because it was produced by vdiff/patch combination (vdiff made some claims of shasums, which patch didn't verify. the fact that i should've verified the press is a different question)
phf: btw one of the reasons for dodgy delete function in the diff is that patches theoretically a reversible, -'ing all the lines of file can conversely be +'d back
phf: but anyway, i'm not convinced that file management is a proper concern for diff. we could add it to a diff format, by placing some instructions in the prelude (which is normally ignored by unix patchers). rm src/foo.c, mv src/foo.c src/bar.c which can be used as instructions for reader with non compliant patchers, or parsed by the vpatcher to be executed. this is all incredibly inband, but conforms to the medium
mircea_popescu: the fact that unix diff is directory blind is an idiocy larger than commonly encountered in that thing's misdesign
mircea_popescu: a file is not "its contents and AN ARBITRARY TRUNCATION OF ITS NAME"
mircea_popescu: and a file's fucking name is its absolute path, not the last bit thereof.
mircea_popescu: but whatever, in 1970 people couldn't afford disks with actual directory structure in them
phf: diff/patch allows for absolute paths, we don't them it though
mircea_popescu: i don't know how it allows if i can't move a god damned file.
phf: well, moving of the file is a filesystem operation, what does it have to do with ~diffing~?
phf: sure, but diff's way of indicating change is to show what happened to a file, that is all the lines of the file got deleted
mircea_popescu: if i edit glib.c and replace line 50 with "fuck you stallman", and then try to compile glib.c, i get an error. if i edit glib.c and MOVE glib.c to /fuck/you/stallman/glib.c, and try to compile glib.c, i get an error
mircea_popescu: ergo, BOTH these operations have been edits of the file.
phf: diff has two things that it can signal: an addition of a line, and a deletion of a line, which is in line with what it claims to diff, i.e. diffing of lines
trinque: problem stemming from that unix uses file path as a matter of identity, and allows this to be mutable (!)
☟︎ phf: but then the question is what is the responsibility of diff
mircea_popescu: phf sure, and subsistence hunting has two things that it can do, throw rock or jab spear. this is in line with it being an occupation of idiots invented by idiotws.
phf: fwiw diff can't even know that a file has been moved
mircea_popescu: "the difference between a/fuckyoustallman.c and b/fuckyoustallman.c is 1) that one's in a and the other in b ; 2) no further"
phf: if you do mkdir a; touch foo; touch a/foo; mv foo a/foo;
phf: there's no way of knowing without having a complete history of states whether or not foo was moved or removed
mircea_popescu: but you can know that one foo is in a and the other not
mircea_popescu: when i say diff a/foo b/foo, diff fails to output "one is in a, the other in b" as the first fucking item on its list of differences. this is because the (idiots) that made diff thought they gain something by eliding "the trivial case".
mircea_popescu: "of course the user knows they're not in the same dir duh" is no design logic.
phf: it's precisely first item it outputs
phf: diff can't know if the newly appeared item that's identical to an item that exists elsewhere in previous state has been moved there from the elsewhere or created in situ
phf: you can communicate that information through a patch format, but that's not something ~diff~ can guess about
mircea_popescu: if you have a : a/b a/c and b : b/b b/d/c it is thereby evident upon diffing a and b that c was moved from a/ to b/d/ if a/c contents === b/d/c contents.
phf: say you have /a/foo and you have /a/bar/foo where both foo are identical. you're running diff -ruN a b, what is the expected behavior?
phf: by your previous question you're saying that diff is supposed to say that foo was moved
mircea_popescu: this'd require all file movements to be a separate patch, as you can't both move and edit in the same go. which imo is bonus the right thing
phf: what if you have /a/foo and /b/bar/foo, /b/qux/foo where all foo are identical?
mircea_popescu: also, if it dies a flaming death in this case that'd be very acceptable, and fuck you for keeping duplicates like that.
phf: so basically hash sums trump namespacing always
phf: in that case we should probably forbid hash identical files to be in different paths
mircea_popescu: we have long ago de facto forbidden hash-identical files ~from being~. anything, at all.
☟︎ phf: (that was by the way how btcbase patcher worked for a long time, until i had to modify it because there are placeholder items in bitcoin source code that are at different filepaths)
mircea_popescu: but this is why this discussion was so important : it has in fact emerged that the correct implementation of diff would first a) calculate hash of all files in each dir ; then b) process moves and only then c) do the diffing.
☟︎ phf: not restricted to moves by the way, there's also copy. there's a certain symmetry lost though. if you say make a genesis with 3 empty files a b c, then they are fresh line patches. but the patch against that that creates another 3 empty files puts cp a x; cp a y; cp a z; in the prelude instead
mircea_popescu: anywya, this system'd be purrfect : if hash unchanged, "this is THE SAME file by a different name (or path, same thing" ; if hash changed "this is DIFFERENT FILE by same name"
a111: Logged on 2017-12-14 21:14 mircea_popescu: we have long ago de facto forbidden hash-identical files ~from being~. anything, at all.
mircea_popescu: phf no such thing as empty lines. put a fucking comment in there.
phf: mircea_popescu: well, empty file does have a shasum
mircea_popescu: if you put empty files in your project i will personally chase you down in the afterlife.
phf: but in this model you can have only one
a111: Logged on 2017-11-14 22:08 asciilifeform must invoke herr babbage, 'i cannot rightfully apprehend the confusion of ideas...'
a111: Logged on 2017-12-14 20:59 trinque: problem stemming from that unix uses file path as a matter of identity, and allows this to be mutable (!)
mircea_popescu: we evidently also ~could~ add filename to the hash. but i dun wanna.
phf: (fwiw so far i've been using patches prelude to stuff metainformation there. one interesting property of patching an already pressed lisp system, is that you don't want a clean press. instead you want to find what state your system is, and then press it further down the chain. but because you don't want to restart the system likewise, you want some additional actions performed as you're moving down the press chain. so i've been using prelude as a place
phf: to put lisp commands that need to be run after the source has been pressed to the current patche's state.)
shinohai: "We're excited to announce that your Blockchain wallet is now offering full support for Bitcoin Cash! "
a111: Logged on 2017-12-14 21:16 mircea_popescu: but this is why this discussion was so important : it has in fact emerged that the correct implementation of diff would first a) calculate hash of all files in each dir ; then b) process moves and only then c) do the diffing.
a111: Logged on 2017-01-05 00:29 asciilifeform: so, one possible diff might be : \4\i'm \+15\quite certainly \80\not fucking learning an aminoacid matrix to be able to use diff i tell you that
ben_vulpes: if i recall correctly, the empty files are necessary to hold the output of trbs compilation process
mircea_popescu: asciilifeform you don't specifically need a manifest, as per discussion (have you been reading the discussion ?) ; can just follow the hashes.
mod6: ben_vulpes: also, patch will not even create those output directories for the build process if the dir doesn't contain at least 1 file. it simply ignores them.
a111: Logged on 2017-12-14 19:55 mircea_popescu: you ~could have a diff format whereby first line is x y z with x = total line count, y notation line count z data line count, and then instead of +++ --- bs you just have line count references in the notation part.
phf: i'm not sure this is necessary, patch already contains line count information in the @ ... @ part
phf: +++ --- is there not for content parsing, but for allowing an arbitrary prelude (that is for including patches in email)
phf: the reason why we have issues with +++ and --- is because vdiff specifically ignores the @ ... @ bits when postprocessing a patch. a complete vdiff-er wouldn't have to do that kind of post processing and can produce a valid patch always
phf: i'm not sure where inband-ness even comes from. patch format has a header of a format 'command used to produce this diff\nsource file\ndestination file\n@@ specific numbers of lines to follow @@\nlines"
phf: so you're proposing to move @@ ... @@ to before "command used" part
mircea_popescu: well, because specific headers used to adnotate (@, +, -) can also appear in the text adnotated
phf: yes, and they won't make a difference!
mircea_popescu: i am in a word proposing to put all the @@ type adnotations in the begining ; and all data at the end
mircea_popescu: but i suppose you're right, a correct v-differ would just follow the extant protocol properly and not have the problem
mircea_popescu: in other news, anyone wanna do a 20bux paypal for me ?
phf: our inband problems stem purely from not utilizing @@ ... @@ information
lobbesbot: Logged on 2017-12-14 22:44:09: <danielpbarron> this is a real testement to quality of S.NSA and its products
mircea_popescu: phf so basically this is cropping down nicely after all. proper vpatch (fixing mod6 's bane, the empty dir thing) + proper vdiff (hash-based preprocessing of rename/move + proper use of @@...@@ + keccak hashing).
☟︎☟︎ phf: hmm, there's a bit of complexity there as far as producing files/directories shuffle, which might take longer, but i'll start with paring things down. i haven't yet seen diff/patch sources closely!
☟︎ mircea_popescu: that came out a lot dumber than intended. how about "plenty of time yet"
diana_coman: to round up the previous thread: previous patch on mpi remains in place but linked to standalone mpi project; EuCrypt got is own genesis patch that creates *the whole currently known structure*; each chapter comes with its own patch adding content
phf: верной дорогой идете, товарищи