tmsr - Log 2018-10-14

a111: Logged on 2018-10-13 07:14 hanbot: anyway the idea is to have an exhaustive list of news outlets with their contact email made, after which i'll have her mail that blurb; i expect something like a week's turnaround, and will report when it's done.

mircea_popescu: http://btcbase.org/log/2018-10-13#1862164 << yes ; cuz all 1470s go to one process and all 1472s go to a different one. eventually as a scalability thing could even go to diff box altogether. there's not so muchrelation between the two types. ☝︎☟︎

a111: Logged on 2018-10-13 20:45 asciilifeform: diana_coman, mircea_popescu : didja ever say wai not made'em all 1472 ?

mircea_popescu: diana_coman 14721 or 14702 BITS long, not octets yes ? ☟︎

a111: Logged on 2018-10-13 20:48 diana_coman: asciilifeform, hmm, there is certainly a case for same size precisely because way simpler code

a111: Logged on 2018-10-13 23:51 asciilifeform: trinque: i dun suppose you have a cured binary-types ? ( cured, but presently fails to run when i strip away the asdfism so i can work it into my tree bodily )

Mocky: http://btcbase.org/log/2018-10-13#1862167 >> I don't see how it would necessarily be any simpler aside from one `if` statement. And there's nothing to stop listening on separate ports and getting all benefits asciilifeform mentions with different sizes ☝︎☟︎☟︎

a111: Logged on 2018-10-13 20:48 diana_coman: asciilifeform, hmm, there is certainly a case for same size precisely because way simpler code

asciilifeform: i pissed on unix idjicy, none of my routines return sizes or read/write variant lengths. all packets presumed to be hardcoded size.

asciilifeform: all received packets are either valid (i.e. the one troo size) or invalid (if not).

Mocky: ok so does the hardcoding need to be in-package for the preallocated buffers?

asciilifeform: diana_coman has a 'generic' ver, a kind of ada cheat i suggested ; but it has minus of preventing restriction encapsulation, as well as inevitably moar complex receiver (mine handles one size and one size only)

asciilifeform: Mocky: y'understand what preallocated means. it means fixed, at compile time, here.

Mocky: it's a simplifying assumption that pays off with smooth transition between program and unix, when it holds. a tactical cut

Mocky: so long as you can assume one tru packet size, you can get some ada benefits + extra simplicity, that you don't get otherwise, no?

asciilifeform: Mocky: unixism per se had ~nuffin to do with it. incut away a degree of freedom. unnecessary degrees of freedom are fundamentally harmful in re simplicity/sanity.

asciilifeform: there's no reason os's udp should even fucking accept a sub-frame packet payload. or super-framed. ☟︎

asciilifeform: leave n bytes in frame empty, simply gives 'fritz chip' handy spot to stuff kleptograms in...

Mocky: if a program wants to send 200 byte packets only, too bad, os won't allow cuz asciilifeform says your small number not godly?

a111: Logged on 2018-10-14 04:50 asciilifeform: there's no reason os's udp should even fucking accept a sub-frame packet payload. or super-framed.

asciilifeform: from electrical pov, you win nuffin by shortening'em under a frame.

asciilifeform: i for instance am sitting here and tryin', not always successfully, to cure folx of delusions that linux instilled in'em, e.g. 'tcp gives cheap an' reliable pipes' ( cured mircea_popescu after , what, 3y ) and nao 'udp packets can be anyffing, not merely 1472' (not cured yet..)

asciilifeform: point being, they're mirages, lies linux tells the hapless user.

Mocky: the important point being that as a matter of policy, perpetuating smaller packet sizes is a bad idea

asciilifeform: Mocky: there's precisely 1 packet size. in physical box. 1500. it's the railroad gauge.

asciilifeform: errything else is hokum created by ip stack theatrics. and incurs complexity cost for 0 win.

asciilifeform: Mocky: read up re what yer nic actually does. then will grasp that by pretending that it does something, anything , else, you incur runaway complexity cost and impedance mismatch. always.

Mocky: I don't disagree. I just wasn't able to infer this stance from your stated objection >> http://btcbase.org/log/2018-10-13#1862166 ☝︎

a111: Logged on 2018-10-13 20:48 asciilifeform: would get much simpler coad (i.e. my orig. fixed frame) vs the extended one with moar moving parts.

asciilifeform: i dun think i can say anyffing else to make this point clearer, it's imho as screamingly obvious as 2+2, if you take the time to rtfm. so i'ma leave it at this.

asciilifeform: the physical nic ~always sends 1500!~ it also always receives 1500!! ☟︎

a111: Logged on 2018-10-02 14:52 asciilifeform: 4096bit is 512byte, you're sending 1500 frame always, even if your nominal packet is 3bytes long. simply how ethernet worx.

asciilifeform: Mocky: ok. so, observe, i dun record or return lengths. all length are either $full ( which i tentatively had set to 512, pre-rftming) or invalid ( may as well 0 )

asciilifeform: and if i were to, say, buffer packets, queue'em, always can say exactly how much space they will occupy.

jurov: Hi all thebitcoin.foundation is being switched to new server, not just the A record but whole DNS changed, there might be issues next few hours.

ave1: asciilifeform, http://btcbase.org/log/2018-10-14#1862262, strange, it seems that ethernet does allow for variable length packages. I can see that the header / data ratio is smallest at the largest physical package size. ☝︎

a111: Logged on 2018-10-14 05:08 asciilifeform: the physical nic ~always sends 1500!~ it also always receives 1500!!

a111: Logged on 2018-10-14 01:10 mircea_popescu: diana_coman 14721 or 14702 BITS long, not octets yes ?

diana_coman: the tester does not pack them in rsa or serpent proper so it's the "package" there rather than protocol message, I guess that might be confusing, I'll update

diana_coman: http://btcbase.org/log/2018-10-14#1862213 -> it's more than just one if statement (although unnecessary branches in themselves are not great anyway); basically it's the udp code itself that has to be messed up to accommodate this particular thing - either using generic or otherwise using the largest of the two and then filtering one level higher ☝︎☟︎

a111: Logged on 2018-10-14 04:30 Mocky: http://btcbase.org/log/2018-10-13#1862167 >> I don't see how it would necessarily be any simpler aside from one `if` statement. And there's nothing to stop listening on separate ports and getting all benefits asciilifeform mentions with different sizes

diana_coman: in fact the 3rd option that is the one actually to use is having different sizes on the two processes (i.e. different constant simply) ☟︎☟︎

diana_coman: http://btcbase.org/log/2018-10-14#1862203 -> the point as I see it is precisely that physically there actually is only ONE type anyway so any different types/sizes is in fact a higher level filtering no matter what (i.e. having 2 different processes each with its own size doesn't mean that each will actually get only the size it wants) ☝︎

a111: Logged on 2018-10-14 01:09 mircea_popescu: http://btcbase.org/log/2018-10-13#1862164 << yes ; cuz all 1470s go to one process and all 1472s go to a different one. eventually as a scalability thing could even go to diff box altogether. there's not so muchrelation between the two types.

deedbot: http://bimbo.club/?p=52 << Bimbo.Club - TMSR Log Summary - 10/11/2018 ☟︎

ave1: Unfortunately is does not read as a straight long division anymore. But copying of the input array is avoided and

diana_coman: bvt, get yourself a pizarro shared account and start your blog there precisely with those pastes, what's keeping you? ☟︎

diana_coman: ave1, it seems I still get the old .vpatch? I took it with curl from http://ave1.org/code/eucrypt/eucrypt_crc32_div.vpatch ; is this the right place?

lobbes: !Qlater tell asciilifeform bot's back. Once auctionbot is finished I will go back and redo the "!Qlater tell" stuff to sit on top of logbot as well (right now, this too is sitting on an old heathen bot that doesn't auto-authenticate with NickServ after fleanode disconnect shenanigans)

lobbes: and speaking of auctionbot: development is complete. At the moment I am getting ready to begin some prod testing and then all that's left is to write the blog post explaining the usage. Getting close! ☟︎

billymg: it appears that php 5.6.38 is now the only 5.6 php available on the upstream portage repo http://wotpaste.cascadianhacker.com/pastes/dqRWG/?raw=true ☟︎

billymg: and even that can't be safely emerged as it would require an update to portage http://wotpaste.cascadianhacker.com/pastes/ZYgae/?raw=true

a111: Logged on 2018-01-31 16:08 asciilifeform: if any part of the edifice ever shows any symptom of fully working, they re-fuck it.

billymg: anyhow, any advice for proceeding would be much appreciated (it's entirely possible i'm missing something obvious here)

ave1: diana_coman, place was right, my publish pipeline failed (somehow the final copy operations did not work)

lobbesbot: asciilifeform: Sent 1 hour and 25 minutes ago: <lobbes> bot's back. Once auctionbot is finished I will go back and redo the !Qlater tell stuff to sit on top of logbot as well (right now, this too is sitting on an old heathen bot that doesn't auto-authenticate with NickServ after fleanode disconnect shenanigans)

BingoBoingo: billymg: What happens if you try: emerge --ask --changed-use --autounmask-keep-masks --deep @world ☟︎

asciilifeform: but in the long term, the pill will have to be cuntoo ( which has permanent trinque repo, unaffected by enemy ) ; conventional gentoo should already today be thought of as 'frozen', emerge cannot be relied to work

billymg: BingoBoingo: yeah, i spent a good bit of time trying to update @world this morning, masking packages one-by-one, and eventually gave up

billymg: build fails at configure: error: mcrypt.h not found. Please reinstall libmcrypt.

billymg: would the next best bet be to install from source, outside of portage?

asciilifeform: billymg: try lobbes's thing, if it fails, then yes, will have to from src

ave1: asciilifeform, I get the updated one, maybe caching problem somewhere (I did have to reload)

asciilifeform: BingoBoingo, mod6 : i'm thinking , i prolly oughta roll the mp-wp prereqs into the standard rk image, in the short term

a111: Logged on 2018-10-14 08:34 deedbot: http://bimbo.club/?p=52 << Bimbo.Club - TMSR Log Summary - 10/11/2018

asciilifeform: http://btcbase.org/log/2018-10-14#1862284 << as i understand, you'll need 2 listeners, on separate ports, if you want'em to go to separate processes, regardless of size setting , aha ☝︎

a111: Logged on 2018-10-14 07:53 diana_coman: in fact the 3rd option that is the one actually to use is having different sizes on the two processes (i.e. different constant simply)

lobbes: !!v 1BC459506CE5EC069FDE57532C95BE95CAB5B1AA1BF10709BA0619A9CDEF8F12

asciilifeform: http://btcbase.org/log/2018-10-14#1862311 << btw, i explicitly disrecomment updating rk gentoo from heathen-upstream. it will lead only to tears. ☝︎

a111: Logged on 2018-10-14 14:19 BingoBoingo: billymg: What happens if you try: emerge --ask --changed-use --autounmask-keep-masks --deep @world

lobbes: asciilifeform: btw, I'm planning to have auctionbot sit in #eulora, and #trilema-lobbes to start. Would you like it to also sit in #pizarro?

lobbes: (to begin, it will not have self-voice capability. Spyked's voicer is for the ircbot branch of the tree sadly, so I will need to add voicing to the logbot branch. However, I figure that can wait for another day) ☟︎

lobbes: "castle-only" may be the way to go anyways; I'm not sure #trilema even needs the auctionbot to sit in here ☟︎

trinque: http://btcbase.org/log/2018-10-14#1862301 << write an ebuild for your preferred PHP, explain why it's preferred in a blog post on a wpmp instance, and I'll rate you ☝︎

a111: Logged on 2018-10-14 13:59 billymg: it appears that php 5.6.38 is now the only 5.6 php available on the upstream portage repo http://wotpaste.cascadianhacker.com/pastes/dqRWG/?raw=true

mod6: <+asciilifeform> BingoBoingo, mod6 : i'm thinking , i prolly oughta roll the mp-wp prereqs into the standard rk image, in the short term << sounds alright to me, alf

trinque: http://btcbase.org/log/2018-10-14#1862212 << I don't see how I could have shaved off just that rating while fixing the diana_away thing, but if it turns out I did, my apologies ☝︎☟︎

a111: Logged on 2018-10-14 04:29 Mocky: oh shit, mircea_popescu unrated me!

trinque: you've still got plenty of ratings to self-voice, but if it turns out I did that, I'll fix it.

Mocky: oh, thx trinque. didn't get around to upping myself, just doing chores atm

trinque: Mocky: yep, looks like I trashed it, and I see no corresponding !!unrate. restored. I will make sure there were no other dropped ratings. ☟︎

diana_coman: ave1, typos: "opation" "to determin" "here a short list" "therefor" "registor" "zero's" "implentation" "not if statements"

diana_coman: as it is, it will be a .vpatch after the lookup implementation - so linear sequence rather than alternative; you might want to branch the tree instead from *before* the lookup implementation so that your div version is effectively alternative branch ☟︎☟︎

diana_coman: though I don't yet see how would one bring them together afterwards without requiring BOTH of them

asciilifeform: diana_coman: i suspect that he forgot to refresh the seal , and that one's from the old ver

ave1: diana_coman, asciilifeform, well I uploaded both with the same scp line, but did not check. So now again new version (thanks for the typo fixes diana_coman!), I just downloaded both again and verified.

ave1: yes, I see! I will try that too. I have no idea how it could automatically resolve (i.e. How could patch that has your original patch as it's parent ever work on top of this one)

a111: Logged on 2018-10-14 15:55 diana_coman: as it is, it will be a .vpatch after the lookup implementation - so linear sequence rather than alternative; you might want to branch the tree instead from *before* the lookup implementation so that your div version is effectively alternative branch

a111: Logged on 2018-10-12 18:14 diana_coman: and it fits perfectly the original idea of alternative, proper

diana_coman: i.e. can one effectively branch the v tree to provide an alternative .vpatch i.e. this or that stand at this place in the pressed line?

asciilifeform: diana_coman: the way i understand 'v branching as civilized replacement for #ifdefism', the branches unavoidably gotta get reground whenever the whole tree is considered stable (i.e. no further changes likely to trunk)

diana_coman: hm, perhaps being a reference implementation it makes sense to remain as branch there and otherwise the tree continues along the main line (not reference)

diana_coman: but other than this, I don't see any need or point for reground

asciilifeform: concretely : ave1 releases crc32 as standalone staticable lib, like my udp. it comes with 2 pressable leaves, 'tabletronic' and 'divtronic'. you can press either and use in e.g. euloratron when building.

diana_coman: ah, you mean that the only way to do this is to take crc32 out of eucrypt tree? ☟︎

asciilifeform: alternatively, both variants are physically included in euloratron tree, but then the latter has 2 pressable leaves, for the respective variants

diana_coman: yes, the way I currently see it now is pretty much that: trunk (main line) goes along the production versions of all stuff (crc32 or keccak or whatever else) and otherwise at the respective points there can be additional branches /leaves with the reference implementations ☟︎

diana_coman: I honestly don't quite see the point of taking crc32 out for instance ☟︎

diana_coman: or keccak or whatever, basically making 5 tiny trees out of eucrypt tree

asciilifeform: part of the exercise here is to purge head of the last vestiges of dark ages 'merge-istic' versiontronics . who wants variants, gotta remember that yer pressing variants built on specific states of the trunk. ( and if trunk meanwhile changed, and you still want it, must regrind )

asciilifeform: diana_coman: iirc mircea_popescu in particular specifically hates libs-as-separate-trees, insists that proggy oughta include errything it eats. ( i dun recall whether he answered why it should not also then include the os and compiler also in same genesis, but i'ma leave thread alone for nao) ☟︎

asciilifeform: he had a pretty good arg imho, tho, that when you write on top of a specific lib, you oughta freeze it in, rather than permit it to change 'under you' at any point.

asciilifeform: imho 'unifiers' (i.e. patch that pulls in specific state from a parallel tree) is a cleaner way of accomplishing this than cut&paste, but i was unable to persuade. ☟︎

diana_coman: asciilifeform, trouble is - what do you do then when/if that tree gets reground? ☟︎

asciilifeform: diana_coman: you carry with your proggy, the specific one you built on

asciilifeform: author can regrind all he wants, you are not forced to regrind yours unless you think it merits

diana_coman: maybe I didn't understand then what you mean by "patch that pulls in specific state from a parallel tree"

asciilifeform: diana_coman: my orig v algo supported unlimited 'genesis'-en

asciilifeform: so it was possible to write a proggy that used items from multiple trees.

asciilifeform: mircea_popescu specifically barfed , tho, and nobody any moar does this. so for nao yer stuck with cut&pasteism, as i understand.

diana_coman: and then you are stuck maintaining those multiple trees - what's the benefit in that? ☟︎

asciilifeform: the diff was that the history was preserved, as opposed to painted over with cut&paste.

diana_coman: once you bring it into your tree, you don't care about the original tree so ...how stuck? ☟︎

asciilifeform: that's where we differ, i think. my whole notion in inventing vtronics was to preserve all history that can be practically preserved.

diana_coman: I can see the history is preserved angle, certainly; and a nice thing for sure; but there is a cost for it and I'm not sure the benefits make up for it

diana_coman: I think the difference might be at whether it is "practical" or not :)

asciilifeform: to bring thread back to current-day -- afaik the only means to implement alternative builds, in current scheme, is 2 (or moar) pressable leaves in erry 'release' ver.

asciilifeform: ada deliberately does not offer equiv of #ifdef, because ifdefism is retarded. so you're left with this method, afaik.

asciilifeform: and ideally erry 'alt' variant has a maintainer, who will regrind so that his variant continues to be usable .

asciilifeform: in that it prevents the combinatorial clusterfucks that ifdefism causes

asciilifeform: and instead each variant is a thing that its author is forced to actually test as-written.

ave1: hey, I was just thinking the same thing offline, so yes I think the new method is sane as it preserves authorship and no magic alternative could be inserted somewhere halfway the tree.

ave1: with the manifest as we have now and no way to automatically merge an alternative (i.e. having more than one possible ancestor)

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

asciilifeform: all presses are deterministic , a particular leaf produces a particular press.

asciilifeform: when you want alternative presses, you gotta have multiple pressable leaves, elementarily.

ave1: well, if I have file A and B, and p1 touches A and B, and p2 touches A in the same way as p1 but B differently

asciilifeform: then p1, p2, p3 are alternative and mutually-exclusive pressable leaves.

asciilifeform: trinque & mircea_popescu specifically introduces manifests to prevent this scenario.

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

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

asciilifeform: in current day vtrons you gotta explicitly bake pressable leaves if you want alternatives.

ave1: I was still on the "automagic" way to choose either the lookup or the divtronic CRC32. Whis will never be automagic, authors just have to work on 2 different threes if they want and let the longest one survive.

asciilifeform: this is the Right Thing, i.e. if you want a variant to exist, you gotta maintain it.

ave1: btw, I'm still interested in the single size ethernet packages (I propably misunderstood) but unfortunately have to bbl

asciilifeform: ave1: there is not much to be said further re subj, i looked into what actually comes out of my lan, it sends 1500 frames upstream always. ☟︎

asciilifeform: ( and yes on paper ~could~ send shorter ones, but actual iron afaik never does )

asciilifeform: best analogy, imho, is sov train carriages. it is possible to make train carriage of many lengths, but they had 1 . so if cargo were smaller, it'd get packed in with other things, or sometimes partially empty car, but short car would not be specially built for shorter crate.

asciilifeform: on 1 occasion it was found necessary to build a icbm rocket that is too heavy for 1 car. head designer v. f. utkin found solution, he had a system of springs to distribute the weight between ~two~ cars. this is analogous to udp fraggism. ☟︎

asciilifeform: ^ the gizmo on the right, was a hydraulic thing to push any electric wires above the tracks, out of the way. whole thing was pretty clever.

asciilifeform: and notably, by some accounts the 'distribute the mass' gizmo did not actually work very well, hence why the thing was eventually scrapped. ( and not because 'usa asked eltsin nicely', as was the popular legend at the time )

asciilifeform: but let's suppose utkin had instead built a rocket that occupies all but one metre of standard rail car. i suspect that it would not have been received warmly by the brass, and at the very least they'd ask why, 'what will go in that free metre of car ? tinned fish ?'

asciilifeform: this is prolly as far as the analogy goes, so i'ma leave it there.

Mocky: http://btcbase.org/log/2018-10-14#1862360 >> does 'restored' mean it should be in there now trinque? I don't see it. ☝︎

a111: Logged on 2018-10-14 15:44 trinque: Mocky: yep, looks like I trashed it, and I see no corresponding !!unrate. restored. I will make sure there were no other dropped ratings.

trinque: purged a few pieces of technical debt lingering from the rapid prototype I built during the schism. sorry to have made you a casualty of the purge!

trinque: (also will no longer suffer from pages being overwritten due to same fp, since dupe fp is banned)

asciilifeform: trinque: unrelatedly, i resolved the binary-types thing, will eventually genesis a working ver.

ben_vulpes: http://btcbase.org/log/2018-10-12#1861273 << largeish place, live music of poor quality on the first floor, asciilifeform and i had the top balcony to ourselves for an hour at least ☝︎

a111: Logged on 2018-10-12 18:46 asciilifeform: nope, definitely ben_vulpes

ben_vulpes: http://btcbase.org/log/2018-10-14#1862478 i lost a few hours to cl-postgres/postmodern/simple date over the past two months; there is now some cl-postgres-simple-date-glue package that needs loading in order for postmodern to use its local-date set of classes. once upon a time loading simple-date after cl-postgres was enough to get the mechanisms in place. ☝︎

a111: Logged on 2018-10-14 18:06 asciilifeform: i'd eventually like to be rid of asdf tho.

ben_vulpes: i've since just cut over to using postgres' own godly datetime knobs because a) better in every way b) works with timezones trivially

ben_vulpes: fence is done, transpocubes for possesions arrive tomorrow. house still unleased and one car yet needing transportation scheduled. other than that, girl and child fly out soon, and i drive out with dog shortly before.

asciilifeform: ben_vulpes: unrelatedly, didja ever post yer cl block/tx eater src ? i seem to recall that you did, but can't presently find in l0gz

ben_vulpes: i'm sure that i did but cannot recall where immediately, sec

ben_vulpes: asciilifeform: www.cascadianhacker.com/wp-content/uploads/2018/10/blockparser.tgz

ben_vulpes: c6f427266725bc5166979cdee5010a7cf417fa788b87e1a05f430f07fdc52719cf697d71730a498fa12faea302908fbf34ea616079530a30dbd88fb00cafb8f7

ben_vulpes: it is pretty novice cl; heavily java-flavored clos

ben_vulpes: apologies for the stink

asciilifeform: dun need to be battlefield-grade, simply wanted to see how ben_vulpes did it, ty

asciilifeform: ( recall, i have my own working block eater in ada, posted last yr, but currently was looking into 'binary-types' in application to btc trad encoding )

asciilifeform: the particular experiment here is a node exerciser, rather than block eater, in cl

ben_vulpes: reading satoshi's varint gave me no ends of headaches with binary-types, i eventually cheated out

a111: Logged on 2018-10-12 18:18 asciilifeform: the 1 'litmus test' i was able to think of , is the 'i pick a block hash and you gimme the block in <1s' algo.

billymg: trinque: thanks for the tip about custom ebuilds. was able to do a local ebuild of the libmcrypt dep by taking what was in upstream and just changing the EAPI version to 6. installed fine, and then php-5.6.38 went fine as well

billymg: about to step out for a bit but have been keeping notes and will put together a writeup after mp-wp is successfully pressed/running

BingoBoingo: billymg: With mp-wp the three most common sources of headbanging are: file and directory permissions, .htaccess (if running apache), and pressing into a populated direction (As in you press, aren't sure anything happened and press again into the output directory without cleansing it; prevalence of this one depends on particular v-tron used))

lobbes: I will be monitoring it to make sure everything is running smoothly. Let me know of any funkyness

lobbes: for the time being, the legacy auctionbot (lobbesbot's !Qauction) will remain up and running as well

lobbes: eventually will take it offline and merge its data into this new bot, but that is later

hanbot: BingoBoingo re remittance shits, i found something here, going to investigate tomorrow if it'll do .uy; will update.

BingoBoingo: hanbot: Thank you. I haven't found anything promising here yet.