Hide Idle (>14 d.) Chans
← 2018-10-13 | 2018-10-15 → ↓
trinque: http://btcbase.org/log/2018-10-13#1862196 << nope, haven't wrestled that pig
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: oh shit, mircea_popescu unrated me!
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: Mocky: didja read the libudp coad ?
Mocky is reading
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: as imho is proper, i.e. max frame size.
asciilifeform: all received packets are either valid (i.e. the one troo size) or invalid (if not).
asciilifeform: all buffers preallocated on stack , to the fixed size.
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.
asciilifeform: invariant.
Mocky: no, i get it
Mocky: it's a simplifying assumption that pays off with smooth transition between program and unix, when it holds. a tactical cut
asciilifeform: Mocky: hm?
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: they're a bus with 4 brake pedals.
asciilifeform: * i cut
asciilifeform: there's no reason os's udp should even fucking accept a sub-frame packet payload. or super-framed.
asciilifeform: 1572 bytes or go pound sand.
asciilifeform: lol 1472
asciilifeform: max ethernet frame - hdr len. nomoar, noless.
asciilifeform: nic sends 1500 frame always, recall.
asciilifeform: no matter what you ask for.
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?
asciilifeform: nic wont allow!
asciilifeform: nic sends and receives 1500 per frame! rtfm plz.
asciilifeform: ethernet spec. blame xerox , not asciilifeform
asciilifeform: yer still sending 1500, even if packet is nominal len 3.
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: Mocky: imho os should not perpetuate delusion.
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: Mocky: i was describing why i wrote it as i did.
asciilifeform: the physical nic ~always sends 1500!~ it also always receives 1500!!
asciilifeform: there are not actually variant packets on the wire!
asciilifeform: only fulls and frags, is all there is.
Mocky: I get it and I agree with you.
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 )
a111: Logged on 2018-10-14 05:09 Mocky: I get it and I agree with you.
asciilifeform: and if i were to, say, buffer packets, queue'em, always can say exactly how much space they will occupy.
asciilifeform: aite, i'ma bbl then, will not belabour the point.
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.
jurov: if you use hosts file: 161.0.121.248
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: packets even, right
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
bvt: hello
bvt: short writeup on what i did and why: http://p.bvulpes.com/pastes/GLopH/?raw=true
bvt: would love to hear your comments
ave1: diana_coman, I've updated the crc32 code! (still at the place)
ave1: Unfortunately is does not read as a straight long division anymore. But copying of the input array is avoided and
ave1: overall more efficient
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, thanks for the update, I'll look at it in a minute
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)
lobbesbot: lobbes: The operation succeeded.
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
billymg: which, spoiler alert, requires gpg2
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)
ave1: diana_coman, please try again...
asciilifeform: ave1: i still see old one
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: BingoBoingo: it'll pull in gpg2
asciilifeform: billymg: what you want is emerge --nodeps
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: asciilifeform: thanks, will try
billymg: build fails at configure: error: mcrypt.h not found. Please reinstall libmcrypt.
billymg: and the only version available is the one that wants new portage
billymg: would the next best bet be to install from source, outside of portage?
billymg: i was not, i was mostly going off http://blog.esthlos.com/mp-wp-setup/
billymg: lemme read that one and see if i missed something
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: ave1: ~nao~ i see new one
asciilifeform: BingoBoingo, mod6 : i'm thinking , i prolly oughta roll the mp-wp prereqs into the standard rk image, in the short term
asciilifeform: given as it seems that erry new user wants'em
asciilifeform: perhaps mp-wp itself, also.
asciilifeform: !Q later tell nicoleci http://btcbase.org/log/2018-10-14#1862287 << s/pint/point
a111: Logged on 2018-10-14 08:34 deedbot: http://bimbo.club/?p=52 << Bimbo.Club - TMSR Log Summary - 10/11/2018
lobbesbot: asciilifeform: The operation succeeded.
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
deedbot: lobbes rated auctionbot 1 << my bot
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
asciilifeform: don't emerge --sync, folx!!!
asciilifeform: the upstream is dead !
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: *disrecommend
asciilifeform: lobbes: would be great, ty
lobbes: o7
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: (obvs I'm about to ask for a wpmp ebuild, but one step at a time)
trinque: mod6: ha, coincidence.
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: !!up Mocky
deedbot: Mocky voiced for 30 minutes.
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
Mocky: ok
trinque: checking yesterday's backup.
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, now the sig doesn't verify??
diana_coman: fwiw gpg also complains that it's bad signature
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: ohai diana_coman
asciilifeform: diana_coman: i suspect that he forgot to refresh the seal , and that one's from the old ver
asciilifeform: !!up Mocky
deedbot: Mocky voiced for 30 minutes.
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)
ave1: resolve though
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
diana_coman: this is why I'm still skeptical re http://btcbase.org/log/2018-10-12#1861225
a111: Logged on 2018-10-12 18:14 diana_coman: and it fits perfectly the original idea of alternative, proper
diana_coman: asciilifeform, perhaps I'm missing something obvious re ^ ?
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
asciilifeform: iirc mircea_popescu prefers this style to the other
asciilifeform: lessee when he wakes up
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.
diana_coman: to my mind that's pretty much the reason, yes
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: ave1, thanks, it verifies fine now!
diana_coman: asciilifeform, trouble is - what do you do then when/if that tree gets reground?
diana_coman: basically you introduce tree dependencies?
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: you're stuck with it even now.
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: and yes they'd have to be reground regularly.
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 .
diana_coman: that actually makes sense
asciilifeform: it is painful, but prolly the Right Thing.
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.
asciilifeform: ave1: which method is this referring to ?
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: it'd defeat whole point of v.
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
ave1: then p3 touches A
asciilifeform: then p1, p2, p3 are alternative and mutually-exclusive pressable leaves.
asciilifeform: there is no ambiguity.
ave1: sorry p3 touches the A as it is after p1
ave1: so p1 -> p3 intended
ave1: but p2 -> p3 also possible it seems to me
ave1: the vpatches are checked on the sha512/keccak sums of the files
asciilifeform: trinque & mircea_popescu specifically introduces manifests to prevent this scenario.
asciilifeform: ( previously it was possible to arrive at it by accident )
ave1: yes, I know, but you asked about the senario; no published vtron permitted...
asciilifeform: aa i see what ave1 meant
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.
ave1: Whis -> This, threes -> trees
asciilifeform: this is the Right Thing, i.e. if you want a variant to exist, you gotta maintain it.
ave1: yes
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: ( tho expensive. )
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: it destroyed tracks.
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: !!reputation
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: Mocky: herp, wrong db. it's there now.
trinque: !!reputation
trinque: !!reputation Mocky
Mocky: thx!
trinque: got the note back in there now too
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: wot.deedbot.org will update too before long
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.
trinque: congrats!
asciilifeform: i'd eventually like to be rid of asdf tho.
asciilifeform: it's pretty sad.
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
asciilifeform: ty ben_vulpes
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.
asciilifeform bbl,meat
deedbot: http://blog.esthlos.com/esthlos-v-release-with-working-keccak/ << esthlos - esthlos-v: Release with Working Keccak
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
trinque: billymg: hold onto that new ebuild for cuntoo.
trinque: we'll need it for a wpmp ebuild
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
billymg: trinque: will do
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))
billymg: BingoBoingo: ah, that's good to know
BingoBoingo: billymg: Have fun
lobbes: ^^ auctionbot (with reverse auction functionality) is now live
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
lobbes bbl
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.
phf: http://btcbase.org/log/2018-10-13#1862183 << no, i don't use portability packages in my own code (they are the hole through which the darkness comes), and when something pulls it as a dependency, it comes from quicklisp
a111: Logged on 2018-10-13 23:31 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...
phf: out of curiousity i went through the log, and bordeaux-threads had that bt nickname pretty much since creation, in 2006
phf: (btcbase uses 0.8.5, though i might have an older version somewhere on backup drives)
asciilifeform: phf: imho it is retarded that packages can conflict
asciilifeform: i dun see why it ougta be possible, period
asciilifeform: ( and afaik in ada -- it aint )
asciilifeform: http://btcbase.org/log/2018-10-15#1862519 << i dun want to marry sbcl.. is this so much to ask
a111: Logged on 2018-10-15 00:17 phf: http://btcbase.org/log/2018-10-13#1862183 << no, i don't use portability packages in my own code (they are the hole through which the darkness comes), and when something pulls it as a dependency, it comes from quicklisp
asciilifeform: ( prolly The Right Thing then is to write own compat layers. for errything. but only 2 hands,sadly )
phf: asciilifeform: well, a portability layer is the ultimate ifdef, and in this case worse written by somebody else
asciilifeform: that, it is
phf: one of the major wtfs when reading asdf code, is that when all the ifdef's fall through, hte system falls back to some seriously questionable solutions, like shelling out to unix level with elaborate commands (i don't remember the example, but it's almost like "mkdir {} && cd ..." type stuff)
asciilifeform: it's actually one of the reasons i haven't ever finished rewrite of phuctor in cl. erry time i sat down to do it, barfed on one of these things
phf: but you would never know, because in sbcl it generally does the right thing
asciilifeform: right, they're mostly skins on sbcl, to the extent they work at all
phf: well, after reading the CADR documentation, source code and generally spending more time on a lisp machine, i realized that modern common lisp is a cargo cult. i'm not sure how naggum didn't see it, but possibly because his lisp was emacs/cmucl/franz
asciilifeform: aha, he had his paid allegro
phf: it's a compatability layer between lisp machines, and as such provides a minimum of coverage of common functionality.
asciilifeform: and it , afaik, worked 'like white man's tech' or near.
asciilifeform: my impression was that allegro did 'all them things not in the standard' and actually did them well.
asciilifeform: so he never had to eat the compat layer liquishit.
phf: yeah, pretty much. a totally different experience from, say, sbcl, and a lot closer to a real lisp machine too. comes with all the things builtin, so you never really need to touch outside world
asciilifeform: prolly the eventual Right Thing will be when we proclaim a republican cltron and start massaging it to eventually climb to that level.
phf: right
asciilifeform: and sbcl aint it. i'd prefer something like kyoto, or which ever was the absolute shortest that implemented whole standard, for starting point
phf: i suspect you might discover it to be same kind of situation as tinyscheme
asciilifeform: actually looking at my notes from ages past, i did, and did.
asciilifeform: would like to find something actually readable, at least, if not buildable-on.
asciilifeform: but even this may be too much to hope.
asciilifeform: phf: context : i was baking a noad walker / torturer, orig in python, little thing, thought it would be doable in a day or 2; then found that mass of prb etc all break protocol in 9000 interesting ways, an extra byte here an' there, and realized that it aint doable without adult condition handling/restarts, which means cl.
phf: aah
phf: yeah, i wrote a small subset of bitcoin protocol in lisp, but rolled my own binary types. i think i can ask for version, and i can also ask for peers, and i started on getblock functionality..
asciilifeform: that's approx where i left off, aha
asciilifeform: worx ok with trb. but heathens do all kinds of weird things, throw up various garbage in place of e.g. getaddr answer
asciilifeform: or disconnect in the middle of things, etc
asciilifeform: phf: i was aiming for 3 basic things : 1) recursively getaddr entire reachable btc net, perhaps erry hour or so 2) find trb-compat (i.e. 'services' == 1 ) non-pseudos (i.e. if i pull block hash out of a hat, he quickly gives correct block) and eventually 3) get inv's and monitor tx propagations.
asciilifeform: the heathen node-viewing www's systematically lie, e.g. conceal 'too old' clients , present fucking pseudos as if they were actual nodes, and commit other war crimes
asciilifeform: i'd like a (ideally real-time) picture of the actual network.
asciilifeform: this line of thought was prompted by my 'trb observatory', which has uncovered a number of 'mpb'-style nodes, i.e. trb-like but not presenting 'modern' vers and therefore invisible from heathen www indices
phf: i wonder what sort of technology those heathen node walkers use, i.e. if it's a patched up bitcoin client, or if they have own protocol parsers. seems like too much serious know how for the later
asciilifeform: phf: hell knows, prolly kilometres of java
asciilifeform: written in bangalore
asciilifeform: with 9000-deep of-else'en.
asciilifeform: phf: essence of hypothesis, is that the ~actual~ bitcoin network looks nothing at all like what 'nodes.io' or other heathen scamola, try to pass off
asciilifeform: for instance, http://btcbase.org/log/2018-10-10#1859945 may or may not be factual
a111: Logged on 2018-10-10 01:22 asciilifeform: https://archive.is/ltRHd << per same, of the 4 public noadez in BingoBoingostan, 3 are in pizarro
asciilifeform: and i'd like to know .
asciilifeform: and really, all of romania is solid prb ??
asciilifeform: difficult to believe.
BingoBoingo: asciilifeform: I have come around to thinking of the process that leads to this "wished helplessness"
asciilifeform: BingoBoingo: hm?
phf: lol, i accidentally pasted that archive url without the d, https://archive.is/ltRH
BingoBoingo: asciilifeform: Bingostan having 4 public nodes
asciilifeform: ahahahahaha phf
asciilifeform: i wonder what other spamola lurks.
BingoBoingo: "wished helplessness" goes with hallucinated optionality
phf: i was like "wtf, kind of shit ascii accidentally pasted instead of the real url" :p
asciilifeform: BingoBoingo: point was, the observation came from heathen site known to systematically lie
asciilifeform: phf: lol
asciilifeform: for non-ru folx, procrusted link goes to a thing re an anti-faggotry protest in ukrlandia
BingoBoingo: asciilifeform: Well, if they wish hard enough they don't have to not lie
BingoBoingo: Who is going to check their work?
asciilifeform: BingoBoingo: it's an empty niche, sorta like phuctor's pre-phuctor
asciilifeform: plenty of scamola artists who supposedly catalogue nodes, but all with 9000 seekrit filters, and present liquishit as if it were noad
BingoBoingo: asciilifeform: Right, it is a niggers.txt.xls document
phf: so it looks like bvt is correct, there's no way to make ada's Create throw an exception if the file already exists
BingoBoingo: Meanwhile, in the meme front: http://archive.is/vExuu
phf: is it the NPC meme?
BingoBoingo: phf: it is the NPC meme vs the Russian bot meme
phf: we're way down the rabbit hole here
asciilifeform: BingoBoingo: lol!! where's this one from
BingoBoingo: asciilifeform: Found on the return of kink guy's forum. Apparently was originally found on twitter.
BingoBoingo: Authorship unknown.
ben_vulpes: mod6 asciilifeform BingoBoingo: the remaining stateside fuckgoats are packed in a specific box that i will relocate with my person.
BingoBoingo: ben_vulpes: Sweet
phf: bvt: your patch has "Binary files..." at the very end of it. i assume it wasn't made with vdiff
phf: !Qlater bvt ^
phf: !Q later tell bvt ^^
lobbesbot: phf: The operation succeeded.
phf: the other thing, and that's somewhat of a personal preference, i think Create_Temporary_File should either act identical to create or be called something else. right now it clashes with ada's naming convention
phf: (when i proposed the name i was thinking that it will be a wrapper around http://www.ada-auth.org/standards/rm12_w_tc1/html/RM-A-8-1.html#p6
phf: but without the name, so you call it, and you get an open file right away, rather than dragging around a useless name)
phf: oh i guess i see why that would be tricky, because of the specialization. i don't know enough ada yet to know how to fix that... perhaps just renaming it to Temporary_File is sufficient
phf: !!key bvt
phf: i like how C 2012 standard says that x flag works "to the extent that the underlying system supports exclusivity". of course no indication when it doesn't..
phf: diana_coman: i've updated eucrypt to keccak, i also added ave1's patch there. also brought udp up to date.
phf: the graph appears to be complete, and the project also presses, thank you for jumping through all the hoops!
deedbot: http://bingology.net/2018/10/14/that-one-agricultural-product-and-uruguay/ << Bingology - BingoBoingo's Blog - That One Agricultural Product And Uruguay
asciilifeform: phf: in other lulz, yet another ivory on lulzbay
asciilifeform: ( from same place as ~always )
asciilifeform: lol apparently ~1h left on it
phf: the gift that keeps on giving
asciilifeform: phf: i'm still waiting for those archaeological finds phf hinted at 2y ago...
phf: asciilifeform: i actually forgot! i'm swamped right now, but can you remind me again in about two weeks, i have a thing for you from the dig that will help with the little piece of silicon you have
asciilifeform: ty phf, will remind.
mircea_popescu: http://btcbase.org/log/2018-10-14#1862213 << im not entertaining the nonsense. will not make different packets of very strictly disjunct content same size to humor software engineer naivitees masquerading as prime principles.
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
mircea_popescu: there's exactly nothing similar between rsa packet and serpent packet. for the same money could ask to have busses and flour delivered in single container.
asciilifeform: funnily enuff , i have 2L bottles of both water and kerosene, dun rely on purely size to distinguish. but mircea_popescu can write his proggy however he wants.
mircea_popescu: what, you taste first each time you open bottle ?
asciilifeform: labels .
asciilifeform: ( and smell, lol, but that comes 2nd )
mircea_popescu: http://btcbase.org/log/2018-10-14#1862282 << nah, you'd have two threads running, one taking packets type 1 and the other taking packets type 2. if it's expedient to use 2 ports, use 2 ports, np.
a111: Logged on 2018-10-14 07:49 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
mircea_popescu: asciilifeform there's no such thing as label in context.
asciilifeform: nah you have it, 2 ports.
mircea_popescu: in fact, this is precisely what you're objecting to, "why should kerosene bottle have a slightly taller red cap, should have exact same cap as water bottle!"
asciilifeform: sorta makes the thread redundant, as diana_coman pointed out, you can still use fixed receivers.
mircea_popescu: asciilifeform not redundant because the rsa processor is "best effort", ie, only goes if there's spacetime in machine
asciilifeform: well yes, it's a separate process, you nice 19 it
asciilifeform: loox simple enuff
mircea_popescu: http://btcbase.org/log/2018-10-14#1862284 << yep, this was precisely the idea.
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)
mircea_popescu: asciilifeform i possibly dun wanna drag the nice thing into it, but i dunno, way too early to optimize this partuclar pile.
asciilifeform doesn't disagree
mircea_popescu: bvt "Ada exposes no functions that have 'exclusive open' semantics, so I imported C
mircea_popescu: functions to make this functionality available." << im not so crazy about this approach, but hey. if it links it links.
asciilifeform: and if even also runs, even better!1
mircea_popescu: http://btcbase.org/log/2018-10-14#1862295 << bootstrapping problem, he has to get vtools compiled to press mp-wp to install it on the rk he already bought.
a111: Logged on 2018-10-14 11:56 diana_coman: bvt, get yourself a pizarro shared account and start your blog there precisely with those pastes, what's keeping you?
mircea_popescu: http://btcbase.org/log/2018-10-14#1862300 << o.O that was quicker than expected...
a111: Logged on 2018-10-14 12:55 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!
asciilifeform: mircea_popescu: i'ma switch to issuing cuntoo for new pilot rk folx as soon as trinque is finished birthing it
asciilifeform: so nomoar 'with what do i press vtron' , 'where is php', etc
mircea_popescu: does it have either vtools or mp-wp ?
asciilifeform: by all rights gotta
asciilifeform: at the very least vtools
asciilifeform: ( sorta whole idea behind cuntoo )
a111: Logged on 2018-10-14 20:41 trinque: billymg: hold onto that new ebuild for cuntoo.
trinque: asciilifeform: what's left is finishing ebuilding-up phf's vtools, then release
phf: trinque: are you waiting on delete/rename or you have your own things to work on?
trinque: not blocked on anything afaik, improvements to vtools can come in as another patch for the ebuild tree
phf: ok, good
phf: i don't think i'll be able to cut rename tonight, and then i'll be busy until friday, though will try to steal an hour here and there
mircea_popescu has been watching nude girlies dancing with mops and detailing floors on all fours (+high heels! who else has platform houseshoes?!) all day, is in a pretty great mood.
mircea_popescu: meanwhile in lulz, https://elonm.ru/
a111: Logged on 2018-10-14 15:08 lobbes: "castle-only" may be the way to go anyways; I'm not sure #trilema even needs the auctionbot to sit in here
a111: Logged on 2018-10-14 15:29 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
mircea_popescu: !!rated mocky
deedbot: mircea_popescu rated mocky 3 at 2018/10/10 16:39:15 << Mocky Habeeb. Wrote a book on Amazon DB ; works for infraWise (which is pretty lulzy, but don't hold it against him).
mircea_popescu: !#s "!!rate Mocky"
asciilifeform: mircea_popescu: trinque fixed
mircea_popescu: confirmed!
mircea_popescu: http://btcbase.org/log/2018-10-14#1862364 << this is important. ave1 you understand the difference ?
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
mircea_popescu: http://btcbase.org/log/2018-10-14#1862386 << not at all! there's two possible ways to implement crc32 : with lookup tables, and with plain division. these are mutually exclusive. type 1 is faster, and therefore mainline. type 2 is smaller, and therefore of interest in certain contexts. therefore, at leaf=n, one has to chose : either n+1 type 1, or else n+1 type 2.
a111: Logged on 2018-10-14 16:11 diana_coman: ah, you mean that the only way to do this is to take crc32 out of eucrypt tree?
mircea_popescu: the leaves downstream from EACH n1 needn't be identical, nor needn't be different. in effect, the tree now has TWO groups of maintainers : those who maintain type 2 tree, for embeds, will not === those who maintain type 1 tree, for general use.
mircea_popescu: IF the groups ever diverge absolutely, they MIGHT eventually re-genesis the thing, making all leaves 1...n into a unified genesis and continuing from there.
mircea_popescu: but while there's overlap of people contributing to both type 1 and type 2 branches, it's more likely the situation will continue unground.
mircea_popescu: in any case, type1 might get i dunno, later-patch-taking-advantage-of-ddram whereas type 2 might get later-patch-needed-for-old-arms etc.
mircea_popescu: is any of this unclear at all ?
mircea_popescu: http://btcbase.org/log/2018-10-14#1862391 << i have no idea what you mean by this "taking out" expression.
a111: Logged on 2018-10-14 16:13 diana_coman: I honestly don't quite see the point of taking crc32 out for instance
← 2018-10-13 | 2018-10-15 → ↑
Random(trilema) | Download hourly DB snapshot | Get Source Code