diana_coman:
http://btcbase.org/log/2018-09-27#1854882 -> got your .tar.gz but I could not find in it the .wot and .seals? at any rate, if I copied over the .wot and .seals dirs, it pressed perfectly fine with v here (9999 K version); ftr I ran also precisely the v.pl you have in there and it also worked!
diana_coman: re using vtools, I currently first check sig (so by hand, separate 1-line) and if ok, then feed patch to vtools
a111: Logged on 2018-09-27 02:28 trinque: obviously I want such a vtron for the cuntoo final cut, or what's the use of the build process producing a vpatch
diana_coman: adding to the above: old v can still be used to check the sigs, to avoid manual check; so use old v to check the sigs and once satisfied, just feed patches to vpatch
diana_coman: I'll add the patches for the tester on top of the above, later today
a111: Logged on 2018-09-27 09:31 diana_coman:
http://btcbase.org/log/2018-09-27#1854882 -> got your .tar.gz but I could not find in it the .wot and .seals? at any rate, if I copied over the .wot and .seals dirs, it pressed perfectly fine with v here (9999 K version); ftr I ran also precisely the v.pl you have in there and it also worked!
a111: Logged on 2018-09-27 09:31 diana_coman:
http://btcbase.org/log/2018-09-27#1854882 -> got your .tar.gz but I could not find in it the .wot and .seals? at any rate, if I copied over the .wot and .seals dirs, it pressed perfectly fine with v here (9999 K version); ftr I ran also precisely the v.pl you have in there and it also worked!
diana_coman: asciilifeform, np; re vtron yes, currently it is only vdiff and vpatch functionality; I use old v to see the flow (since it checks the seals but doesn't care about the hashes until press time) and then the vpatch to actually press; looking forward to esthlos' vtron
diana_coman: I added the manifest + comments in it; otherwise *all* code is precisely what I got from pressing your patches
diana_coman: asciilifeform, ok, I'll mirror your sigs too and link to the page anyway; a bit later today
diana_coman: I'll have to, since the sigs need to fit the .vpatch file name, yes
diana_coman: fwiw I *did* specifically state in the manifest that it's using Keccak hashes
a111: Logged on 2018-09-27 13:50 diana_coman: asciilifeform, np; re vtron yes, currently it is only vdiff and vpatch functionality; I use old v to see the flow (since it checks the seals but doesn't care about the hashes until press time) and then the vpatch to actually press; looking forward to esthlos' vtron
a111: Logged on 2018-09-26 22:00 asciilifeform: mircea_popescu: prolly like most folx who actually work on proggies, asciilifeform has '9000' vtrees on various disk, on various boxen, that are in classical format, and many not even intended for publication, the ones that see daylight naturally will become newtype
a111: Logged on 2018-09-26 22:01 asciilifeform: unlike some folx (as late as '16 some confessed to git ) asciilifeform does not use heathen versiontrons internally, strictly 100% v from aug '15
phf: asciilifeform: this has been extensively discussed in the logs. there was never a need for "new style v". v works just fine. one of the design goals of vtools was to nail down (and improve upon) the patch format. vtools are explicitly designed to be used with an existing v (for example i use it with v.py). vdiff produces wellformed vpatches and vpatch presses them ensuring that the format is valid and that the hashes stand. there's no
phf: need for the separate keccak hashing tool, because vpatch ensures that the result is valid.
lobbesbot: phf: Sent 14 hours and 6 minutes ago: <asciilifeform> nm, distinguished by hand... but my vtron doesn't verify the sigs (not immediately sure why) and mod6's -- sees only Leaf: vtools_vpatch_newline.vpatch (phf)
phf: asciilifeform: but if you want a full "v replacement and i don't want to think about none of that" then just use esthlos's item. i believe he has a working keccak already
a111: Logged on 2018-09-27 13:50 diana_coman: asciilifeform, np; re vtron yes, currently it is only vdiff and vpatch functionality; I use old v to see the flow (since it checks the seals but doesn't care about the hashes until press time) and then the vpatch to actually press; looking forward to esthlos' vtron
phf: asciilifeform: you're just spreading fud, i don't know where to start unpacking this conversation
phf: asciilifeform: vtools is not a replacement for v.pl!
phf: asciilifeform: you already have the shaft, it's v.py
phf: when i started working on vtools there was already a handful of battle tested V implementations, that relied on vdiff.sh/gnu patch combination. vtools is a "drop in" replacement for the later. you get valid vpatch on the input, valid press on the output. the purpose is to nail down the format, and gradually replace out its parts (e.g. transparent sha->keccak transition)
mod6: I had started on a ada vtron last year, but I got hung up with some of the string handling, and the fact that I had to use shell-outs for pgp. I'd like to get back to it at some point. I would love to dispense with the shell outs - and can probably do so, but not until 'peh' is finished.
mod6: The string handling, discussed previously in the logs, is basically a solved problem - would just need something similar to what alf or others have done before - character by character.
mod6: Anyway, lack of time is a problem here too.
mod6: asciilifeform: ok cool.
phf: i think v.pl is a venerable tool, it's battle tested, it has established interface, it's been worked on for three years now. i don't see any reason to throw it out.
phf: i guess it's presumptuous on my part to think that it's exactly obvious how to take vtools and plug it directly into an existing v's, but that's all that's needed
phf: asciilifeform: well, you're one of the v maintainers, i'd think you would want to do it to your own tool.
phf: re standalone keccak hasher: i'm not sure that it's needed, i think the relevant phase can just be dispensed with altogether. `vpatch' verifies the hashes as it goes along
phf: you can basically do (cat foo.vpatch bar.vpatch qux.vpatch) | vpatch and expect the resulting press to be fully valid, hashes and all
a111: Logged on 2018-09-27 15:33 phf: asciilifeform: this has been extensively discussed in the logs. there was never a need for "new style v". v works just fine. one of the design goals of vtools was to nail down (and improve upon) the patch format. vtools are explicitly designed to be used with an existing v (for example i use it with v.py). vdiff produces wellformed vpatches and vpatch presses them ensuring that the format is valid and that the hashes stand. there's no
trinque: phf: did the problem which caused folks to have to delete one branch of your vpatch tree to press the other get fixed in v.pl?
trinque: oh, modified. /me sips moar coffee
trinque: trinquebrain clearly not handling the swaps between v.pl and v.py in thread just yet
trinque: v-esthos if it's finished, and works, though I'm willing to hear counterarguments
trinque: afaik it's the most didactic of the items
trinque: however it'll need a vdiff too, so was going to pull in also phf's work
phf: trinque: it hasn't been, and i'm doing omission by not mentioning that vtools had a later mandate for graph resolution. meanwhile esthlos v was supposed to supposed to fix the issue, i suspect that different v's will eventually catch up.
phf: trinque: vtools has not been design or intended to compete with any particular v implementation. it's a set of tools that you can use in a v workflow (hence the name). at least initially it was two matching tools vdiff and vpatch that know how to produce and consume a canonical vpatch. the conflation came up, because i also published vtools in a form that broke existing canonical v, v.pl, and was tasked with fixing the situation.
phf: re esthlos's work i think it's a shame that he chose to reimplement own keccak, but is still calling out to gnu patch. he could just focus on graph resolution/signature/wot checking, and offload the validation on vpatch: construct the press list, feed the patches in-order to vpatch, if vpatch succeeds then you know _for certain_ that the sequence of patches is valid, hashes and all
mod6: yeah, this is the right approach imho. it's what i'd do with my ada-vtron, if it ever does breathe.
trinque: phf: in principle I'm entirely in favor of the "unix philosophy" approach of simple, single-purpose tools
trinque: the "hunk succeeded at offset $hurrr" thing is abominable
trinque: tonail-eater tier mental rigor.
phf: right vpatch applies 'diff -ruN' style patches exactly. it also keeps track of both the hash of the patched file and the hash of the result state as it's reading/patching (there's no double read happening), and errors out if either fails to match the hashes in the header
phf: asciilifeform: i have a ksum PoC for you,
http://btcbase.org/patches/vtools_ksum signed but it's from workbench, potentially buggy. "ksum foo bar qux" gives you shasum style <hash> foo\n<hash> bar\n<hash> qux\n
BingoBoingo: asciilifeform: I have returned from the envirorast office, about to fire off a message to DHL informing them to try again as I am a provisionally acredited importer of packaged goods for commercial use
a111: Logged on 2018-09-27 13:35 asciilifeform: call me an idjit, but i thought there were a new vtron...
mircea_popescu: keep your tools in state of good repair, you won't have to start fixing fence by fixing hammer and nails.
mircea_popescu: in any case shit in the logs ain't gonna to "just go away", this isn't linuslands. ignoring it is like ignoring hot coals.
a111: Logged on 2018-09-27 15:12 asciilifeform: ( fughot that they decrement ! )
a111: Logged on 2018-09-27 20:00 mircea_popescu:
http://btcbase.org/log/2018-09-27#1854988 << we came up with this clever thing sometime in 2015 or so iirc. not sure what is gained by doing 99995 --> 99994 etc in light of experience, but i clearly recall how cool it looked at the time.
a111: Logged on 2018-09-18 18:22 asciilifeform: this is the other thing, 'changes are expensive' promote imho a sane view of software, where you actually try to perma-stabilize yer proggy, rather than to keep up the classic 'open sores' eternal cauldron of bubbling liquishit
a111: Logged on 2018-09-27 19:52 mircea_popescu:
http://btcbase.org/log/2018-09-27#1854952 << what you apparently did was completely ignore the matter for five months, then discover like children that you actually need tools at the time you started on the task (late at night etc) and so forth.
a111: Logged on 2018-09-27 19:17 BingoBoingo: asciilifeform: I have returned from the envirorast office, about to fire off a message to DHL informing them to try again as I am a provisionally acredited importer of packaged goods for commercial use
a111: Logged on 2018-09-27 19:52 mircea_popescu: in any case shit in the logs ain't gonna to "just go away", this isn't linuslands. ignoring it is like ignoring hot coals.
diana_coman: asciilifeform, ^ there is also a small .vpatch for that issue with null chars at ip
diana_coman: the rest then are for the tester only - let me know if you give it a spin and how it behaves
diana_coman: but otherwise the udp_tester.vpatch makes some changes to udp lib that are really just for testing (i.e. I think they should not be part of production use of udp lib)
diana_coman: it's the move to generic + relaxation of some constraints (because of generic and because of using Calendar for local time to log)
mircea_popescu: asciilifeform no, i understand the principle, just... nothing, not even mozilla went through 10k versions to date.
mircea_popescu: more's the point : HOW do we establush "100is much, 10k is enough, etc"
a111: Logged on 2018-09-27 20:21 asciilifeform:
http://btcbase.org/log/2018-09-27#1855078 << trickier item. recall 'the song of the sirens, some have escaped, but their silence -- no one' . how to deal with 'but ~was~ it in the l0gz'.
a111: Logged on 2018-09-27 20:58 mircea_popescu: more's the point : HOW do we establush "100is much, 10k is enough, etc"
a111: Logged on 2018-09-27 21:02 mircea_popescu:
http://btcbase.org/log/2018-09-27#1855089 << i have no fucking idea how. i read the logs daily atm, mostly impelled by... outright fear. the best heuristic i know of, but otherwise this promises to be a first caliber bane as time goes by.
BingoBoingo: For the longs: Peso Argentino went from 0.85/1.45 to 0.55/1.25 in one month.
mod6: nice work diana_coman
a111: Logged on 2018-09-25 15:58 mircea_popescu: add a 1s delay between packets.
a111: Logged on 2018-09-27 15:36 phf: asciilifeform: but if you want a full "v replacement and i don't want to think about none of that" then just use esthlos's item. i believe he has a working keccak already
a111: Logged on 2018-09-27 15:50 phf: asciilifeform: you're just spreading fud, i don't know where to start unpacking this conversation
a111: Logged on 2018-09-27 19:52 mircea_popescu:
http://btcbase.org/log/2018-09-27#1854952 << what you apparently did was completely ignore the matter for five months, then discover like children that you actually need tools at the time you started on the task (late at night etc) and so forth.
mircea_popescu: sadly there's no simple/just-add-water way out of "i've been ignoring this whole thing for x interval, wut nao". nao -- pick up from where you left off, what.
a111: Logged on 2018-09-19 15:56 asciilifeform: mod6: i dun like to discourage folx, esp. mircea_popescu's pupil, who is evidently pouring sweat into the job. but i expected the items would get better with time, and imho so far they haven't
mircea_popescu: but yes, the obnoxious part about the ignorant approach is that it purports to "identify as problems" the speciffic parts that are both well designed and functioning as designed, ie specifically the hash transition.
mircea_popescu: that alf manages to do this naturally and with i suspect no malice aforethought (or anything else aforethought at all) is in a sense supportive of the hopes of humanity -- apparently ignorance breeds the nonsense on its own, no "dark lizard" behind it all needed.
mircea_popescu: you realise, i'm not going to go "here -- use THIS .emacs". not in this life.
mircea_popescu: yes there's nothing wrong with people publishing toolsets ; but this can't become a fucking expectations wth. craftsman -- has toolset.
mircea_popescu: standardized tools -- for mcdo cashiers. actual craftsman, responsible for his toolset, which nobody inspects for him but himself.
mircea_popescu: as things grow, upgrades by parts become a matter of necessity.
mircea_popescu: restaurant served me complete pie, but body shop did only paint the preexisting car i supplied them with.
mircea_popescu: nb. let it run for a few weeks if you will, so we have nice datasets to work on
mircea_popescu: and bidirectional is good imo, i half expect to discover parity between lastmile->dc and dc->lastmile directions.
mircea_popescu: so then. phf did a new ~vdiff~. and a very good one at that, from all i can see.
mircea_popescu: and diana_coman or hanbot or who will you pick have little problem in turning over next-day keccak patches on trees, as recently put on display. i don't think they're either smarter or blesseder than you, they just have the toolset ready.
mircea_popescu: asciilifeform wanna run one with .1 s or 10ms ? that might be a good move.
mircea_popescu: just makew sure you put something in there to distinguish "my interface is shitdrops on the floor"
mircea_popescu: because we're not really into measuring shitty nat routers on cisco customer walls per se.
mircea_popescu: early proto-test indicated most of the lossage happens before 2nd hop
mircea_popescu: in the worst case, capture the flow upstream and see if the box actually puts out the packets ?
mircea_popescu: though in general can have interface log outbound, say.
mircea_popescu: but yes -- the test can (and likely will) be tightened. for starters we just wanted to get a sort of "absolute path limits". and THESE do indeed turn out to be further out than originally thought -- 2kb packets make it np unfragged and in order 100% of the time, and even 20-60kb packets made it.
mircea_popescu: (and when didn't made it -- local interface dropping was the likely culprit)
mircea_popescu: that whole "1 packet per burst makes it" was very much "well doh, 1 gets sent at all"
mircea_popescu: apparently some parts of the internet DID get better over time.
mircea_popescu: truth be told, on the internet-as-we-thought-it-was, video on demand'd have been a miracle.
mod6: thats still 2 orders faster than the last test tho.
mircea_popescu: i don't really want the traffic to go much over the kb/s range
mircea_popescu: but anyway, imo if mmorpg needs > kb/s connectivity something's misdesigned somewhere.
mircea_popescu: not including here asset transfers ; merely the "bread and butter" so to speak.
mircea_popescu: even if you do voices, client should acquire the asset and cache it.
mircea_popescu: kinda weird for a restaurant to also attempt to provide phone service for the patrons. what, they can't carry phones inside ?
mircea_popescu: asciilifeform through whatever they like. it's their fucking friends, neh ? sometimes gaming i'll speak acrossd table / yell across room w/e. my fucking harem, my fucking business.
a111: Logged on 2018-09-27 15:57 phf: i think v.pl is a venerable tool, it's battle tested, it has established interface, it's been worked on for three years now. i don't see any reason to throw it out.
a111: Logged on 2018-09-26 18:52 mircea_popescu: so delete them, then.
a111: Logged on 2018-09-27 15:58 phf: i guess it's presumptuous on my part to think that it's exactly obvious how to take vtools and plug it directly into an existing v's, but that's all that's needed
a111: Logged on 2018-09-27 16:02 phf: you can basically do (cat foo.vpatch bar.vpatch qux.vpatch) | vpatch and expect the resulting press to be fully valid, hashes and all
mircea_popescu: re stand-alone hasher : useful in general (for reason alf describes) even if not strictly needed for v work ; the only way to get one i know of atm is via eucrypt.
mircea_popescu: dunno how many people keep that around though. i don't think it'd be a crime or anything to make a command-line keccak branch off of it, so people can just press to that if they want.
mircea_popescu sitll goign through teh logs. apparently going out for a few hours IS UNSAFE
mircea_popescu: Die Kaisrin hat sich mit dem Franzosen alliiert und das Römische Reich gegen mich revoltiert. De Russen sind gefallen in Preußen ein, etc etc.
mircea_popescu:
http://btcbase.org/log/2018-09-27#1855041 << this is so, "here's a complete model" is a periodic necessity. just you know, can't complain that "not there jit when i wanted it". but yes in general, ur examples must be had, fully functional model trains must exist, etc. otherwise how to even run academia.
a111: Logged on 2018-09-27 16:08 asciilifeform: imho the situation where 'errybody made own hack' but no one posted 'because obvious' is a barbarism, really ought to have a civilized 'here is the whole thing' sitting on www somewhere.
mircea_popescu: we don't do shit for any other reason than because "alternatives were reviewed, this came out".
a111: Logged on 2018-09-27 17:27 phf: trinque: vtools has not been design or intended to compete with any particular v implementation. it's a set of tools that you can use in a v workflow (hence the name). at least initially it was two matching tools vdiff and vpatch that know how to produce and consume a canonical vpatch. the conflation came up, because i also published vtools in a form that broke existing canonical v, v.pl, and was tasked with fixing the situation.
a111: Logged on 2018-09-27 17:49 asciilifeform: esthlos's thing calls to gnupatch ?! ugh
a111: Logged on 2018-09-27 17:54 asciilifeform: phf: imho your approach , i.e. dispensing with gnupatch, is The Right Thing, historically there was quite a bit of grief from gnupatch's habit of eagerly attempting to apply an invalid (by vtronic lights) but 'partially ok' by barbarian lights patch
a111: Logged on 2018-09-27 19:17 BingoBoingo: asciilifeform: I have returned from the envirorast office, about to fire off a message to DHL informing them to try again as I am a provisionally acredited importer of packaged goods for commercial use