1300+ entries in 0.178s
ben_vulpes: obviously is going to be slow, but mimi has zero trouble keeping up with the tip-o-the-chain since applying your
patch a111: Logged on 2018-01-27 20:02 diana_coman: re nodes: mine is still there but still not at the top; I even pressed and ran asciilifeform's
patch but it's unclear to me if it helped tbh; I admit I did not have much time to really dig deeper there exactly
diana_coman: re nodes: mine is still there but still not at the top; I even pressed and ran asciilifeform's
patch but it's unclear to me if it helped tbh; I admit I did not have much time to really dig deeper there exactly
☟︎ douchebag: However, even though I have to wait until they
patch the bugs I found before they reward me, they did reward me $150 on triage and will be rewarding the rest at a later date
douchebag: Well, I still have to wait until they
patch them before they reward the bounty. They pay based on likelyhood/impact, now a friend of mine reported a vulnerability less serious than the one I found and he was rewarded $2,000 total
a111: Logged on 2018-01-25 19:12 ben_vulpes: suresure. what even means "a release" though, in a world where each
patch now touches the changelog file. that eg ben_vulpes produces a
patch that *only* touches the changelog, saying "the foundation makes of this link in the chain a checkpoint"?
trinque: experimental patches meanwhile wouldn't, and the operator is invited to regrind the experimental item into a
patch which edits changelog, if it's graduating out of "experimental"
ben_vulpes: that the world promises to deliver me a regrinding nightmare out of stitching together ten patches that all descend from the release
patch ben_vulpes: suresure. what even means "a release" though, in a world where each
patch now touches the changelog file. that eg ben_vulpes produces a
patch that *only* touches the changelog, saying "the foundation makes of this link in the chain a checkpoint"?
☟︎ trinque: wasn't that
patch marked experimental?
diana_coman: I suppose the "
patch" would be to check endianism at runtime and use the correct constants as it were; I ...still don't see why should I have endianism in there to start with
mircea_popescu: esthlos it is not standard procedure ; the emerging consensus is to have a dedicated philosophy file which a) all patches must touch (by protocol) ; b) contains comments as to the patcher's state of mind and c) contains one line per
patch uniquely identifying it, machine generated. the format's not fixed yet, but as phf is working on a new proper vdiff it's probably going to coalesce around a variant of whatever he uses.
☟︎☟︎☟︎ a111: Logged on 2018-01-21 23:56 spyked looked at the
patch. admits to not being able to compile an example with gcc 4.9 nor 5; so there's probably more to it, e.g. C++ voodoo. I'm curious of asciilifeform's answer
trinque: once done I'll post to blog, and hopefully
patch authors can add detail.
spyked looked at the
patch. admits to not being able to compile an example with gcc 4.9 nor 5; so there's probably more to it, e.g. C++ voodoo. I'm curious of asciilifeform's answer
☟︎ trinque: that is exactly what the
patch did, include stdint.h
phf: (there's yet another solution is to actually provide a binary patcher, that uses some minimal delta algorithm to
patch files, while also providing the patching details in plain text. so you could say that the result is readable in a sense that it takes file FOO and replaces bits #10 #1343 #325435 etc)
shinohai: Worth looking into tho, I should grep and see if this
patch was applied at some point in there. Thanks for notifying!
shinohai: tfw sifting through old trb stuff and you find "rotor-db-configure-fix.
patch"
a111: Logged on 2018-01-18 20:58 mircea_popescu: consider concretely the case of eucrypt's keccak. diana_coman is writing it as a direct derivation off genesis, meaning on extant v impls if one wanted to import it they could import JUST it, without the rest of eucrypt (it'll be pulled in later through the usual procedure in eucrypt itself). superficially this may seem like it encourages phf to go "o i know, i'll just link keccak
patch into my codebase rather than regring (i
a111: Logged on 2018-01-18 20:58 mircea_popescu: the problem is that later on, eucrypt's smg_keccak will be pulled into the main to be used for purposes ; if EVEN LATER it gets a
patch, phf will then not actually have a way to seamlessly "get just the
patch", he will have to regrind at that time anyway.
mircea_popescu: the problem is that later on, eucrypt's smg_keccak will be pulled into the main to be used for purposes ; if EVEN LATER it gets a
patch, phf will then not actually have a way to seamlessly "get just the
patch", he will have to regrind at that time anyway.
☟︎ mircea_popescu: consider concretely the case of eucrypt's keccak. diana_coman is writing it as a direct derivation off genesis, meaning on extant v impls if one wanted to import it they could import JUST it, without the rest of eucrypt (it'll be pulled in later through the usual procedure in eucrypt itself). superficially this may seem like it encourages phf to go "o i know, i'll just link keccak
patch into my codebase rather than regring (i
☟︎ diana_coman: apparently
patch worked, v reports now new version
mod6: np. use that to
patch 99994.
diana_coman: k, I'll try that as soon as mod6 finds the
patch mod6: diana_coman: you mean the
patch for 99993? yeah, i pasted it in here.... lemme look for it quick.
apeloyee: "may be a 50kg sword" << doesn't seem to be. can be retrofitted into an existing design. as i said above "there needs to be a tree hash in the _leaf_
patch. and it MUST match the resulting tree"
trinque: they're equivalent neh? signed antecedent state or signed resulting state + fact that the
patch is signed
apeloyee: that's a spurious objection. one need not to sign an antedecent state, one needs to sign a RESULTING state. to expand on
http://btcbase.org/log/2018-01-17#1771900 , you're free to pick individual files from wherever, possibly several different trees, but there needs to be a tree hash in the _leaf_
patch. and it MUST match the resulting tree (under the principle that
patch author takes the...
☝︎ a111: Logged on 2018-01-16 16:01 shinohai:
http://archive.is/pU5zY <<< "Microsoft was faced with 8 (eight!)* new vulnerabilities in Equation Editor reported after their manual
patch, they gave up on the idea of continuing manual support for it."
shinohai:
http://archive.is/pU5zY <<< "Microsoft was faced with 8 (eight!)* new vulnerabilities in Equation Editor reported after their manual
patch, they gave up on the idea of continuing manual support for it."
☟︎ a111: Logged on 2018-01-16 06:15 apeloyee: FFA homework is fun! I'd like to present a homework problem of my own, the following Perfectly Innocent (tm)
patch:
http://p.bvulpes.com/pastes/tcvvO/?raw=true . The task is to find a bug WITHOUT running the code (that's cheating, per Dijkstra: " we see to it that the programming language in question has not been implemented on campus so that students are protected from the temptation to...
apeloyee: FFA homework is fun! I'd like to present a homework problem of my own, the following Perfectly Innocent (tm)
patch:
http://p.bvulpes.com/pastes/tcvvO/?raw=true . The task is to find a bug WITHOUT running the code (that's cheating, per Dijkstra: " we see to it that the programming language in question has not been implemented on campus so that students are protected from the temptation to...
☟︎ mod6: So I have an experimental
patch here that applies right on top of release version 99994 of my vtron. ONLY use this in a testing capacity - the contents of the
patch are subject to change at any time.
mod6: shinohai: ah, alright, i'll probably have a full
patch for people to look at here later today.
ben_vulpes: if you want to
patch an existing tree, the
patch util is to your left
ben_vulpes: yes, one does not press a
patch, one presses a tree.
phf: this is the first time i actually got to witness the entirety of the ritual (accidentally the cafe was in front of
patch of grass, and i guess it was sufficiently cold that old ladies didn't want to go all the way to the park)
PeterL: and how do I know if I take random
patch from you and stick it in my different
patch tree that it will not break something? wouldn't I want to have the same world as you before adding your
patch?
PeterL: have a
patch-of-the-
patch?
PeterL: and I don't see it as cut-and paste, you would just be changing the one line in the
patch to merge it into your own flow?
PeterL: couldn't having a standard of "touch readme file each
patch" be a form of "don't do that"?
PeterL: if the is are sister patches A and B, and you want to make C using both of them you just regrind B to B', the only difference would be the one
patch version file, and that difference would be readily vissible by diffing B and B', then make C ontop of B', works with current v IIUC
PeterL:
http://btcbase.org/log/2018-01-06#1765616 << I dun see why patches have to change much? Thinking of the system proposed by mircea_popescu you would have one line change in a "
patch version" file, the rest of the
patch would be identical to what we have now
☝︎ mircea_popescu: so no, at no fucking point does any
patch have anything other than a single parent, which is properly speaking "the previous press", rather than "a random collection of files scattered about". like it or not, files don't have the sort of semantic power whereby a db.cpp "of the right hash" will always be useful when imported into some random project. files are not contextless ; neither because they aren't currently tooled to b
a111: Logged on 2018-01-06 04:29 mircea_popescu:
http://btcbase.org/log/2018-01-05#1765580 << eh get the hell out of here, so you want someone to take that
patch and put it into some random other tree which happens to have a db.cpp that matches its hash ? this is insanity on the level of early organ transplantation experiments.
a111: Logged on 2018-01-05 23:40 asciilifeform: think, if EVERY
patch requires global regrind of all of world history, you ain't using v, may as well throw out all of the unnecessary equipment -- you're passing a monolithic turd around
a111: Logged on 2018-01-05 23:39 asciilifeform: if instead it demanded that your tree, to apply it, be bitwise-identical to asciilifeform's tree when he made it -- you could only build on this
patch if you reground ALL of EVERYONE's work every single fucking time
mircea_popescu:
http://btcbase.org/log/2018-01-05#1765580 << eh get the hell out of here, so you want someone to take that
patch and put it into some random other tree which happens to have a db.cpp that matches its hash ? this is insanity on the level of early organ transplantation experiments.
☝︎☟︎ mircea_popescu: problem A has two possible legitimate answers : A.1 : introduce a further parentage chain (so
patch does not discuss merely file hashes but also somehow a hash of prev
patch) and A.2 : introduce a magic file which must (by protocol) be touched by all patches.
mircea_popescu: problem S will not be considered ; problem X is resolved by answering yes. because god fucking help you, if your
patch has two antecedents you are a heretic anathema.
a111: Logged on 2018-01-05 23:24 ben_vulpes: or to put it a different way, that one *must* create an invalid state in order to
patch atop two divergent patches.
a111: Logged on 2018-01-05 22:43 asciilifeform:
patch on top of ch5 plox
mircea_popescu: in the republic, the reference system is
patch-tree ; press-head ; word-offset. wtf is wrong with that!
trinque: this is nonsense. people can choose any prior state whatsoever as basis for a new
patch.
ben_vulpes: but this is the magic political speshul case of a
patch that ties together other patches for the political object that is a release!
trinque:
patch A1 and A2 are peers, happened to different files with same starting codebase state. you proposed writing a B that encompases whatever changes plus the bodies of A1 and A2.
trinque: how does this not expand to still more antecedents dragged into child
patch as time goes on?
ben_vulpes: or to put it a different way, that one *must* create an invalid state in order to
patch atop two divergent patches.
☟︎ ben_vulpes: what irks me about this is that one can make a
patch that depends on a state of the codebase that is not a valid press.
trinque: you edit db.cpp. I edit main.cpp. how does someone now use both of those pieces of work in a 3rd
patch.
☟︎ ben_vulpes: i haven't bitten off the
patch yet, and might not get to it by the time you release ch6, this all takes me a lot longer than phf or lobbes
mod6: wanna see the experimental
patch i'm workin on?
phf: the way btcbase does it is first pairs all patches by name (following our convention, but next by subst distance), processes those and what's left over is brute forced. algo though was implemented back when naming convention was in flux, so in practice it's o(n), but in reality it could approach o(n^2) if
patch bucket is full of shit
mircea_popescu: asciilifeform when building a tree, first load up the sig folder, then apply it as a mask on the
patch folder, then proceed building with only the patches that passed.
a111: Logged on 2016-01-18 15:58 ascii_butugychag: the O(N^2) instrinsic runtime of unknown-
patch-bag+unknown-sig-bag is something i realized from the start
a111: Logged on 2017-12-30 20:11 ben_vulpes: a useful
patch for folks in jawbone2 's position would update the results of getinfo to indicate whether trb considered a connection 'inbound' or 'outbound' so that you could determine if your dyndns hacks were working
mircea_popescu: but in shorthand practical terms, if they don't have a genesis we can
patch upon, they don't exist.
ben_vulpes: a useful
patch for folks in jawbone2 's position would update the results of getinfo to indicate whether trb considered a connection 'inbound' or 'outbound' so that you could determine if your dyndns hacks were working
☟︎ ben_vulpes: would be neat to
patch trb to have this dynamically settable, and nothard either, see settxfee
a111: Logged on 2017-12-29 19:18 phf: for example one thing that i tried with my lisp workflow is to have the system automatically compile/load touched files in their order of appearance in a v
patch. but the order here is explicitly linear, requires fiddling with
patch order, and is definitely not how we use it now
phf: for example one thing that i tried with my lisp workflow is to have the system automatically compile/load touched files in their order of appearance in a v
patch. but the order here is explicitly linear, requires fiddling with
patch order, and is definitely not how we use it now
☟︎