tmsr - Search: vtron

asciilifeform: diana_coman: rright, folx going about not only using vtron, but teaching entire university course on it, while ignoring the basic logical consistency of 'i signed, i am equally responsible' aint none of my concern, aite.

ossabot: Logged on 2019-10-23 11:18:46 asciilifeform: fwiw a mp-wp extension that lets folx 'download these-here patches' imho may be useful. but really ought not to be ~in vtron~ .

mp_en_viaje: http://logs.ossasepia.com/log/trilema/2019-10-23#1947816 << well, in practice vtron will come bundled with toolkit, what can do.

asciilifeform: asciilifeform's orig. vtron did not make use of the net at all, runs a++ on boxes w/out nics, and imho this is Right Thing.

asciilifeform: fwiw a mp-wp extension that lets folx 'download these-here patches' imho may be useful. but really ought not to be ~in vtron~ .

spyked: when I first looked into it, I found it a little odd myself, since it expects a particular URL structure, e.g. mp-wp/v/{patches,seals}. but then I got used to it and even adjusted my v mirror to match. afaik v.pl is the only vtron that comes with this functionality

asciilifeform: hrm i prolly oughta patch vtron so that actually gives detailed barf when encounters an apparently 'martian' antecedent, and for ~all~ such encounters in full list.

asciilifeform: trinque: the vtron may be buggy tho. ( i haven't tried personally however )

asciilifeform: if accept '100MB genesis' , then most of 'portage' is actually redundant, and as i understand whole thing can be replaced with a slightly mechanized vtron

asciilifeform: in fact, recall how trb 'chicken' genesis was a hand-cranked recipe, cuz had to delete binary gif turds etc and vtron of the time could not autodigest such deletion

asciilifeform: this resembles asciilifeform's orig. argument against having to write vtron -- 'just press the fucking patches by hand, lazy people'. but mircea_popescu didn't buy it then, so had to write vtron.

asciilifeform: http://btcbase.org/log/2019-06-22#1919415 << i must point out, this item imho is orthogonal to the problem of this thrd, a standard 'machine' does not remove the need for proper 'systemwide vtron'-aka-portage-replacement ☝︎

asciilifeform: there is even a (sad, disused, esthlos went to bottom of sea) but last i saw -- working -- cl vtron

asciilifeform: mircea_popescu: re 'ebuilds', as i understand trinque's angle was/is to organically replace gentoo's ebuild duct tape with vtron

mod6: I used diana_coman's vtron build with the same. Pressed the (yet unverified by lord keccak vpatch bundle that I created in January) keccak tree, made the changes in the makefiles, etc. Have a vpatch.

a111: Logged on 2019-04-25 15:09 asciilifeform: e.g. an auto-installable cuntoo that runs on commonplace irons and includes working gnat, vtron, etc. would save massive amount of work, vs. current situation where 'oh you bought a new box? here's a buncha toothpicks and glue'

asciilifeform: e.g. an auto-installable cuntoo that runs on commonplace irons and includes working gnat, vtron, etc. would save massive amount of work, vs. current situation where 'oh you bought a new box? here's a buncha toothpicks and glue' ☟︎

a111: Logged on 2019-04-07 16:04 asciilifeform: http://btcbase.org/log/2019-04-07#1907304 << i formerly thought that this was obvious from the docs , but you ~can~ operate on vpatches without a vtron ( they're edible by trad. unix 'patch' util, and you can verify the sigs with anyffin roughly gpg-like , also by hand )

asciilifeform: OriansJ: you may find it interesting that a number of noobs wrote own vtron, rather than bothering to audit the old; the former is generally easier than the latter

asciilifeform: http://btcbase.org/log/2019-04-07#1907304 << i formerly thought that this was obvious from the docs , but you ~can~ operate on vpatches without a vtron ( they're edible by trad. unix 'patch' util, and you can verify the sigs with anyffin roughly gpg-like , also by hand ) ☝︎☝︎☟︎

asciilifeform: ( even tho it is about the ancient proof of concept vtron, with old-style hashes etc., re the basic mechanics it is still 100% correct )

asciilifeform: pretty sad, imho : esthlos wrote a++ log summaries, a working vtron, possibly other items i cant recall

asciilifeform: ( trb vgenesis released slightly ~prior~ to 1st vtron per se, recall )

asciilifeform: ^ also had a vtron. but then sank to the bottom of the sea, so unmaintained afaik.

asciilifeform: hanbot: other nitpick -- v.py is asciilifeform's orig. demo; v.pl is mod6's vtron

asciilifeform: hanbot: it is also possible to bootstrap any vtron using naked gpg, ancient gnupatch, and bare teeth ( manually check sig and patch -p0 < foo.patch, for ea. )

asciilifeform: mod6: at the risk of sounding like mircea_popescu in earlier thread -- why is this a mega-project ? i reground ffa to keccak in about 10minute (after getting hold of a working keccak-vtron)

asciilifeform: grr, was looking for mircea_popescu's also for vtron file movements, still not found in log

asciilifeform: fwiw i gave orig vtron, 'v.py' , 100. it's on 97 (phf's revision) and when i get around to massaging it, i suppose will be 96, and i dunsee why to touch it again after that..

a111: Logged on 2018-12-03 19:31 asciilifeform: spyked: it's the 1st one most folx used, given as it was the first vtron

asciilifeform: spyked: it's the 1st one most folx used, given as it was the first vtron ☟︎

spyked: http://btcbase.org/log/2018-12-03#1877949 <-- ftr, v.py was the first vtron that I read, and I think it's a great didactic implem (though nowadays esthlos v is imho a good competitor in that field) ☝︎

asciilifeform: lobbes: asciilifeform currently using diana_coman's vtron , worx a+++

asciilifeform: and ftr naming convention ( carried on since asciilifeform's original vtron ) is simply that patch is $string.vpatch and sig is $string.vpatch.author.sig .

asciilifeform: mircea_popescu: vtron (including phf's , and in fact his esp. well) solves.

asciilifeform intended to release a thing somewhat like it with the orig 2015 vtron, but asciilifeform's wwwtronics was not equal to the task, never made a usable incarnation of item

a111: Logged on 2018-11-14 00:20 mod6: 2) http://btcbase.org/log/2018-11-13#1872126 << diana_coman I tried to leave you a note on your blog. But seems that you've based the genesis off of my vtron version 99994K, but there is a newer version: http://thebitcoin.foundation/v/V-20180222.tar.gz http://thebitcoin.foundation/v/V-20180222.tar.gz.mod6.sig Which is denoted as version 99993K.

mod6: ah yeah (0x05), it is a significant change from all previous releases of my vtron.

mod6: 2) http://btcbase.org/log/2018-11-13#1872126 << diana_coman I tried to leave you a note on your blog. But seems that you've based the genesis off of my vtron version 99994K, but there is a newer version: http://thebitcoin.foundation/v/V-20180222.tar.gz http://thebitcoin.foundation/v/V-20180222.tar.gz.mod6.sig Which is denoted as version 99993K. ☝︎☟︎

a111: Logged on 2018-11-13 21:36 asciilifeform: http://btcbase.org/log/2018-11-13#1872052 << i'ma hold off on posting http://btcbase.org/log/2018-11-13#1871779 item , then, so that i can link to diana_coman's vtron

asciilifeform: btw i confirmed that phf's v98 ( when patched to remove the subkey handler thing ) successfully presses ch1-11, with bitwise-correct results ( compared with classic vtron )

asciilifeform: once we have a One Troo scripting language ( possibly some variant of spyked's gc-less ada lisp.. ) i'd like to write a vtron in that ( supposing nobody else beats me to it )

asciilifeform: phf: right, my current understanding is that presently ~errybody has a kludged vtron, but no one yet posted a 'canonical' variant that's 1) properly genesis'd 2) worx errywhere

asciilifeform: seems like the closest thing to a working keccak-vtron currently is phf's v98 tho

asciilifeform: and imho it is pretty sad that a vtron even sees ~anything~ 'systemwide'.

mircea_popescu: and i know no reason vtron must have "max line length picked in advance" either.

asciilifeform: and to write e.g. vtron, you gotta pick a max length in advance

asciilifeform: i hate to bring back ancient thread re 'how many columns in terminal', but you ~must~ have a finite width, or cannot write even basic thing like vtron without idjit heapism. and i'm heavily biased to 'make'em 80' , that's how wide my terminal and printers are.

mircea_popescu: i guess so. there were some other items scattered about re what should go in the config file for vtron

asciilifeform: btw phf , i'm starting to think that esthlos-vtron could be turned into a proper replacement for asdf,quicklisp,all the heathen rubbish packagerisms

asciilifeform: in orig vtron i relied on 'muscle power' to avoid this boojum, it proved insufficient; hence manifests.

ave1: yes, I know, but you asked about the senario; no published vtron permitted...

asciilifeform: ave1: no published vtron ever permitted 'more than one possible ancestor'

trinque: btw no insult meant to esthlos; we'll get an ebuild in there for his vtron as well, but he lacks a differ, and thus it's not a full v

asciilifeform: bvt: since you're already playing with a vtron, i suspect you know what the correct process is re patch

asciilifeform: but even if not changes, but minor refinements, e.g. the graph plotter -- n00bs will end up with old vtron, and then gotta press a newer

asciilifeform: diana_coman: as i understand q was 'how to give n00b his 1st vtron'

a111: Logged on 2018-10-01 11:51 esthlos: trinque: asdf is used to join the pieces together (keccak, gpg, etc.) for use by the vtron proper. I tried to build the vtron modularly, and my understanding is that asdf is the standard for handling modules in common lisp. is there a better way to do package management in cl?

asciilifeform: http://btcbase.org/log/2018-10-01#1856349 << right nao it's asdf, yes. but hopefully soon asdf can be replaced by your vtron-in-cl ! ☝︎

esthlos: trinque: asdf is used to join the pieces together (keccak, gpg, etc.) for use by the vtron proper. I tried to build the vtron modularly, and my understanding is that asdf is the standard for handling modules in common lisp. is there a better way to do package management in cl? ☟︎

esthlos: trinque: wrt the keccak vtron, see http://p.bvulpes.com/pastes/YWfb5/?raw=true . I haven't managed to get asdf working with ccl, though the sbcl version builds and appears to work. Note that the thing will barf on non-keccak vpatches. Write-up will come in the next few days. I also have some log catch-up to do: will read the context and repond to your other question soon.

mod6: I want users to be able to get a vtron, as they do now, with v.pl, then build trb in very much the same way they are able to today.

mod6: <+mircea_popescu> the one useful thing here would be to get trb properly ground already. << I'm probably not going to do this until there is a vtron that supports keccak.

asciilifeform: ( asciilifeform plowed through the phf-vtronics thread when came back from voyage, and then second time when diana_coman requested keccak regrind, and both times failed to converge to correct answ re 'is there complete keccak vtron' )

a111: Logged on 2018-09-27 13:35 asciilifeform: call me an idjit, but i thought there were a new vtron...

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

asciilifeform: trinque: which vtron are you thinking of including in cuntoo beta ?

asciilifeform: phf: my orig vtron has been sad and unmaintained, and afaik unused by anybody by me, for long time

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.

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.

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: apparently diana_coman has been hand-cranking it, sorta like asciilifeform's 1st yr of trb pre-vtron

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

lobbesbot: phf: Sent 14 hours and 6 minutes ago: <asciilifeform> nm, distinguished by hand... but my vtron doesn't verify the sigs (not immediately sure why) and mod6's -- sees only Leaf: vtools_vpatch_newline.vpatch (phf)

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

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

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