log☇︎
24600+ entries in 0.191s
asciilifeform: this is prolly as far as the analogy goes, so i'ma leave it there.
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: http://militaryarms.ru/wp-content/uploads/2016/06/bzhrk-molodec-i-barguzin.jpg << subj.
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. ☟︎
ave1: btw, I'm still interested in the single size ethernet packages (I propably misunderstood) but unfortunately have to bbl
asciilifeform: this is the Right Thing, i.e. if you want a variant to exist, you gotta maintain it.
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: in orig vtron i relied on 'muscle power' to avoid this boojum, it proved insufficient; hence manifests.
asciilifeform: aa i see what ave1 meant
ave1: yes, I know, but you asked about the senario; no published vtron permitted...
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
ave1: with the manifest as we have now and no way to automatically merge an alternative (i.e. having more than one possible ancestor)
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.
diana_coman: I think the difference might be at whether it is "practical" or not :)
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
asciilifeform: that's where we differ, i think. my whole notion in inventing vtronics was to preserve all history that can be practically preserved.
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: maybe I didn't understand then what you mean by "patch that pulls in specific state from a parallel tree"
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. ☟︎
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) ☟︎
diana_coman: I honestly don't quite see the point of taking crc32 out for instance ☟︎
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: but other than this, I don't see any need or point for reground
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: 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?
diana_coman: asciilifeform, perhaps I'm missing something obvious re ^ ?
diana_coman: this is why I'm still skeptical re http://btcbase.org/log/2018-10-12#1861225 ☝︎
ave1: yes, I see refers to: http://btcbase.org/log/2018-10-14#1862364 ☝︎
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)
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.
asciilifeform: diana_coman: i suspect that he forgot to refresh the seal , and that one's from the old ver
diana_coman: though I don't yet see how would one bring them together afterwards without requiring BOTH of them
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: you've still got plenty of ratings to self-voice, but if it turns out I did that, I'll fix it.
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 ☝︎☟︎
trinque: (obvs I'm about to ask for a wpmp ebuild, but one step at a time)
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#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 ☝︎
lobbes: "castle-only" may be the way to go anyways; I'm not sure #trilema even needs the auctionbot to sit in here ☟︎
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: 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?
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 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)
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 ☝︎
asciilifeform: BingoBoingo, mod6 : i'm thinking , i prolly oughta roll the mp-wp prereqs into the standard rk image, in the short term
asciilifeform: ave1: ~nao~ i see new one
ave1: asciilifeform, I get the updated one, maybe caching problem somewhere (I did have to reload)
billymg: lemme read that one and see if i missed something
billymg: i was not, i was mostly going off http://blog.esthlos.com/mp-wp-setup/
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
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)
asciilifeform: ave1: i still see old one
billymg: anyhow, any advice for proceeding would be much appreciated (it's entirely possible i'm missing something obvious here)
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! ☟︎
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)
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?
diana_coman: ave1, thanks for the update, I'll look at it in a minute
ave1: diana_coman, I've updated the crc32 code! (still at the place)
bvt: short writeup on what i did and why: http://p.bvulpes.com/pastes/GLopH/?raw=true
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) ☝︎
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) ☟︎☟︎
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: 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
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. ☝︎
asciilifeform: aite, i'ma bbl then, will not belabour the point.
asciilifeform: and if i were to, say, buffer packets, queue'em, always can say exactly how much space they will occupy.
a111: Logged on 2018-10-14 05:09 Mocky: I get it and I agree with you.
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 )
Mocky: I get it and I agree with you. ☟︎
asciilifeform: Mocky: i was describing why i wrote it as i did.
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.
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.
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 ☝︎
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: * i cut
Mocky: no, i get it
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: all received packets are either valid (i.e. the one troo size) or invalid (if not).
asciilifeform: as imho is proper, i.e. max frame size.
asciilifeform: i pissed on unix idjicy, none of my routines return sizes or read/write variant lengths. all packets presumed to be hardcoded size.
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 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 )
mircea_popescu: http://btcbase.org/log/2018-10-13#1862190 << i lolled. ☝︎
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.
asciilifeform: it's come to where i can't look at heathen coad for an hour without turning up an intractable barfology.
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 ) ☟︎
trinque: lol well lobbes I tried :p
asciilifeform: !Qlater tell phf wouldja happen to have a frozen nonretarded version of bordeaux-threads somewhere ? the one i have, is utterly sad, squats nickname 'bt' which prevents binary-types from working...
asciilifeform thought, naively, 'binary-types itself is ~1k loc, why don't i fix ~that~... 6 hrs later...'
asciilifeform: !Q later tell phf wouldja happen to have a frozen nonretarded version of bordeaux-threads somewhere ? the one i have, is utterly sad, squats nickname 'bt' which prevents binary-types from working... ☟︎
asciilifeform: ( i.e. you dun have to 'check what it is' on top of existing logic, e.g. if port 9000 it goes to serpent, if 9001 -- to rsa , and each respective process validates per the existing rulez )
diana_coman: strictly from an implementation perspective I'd certainly prefer to have only ONE size of message to deal with - even if it means potentially that one has to check wtf it is; still, I'll wait for mircea_popescu to weigh in on this
asciilifeform: i.e. simply run the acct one with 'nice 19 ...'
asciilifeform: rright, i did read mircea_popescu's spec
a111: Logged on 2018-10-02 16:25 mircea_popescu: ok, so this back of a digital envelope seems to suggest we want : 1. fixed size 1470 byte rsa packets, made to work with 3920-bit rsa (of which i presume the useful message size to be 1872 bit, diana_coman plox to confirm maffs ?). such a packet has then 1696 bits spare for e and bullshit.
asciilifeform: would get much simpler coad (i.e. my orig. fixed frame) vs the extended one with moar moving parts. ☟︎
trinque: I'll make an archive of current state before blowtorching unrated and latter-of-doublerated
trinque: yep, I don't think so either. rater won't know where his rating went
trinque: I figure now's a good time to purge the unrated. for the few with ratings on both, I can merge to the nick with earliest rating, or drop.
diana_coman: mircea_popescu, I know, hence ox; ("at most calves" if BingoBoingo considers that they really are just boys)