232100+ entries in 0.141s
a111: Logged on 2016-12-20 13:18 mircea_popescu: btw mod6 ben_vulpes
trinque re
the whole db/fs etc discussion, anyone recall
the symlinks method / proposed
tests ?
ben_vulpes:
http://btcbase.org/log/2016-12-20#1586531 << i don't recall
the proposed
tests, actually. i mulled on
this for a bit, am reluctant
to
try any sort of implementation until i finish
the sqlator which a) is probably just sunk cost fallacy rearing its head, as i've done not much
there but design
the schema and prep a massive ingest job and b) has now been bumped down my
todo list *again* in favor of vtronic
☝︎ a111: Logged on 2016-12-22 01:49 phf: well, last
time i brought it up with mod6 he said something along
the lines of "i'm not ready
to sign, because it's still work in progress"
BingoBoingo: locally Praxair is known for exploding (literally) in
the 1990s
ben_vulpes: also nfi how
this fits into your agricultural fanfic
a111: Logged on 2016-12-22 01:52 ben_vulpes: r sounds like g
to
them or something
BingoBoingo: But yes, steel seems
to want
to be made in India
BingoBoingo: Anything beyond waits for
Trumpreich's credit card
BingoBoingo: Seriously. Anyways
the Granite City and Gary Mill are as described, opened enough
to get machines warm.
mircea_popescu: it's funny, you know, after ~2500 years, steel went back home
to pradesh
mircea_popescu: BingoBoingo
there's absolutely no way in hell anything in
the us can compete with mittal.
mircea_popescu: (not
that
this consideration has much practical value - outside of #trilema
the community
to do such
thing doesn't exist, and so wasn't at
the
time an option)
mircea_popescu: bitcoin'd certainly be infinitely stronger were it
the result of a concurrent development effort in
this style.
mircea_popescu: so
there's no real strong categorical difference from
theory. but in practice it sure as fuck exists.
mircea_popescu: and on
the other hand, i suppose it's entirely possible
that if a years-made-wiser satoshi
tried
to release bitcoin, it'd have been done in
the manner of how we did vtrons not in
the manner of how he did bitcoin, ie, "here's what should happen - anyone who wants
to participate make one"
mircea_popescu: i suppose it's possible
that as
technology matures it goes from
this stage
to "yawn, whatever, just use
the cannonical version". so
there's possibly
that path
there.
a111: Logged on 2016-12-22 01:58 asciilifeform:
there is a 'harem-v' and a 'forum-v'
mircea_popescu: this opposition may be less categorical
than it seems here, and may evolve in
time, but i suspect even if a continuous function it'll never be convex.
mircea_popescu: i perceive no benefit
to, eg, getting everyone
to use mod6's or alf's or anyone else's v implementation, as opposed
to
the present situation ; just as i perceive no advantage
to getting everyone
to make "his own"
trb.
a111: Logged on 2016-12-22 01:47 phf: ben_vulpes:
this subthread since your response
to my original statement is one example of what i'm
talking about. in
this case none of
the v implementations are on btcbase, because nobody wants
to sign own hacks, because
the cost of failure is
too high.
mircea_popescu:
http://btcbase.org/log/2016-12-22#1587923 << i am fwiw satisfied
that it's qutie mroe
than
this : vs aren't on btcbase because
they don't fundamentally belong on btcbase, because unlike public
trb "we all use
this"
they're private "my girl will dance
the way ~i~ want her
to dance and stfu".
there's a much more limited set of rules re what vtrons should do ;
than re what
trbs should do.
☝︎ mircea_popescu: more or less loud recalibrations as practice crystallizes
to be expected in such circumstance.
a111: Logged on 2016-12-22 01:44 asciilifeform: i ended up
turning
that into a warning, vs fatal, but it looks like i never posted
this variant.
a111: Logged on 2016-12-22 01:35 asciilifeform:
trinque: are you
thinking of mod6's minor bug , or of some other
a111: Logged on 2016-12-22 01:39 mod6: now, we not want
that behviour any longer.
a111: Logged on 2016-12-22 01:22 ben_vulpes: just because mircea_popescu didn't complain about
the failure at
the
time doesn't make it right.
mircea_popescu: i was saying "this is working correctly", did it end up reading
the opposite ?
a111: Logged on 2016-12-22 01:15 mod6: i just feel like we've been here before. like i have some pavalonian response from
this.
deedbot: mircea_popescu rated phf 4 at 2016/05/17 03:19:21 << his lordship
the lord chancellor
mod6: i mean, we could do it
that way... where
the printable flow
tells you which do not have sigs, but
then impl-wise,
they must be
two different lists as
to not inadvertantly press out a WILD vpatch.
that, or re-check
the flow at press
time.
ben_vulpes: and
this can only be done by calculating
the dag and
then indicating who signed which patches.
ben_vulpes: but if it doesn't show me which patches are lacking sigs,
that strikes me as a bug.
☟︎ mod6: ben_vulpes: i actually love
that feature.
ben_vulpes: fact remains
that
the dag can be constructed without reference
to
the wot.
mod6: pressable or printable, doesn't matter.
the wot is
the dictator.
mod6: because why would i want gavin's vpatch stuck in
the middle of my flow, if he's not in my wot?
mod6: it is completely dependant on
this.
mod6: <+ben_vulpes> flow is simply
the directed acyclic graph of patches, and is *not* predicated on wot contents. << disagree.
ben_vulpes: flow is simply
the directed acyclic graph of patches, and is *not* predicated on wot contents.
mod6: and
this would be predicated upon who is in your .wot.
mod6: the printable flow, is
the same as
the pressable flow.
☟︎ mod6: if you were
to print
the flow, it would still not show up.
mod6: <+ben_vulpes> pressable being operative word
there. << it is inconsequencial.
ben_vulpes: the antecedent chain can be constructed without ever needing
to refer
to
the signing of patches, and imho should show all patches in
the flow, alongside which keys signed
them and if none
then marked as wild
mod6: but i apologize, and see
that
this is
the wrong way. and
there is a better way.
mod6: this is why
they exist in
the first place,
these WILD vpatches, because my impl wasn't written with
this in mind. i was more written with
the idea
that a guy would place
things in .wot/.seals/patches by hand and would know what is what.
ben_vulpes: "flow" refers
to
the antecedent chain, nothing else.
mod6: you will, you must, have everything signed for it
to show up in a pressable flow.
☟︎ ben_vulpes: they should still appear in
the flow but marked as wild.
ben_vulpes: well, hang on. if patches with no sigs are omitted from flow,
they won't show up as WILD in
the flow, correct?
ben_vulpes: i
think
this is 'implementation detail'.
mod6: i
thought
that you just wanted
to it
to be left out of any possible flow.
mod6: i
thought you didn't want it
to fail.
ben_vulpes: (and in
the absence of a WILD boolean, asciilifeform's pain-receptor-switch)
ben_vulpes: provided
the implementation fails if any patch in
the flow has *no* signatures from keys in .wot,
that sounds right.
mod6: i apologize for
this oversight about
the WILD patches.
mod6: it sounds like everyone wants instead, a general overhaul
to get
to
the 'wot variant press' instead, which would also fix
the bug, because
these vpatches, without a corresponding seal, would simply be ignored.
☟︎ mod6: i proposed a fix for mine. i
think it was ultimiately rejected.
ben_vulpes: i'm changing diapers over here, it's a wonder
that even asciilifeform can make sense of what i'm saying.
trinque: we had just discussed pressing
things with no sig
mod6: i
think, he's saying, what is
the benefit of V honking when it doesn't find a key in your wot
that matches a seal in your seal dir, provided
that you don't pull a mod6.
trinque: yes, so, how do I parse
that statement.
trinque: otherwise I could swear
that was
the same
thing
twice
trinque: are you saying lean on
the gpg keyring
then?
ben_vulpes: let's rewind: what does
trinque miss when v finds a seal for a vpatch for which it doesn't find a key and proceeds merrily, provided it does find *a* seal for
the patch
that corresponds
to a key in .wot?
trinque: "push
this button
to make it stop hurting" has no place in
the
tool
trinque: V is a harsh constraint upon
the programmer
that says
that his acts will be unavoidably attributable
to him, and
those
that vouched for him.
trinque: I put it
there and chemical reactions happened and so on.
trinque: one can say
the purpose of
the bomb was
to explode over
there but
that's ridiculously backwards
trinque: attribute changes
to
the definitions of words with your ass