70400+ entries in 0.043s
phf: mircea_popescu:
the next line after
the one you quoted is "all files are identified by hashesof
their name and content"
mircea_popescu: kinda what
the problem is with
these "brought back from
the swamps of memory" items,
the result
takes some washing.
mircea_popescu: as i say, my latter statement of
the notion was misleading & vague.
phf: yes, i remember
the algo, and algo requires
that
the hash is just of content. i
thought i was entirely insane, because immediately after "hash
the name + content" i say "we're on
the same page"
mircea_popescu: this is correct ; my above "hash
the filename" was incorrect, or rather, inexact.
a111: Logged on 2018-04-03 00:02 mircea_popescu: asciilifeform
the logged discussion on
the
topic was, "if hashes match but paths do not,
the file was moved ; if hashes match and paths match,
the file is untouched ; if hashes do not match but paths match
the file was modified ; if hashes do not match and paths do not match
the file was created/deleted"
phf: and later i say we're on
the same page, and i have no idea why and how
a111: Logged on 2018-04-02 23:57 mircea_popescu: at which juncture i suppose it'd pay
to check, huh. hey phf, my memory of logs discussion includes
this item whereby
the above problem was fully resolved by declaring
the path as inseparable part of
the filename. you on
the same page ?
mircea_popescu: well now i'm reading
through all dis, what can do. phf's four months at work resulted in same many months of rot, now we don't recall
the spec, log is long, life is short, so on an' so forth.
phf: i'm
trying
to find
the relevant
thread right now
phf: mircea_popescu:
the later, but i don't
think
that was
the last iteration of your algorithm
mircea_popescu: phf when you calculate
the file hash, do you
take ~the full name~ plus "the content or just "the content" ?
mircea_popescu: but i am not currently in a position
to
take a day off and review poorly executed jobs in detail.
mircea_popescu: i can't currently conceive how
the fuck he even MADE a vtools without it, because it was a root node and nothing works without it anyway (eg, i expect all
the hashes he calculates are wrong)
mircea_popescu: right. phf was supposed
to have ~support for deletion/movement/fullspecified filename~ baked in.
a111: Logged on 2018-10-06 17:12 asciilifeform:
tangentially on-thread, it still bothers asciilifeform
that he was unable
to represent
the diff b/w mircea_popescu's bitcoin-0.5.3.tar.gz and
the genesis as a vpatch ( neither orig v nor current is able
to represent
the deletion of binariolade... )
mircea_popescu: there was NO discussion of "bion diffing". nor will
there be.
there was specified support ~for deletion of files~, which is WHAT YOU WERE
TALKING ABOUT
mircea_popescu: you mean
the client ? no-one's even bothered
to genesis
thart yet ; being replaced i expect.
☟︎ mircea_popescu: asciilifeform bins in mp-wp
tree, hanbot expertly ascii-ized.
phf: asciilifeform: i
think
the divergent points were a lot more elaborate
than
this particular reduction
phf: i have couple of hours
tomorrow, so i'll pick up
the deletions and renames code either way, and either release it, or give an estimate for how long it will
take me
to bake it
☟︎☟︎ phf: there are
three distinct options: deletions and renames (which is handled by mp algo), creations (that can be handled by e.g. <size><content in hex>) and diffing (which is
top complexity, needing e.g. needleman-wunsch)
☟︎ phf: my first priority is
to revive delete/rename
though since i have algo and code for it
phf: asciilifeform: i don't have binary diffing even in prototype form, if you could adaize your needleman-wunsch i could add it
to vtools,
the way i did with diana_coman's keccak
☟︎ phf: asciilifeform: because binary we've been going back and forth on over many conversations over
the past year. e.g. mp-wp was rewritten
to not use binaries because around
the
time
the resolution was
to not pack binaries into vpatches and instead move in
the direction of human readable formats
phf: mircea_popescu: i understand, it's
the height of idiocy on my part
phf: format breaks only in a sense
that gnu patch won't press it. current vpatches
that don't delete/rename (since
the feature is not
there) will never
the less work with any future changes
to vtools
mircea_popescu: asciilifeform we had solution
to
that, whole discussion with fully specified filenames, on it goes.
phf: asciilifeform is right, i dropped
the ball on it. i prototyped it right after we had a conversation, and
then i had
the four months of fiat work, and i forgot
that it was on my plate.
mircea_popescu: i really don't like
this constant process you got in your head going sed -e 's/i don't know/doesn't exist/' everything-i-never-read.txt
mircea_popescu: we discussed
this extensively, before phf even started. new vtools is perfectly capable of describing
the deletion/movement/etc of ~any files~.
mircea_popescu: the whole fucking point of
the entire new v was
to be able
to represent deletion of files.
mircea_popescu: neither orig v nor current is able
to represent
the deletion << no FUCKING way.
a111: Logged on 2018-10-06 20:05 asciilifeform: 'Discussion regarding article about apple and amazon denied
that Chinese spies implemented backdoor chips into hardware' << uhm, 'казнить нельзя помиловать'
trinque: ah I was over here
trying
to figure out what webcomic
that was, maybe oatmeal
trinque: no need
to chimerize where necessity doesn't force
trinque: sure, vtron presses
the ports
tree, gprbuild builds
trinque: bsd ports
tree uses exactly make for
this
trinque: just a bridge off
the infected island
trinque: also questionable whether
there's such
thing as a republican portage, or whether it all ought
to be
trashed for something gprbuild-based and with far less optionality.
☟︎ trinque: mhm, perhaps source gets slurped directly into ebuild dirs as
time goes on. open question yet how
that step proceeds.