log☇︎
1000+ entries in 0.07s
mircea_popescu: the 5 don't have to regrind anymore than you do, can just import the patch.
asciilifeform: i'ma bake another patch later this wk, unless somebody else does first.
asciilifeform: for a correctly-written proggy, v-branching is clean, you can make patch that only affects os-specific coad
mircea_popescu: ave1 once he publishes later today you can just read/patch/collaborate.
asciilifeform: https://patchwork.ozlabs.org/patch/843954/ << dec '17, the moment of liquishitification
asciilifeform: look at yer patch
asciilifeform: ( patch & all )
asciilifeform: loox like the patch was from a broken vdiff.sh ??
a111: Logged on 2016-08-29 13:54 trinque: right. in this case I challenge anyone to find a need for a second patch on those modules themselves, rather than creating a genesis vpatch for their own module which talks to the db in postgres.
asciilifeform: ( unrelatedly, dug up vintage lul http://trilema.com/2017/how-i-almost-created-a-constellation-of-bitcoin-nodes/ , where mircea_popescu went through the sweat to replicate my failed pipes experiment . where in the end, yr+ later, the correct pill turned out to be entirely unrelated aggression patch )
asciilifeform: i suspect that playing 'let's patch winblowz' but with fleanode, is not winning proposition, yes
asciilifeform: for non-expert entomologists : the perps ( i dun distinguish b/w 'bug'-inserters and coverup-artists ) ~continue~ to spew the squid ink where the patch is disguised as 'for denial of service bug' rather than arbitrary r/w -- despite the cat being out of the bag for nearly whole day nao
a111: Logged on 2018-07-11 04:45 hanbot: esthlos it doesn't. footnotes source & instructions are in http://thewhet.net/2017/10/a-compendium-of-possibly-helpful-stuffs-for-erecting-mircea-popescus-wordpress-with-nearly-free-speech-hosting/ , and i've never actually taken on the selection jazz. i can tuck em both into next patch tho.
asciilifeform: or hm, am i simply missing a patch ??
asciilifeform: ( for bonus lulz, was triggered by an intel official microcode patch as gzip payload... )
mircea_popescu: but in any case usb-+ should not be on mainline kernel. let he who runs rockchip farm patch in the ugly.
mircea_popescu: http://btcbase.org/log/2018-08-01#1838724 << on the positive score, kernel patch for cuntoo killing this with fire quite feasible. ☝︎
asciilifeform: ^ the largest patch since genesis ( >80kB ) but unfortunately could not be avoided.
deedbot: http://qntra.net/2018/07/oracle-re-patches-11-year-old-solaris-hole-that-survived-first-patch/ << Qntra - Oracle Re-Patches 11 Year Old Solaris Hole That Survived FIrst Patch
spyked: http://btcbase.org/log/2018-07-22#1837147 <-- gah, sorry for the abstruseness. more explicitly: the bot goes through each line in http://www.loper-os.org/pub/ro_eng_expr.txt and if it finds one for which the query is a substr of the entry, it displays the definition. not very effective, it's intended as a very simple (<100 lines of code) demo for next trilemabot patch. but imho there's room for improving it even without adding google ☝︎
asciilifeform: ^ if anyone gets eggog on verification of either sig in this file (readme's or patch's) plox to lemme know
asciilifeform: jurov: would it be simple matter to patch turdatron to reject these ?
asciilifeform: 1st patch to make it to flagship branch since 'makefiles', iirc.
phf: some libc's (specifically in glibc, musl, there's also a custom one in busybox. presumably cygwin/mingw comes with a glibc derivative), but that shouldn't be used directly. PeterL's patch is not needed on linux/freebsd/apple.
a111: Logged on 2018-06-27 18:03 phf: PeterL: the approach that we've been taking with legacy C code is pulling out autotools, and replacing with a single #ifdef/.. configuration header. outside of linux/bsd code is probably not going to work, and the approach is to look at the configuration header file (http://btcbase.org/patches/vdiff_sha_static/tree/vtools/src/system.h#L145 in case of vtools) and patch it for your system
phf: well, 100 ln patch to the compiler, because it can't be done as a user proggy (e.g. (symbol-value 'foo) triggers a mechanism of some sort, without an indirection)
a111: Logged on 2018-07-15 14:22 shinohai: gm #trilema http://btcbase.org/log/2018-07-13#1834119 <<< Ran a x86 node 3+ years with mechanical hdd, aggression patch did keep mine within ~10 blocks always.
a111: Logged on 2018-07-13 15:31 diana_coman: asciilifeform> shinohai: trying doesn't hurt. and iirc somebody actually got a mechanical-hdd node to stay synced more or less decently with aggression patch -> yes, I did
shinohai: gm #trilema http://btcbase.org/log/2018-07-13#1834119 <<< Ran a x86 node 3+ years with mechanical hdd, aggression patch did keep mine within ~10 blocks always. ☝︎☟︎
diana_coman: good; explain why do you think it should press that patch ?
brazilish: problem: downloaded asciilifeform_blackhole_reads.vpatch and placed in patches folder, same for the sig file in .seals, then running ./v.pl p v trb054 makefiles.vpatch, but i don't get the patch in the src files
diana_coman: brazilish, the fastest way to sync short of feeding the blocks directly is with the agression patch
brazilish: does it include this patch?
diana_coman: brazilish, did you get the timing patch and noticed lower timings or how is that "painfully slow to process blocks" evaluated?
lobbes: asciilifeform: oya, I've squirreled away that link to the timer patch you dropped earlier in the logs. I'm thinking I'll apply it to my node once I get auctionbot2.0 through the conveyor, after which I can publish more concrete data.
asciilifeform: lobbes: your node sounds like a good candidate for the timer patch (i.e. determine, why not syncs, is it block db delay, or it somehow gets nuffin from peers, or which.)
asciilifeform: mircea_popescu: he actually baked a patch, about same time as my aggression item, http://therealbitcoin.org/ml/btc-dev/2017-December/000282.html
asciilifeform: notably , the patch started life as a general-purpose profiling of a whole buncha things in trb, but i ended up cutting out all but block timing, given as that was where something like 99% of ~active~ (i.e. as opposed to waiting for rain to fall, this was pre- aggression) cycles are spent
diana_coman: right; I didn't press that patch
asciilifeform: diana_coman: reporting block r/w times currently requires pressing with the little patch that takes the times. ( it is not part of 'flagship' trb )
diana_coman: asciilifeform> shinohai: trying doesn't hurt. and iirc somebody actually got a mechanical-hdd node to stay synced more or less decently with aggression patch -> yes, I did ☟︎
asciilifeform: shinohai: trying doesn't hurt. and iirc somebody actually got a mechanical-hdd node to stay synced more or less decently with aggression patch
hanbot: esthlos it doesn't. footnotes source & instructions are in http://thewhet.net/2017/10/a-compendium-of-possibly-helpful-stuffs-for-erecting-mircea-popescus-wordpress-with-nearly-free-speech-hosting/ , and i've never actually taken on the selection jazz. i can tuck em both into next patch tho. ☟︎
asciilifeform: PeterL: read again the algo. at no point will it attempt to press a patch that is not an ancestor of the selected leaf.
a111: Logged on 2018-01-05 23:18 trinque: you edit db.cpp. I edit main.cpp. how does someone now use both of those pieces of work in a 3rd patch.
mircea_popescu: recall, the huge discussion re patch / vpatch ?
asciilifeform: mircea_popescu: the headache is from the fact of notion of 'file' having been baked quite firmly into unix patch util. the only 'final solution' presently known to asciilifeform for the entire class of topological ugh, is the trinquian cut.
mircea_popescu: the only reason i can imagine someone'd have the problem you describe is if they built their thing around the primitive "file" rather than around the primitive "patch"
mircea_popescu: i don't understand this, you mean patch A having changes a, b, d, e (ie, 4 different patch sections) and B having c, d, e, f ?
a111: Logged on 2018-07-10 14:43 phf: so policy wise, like you say "no cyclical graphs" you can say "no identical changes in more than one v patch"
phf: so policy wise, like you say "no cyclical graphs" you can say "no identical changes in more than one v patch" ☟︎
phf: let me retest it, but as far as i recall it was producing a patch order that doesn't press
a111: Logged on 2018-07-09 01:53 mircea_popescu: esthlos can't select portions of your blog! but anyway, "Make a new patch with esthlos-v_genesis and some node of the EuCrypt tree as parents." wasn't contemplated, because http://btcbase.org/log/2016-12-29#1592769
mircea_popescu: this is the "default genesis" so to speak of any signature's seals. if the owner patches upon it, to make it eg "this is a lulz signature, will sign all retarded implementations with it", that'd be his problem, and yours only by the extension of, "why are you trusting signatures without knowing the owner enough to have seen the actual meaning-patch-tree he uses".
mircea_popescu: http://blog.esthlos.com/routes-to-keccak-in-esthlos-v/#footnote_5_24 << signing a patch signifies, at the common basis, a) that the signer has read the patch and that b) in his best effort determination b1) the transformation that the specified patch brings upon b2) the exact codebase specified will not b3) ~introduce~ properties that are b4) novel, unobvious and nefarious (all three).
mircea_popescu: so it was, "re-grind your genesis ~as a patch upon eucrypt~."
mircea_popescu: esthlos can't select portions of your blog! but anyway, "Make a new patch with esthlos-v_genesis and some node of the EuCrypt tree as parents." wasn't contemplated, because http://btcbase.org/log/2016-12-29#1592769 ☝︎☟︎
a111: Logged on 2018-07-07 23:58 phf: esthlos: your v_genesis patch is broken, http://btcbase.org/patches/v_genesis/file "contact" etc.
spyked: http://btcbase.org/log/2018-07-07#1832633 <-- ok. this'll be a very good exercise for the spyked patch-making muscle, I need it. ☝︎
mircea_popescu: asciilifeform how do you know what hash patch x is hashed in ?
phf: asciilifeform: well, that would be one of the reasons why "hasher gotta be hardwired". vtools give you hard guarantees about the format of the patch, the state of the press, that can actually be manipulated outside of unix soup
phf: esthlos: your v_genesis patch is broken, http://btcbase.org/patches/v_genesis/file "contact" etc. ☟︎
phf: http://btcbase.org/log/2018-07-07#1832417 << so far only one patch is using keccak, the new patches that came out are all sha512 and none of the existing projects attempted a regrind ☝︎
diana_coman: esthlos, you can compile it standalone but indeed because of the bitrate fix you'll need to patch all the way to that at least so getting everything in
mircea_popescu: esthlos if you patch ~off~ of eucrypt your whole thing becomes a patchset.
esthlos: trying to figure out what patch I can base the press from to get keccak. seems like its eucrypt_keccak_birate_fix, but that pulls in the other components according to the graph
mircea_popescu: esthlos there's an eucrypt keccak you can either import (by patching off eucrypt) or copy over (as a different patch).
esthlos: so two things I see are: 1. what to do for hasher? somehow integrate phf's item into my vtron? 2. what do to for diff/patch? lisp McIlroy?
mircea_popescu: now, shelling out to diff / patch is one thing (though somewhat iffy for reasons discussed in a long thread, which phf mostly fixed). but shelling out to hasher is no longer possible because keccak implementation isn't shell.
mircea_popescu: just patch on it.
esthlos: additionally, before I make another mistake, does this warrant redoing the genesis (because original item is broken?), or a new patch?
trinque: is the task for esthlos here to produce a patch util that cares about hashes, or to build all patching functionality into the vtron ?
asciilifeform: looking again at his coad, seems like it simply calls out ( just like my vtron did ) to patch util
a111: Logged on 2018-07-06 23:13 trinque: shells out to patch, perhaps the intent there was to end up with an external patch util that understands vpatch hashes. esthlos, maybe shed light?
esthlos: http://btcbase.org/log/2018-07-06#1832404 << my vtron doesn't include a vdiffer or a patch-applier. was this an oversight? ☝︎
a111: Logged on 2018-07-02 12:07 spyked: ^ phf, can you pl0x add this to the btcbase patch list? and http://lucian.mogosanu.ro/src/trilemabot/ ?
trinque: shells out to patch, perhaps the intent there was to end up with an external patch util that understands vpatch hashes. esthlos, maybe shed light? ☟︎
trinque: http://btcbase.org/log/2018-06-18#1826640 << cut weight to 2.4mb by removing alternative versions of ebuilds. who wants one of 'em can sign a patch. ☝︎
spyked: ^ phf, can you pl0x add this to the btcbase patch list? and http://lucian.mogosanu.ro/src/trilemabot/ ? ☟︎
a111: Logged on 2014-10-24 23:22 asciilifeform: because all that was done in patch 1, is remove ifdef crud
phf: but where this subthread started "_outside of linux/bsd_ code is probably not going to work, and the approach is to look at the configuration header file and patch it _for your system_
phf: PeterL: the approach that we've been taking with legacy C code is pulling out autotools, and replacing with a single #ifdef/.. configuration header. outside of linux/bsd code is probably not going to work, and the approach is to look at the configuration header file (http://btcbase.org/patches/vdiff_sha_static/tree/vtools/src/system.h#L145 in case of vtools) and patch it for your system ☟︎
a111: Logged on 2018-06-26 17:45 phf: trinque: one reason i didn't include patch name in the manifest is because patch name becomes a promise, unless you enforce it by tooling. i didn't want to go that way, but since current standard manifest does include patch name, than perhaps V ought to check the manifest against the patchset. relatedly fully manifest-based v doesn't even need graph tooling, can presumably press according to manifest's chain.
trinque: wont be able to press a "makefiles" + manifest until that subsequent patch, but I don't really see a problem with that
trinque: what's it look like in the patch file
ben_vulpes: reference the manifest file in a later patch.
trinque: eh that accretion of patch material means patch size/readability is inversely proportional to modularity of the code
mircea_popescu: 3. you sign yet another new patch, hurr-biff.patch, referencing fixing-bugzappers.
mircea_popescu: 2. you sign another new patch, later on, "fixing-bugzappers.patch". this patch references manifest patch and ircbot-multichan-etc.
mircea_popescu: 1. you sign a new patch, manifest.patch. at this juncture, phf's viewer will show it to the side, unconnected to the tree.
asciilifeform: i think trinque's observation is re how to glue the ~old~ tree on, in the first manifest-bearing patch
asciilifeform: mircea_popescu: in the classical v, you gotta touch the old filez to weld your new patch onto the ancestor-tree that you want
trinque: how's the patch look, that adds the new file?
mircea_popescu: ed patch is now also well ordered, "caught in the patchchain" as it were) and b) we can and very likely will re-organize the portion between genesis and the manifest patch later anyway.
mircea_popescu: it's not being proposed as a retoactive fix. the idea is, ~after~ the patch that puts in a manifest, ~subsequent~ patches will be well ordered. and the fact that the earlier ones aren't exactly well ordered is a) resolved in any practical sense by the fact that you won't have patch imports across the barrier more than 1 deep (ie, once a patch after the manifest patch references a patch before the manifest patch, THAT refernec
mircea_popescu: http://btcbase.org/log/2018-06-26#1829660 << you could just add the manifest in a patch, like diana_coman did for eucrypt. ☝︎
trinque: ben_vulpes: got it; yeah, I'd say if it gets bolted on, inside the makefiles patch is a sensible place
mod6: ah, interesting point re patch name
phf: trinque: one reason i didn't include patch name in the manifest is because patch name becomes a promise, unless you enforce it by tooling. i didn't want to go that way, but since current standard manifest does include patch name, than perhaps V ought to check the manifest against the patchset. relatedly fully manifest-based v doesn't even need graph tooling, can presumably press according to manifest's chain. ☟︎
ben_vulpes: s/after makefiles/in the makefiles patch/