tmsr - Search: i

26400+ entries in 0.156s

asciilifeform: i can see the logic, ethernet frame is 1500 , ip header -- 20 byte

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.

asciilifeform: http://btcbase.org/log/2018-09-27#1855108 << i read'em when waking, when going to sleep, and in between have scrolling in real time within peripheral vision. but evidently even this not guaranteed to suffice.. ☝︎

asciilifeform: http://btcbase.org/log/2018-09-27#1855107 << the proggy author's duty, and nobody can save him from it. fwiw i go roughly by size/complexity of orig draft. ☝︎

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. ☝︎☟︎

mircea_popescu: asciilifeform no, i understand the principle, just... nothing, not even mozilla went through 10k versions to date.

asciilifeform: yea i can't picture for what might need variable masses in production ☟︎

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)

asciilifeform: diana_coman: i'ma test & mirror that one when i get a chance

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

asciilifeform: http://btcbase.org/log/2018-09-27#1855075 << yea if i'd smoke-tested it earlier, would have found. on top of this, naively assumed that diana_coman has a working and complete keccaktronic v , given as she's moved smg to newform ☝︎

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.

asciilifeform: http://btcbase.org/log/2018-09-27#1855080 << i stole the notion , in slightly modified form, from knuth. the logic is, decrementing versions, with finite initial N, support a http://btcbase.org/log/2018-09-18#1851362 flow , where 'if you fucked it N+1 times , nao forced to call proggy something else' -- specifically in opposition to the heathen plague of runaway ver nums (e.g. linux kernel, emacs, firefox, etc) ☝︎☝︎

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-27 13:35 asciilifeform: call me an idjit, but i thought there were a new vtron...

a111: Logged on 2018-09-27 12:47 diana_coman: since I need to get the work done on this, I reground the UDP lib and I'll proceed from there; asciilifeform, phf and anyone else interested, keccak-patches are on my Code Shelf as usual: http://ossasepia.com/reference-code-shelf/#selection-477.0-477.19

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 ☟︎☟︎

asciilifeform: i'ma test.

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

asciilifeform: trinque: recall when i thought that this nonsense could be disabled by flags, hah

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 ☟︎

asciilifeform: i did not yet know this.

trinque: phf: in principle I'm entirely in favor of the "unix philosophy" approach of simple, single-purpose tools

mod6: yeah, this is the right approach imho. it's what i'd do with my ada-vtron, if it ever does breathe.

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

asciilifeform: phf: i finally sat down and properly read the thing, and i think i finally grasp.

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: 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.

asciilifeform: prolly will also makes sense to standardize the calling for it eventually ( and i'ma rework mine to fit, etc )

trinque: v-esthos if it's finished, and works, though I'm willing to hear counterarguments

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

asciilifeform: btw phf , if you're willing to post your modified v.py ( i.e. http://btcbase.org/log/2018-09-27#1854990 ) i'ma sign ☝︎

asciilifeform: ( i.e. i'd like to dispense with sha512sum util entirely , aside from existing ancient items which have sha512 hashes in the l0gz from years ago )

asciilifeform: then not direly needed. though i'd still like to be able to post keccak hash in the log next time we're doing a thread with fw images or the like.

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

asciilifeform: phf: but yes i'ma revive it.

phf: asciilifeform: well, you're one of the v maintainers, i'd think you would want to do it to your own tool.

asciilifeform: phf: i don't dispute that it is obvious, but thought it had been done, this was my mistake.

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 ☟︎

asciilifeform: phf: right . what i was looking for is variant of same that calls out to keccak instead of sha512 ( mod6's latest vtron actually checks hashes ) . but apparently still needs baking.

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. ☟︎

asciilifeform: mod6: for nao i'll be entirely satisfied with the variant phf describes.

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.

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)

asciilifeform: phf: loox like. i'ma put the head on the shaft in next coupla days .

asciilifeform: now i'ma need the shaft.

asciilifeform: this thread is not meant to insult phf et al , but i open box where i thought was hammer, but there is only a hammer head

asciilifeform: my ancient v100 , could also be reworked, but i'd like to put it to rest ( for one thing, it dun check hashes at all )

phf: asciilifeform: you're just spreading fud, i don't know where to start unpacking this conversation ☟︎

asciilifeform: i'd also like to see a continuing existence of multiple working vtrons, so eventually would like to rework mod6's to use newtype format ( unless mod6 would prefer to do it himself )

asciilifeform: once it ~does~ exist, and fully displaces the duct tape, then yes i'ma start regrinding other things , and i expect then mod6 -- trb, etc

asciilifeform: phf: this is not a criticism of the format. but turns out asciilifeform has been looking for a 'i missed it in logz?' piece that doesn't exist quite yet ( hopefully will in 3 days... )

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

asciilifeform: ( recall, i introduced the patches thing considerably prior to ~vtronic~ patches )

asciilifeform: and yes it is the picture i got from log. the gap in my head is where diana_coman switched to the new format; i then assumed there is a 100%-complete new vtron, and that 'hmm simply missed this, is in log somewhere' , turns out nope, notyet

asciilifeform: phf: try an' see from my pov : i get a 'goddamn stop using old v' , go an' uncrate the replacement, and turns out it ain't a plug-in replacement but a set of pieces and a roll of duct tape

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 ☟︎

lobbesbot: phf: Sent 14 hours and 10 minutes ago: <asciilifeform> are http://barksinthewind.com/2018/vtools-keccak-regrind/ old-style or new-style vpatches ?? my vtron won't press'em, and there is no way to distinguish , nor anything in the post to indicate, unless i'm thick

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 ☟︎

asciilifeform: oh ha i see what i did.

asciilifeform: mod6: the latter was the one i turned out to have on my box last night

a111: Logged on 2018-09-27 13:26 asciilifeform: http://btcbase.org/log/2018-09-27#1854880 , http://btcbase.org/log/2018-09-27#1854913 << interestingly, this worked, mod6 ! wtf is 99994 K one ? where did i even get it ? ( i take it , was buggy release ? )

asciilifeform: ( given http://btcbase.org/log/2018-09-26#1854819 + http://btcbase.org/log/2018-09-26#1854820 , i'd really like to have a 100% working item prior to entirely retiring the old ) ☝︎☝︎

asciilifeform: if phf's item came with a standalone keccak hasher , would then be quite simple to retool e.g. mod6's vtron, to follow the new format. but as it is loox like i'ma have to wait for esthlos , to get full working replacement for old vtrons

a111: Logged on 2018-09-27 02:27 esthlos: http://btcbase.org/log/2018-09-27#1854912 << I plan to integrate Keccak into the thing this weekend. At that point it should be fully operational.

diana_coman: I kept waiting on phf and esthlos since they were working on it as far as I could tell; and http://btcbase.org/log/2018-09-27#1854921 ☝︎

asciilifeform: i'ma try esthlos's item as soon as it is rolled out.

asciilifeform: this is what i thought, and why i did not hurry to start the regrindings earlier

asciilifeform: so as i understand nobody has a 100% complete newtype vtron quite yet

diana_coman: asciilifeform, not that I know of; I use: http://btcbase.org/log/2018-09-27#1854956 ☝︎

diana_coman: fwiw I *did* specifically state in the manifest that it's using Keccak hashes

diana_coman: I'll have to, since the sigs need to fit the .vpatch file name, yes

diana_coman: asciilifeform, ok, I'll mirror your sigs too and link to the page anyway; a bit later today

diana_coman: I added the manifest + comments in it; otherwise *all* code is precisely what I got from pressing your patches

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 ☟︎☟︎

asciilifeform: aaand it loox like diana_coman already did my chore for me... i'ma do the elementary test on it nao, and sign/mirror.

asciilifeform: call me an idjit, but i thought there were a new vtron... ☟︎

asciilifeform: http://btcbase.org/log/2018-09-27#1854935 << i did, phf reminded earlier ☝︎

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!

asciilifeform: http://btcbase.org/log/2018-09-27#1854926 << confirmed ( and somehow nobody last night noticed ? ) apparently tar by default refuses to tar up 'hidden' ( i.e. starts with . ) dirs ! ☝︎

asciilifeform: http://btcbase.org/log/2018-09-27#1854880 , http://btcbase.org/log/2018-09-27#1854913 << interestingly, this worked, mod6 ! wtf is 99994 K one ? where did i even get it ? ( i take it , was buggy release ? ) ☝︎☝︎☟︎

diana_coman: I'll add the patches for the tester on top of the above, later today

diana_coman: since I need to get the work done on this, I reground the UDP lib and I'll proceed from there; asciilifeform, phf and anyone else interested, keccak-patches are on my Code Shelf as usual: http://ossasepia.com/reference-code-shelf/#selection-477.0-477.19 ☟︎

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: http://barksinthewind.com/2018/vtools-keccak-regrind/ -> gotta ask here, phf, am I missing something or what Wednesday was that there in the first line meant to be? ☟︎

a111: Logged on 2018-09-27 02:27 esthlos: http://btcbase.org/log/2018-09-27#1854912 << I plan to integrate Keccak into the thing this weekend. At that point it should be fully operational.

diana_coman: re using vtools, I currently first check sig (so by hand, separate 1-line) and if ok, then feed patch to vtools

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! ☝︎☟︎☟︎

BingoBoingo: <trinque> does it now properly verify hashes? << I am still at the point where I hand read input, patch, and output

trinque: obviously I want such a vtron for the cuntoo final cut, or what's the use of the build process producing a vpatch ☟︎

esthlos: http://btcbase.org/log/2018-09-27#1854912 << I plan to integrate Keccak into the thing this weekend. At that point it should be fully operational. ☝︎☟︎☟︎

mod6: lol, I don't know how to make it do stuff either, but I guess that's a different problem :]

mod6: Alright, I guess the makefile doesn't build the vpatch binary by default, so I built it manually:

mod6: but I only ended up with a 'vdiff' binary (maybe this is correct?)

mod6: I used your patches, there are 8 of them, and I was able to press this fine.

mod6: I took your tarball, dumped in the latest version of my vtron, dropped in the .wot (phf) and seals from what I had in my sandbox previously.

BingoBoingo: asciilifeform: I used the esthlos thing.

asciilifeform: loox like the matter may have to wait until the folx with working keccaktrons wake up and tell me what i'm missing.