Forum logs for 14 Dec 2017
| ben_vulpes: | canvassing the low bandwidth radio space | [00:08] |
| ben_vulpes: | concretely, trying to figure out what it would take to prototype a tuneable phase locked loop channel | [00:14] |
| diana_coman: | asciilifeform, would you please elaborate on http://btcbase.org/log/2017-12-07#1748150 ? apparently it's still not straightforward enough for me in practice | [06:19] |
| a111: | Logged on 2017-12-07 16:51 asciilifeform: mircea_popescu: you can: diff ~the patch~ | [06:19] |
| BingoBoingo: | !~ticker --market all | [07:59] |
| 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 | [07:59] |
| shinohai: | Is this UBI thing a meme now? http://archive.is/q3fXn | [08:03] |
| BingoBoingo: | No, memes are funny | [08:48] |
| BingoBoingo: | And they stick | [08:49] |
| BingoBoingo: | It's an unfunny forced meme | [08:49] |
| shinohai: | But the concept of a UBI is hilarious period. | [08:49] |
| BingoBoingo: | But it would piss of walmart customers: "Whaddya mean the help is taking home more money because they work AND get muh welfares! | [08:52] |
| asciilifeform: | !~later tell diana_coman plox to describe, very very specifically, what you need done. then i'll show how. | [09:52] |
| jhvh1: | asciilifeform: The operation succeeded. | [09:52] |
| 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 | [09:58] |
| diana_coman: | fwiw I managed to do this to some extent, but I don't like this "to some extent" | [10:01] |
| asciilifeform: | diana_coman: i gotta ask , what did this 'to some extent' look like. | [10:14] |
| 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 | [10:17] |
| asciilifeform: | let's see it | [10:17] |
| 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 | [10:18] |
| asciilifeform: | i'm making an example, brb | [10:19] |
| diana_coman: | k, thanks | [10:19] |
| 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 + + + + | [10:36] |
| asciilifeform: | phf: this is the basic insanity of gnupatch. a proper vpatch ought to see that the hashes are the same incoming and outgoing , and Do The Right Thing without the idiot spew | [10:37] |
| asciilifeform: | *vpatcher | [10:37] |
| asciilifeform: | the 1 thing i still don't fully understand is why diana_coman's subdir gotta move | [10:38] |
| asciilifeform: | it isn't required for the linker, nor for maintaining v-lineage ( the latter works just as well if diana_coman were to simply add a comment to 1 or more items in mpi dir , that 'this is nao part of eucrypt' ) | [10:38] |
| asciilifeform: | i.e. why can't 'eucrypt' be a ~sibling~ dir to 'mpi' | [10:39] |
| asciilifeform: | then you dun need any gnupatch shenanigans. | [10:39] |
| asciilifeform: | i'ma demonstrate, brb | [10:40] |
| phf: | presumably she doesn't want to compromise the resultant press because of poor tooling | [10:40] |
| asciilifeform: | waiwat | [10:41] |
| phf: | well, the project is called eucrypt, presses into eucrypt directory, inside it has support infrastructure like mpi | [10:43] |
| phf: | if she decides to replace bignum backing, presumably mpi will get nuked and replaced with something else | [10:44] |
| asciilifeform: | 1s, almost done with example | [10:44] |
| asciilifeform: | http://www.loper-os.org/pub/mpi/pseudo_eucrypt.vpatch << demo | [10:47] |
| asciilifeform: | it's not eucrypt, of course, but the helloworld i originally included in mpi . but shows what i meant above. | [10:48] |
| asciilifeform: | you can press it in my vtron, by 1) recreating diana_coman's working set from last week 2) drop pseudo_eucrypt.vpatch into patches dir 3) ./v.py -wild --wot .wot --seals .seals patches p patches/pseudo_eucrypt.vpatch pseudoeucrypt | [10:49] |
| BingoBoingo: | !~bcstats | [10:49] |
| 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 | [10:49] |
| asciilifeform: | BingoBoingo: do you mind? | [10:49] |
| BingoBoingo: | sorry | [10:49] |
| 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. | [10:51] |
| asciilifeform: | now let's come back to my much earlier pill, which i suggested in the mircea_popescu thread. which is imho even uglier. in that one, diana_coman would have to introduce the three mpi-ism vpatches comprising her working set, as ~files~ into eucrypt. and a sed script, and a vtron invocation, into her eucrypt makefile. | [10:53] |
| asciilifeform: | if phf , or anyone else, can think of a 3rd ( that is, one that actually preserves the v-genealogy , rather than idiot-cut-and-pastism ) i'm all ears. | [10:54] |
| 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. | [10:55] |
| asciilifeform: | imho the item i posted just nao, illustrates the cleaner method. but it has down-side in that one has to give up on 'i get to decide exactly what the unix dir structure will look like, notwithstanding the fact that gnumake was dropped as a baby and has nfi what file moving is' | [10:55] |
| asciilifeform: | mod6: if you dun have a testmode, you gotta sign it yerself to run it, what can i say | [10:55] |
| mod6: | That is fine if it has a valid corresponding signature. | [10:55] |
| asciilifeform: | mod6: i dun like to uncase the launch codes 10,000,000 times per day every time test press. but others are moar than welcome to. | [10:56] |
| 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. | [10:56] |
| asciilifeform: | or can sign it with the mahmood khadir key, or 1 of the others we broke, lol | [10:57] |
| mod6: | haha, fair enough | [10:57] |
| asciilifeform: | at any rate it oughta be obvious what the illustration does simply from naked eye reading. | [10:57] |
| asciilifeform: | you dun actually need to press it, unless specifically want to. | [10:58] |
| mod6: | sure, thanks for posting the sample for diana_coman | [10:58] |
| asciilifeform: | now here's a 3rd pill : | [10:58] |
| asciilifeform: | eh nm no 3rd. can't think of one. | [10:59] |
| 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 | [10:59] |
| asciilifeform: | i'ma leave it for diana_coman , mod6 , phf , mircea_popescu , et al, to consider which pill is less barfatronic, and possibly conceive of another. | [10:59] |
| asciilifeform: | phf: sad indeed, and afaik unfixable without sending gnupatch/gnudiff to where they belong -- into the oven. | [11:00] |
| asciilifeform: | though i'll admit that i personally dun get the fixation with moving mpi to being a subdir of $newproj. | [11:02] |
| asciilifeform: | the vdiffing worx exactly correctly, as does the linkage, without this. | [11:02] |
| asciilifeform: | ( both demonstrated in the example. ) | [11:03] |
| 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 | [11: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/... | [11:13] |
| asciilifeform: | i happen to see the entire unix directory scheme as idiocy | [11:13] |
| phf: | sure, but you can't avoid namespacing issue. you're pressing files by name. | [11:14] |
| asciilifeform: | but, observe, phf's scheme could easily work, and require afaik no regrinds | [11:14] |
| asciilifeform: | take for instance trb , as seen in http://btcbase.org/patches/genesis/file | [11:14] |
| asciilifeform: | dir is 'bitcoin' | [11:15] |
| asciilifeform: | take mpi . dir is 'mpi'. | [11:15] |
| asciilifeform: | iirc all of the v-releases, to date, are already dir-siblings in phf's hypothetical tmsr-rootdir. | [11:15] |
| phf: | nah | [11:16] |
| phf: | actually, i think fg is the only exception | [11:16] |
| 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 | [11:17] |
| asciilifeform: | aha, as shown | [11:18] |
| phf: | no what's shown is eucrypt ~inside~ mpi | [11:18] |
| asciilifeform: | and yes fg genesis apparently lacks subdirization. | [11:18] |
| asciilifeform: | phf: how inside ? they're sibling dirs | [11:19] |
| phf: | ah yeah you're right | [11:19] |
| phf: | well, then we're on the same page | [11:19] |
| asciilifeform: | aha. | [11:19] |
| asciilifeform: | i like phf's unification idea. even if it means that at some point i gotta regrind fg-genesis. | [11:20] |
| asciilifeform: | common dir root for errything. | [11:20] |
| asciilifeform: | it very much seems to me, to be The Right Thing. | [11:22] |
| asciilifeform: | also oughta satisfy mircea_popescu's 'there was 1 genesis' item. because under phf's unification, there in fact ~was~ , created an empty universe with a 'bitcoin' dir. | [11:23] |
| asciilifeform: | this also makes the vtronic-linux a moar tenable, imho, proposition. | [11:26] |
| asciilifeform: | picture, all v-released items live in /v/ seals in /seals/ wot in '/wot/ /v/ gets pressed on install, and on request whenever later... | [11:27] |
| asciilifeform: | common root lets you vdiffate whatever change you made to anything, even if it takes in > 1 subsystem. | [11:28] |
| asciilifeform: | all binaries on the box must trace their descent to contents of /v/... | [11:28] |
| phf: | right | [11:30] |
| 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 | [11:31] |
| asciilifeform: | suckless ? | [11:32] |
| phf: | err, yes, i was going to say slackware, but they are sloppier than bsd | [11:32] |
| asciilifeform: | http://btcbase.org/log/2017-12-14#1751421 << ben_vulpes wtf is 'low bandwidth radio space' ??! how does this differ from 'low thickness physical space' ? how do i parse yer sentence ? | [11:36] |
| a111: | Logged on 2017-12-14 05:08 ben_vulpes: canvassing the low bandwidth radio space | [11:36] |
| asciilifeform: | http://btcbase.org/log/2017-12-14#1751422 << where does one find a ~non~-tunable pll , ben_vulpes ? | [11:36] |
| 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 | [11:36] |
| asciilifeform: | what's even is it. | [11:36] |
| asciilifeform: | possibly i can guess what ben_vulpes wanted... answr is, there is 0 ionospheric propagation at any of the spectrum the cheapo rtl dongle is able to pick up. | [11:38] |
| asciilifeform: | it's good for what comes from before your horizon, and that's it. | [11:38] |
| ben_vulpes: | too parsimonious! | [11:38] |
| asciilifeform: | it also doesn't transmit. if you wanna transmit, you need an actual sdr, e.g. 'hackrf' , 'gnuradio', or something made with own hands. | [11:39] |
| ben_vulpes: | hardware for broadcasting and receiving data over low bandwidth radio links | [11:39] |
| asciilifeform: | rtldongle dun transmit. | [11:39] |
| ben_vulpes: | yeah, this i know. | [11:39] |
| ben_vulpes: | vga card doesn't receive, right? | [11:39] |
| asciilifeform: | vga card + pirate hf amp -- transmit. | [11:39] |
| ben_vulpes: | aha. | [11:40] |
| asciilifeform: | ( connection left as exercise for the reader. ) | [11:40] |
| asciilifeform: | rtl dun receive ~anything at <=30Mhz . | [11:40] |
| asciilifeform: | ( and the supposed converter boxes, dun work worth a shit. ) but iirc i already mentioned this. | [11:40] |
| ben_vulpes: | yup | [11:40] |
| * ben_vulpes | bbl, teaching human 101, will return later | [11:41] |
| asciilifeform: | try 'hackrf' or 1 of the other inexpensive 0-2Ghz or whatever, 'swiss army knives' | [11:41] |
| * asciilifeform | also bbl | [11:42] |
| mircea_popescu: | o hai | [11:52] |
| mod6: | mornin' | [11:55] |
| ben_vulpes: | apparently mike_c's new gig has now banned messages to girls from users they haven't "liked" yet | [13:21] |
| ben_vulpes: | they show up on the sender's "profile" instead | [13:21] |
| ben_vulpes: | so it's a shitty bumble now. | [13:22] |
| 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. | [13:22] |
| BingoBoingo: | ben_vulpes: Well, maybe it's part of mircea_popescu's vast conspiracy to push people into more crowded spaces? | [13:31] |
| ben_vulpes: | mike_c, the republic's mole in IAC | [13:32] |
| ben_vulpes: | buenos dias, BingoBoingo | [13:32] |
| BingoBoingo: | ben_vulpes: Aqui es "Buen dia" en la manana. Otra veces "Buenas" (tardes o noche not specified) | [13:33] |
| ben_vulpes: | buen dia! | [13:33] |
| * BingoBoingo | first 3 days heard it as "Bom dia" though they adopted portuguese greeting from Brasil. | [13:34] |
| mircea_popescu: | http://btcbase.org/log/2017-12-14#1751431 << nah. there's a straight relationship between humour and hope : anything thats hopeable is not humorous and vice-versa. | [13:36] |
| a111: | Logged on 2017-12-14 13:49 shinohai: But the concept of a UBI is hilarious period. | [13:36] |
| 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.) | [13:36] |
| 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. | [13:37] |
| mircea_popescu: | http://btcbase.org/log/2017-12-14#1751446 << VERY late in the game to "not understand" this. | [13:38] |
| 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 | [13:38] |
| mircea_popescu: | the correct time to not understand it was LAST fuycking week, when http://btcbase.org/log/2017-12-07#1748152 | [13:39] |
| 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 ? | [13:39] |
| ben_vulpes: | always entertaining to watch "just wanted"s rack their nuts on the handrail of reality | [13:39] |
| mircea_popescu: | there is that. | [13:39] |
| * BingoBoingo | will have to add that to hosting menu. How many nuts per RU? | [13:39] |
| asciilifeform: | 4!1 | [13:40] |
| mircea_popescu: | http://btcbase.org/log/2017-12-14#1751448 << because it's not a fucking sibling to fucking mpi | [13:40] |
| a111: | Logged on 2017-12-14 15:39 asciilifeform: i.e. why can't 'eucrypt' be a ~sibling~ dir to 'mpi' | [13:40] |
| ben_vulpes: | none, cab should be threaded :D | [13:40] |
| 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. | [13:40] |
| mircea_popescu: | exactly like ANY OTHER piece of fucking useless heathenry | [13:40] |
| mircea_popescu: | http://btcbase.org/log/2017-12-14#1751463 << it does exactly one fucking job. this one : diana_coman please don't talk to asciilifeform or take any further advice from him. total timewaste. | [13:45] |
| 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. | [13:45] |
| * asciilifeform | dun have an answer, other than http://btcbase.org/log/2017-12-05#1746586 . | [13:48] |
| 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. | [13:48] |
| mircea_popescu: | this isn't work, what you're doing. this is anti-work. | [13:48] |
| 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. | [13:49] |
| 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. | [13:49] |
| mircea_popescu: | the world's not some sort of wide open grazing range where we can just randomly produce useless nonsense. | [13:50] |
| asciilifeform: | not as if asciilifeform hypnotized diana_coman into repeatedly requestion (unpaid!) support for her (commercial) proj from him. | [13:54] |
| asciilifeform: | *requesting | [13:54] |
| mircea_popescu: | so now that problem is solved go do something else, there shall be no more of this. | [13:54] |
| * asciilifeform | returns to somethingelse | [13:55] |
| BingoBoingo: | !~ticker --market all --currency gbp | [14:08] |
| jhvh1: | BingoBoingo: Kraken BTCGBP last: 8031.0, vol: 0.03649989 | Volume-weighted last average: 8031.0 | [14:09] |
| BingoBoingo: | !~ticker --market all | [14:09] |
| 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 | [14:10] |
| BingoBoingo: | Incredilag | [14:11] |
| mircea_popescu: | lag is always credible. | [14:15] |
| mircea_popescu: | http://btcbase.org/log/2017-12-14#1751486 << i considered this. it's not evidently broken, but i think it subtly is broken, and the principal cause of the failure of the unix actually -- a failure to correctly handle namespaces. | [14:18] |
| 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/... | [14:18] |
| 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. | [14:19] |
| asciilifeform: | that'd mean tmsr-diff | [14:19] |
| 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 | [14:22] |
| 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. | [14:22] |
| 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. | [14:23] |
| asciilifeform: | if mircea_popescu decides to have the eulora programmers not only copy the thing verbatim, as if v never existed, but to retype it, and whack'em with a stick for each mistyped letter, who am i to object . it's his proggy. | [14:27] |
| mircea_popescu: | contrary to naive intuition, there is no damage in re-reading old code as if it were new. | [14:28] |
| asciilifeform: | fwiw i do it ~all day, ~every day. | [14:28] |
| mircea_popescu: | in fact, i expect it will be the MAJORITY of work for humans in the future. | [14:28] |
| asciilifeform: | it's what i do for a living. | [14:28] |
| asciilifeform: | mechanical tools can make the job slightly smaller, or - when they're rubbish - slightly larger. but it remains. | [14:29] |
| asciilifeform: | incidentally if mircea_popescu wanted to go 'whole hog' re http://btcbase.org/log/2017-12-14#1751589 , could even throw out asciilifeform's mpi and make new one from the source material. see if it ends up same, possibly find new cuts. | [14:34] |
| 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 | [14:34] |
| * asciilifeform | promises not to cry , is old enuff | [14:34] |
| mircea_popescu: | that's ok, minigame delayed enough as it is. | [14:34] |
| mircea_popescu: | phf are you amenable to re-writing diff btw ? http://btcbase.org/log/2017-12-06#1747792 is going to happen later this year, and v-immutability is a pita. | [14:42] |
| a111: | Logged on 2017-12-06 22:51 mircea_popescu: once we have keccak. | [14:42] |
| asciilifeform: | iirc ben_vulpes had a prototype . | [14:43] |
| ben_vulpes: | mnope did not | [14:45] |
| asciilifeform: | mircea_popescu: consider making a spec for the One Troo Diff ? | [14:47] |
| * asciilifeform | promises to read | [14:47] |
| 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. | [14:47] |
| asciilifeform: | yea but mircea_popescu demanded sane namespace behaviour | [14:48] |
| mircea_popescu: | i'm letting him contribute, what. he understands what the problems are. | [14:54] |
| mircea_popescu: | maybe he bites the bullet and makes special files. or who the hell knows. i'm curious. | [14:54] |
| 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. | [14:55] |
| mircea_popescu: | can EVEN KEEP the +++ --- style separators, but in the DATA segment | [14:56] |
| mircea_popescu: | making your file comvertible to old style patch through a truncation op. | [14:56] |
| asciilifeform: | ( pertinent old threads -- http://btcbase.org/log/2017-01-03#1595812 http://btcbase.org/log/2017-01-05#1596689 http://btcbase.org/log/2017-01-05#1596584 and elsewhere ) | [15:05] |
| a111: | Logged on 2017-01-03 21:14 mircea_popescu: v is really only as powerful as the underlying differ is. | [15:05] |
| 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 | [15:05] |
| a111: | Logged on 2017-01-05 00:24 mircea_popescu: lines are good! | [15:05] |
| mircea_popescu: | !!up nocko | [15:10] |
| deedbot: | nocko voiced for 30 minutes. | [15:10] |
| mircea_popescu: | you new here ? | [15:10] |
| asciilifeform: | possibly http://btcbase.org/log/2017-12-10#1749289 | [15:11] |
| 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. | [15:11] |
| mircea_popescu: | ah | [15:11] |
| asciilifeform: | !!key nocko | [15:11] |
| deedbot: | Not registered. | [15:11] |
| asciilifeform: | maybeshakespeare, maybeanothermanbysamename | [15:11] |
| * asciilifeform | bbl, meat maneuvers. | [15:12] |
| phf: | http://btcbase.org/log/2017-12-14#1751602 << i have some ideas of the first steps, that is i can make backwards compatible vpatched diff/patch | [15:18] |
| a111: | Logged on 2017-12-14 19:42 mircea_popescu: phf are you amenable to re-writing diff btw ? http://btcbase.org/log/2017-12-06#1747792 is going to happen later this year, and v-immutability is a pita. | [15:18] |
| mircea_popescu: | how ? | [15:18] |
| 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. | [15:20] |
| mircea_popescu: | why without ? | [15:21] |
| 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 ...") | [15:22] |
| mircea_popescu: | mpi ? | [15:23] |
| 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" | [15:23] |
| mircea_popescu: | the whole idea is to eg import keccak from eucrypt | [15:23] |
| mircea_popescu: | and why would diff/patch be outside of vtroner is the larger design question | [15:23] |
| phf: | mpi is a fraction of what gnupg is, are we then moving away from pgp keys and signatures? | [15:24] |
| mircea_popescu: | idea is to use tmsr-rsa anyway | [15:24] |
| phf: | hmm | [15:26] |
| phf: | this then is entirely unscoped | [15:26] |
| mircea_popescu: | it is. open discussion. | [15:26] |
| mircea_popescu: | in principle we could do incremental builds but only if they can be cleanly upgraded later, that's a major point. | [15:27] |
| 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 | [15:28] |
| mircea_popescu: | so basically keep them modular ? | [15:29] |
| mircea_popescu: | can you imagine any other context besides pressing this new diff/patch would be used in ? | [15:29] |
| 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) | [15:29] |
| mircea_popescu: | how can they sig for you | [15:30] |
| phf: | i thought that's what you were talking about? | [15:30] |
| mircea_popescu: | no ? | [15:30] |
| mircea_popescu: | ~check~ signatures. | [15:30] |
| phf: | or the thinking that vdiff doesn't sig, but then vpatch expects a sig never the less? | [15:30] |
| mircea_popescu: | not produce them | [15:30] |
| mircea_popescu: | and yes. | [15:31] |
| mircea_popescu: | sign in your sign room, mofo. | [15:31] |
| 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. | [15:34] |
| mircea_popescu: | it doesn't have to be decided now. | [15:34] |
| mircea_popescu: | isn't the latter actually ideal, protocol wise ? | [15:35] |
| 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 | [15:37] |
| 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 | [15:38] |
| mircea_popescu: | aaaa | [15:39] |
| mircea_popescu: | you're absolutely right. patch process must be much looser than this. | [15:39] |
| 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) | [15:41] |
| mircea_popescu: | hm. | [15:44] |
| 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 | [15:45] |
| 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 | [15:49] |
| mircea_popescu: | the fact that unix diff is directory blind is an idiocy larger than commonly encountered in that thing's misdesign | [15:50] |
| mircea_popescu: | a file is not "its contents and AN ARBITRARY TRUNCATION OF ITS NAME" | [15:50] |
| mircea_popescu: | and a file's fucking name is its absolute path, not the last bit thereof. | [15:51] |
| mircea_popescu: | but whatever, in 1970 people couldn't afford disks with actual directory structure in them | [15:52] |
| phf: | diff/patch allows for absolute paths, we don't them it though | [15:55] |
| mircea_popescu: | i don't know how it allows if i can't move a god damned file. | [15:55] |
| phf: | well, moving of the file is a filesystem operation, what does it have to do with ~diffing~? | [15:56] |
| mircea_popescu: | that the name of the file is the file. | [15:56] |
| mircea_popescu: | the FILE has changed. | [15:56] |
| 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 | [15:57] |
| 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 | [15:57] |
| mircea_popescu: | ergo, BOTH these operations have been edits of the file. | [15:58] |
| mircea_popescu: | phf and in that diff is designed by turkeys. | [15:58] |
| 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 | [15:59] |
| phf: | *claims to do | [15:59] |
| trinque: | problem stemming from that unix uses file path as a matter of identity, and allows this to be mutable (!) | [15:59] |
| trinque: | can't be both | [15:59] |
| mircea_popescu: | ^ | [15:59] |
| mircea_popescu: | trinque's statement is perfectly acceptable. | [16:00] |
| phf: | but then the question is what is the responsibility of diff | [16:00] |
| 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. | [16:01] |
| phf: | fwiw diff can't even know that a file has been moved | [16:01] |
| mircea_popescu: | but it can know that it's not in the same directory. | [16:01] |
| phf: | no, it can't | [16:01] |
| 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" | [16:01] |
| mircea_popescu: | why can't it ? | [16:02] |
| phf: | if you do mkdir a touch foo touch a/foo mv foo a/foo | [16:02] |
| phf: | there's no way of knowing without having a complete history of states whether or not foo was moved or removed | [16:03] |
| mircea_popescu: | but you can know that one foo is in a and the other not | [16:03] |
| mircea_popescu: | diff compares two items, not an item to itself | [16:03] |
| 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". | [16:04] |
| mircea_popescu: | this turns out to not have been so | [16:04] |
| mircea_popescu: | "of course the user knows they're not in the same dir duh" is no design logic. | [16:04] |
| phf: | wut | [16:04] |
| phf: | it's precisely first item it outputs | [16:05] |
| mircea_popescu: | then WHY!!!! can't i use it to move files!!11 | [16:05] |
| 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 | [16:07] |
| phf: | you can communicate that information through a patch format, but that's not something ~diff~ can guess about | [16:07] |
| mircea_popescu: | i dun get what the problem is. | [16:08] |
| 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. | [16:08] |
| 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? | [16:09] |
| mircea_popescu: | what's to guess ? | [16:09] |
| phf: | by your previous question you're saying that diff is supposed to say that foo was moved | [16:10] |
| 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 | [16:10] |
| mircea_popescu: | phf yeah ? | [16:10] |
| phf: | what if you have /a/foo and /b/bar/foo, /b/qux/foo where all foo are identical? | [16:11] |
| mircea_popescu: | then the first one was moved and the other created. | [16:11] |
| 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. | [16:12] |
| phf: | so basically hash sums trump namespacing always | [16:12] |
| mircea_popescu: | it's why we have them | [16:12] |
| mircea_popescu: | "file's identity" as per trinque | [16:13] |
| phf: | in that case we should probably forbid hash identical files to be in different paths | [16:13] |
| mircea_popescu: | kinda what i said above | [16:14] |
| mircea_popescu: | we have long ago de facto forbidden hash-identical files ~from being~. anything, at all. | [16:14] |
| 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) | [16:14] |
| mircea_popescu: | hence the keccak instead of curent whatever it is. | [16:14] |
| mircea_popescu: | phf because it's the logical way for it to work | [16:15] |
| 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. | [16:16] |
| 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 | [16:18] |
| 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" | [16:19] |
| asciilifeform: | http://btcbase.org/log/2017-12-14#1751721 << ftr my orig v eggogs, 'cyclic graph!' if any new-hash is == to any old-hash | [16:19] |
| 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. | [16:19] |
| mircea_popescu: | phf no such thing as empty lines. put a fucking comment in there. | [16:19] |
| mircea_popescu: | empty files* i mean | [16:19] |
| phf: | mircea_popescu: well, empty file does have a shasum | [16:20] |
| mircea_popescu: | if you put empty files in your project i will personally chase you down in the afterlife. | [16:20] |
| phf: | but in this model you can have only one | [16:20] |
| mircea_popescu: | tbh i don't even understand why the machine permits such insanity. an empty file is very much a http://btcbase.org/log/2017-11-14#1738478 trigger | [16:21] |
| a111: | Logged on 2017-11-14 22:08 asciilifeform must invoke herr babbage, 'i cannot rightfully apprehend the confusion of ideas...' | [16:21] |
| asciilifeform: | mircea_popescu: it's a cmachineism -- 'hey this register CAN haz a 0 in it, ergo lengths of 0 are permissible'. observe that i banished this idiocy from ffa planet | [16:22] |
| phf: | http://btcbase.org/log/2017-12-14#1751683 | [16:22] |
| 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 (!) | [16:22] |
| asciilifeform: | ( where length of FZ 0 is ~not~ permitted, because wtf ) | [16:22] |
| mircea_popescu: | we evidently also ~could~ add filename to the hash. but i dun wanna. | [16:23] |
| asciilifeform: | you could in phf's unified-namespace thing, but i dun see how else otherwise | [16:23] |
| mircea_popescu: | myeah. | [16:23] |
| 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 | [16:27] |
| phf: | to put lisp commands that need to be run after the source has been pressed to the current patche's state.) | [16:27] |
| shinohai: | "We're excited to announce that your Blockchain wallet is now offering full support for Bitcoin Cash! " | [16:27] |
| shinohai: | Why even bother with Bitcoin | [16:28] |
| asciilifeform: | phf: consider posting example ? | [16:29] |
| mircea_popescu: | phf interesting | [16:29] |
| asciilifeform: | http://btcbase.org/log/2017-12-14#1751725 << the retardation of unixdiff is unfortunately not limited to file moves. it also has no ability to represent , e.g., sections of a file moving ( iirc this came up during the original genesis thread ) | [16:30] |
| 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. | [16:30] |
| asciilifeform: | it's a pathetically dumb state machine. | [16:31] |
| asciilifeform: | the tragicomic part is that i picked plain old diff for vtronics 'so that patches will be readable' | [16:32] |
| asciilifeform: | ( and 'everyone already has it, and it works' etc ) | [16:33] |
| asciilifeform: | whereas if you want to be able to compactly represent ~arbitrary transforms of text and of dirs, you end up with something like sed on top of a... text representation of a tar ? | [16:34] |
| asciilifeform: | ( or even with http://btcbase.org/log/2017-01-05#1596596 . ) | [16:35] |
| 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 | [16:35] |
| asciilifeform: | incidentally mircea_popescu , phf , consider a particular cut : suppose that ( otherwise unchanged ) diff format did not mention paths at all, only hashes. and there is a separate section, 'manifest', that is table of hashes to paths. during press, the latter is eaten and traditional unix dir appears. | [16:39] |
| mircea_popescu: | too many knobs | [16:40] |
| asciilifeform: | it's 1 knob. | [16:40] |
| asciilifeform: | and does away with the horror chamber of 'i moved a file, where did the 10 MB of crud come from' | [16:40] |
| asciilifeform: | i dunno that the addition of a knob to divorce from the idiocy of unixpathism , is really escapable | [16:41] |
| asciilifeform: | it'll have to be solved , in some way, with at least 1 knob. | [16:41] |
| ben_vulpes: | if i recall correctly, the empty files are necessary to hold the output of trbs compilation process | [16:42] |
| asciilifeform: | ben_vulpes: only because unix diff , again , is retarded | [16:42] |
| asciilifeform: | and pretends that empty dirs don't matter, but somehow a dir that is empty BUT for 1 emptyfile -- is nonempty. | [16:42] |
| asciilifeform: | it's rubbish. | [16:42] |
| asciilifeform: | observe that in e.g. ffa , used nonempty placeholders. | [16:43] |
| asciilifeform: | ( trb-genesis, for better or worse, was a plain cut of the original material. ended up preserving the idiocy of empty file. ) | [16:44] |
| mircea_popescu: | asciilifeform you don't specifically need a manifest, as per discussion (have you been reading the discussion ?) can just follow the hashes. | [16:48] |
| asciilifeform: | aha caught up | [17:03] |
| asciilifeform: | imho this is the troo cut | [17:03] |
| asciilifeform: | make paths non-special | [17:03] |
| asciilifeform: | and just text, and subject to diffing like any other text. | [17:03] |
| * asciilifeform | bbl,meat | [17:04] |
| 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. | [17:06] |
| mircea_popescu: | ^ | [17:06] |
| mod6: | it's idiotic. | [17:06] |
| mircea_popescu: | h] | [17:35] |
| mircea_popescu: | phf any word on specifically http://btcbase.org/log/2017-12-14#1751612 ? | [17:35] |
| 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. | [17:35] |
| phf: | i'm not sure this is necessary, patch already contains line count information in the @ ... @ part | [17:37] |
| phf: | +++ --- is there not for content parsing, but for allowing an arbitrary prelude (that is for including patches in email) | [17:38] |
| 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 | [17:39] |
| mircea_popescu: | but this would remove the inband-ness | [17:41] |
| 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" | [17:43] |
| phf: | so you're proposing to move @@ ... @@ to before "command used" part | [17:44] |
| mircea_popescu: | well, because specific headers used to adnotate (@, +, -) can also appear in the text adnotated | [17:44] |
| phf: | yes, and they won't make a difference! | [17:44] |
| mircea_popescu: | i am in a word proposing to put all the @@ type adnotations in the begining and all data at the end | [17:44] |
| mircea_popescu: | but i suppose you're right, a correct v-differ would just follow the extant protocol properly and not have the problem | [17:44] |
| mircea_popescu: | in other news, anyone wanna do a 20bux paypal for me ? | [17:45] |
| mircea_popescu: | danielpbarron ? | [17:45] |
| phf: | our inband problems stem purely from not utilizing @@ ... @@ information | [17:45] |
| danielpbarron: | mircea_popescu, sure | [17:46] |
| mircea_popescu: | 1sec | [17:46] |
| mircea_popescu: | in other crossposts, http://logs.minigame.bz/2017-12-14.log.html#t22:44:09 | [17:48] |
| lobbesbot: | Logged on 2017-12-14 22:44:09: <danielpbarron> this is a real testement to quality of S.NSA and its products | [17:48] |
| 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). | [17:49] |
| mircea_popescu: | by the looks of it, sometime in january. that works ? | [17:49] |
| phf: | should be doable | [17:49] |
| mircea_popescu: | cool. | [17:50] |
| 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! | [17:51] |
| mircea_popescu: | kinda why im giving you a two week lead here. | [17:52] |
| mircea_popescu: | danielpbarron pm | [17:53] |
| mircea_popescu: | that came out a lot dumber than intended. how about "plenty of time yet" | [17:55] |
| deedbot: | http://www.dianacoman.com/2017/12/14/eucrypt-chapter-2-a-source-of-randomness/ << Ossasepia - EuCrypt Chapter 2: A Source of Randomness | [17:55] |
| 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 | [17:58] |
| mircea_popescu: | onwards&upwards | [17:58] |
| phf: | верной дорогой идете, товарищи | [18:01] |
| phf: | diana_coman: since you basically split from mpi, i put you into a separate project http://btcbase.org/patches?patchset=eucrypt | [20:57] |
| mircea_popescu: | diana_coman one that I actually bought link to http://www.dianacoman.com/2017/10/02/some-costs-of-importing-randomness/ neh ? mightaswell... | [20:57] |
| phf: | asciilifeform: http://downloads.cornall.co/ibm-capsense-usb/ is that what you used for your model f? | [20:57] |
| phf: | ah found relevant bits in logs http://btcbase.org/log/2016-09-12#1540407 | [21:03] |
| a111: | Logged on 2016-09-12 17:26 phf: asciilifeform: are you using breadboarded/soldered version, or you ended up printing the pcb too for the keyboard controller? | [21:03] |
| asciilifeform: | aha phf, it | [21:19] |
| asciilifeform: | http://btcbase.org/log/2017-12-14#1751799 << this sounds mightily spiffy | [21:20] |
| a111: | Logged on 2017-12-14 22:49 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). | [21:20] |
| asciilifeform: | http://btcbase.org/log/2017-12-14#1751797 << lolneato. congrats on success of FG dealership, danielpbarron | [21:24] |
| a111: | Logged on 2017-12-14 22:48 mircea_popescu: in other crossposts, http://logs.minigame.bz/2017-12-14.log.html#t22:44:09 | [21:24] |
| asciilifeform: | http://btcbase.org/log/2017-12-14#1751803 << at one time i linked to 'diff' src here, when hunting for ordering nonuniformity that turned out to be a uniturdism . it made koch's war crime, look clean. | [21:25] |
| a111: | Logged on 2017-12-14 22:51 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! | [21:25] |
| asciilifeform: | http://btcbase.org/log/2015-08-21#1246540 << thread. | [21:27] |
| a111: | Logged on 2015-08-21 01:22 asciilifeform: mircea_popescu: try this on for size: | [21:27] |
| asciilifeform: | http://btcbase.org/log/2017-12-14#1751807 << the fg link goes to my www , naked , which imho is not obviously relevant : i recommend https://archive.is/CGQkR instead | [21:34] |
| a111: | Logged on 2017-12-14 22:55 deedbot: http://www.dianacoman.com/2017/12/14/eucrypt-chapter-2-a-source-of-randomness/ << Ossasepia - EuCrypt Chapter 2: A Source of Randomness | [21:34] |
Category: Logs
