log☇︎
▁▁▁▁▁▁▁▁▁▁▁▁⏐︎▁▁▁▁▂▁▂█▂▁▁▁ 5591
asciilifeform finally grunted out & typeset new proof for ch14. nao for measure-77-times-cut-1ce..
feedbot: http://bimbo.club/?p=104 << Bimbo.Club -- TMSR Log Summary - 11/21/2018
diana_coman: !!rated douchebag
deedbot: diana_coman has not rated douchebag.
diana_coman: !v 26D6263DD1CF71B77F9F08B00E556AFD5151F70108D684D43B134054F28A21FF
diana_coman: !!v 26D6263DD1CF71B77F9F08B00E556AFD5151F70108D684D43B134054F28A21FF
deedbot: diana_coman rated douchebag -5 << obstinate time waster
diana_coman: trinque, is the !!ledger cmd not working? deedbot seems to ignore it (didn't yet reply to one sent ~30 minutes ago although it replied to the !!rate meanwhile)
diana_coman: lmao
phf: the people must know!
diana_coman: I'll consider it as part of my fanbase as per http://btcbase.org/log/2018-12-11#1879491 ☝︎
a111: Logged on 2018-12-11 00:17 diana_coman: oh, fanbase,pfuai
diana_coman: I lost count how many times I told him to go & exploit but apparently I don't know anything about modern vulnerabilities that can't be exploited
phf: you don't understand it's a level 3 bounty, it's supposed to net him 3042 hckr.io points, and a payout of $27
diana_coman: quite; tbh it merges into a sort of "code political correctness" model to me: basically the effect does not matter, but if you use the "wrong" and unapproved formulation then it's BAD; and it should be reported; and it matters!
asciilifeform: holyfuq, that fella
asciilifeform: http://p.bvulpes.com/pastes/XAWtr/?raw=true << selfsame lulzspamola preserved for l0gz.
diana_coman: eh, he prolly found therefore a vulnerability in deedbot too!! look, he can still speak even if no voice
mircea_popescu: so in the end the understanding is these bright young minds aspiring to a "computer security career" are the period politruks, looking to help construct a social narrative consensus by policing [the relevant forms of] speech ?
asciilifeform: !Q later tell ben_vulpes canhaz logbot again in #a plox ? ty
lobbesbot: asciilifeform: The operation succeeded.
mircea_popescu: this notion is so indigestible to me... ☟︎
asciilifeform: mircea_popescu: my current impression is that ( possibly unlike the 'sjw chix' ) the 'bright young' douchebags dun even bother to consider the political substance of the oddball gymnastics they participate in, but see moar as simple mechanical motion, like plowing field
mircea_popescu: this is how soviet-hero-pioneer worked, also.
asciilifeform: aha
mircea_popescu: the guy immortalized in 1984, "turned in uncle" etc... that's now a work of fiction. by then, had 2-3 decade history behind.
asciilifeform: carefully avoiding thought is simplest way not to 'thoughtcrime'
asciilifeform: fwiw i have nfi why d00d is banging on ~this~ door, there's 9000 others where could bang
mircea_popescu: there's a good match between the [biology-driven] formalist approach of children, "act like adult become adult" and the purely formalist approach to the world of the superificial mental systems typical of naggum's "the meaningless lives of those who do not wish to have any meaning to their lives".
mircea_popescu: asciilifeform because this is the only door that ~means something~.
asciilifeform: the latter is exactly the former, but perma-wedged -- rather like dwarfism
mircea_popescu: i'm of the same mind.
mircea_popescu: but yes, in terms of ye olde "Wäre es da Nicht doch einfacher, die Regierung Löste das Volk auf und Wählte ein anderes?", 15yo soviet pioneer ~only true and proper citizen of soviet state.
mircea_popescu: a point not lost on the very soviet state in question.
asciilifeform: eh even 15yos mocked the crapola. e.g. the Official 'Как повяжешь галстук, Береги его: Он ведь с красным знаменем. Цвета одного' turned into '...он ведь с носом пьяницы цвета одного' and even '...Есть на чем повеситься, В случае - чего'
mircea_popescu: the brighter ones lol.
mircea_popescu: not the normies.
asciilifeform: ( there's ~infinitely many of these, for aficionado )
BingoBoingo: Maybe the kid just needs a (((packing))) peanut internship with avik?
asciilifeform: mircea_popescu: https://archive.is/D8JfE << orig form
BingoBoingo: The pair can take turns drugging and appropriating each other, perhaps this even occupies them enough to constrain their external actions by occupying all their time
BingoBoingo: Of course there is the mid-long term hazard the kid outlives avik and evangalizes the predatory stupids down the line
trinque: diana_coman: works for me over here. at what time were you trying?
asciilifeform: mircea_popescu: the 'normies', to the great wrath (and eventual demise) of that empire, imitated the 'bright'
diana_coman: trinque, at ~11 and then later at 11:26; in between those it worked perfectly fine to rate
diana_coman: hm, now it answers !!ledger though so I guess it was a hiccup at that time
diana_coman: http://btcbase.org/log/2018-12-13#1880441 -> as in "can't stand it" or "can't make sense of it"? ☝︎
a111: Logged on 2018-12-13 15:58 mircea_popescu: this notion is so indigestible to me...
diana_coman: at any rate, the whole "security testing" seems to be "check if they do x and y and z if they don't do one of them then vulnerability!!!"; no context, no interest for what the thing is or in what context it is used or what it stands for, nothing more than "did they say tovarase ceausescu x times per page?"
trinque: diana_coman: wallet's a different service that connects to the other bot for IRC. I'll take a look when I get a moment. I wager the internet connection between the two went down.
feedbot: http://ossasepia.com/2018/12/13/smg-comms-chapter-12-thread-safe-queues/ << Ossasepia -- SMG Comms Chapter 12: Thread-Safe Queues
diana_coman: trinque, ah, that would explain it yes; at any rate it's no rush at all and no real trouble caused
asciilifeform: diana_coman: i could've sworn that the standard provided queues
asciilifeform: ( did they end up having secondarystackism glued in, or what was it )
diana_coman: asciilifeform, hm, I guess I need to search more and see exactly what it provides then
asciilifeform: diana_coman: i haven't tried'em myself
asciilifeform: but the 2012 rationale b00k seems to contain'em
diana_coman: iirc there is some synchronized queue interface and container but it seemed overkill
diana_coman: I'll read in more detail again at any rate, won't hurt
asciilifeform: in other lulz, asciilifeform finally bought that bolix
asciilifeform: ( and funnily enuff, that thing was not even the highest-priced ancient desktop comp on lulzbay -- for mysterious reasons, crapple 'lisa' sells for e.g. 70k u.s... )
diana_coman: !!rated juliankunkel
deedbot: diana_coman rated juliankunkel 2 at 2018/12/13 17:48:15 << CS Lecturer at Reading Uni, invited me to give a Bitcoin talk.
asciilifeform: oh hey
diana_coman: juliankunkel, try !!up now
asciilifeform: mircea_popescu: i'ma try an' bribe a dentist to take those xray pics, seems like cheapest pill.
asciilifeform: ( might have to soft-stitch the shots, dental film aint quite large enuff )
asciilifeform: cuz 'industry' people apparently were dropped by their mothers as children, e.g. one http://btcbase.org/log/2018-12-12#1879986 , and 3 others no reply at all ( they dun like money ? ) ☝︎
a111: Logged on 2018-12-12 16:14 asciilifeform: meanwhile, in other tardations, re http://btcbase.org/log/2018-12-11#1879893 >> the radiographers all seem to want 2-3k. which is lulzy, cuz for half of that one can simply buy the machine..
diana_coman: oh hey, welcome juliankunkel !
juliankunkel: hi all. Interesting stuff with your WOT and game. ☟︎
diana_coman: since Julian was at my talk on Monday, he now knows something about WoT :D But more to the point: he is so far the one and only Uni lecturer who wants to understand this bitcoin thing as opposed to just talk about it. So I'm quite happy he's here.
asciilifeform: welcome juliankunkel
asciilifeform: juliankunkel: you will find the logs ( http://btcbase.org/log/ ) to be of interest
BingoBoingo: Welcome
juliankunkel: asciilifeform: thx, I will have a look; I'm looking a bit round here.
asciilifeform: juliankunkel: as a maths fella, you may also find 'ffa' ( asciilifeform's current item, http://www.loper-os.org/?cat=49 ) interesting, world's only sidechannelism-proof crypto lib, ~80% done
juliankunkel: side-channel attacks seem fun; how much longer you'd expect until it works and is proof?
asciilifeform: juliankunkel: it's 'proof' now. most of what remains is performance opt.
asciilifeform: ( i.e. starting with ch.6 can already rsa )
asciilifeform: ( see ch.1 , http://www.loper-os.org/?p=1913#selection-7.0-151.23 , re: what thing's made of and why )
juliankunkel: asciilifeform: interesting stuff. going home now ; see you!
asciilifeform: laters.
mircea_popescu: diana_coman as in "the only possible statement of mp's ultimate optimism will be centered around a refusal to believe such, for lack of any other available centers."
asciilifeform: guten tag mircea_popescu !
mircea_popescu: hola.
mircea_popescu: if you go the dentist route, make sure you check the rated power. plenty of the last gen things so low power, can't see through tin foil.
asciilifeform: mircea_popescu: 10 or so KeV oughta suffice, by my napkin reckoning
mircea_popescu: they measure in microsieverts (ie, grays) for some reason. but anyway, the latest ones do like 12 uSv
asciilifeform: the board has 1 component side ( and 2 track sides, 0 sandwich, 1980s recall ) , the item of interest is the track side obscured by the components ( all through-holes ) .
mircea_popescu: (background is about 2 uSv, for comparison)
asciilifeform: so it'll be a straight subtraction ( of the visible bottom tracks ) .
mircea_popescu: asciilifeform there's no metal layer in between ?
asciilifeform: nope.
asciilifeform: it's a board of same type as FG ( but 100% through-hole )
mircea_popescu: ah ah. well ok.
asciilifeform: the 1 item of concern is heatsink on the cpu, i'ma pull cpu out prior to the magic moment
asciilifeform: xray i expect is the 'easy' part. the real bitch will be the GALs
asciilifeform: a coupla of them are of the kind that have flipflops ( so not susceptible to pure combinatorial brute )
asciilifeform: if the orig maker didn't bother to set the 'no read' bit, it'll be 9000x easier (whether so, not known yet, afaik nobody's ever fessed up to so much as trying)
mircea_popescu: i can see it.
asciilifeform: 1st logical step , on the magic day when asciilifeform has both pcb layout and GAL contents nailed down, will prolly be to make an exact physical copy of the board. ☟︎
asciilifeform: ( then can sell the original back to the wanker people )
mircea_popescu: http://btcbase.org/log/2018-12-13#1880490 << you ever read http://trilema.com/2014/what-the-wot-is-for-how-it-works-and-how-to-use-it/ then ? ☝︎
a111: Logged on 2018-12-13 17:52 juliankunkel: hi all. Interesting stuff with your WOT and game.
mircea_popescu: asciilifeform not a bad idea, at that.
asciilifeform: phf may find interesting , that this 'macivory' happens to be the one with no weitek. which normally would be a sad, but in my case is gold, from my pov the weitek is just extra crud to emulate
asciilifeform: let weitekism run in soft that bolix helpfully wrote, at fpga speed
asciilifeform: ( the crapple box the thing sits in, incidentally, is about 100bux on the junk markets, quite handily )
asciilifeform: 1 of those things that was approx on par with 'amiga'
feedbot: http://qntra.net/2018/12/facial-recognition-being-used-to-screen-for-stalkers-at-blondie-concerts/ << Qntra -- Facial Recognition Being Used To Screen For Stalkers At Blondie Concerts
asciilifeform miser, prolly oughta have gone to dks and bought 1 of these aeons ago. hell, the comp i'm sitting on nao cost > than the thing
asciilifeform: mircea_popescu: 'physical copy' + place to put logic analyzer sausage, if not obv. earlier (the orig item is pretty cramped)
mircea_popescu: right.
asciilifeform: really a 'sapper errs once' sorta job, if i zap so much as 1 GAL i'ma need whole new orchestra again.
asciilifeform: and whoknows, perhaps the folx who attempted this in the past will finally pull their heads out of arse and come out into the light
asciilifeform: ( not banking on it tho, i suspect their heads have fully tissue grafted into arse at this pt )
asciilifeform: while on subj, from the extant photo i already can see that ~90% of the board surface is sram/dram, each of which respectively would fit on a '90s-era 5v 1chip
mircea_popescu: should be fun to see how well "magical tech" works if plugged into LARGE ram.
asciilifeform: i dun think it has any extra addr lines
mircea_popescu: i have a lingering suspicion we'd like x86 stack a lot better if memory had stayed the size it was WHEN THE DAMNED THING WAS DESIGNED
asciilifeform: so will be same thing, only less mass.
asciilifeform: mircea_popescu: x86 was ~ok when 64k (i.e. prior to introducing 'segments' )
mircea_popescu: yes, but the 1st step in the http://btcbase.org/log/2018-12-11#1879649 line will be... "just like bolix but with 1024x the ram" ☝︎
a111: Logged on 2018-12-11 17:34 mircea_popescu: then ~lone man~ of wanna-be rus' yellow man copied item.
mircea_popescu: asciilifeform aha!
asciilifeform: re bolix, iirc of the 36bit, 28 were available for addressing, so theoretically can 256MB.
asciilifeform: ( i dun recall if the 'xl' actually could be fed 256MB, possibly phf knows )
mircea_popescu: can has 64GB ram on the cheap now. considering what period pricing was like, 2020 reconstructed bolix'd better have 1TB ram.
asciilifeform: reconstructed can have whatever one likes, that aint the tricky bit.
mircea_popescu: we'll see how this goes.
asciilifeform: tricky bit is to turn thing from 'martian artifact' back into bits.
asciilifeform: so folx can 'you wouldn't download a car!111' 'fuck you, would if i could' (tm)
mircea_popescu: yes, but n+1 step there is... "well, bolix v2020 comes with 1tb ram. which it uses."
asciilifeform: mircea_popescu: presently can't think of any reason not to put whole effort, chunk by chunk, on www
mircea_popescu: me either.
asciilifeform: ( witness, 2 yrs of FG and no 'chinese copy' )
mircea_popescu: meanwhile, let's hijack this a little for some s.mg discussion.
asciilifeform: yea subj is tapped out till i get the box in hands
mircea_popescu: so, i hear from cto the comms spec's mostly implemented. now, we're at the point where we wanna make a rsa and a serpent sender.
asciilifeform: mircea_popescu: iirc diana_coman wrote one 3wk ago
mircea_popescu: there's two evident ways to go about this : either have these together in a single chunk that owns a socket ; or else have them independent, in which case what, they share a socket ? they each get a socket ?
mircea_popescu: even go the distance of keeping a task manager to keep spawning them, and giving them sockets ?
diana_coman: asciilifeform, lol, no, the point there is the sender/receiver layer of a eulora app essentially
asciilifeform: mircea_popescu: with diana_coman's variant of my udp routine, you dun need >1 socket to send
asciilifeform: 1 socket can send whatever one likes
mircea_popescu: asciilifeform suppose you're on a multi-core cpu, suppose the socket's not filled but the sender is.
mircea_popescu: spawning another one then makes sense.
diana_coman: asciilifeform, you do need because 2 different sizes i.e. 2 different udp lib types essentially
mircea_popescu: that also.
mircea_popescu: diana_coman thinking of it : the ~server~ very likely wants a lot of sockets ; strictly because talking to multiple clients at same time.
asciilifeform: mircea_popescu, diana_coman : you have 1 thread, that monopolizes socket, and fetches from a semaphoric queue ( diana_coman posted such a queue today ). other threads can put whatever on queue, and sender sends.
asciilifeform: you dun need a socket per client in udpism
mircea_popescu: need nothing. does it help to have ?
asciilifeform: imho not.
mircea_popescu: any specifiable meat on that h ?
asciilifeform: unix is retarded : limits total # of open sockets. so having >1 not only imposes overhead without achieving anyffing, but will eventually hit ceiling.
diana_coman: asciilifeform, the q is basically: how many messages/sec clogs the socket essentially
mircea_popescu: diana_coman the problem's rather, two sockets will possibly clog for fever total msg/sec than one.
asciilifeform: diana_coman: you're cpu bound ( serpent ) so you likely will never hit the bandwidth bound. so the udpgrams will go in ~realtime.
asciilifeform: no 'clog'
asciilifeform: recall also that your udp sender is blocking
diana_coman: asciilifeform, I don't follow - 1mn clients can send 1mn datagrams to server, what has serpent to do ?
asciilifeform: therefore the call to it won't return until the packet has left the house
mircea_popescu: diana_coman does it then make sense to have a process that has a socket open and handles the serpent queue, and one proces with a different socket open handling the rsa queue (with a view that these :6666 and :6667 ports then get moved to separate machines if need be) ?
diana_coman: mircea_popescu, that was my current idea: 2 sockets, one for rsa and one for serpent, with different ports too
mircea_popescu: defo diff ports.
asciilifeform: it dun make sense, in that light, 'clog' -- all that happens if waiting on nic, is that the sender thread empties its queue slower.
diana_coman: receiver just grabs from udp lib and drops into a queue
mircea_popescu: whole reason to even do it liek this so client can separate its traffic
diana_coman: doesn't even bother to decrypt or whatnot because anyway it has no info as to keys and all that
asciilifeform: mircea_popescu: if you have 2 sockets, can even use orig variant of udptron.
asciilifeform: ( i.e. without the variant packet widths . instantiate one with rsa-width buffer, and 1 w/ serp.width )
diana_coman: asciilifeform, I made it generic so I don't have to copy/paste code just for different const
mircea_popescu: diana_coman the expectation that serpenting rather than netsending will be the processing bottleneck is not unfounded, imo.
asciilifeform: mircea_popescu: even on hypothetical box with 9000 cpus, still no 'clogs', all you get is that the sender waits on the nic. queue cannot overflow cuz your protocol is synchronous ( server dun send anyffing to client unless asked )
diana_coman: well yes, as long as sender/receiver are ultra-thin aka only from/to queue to/from udp lib then no clog expected at socket
mircea_popescu: "sender waits on nic" is what is meant by clog.
diana_coman: well, except for the case where 1mn simultaneous clients I suppose but possibly that gets lost before even reaching the nic
asciilifeform: mircea_popescu: i thought your orig queue was specifically re clog (impedance mismatch) in the unix ip stack
mircea_popescu: diana_coman conversely, if they're that thin why do they exist. ☟︎
diana_coman: that's what I've been going round in for most of today!!
asciilifeform: diana_coman: per my current understanding of mircea_popescu's protocol, it is immune to packet loss (i.e. client will retry)
asciilifeform: i.e. if client's cord gets pulled, from his pov he will stall, from server's , his character is standing still, and when plugs back in, will live again
diana_coman: asciilifeform, yes; the idea though was not to lose the packets that made it to the nic though aka because server busy sort of thing
mircea_popescu: diana_coman to proceed logically : 1. it is factual that the expected bottleneck reasonably is de-serpenting. 2. everything-else then may safely be non-threaded. 3. do we actually want to thread the serpenting part ?
diana_coman: 1. expected bottleneck is message processing: encrypting/decrypting sounds most likely but in principle whatever further processing since not even specified yet fully! 2. the everything else is raw udp (aka udp lib) and feeding it/reading from it aka those would be sender/receivers
diana_coman: 3. I think that's to be a dynamic thing basically aka at a higher level server looks and if it needs to, it creates more workers to process those messages accumulating there
mircea_popescu: anyway, i have an answer re http://btcbase.org/log/2018-12-13#1880600 : because this way you take the queue out of the ip stack's 64kb into the 1tb of ram or w/e you use. ☝︎
a111: Logged on 2018-12-13 19:29 mircea_popescu: diana_coman conversely, if they're that thin why do they exist.
diana_coman: aha
asciilifeform: mircea_popescu: in re 'synchronous', it is my understanding that client is not permitted to send a packet unless the n-1'st has been ack'd
asciilifeform: so server cannot be 'swamped'
diana_coman: asciilifeform, well, client CAN send
mircea_popescu: asciilifeform im not strictly aware of this. whence the notion ?
diana_coman: what is there to stop it
asciilifeform: diana_coman: can send, but then he's a spammer, not client, and gets kicked
mircea_popescu: diana_coman so then : a) thin wrappers mosrtly to rescue the queue from ip stack into ram ; b) threaded workers later, which may include but will likely not be limited to, specialist decipherers.
mircea_popescu: that leave anything hanging ?
asciilifeform: (i.e. added to the kicklist, which rejects packet in O(n log N) where N is number of idjits )
asciilifeform: mircea_popescu: threaded worker 'rescuing from nic' into queue, and threaded eaters eating from same, is how asciilifeform baked prototype gossip thing from which udplib taken
asciilifeform: so imho a++
asciilifeform: ( asciilifeform's item defo not adult grade, however )
diana_coman: mircea_popescu, works, it's a clear decision at least
mircea_popescu: weren;'t you arguing asecond ago the rescuing from nic needn't be threaded ?
asciilifeform: mircea_popescu: 1 thread for tx, 1 for rx
asciilifeform: ( rather than per-user )
mircea_popescu: ah. "threaded" here means, "task manager spawns processes". think how apache server works.
mircea_popescu: imo venerable, successful, and mandatory to copy mechanism./
diana_coman: the one thing hanging would be re errors I suppose
asciilifeform: mircea_popescu phrased it correctly earlier, point is to remove from ip stack the job of queueing
mircea_popescu: diana_coman what errors ?
diana_coman: what should sender/receiver do on udp lib barf
asciilifeform: diana_coman: what sorta errors ? packet is either legit or not, neh
mircea_popescu: udp lib can barf ?!
asciilifeform: diana_coman: under what condition wouldja get udp lib barf ?
diana_coman: eggogs
asciilifeform: i can think of only 1, dead irons
diana_coman: to use correct terminology
mircea_popescu: ie the item died ?
asciilifeform: it's like fg, the only failure mode is magic smoke release
asciilifeform: ( unlike e.g. tcp, where pipe can die )
mircea_popescu: if it isn't, i'd like to know about it, because i quite like the model.
diana_coman: well yes, it fails to transmit
diana_coman: so raises UDP_Failed_Transmit
asciilifeform: diana_coman: see what happens when nic cord yank
diana_coman: q is what should sender do
asciilifeform: ( iirc nothing happens, udp dun guarantee delivery, lol )
mircea_popescu: diana_coman you proposing it'd be better to resend than ignore ? ☟︎
diana_coman: well, udp lib closes the socket in this case
mircea_popescu: when udp fails, it's generally because op got dc'd.
diana_coman: I don't know but given Close_Socket(S), ignoring seems rather ...
mircea_popescu: rather what ?
diana_coman: weird because no way to recover even if plugged back in or something
asciilifeform: diana_coman: have you managed to achieve the socket-closing eggog without directly abusing the lib ? (e.g. by trying to send oversized packet, etc)
mircea_popescu: there's two possible situations here. 1. connection has transient problems, resending would help ; 2. connection died, resending will waste more time.
mircea_popescu: the idea is udd_ft is 99.999x% 2 and never 1.
diana_coman: but if udp lib closed the socket how would it help?
asciilifeform: mircea_popescu: there ain't a 'connection' in udpology
mircea_popescu: i was saying in principle.
mircea_popescu: asciilifeform right.
mircea_popescu: "logical" connection how shall i put it. path ? line ?
diana_coman: I don't mean "resend this packet"
asciilifeform: it eats a packet and then tries to send , afaik the os will not report a eggog on send() unless there in fact are no working nics
diana_coman: I mean don't keep trying to send on a closed socket sort of thing
mircea_popescu: well what could the wrapper possibly do other than resend ?
mircea_popescu: but i mean... if the socket's closed the wrapper returns neh ?
diana_coman: uhm, how/why?
diana_coman: or which one do you call wrapper?
diana_coman: the sender? so it's not ignore, but "abort all"?
asciilifeform: diana_coman: my current understanding is that the socket won't ever close, if iron is intact.
asciilifeform: ( see if this holds , for various scenarios, yank cord, yank nic )
mircea_popescu: diana_coman if the socket is in fact closed, your program dies, there's no twowaysabout this.
diana_coman: I suppose "ignore" in the sense of let the exception propagate and the program die
asciilifeform: it's like the fg serial socket.
asciilifeform: and yes death is the correct behaviour.
mircea_popescu: diana_coman that's a very overloaded sense.
mircea_popescu: "returns" in the sense of "return error, let machinery stop"
mircea_popescu: "ignore" in the sense of "keep trying"
diana_coman: that was my original meaning but then I got the impression you said the wrapper should ignore so then...it should keep trying?
diana_coman re-reads
mircea_popescu: no, what i'm saying is that with udp it is ~never worth "Retrying" in the tcp sense.
asciilifeform: if only thing that can kill the socket is killed iron, retrying it won't bring back to life will it.
diana_coman: right, that wasn't the proposed approach at any time
mircea_popescu: and this is a fundamental assumption baked into the udp spec etc.
asciilifeform: correct, udp quite analogous to, say, radio, you can send but no promises that anyone heard
diana_coman: asciilifeform, I don't know if/that that is indeed the only thing that can kill the socket; and testing won't quite tell me either
mircea_popescu: i guess this is a spot you;ll have to proceed on faith,
mircea_popescu: "there are not enough errors you can fix for the machinery to fix errors be worth having around".
mircea_popescu: like an airport where it never snows, just meteors fall now and again. snowplows not useful.
diana_coman: mircea_popescu, re ignore vs retry this sent me into confusion-mode: http://btcbase.org/log/2018-12-13#1880648 ☝︎
a111: Logged on 2018-12-13 19:39 mircea_popescu: diana_coman you proposing it'd be better to resend than ignore ?
mircea_popescu: ah ah.
mircea_popescu: "wtf does he mean ignore, isn't that just resend???" sorta thing ?
asciilifeform: mircea_popescu: sorta the philosophy i went with in FG -- redundancy against iron-death error oughta live upstack ( i.e. you plug in >1 ) rather than inside box
diana_coman: exactly!
mircea_popescu: i see. not the best use of words on my part.
mircea_popescu: asciilifeform indeed.
mircea_popescu: in the other line, have you played with ada threads any ? are you friends ?
diana_coman: anyway, rewinding: thin sender/receiver wrappers; on udp lib eggog, program dies (hopefully more gracefully than disgracefully but still death)
asciilifeform: diana_coman's udp tester was threaded
asciilifeform quite fond of the ada thread model, it's prolly closest one can get to sanity on pc irons
mircea_popescu: yeah, it was.
mircea_popescu: diana_coman yes, certainly should provide whatever diagnosis tools and equipment you want. i don't want to fill that in yet, it'll... come to you, as it happens :)
asciilifeform: ( ffa is not threaded per se, but is thread-safe, dun allocate anyffing other than on stack, i.e. can be used inside a thread safely )
mircea_popescu: "this is needed for the same reason as the generic at UDP lib previously - to allow one to store Serpent messages or RSA messages while maintaining them clearly differentiated" << why are you putting ducks and geese in the same line though ?
asciilifeform: you'd want'em in separate queues, neh? whole point of marking the packets distinguishable by size
mircea_popescu: hm. i suppose this is okay, really. scalable enough, if eventually we decide to get a s and a r machine, they'll just have their own queues and that's it.
mircea_popescu: asciilifeform no, counterintuitively hers is the right cut.
asciilifeform: hm ?
asciilifeform: ( i thought orig mircea_popescu spec was 'keep rsa packets in own queue, so clearly cap the resource that is spent on'em'
asciilifeform: )
mircea_popescu: two kilobytes are two kilobytes. the advantage of doing it the way she does it is that if you get two machines later, you can run this code unmodified. the disadvantage is absent, because two kilobytes are two kilobytes, what do yo ucare if "separate"
mircea_popescu: hers is the right cut.\
asciilifeform: mircea_popescu: how wouldja, e.g., 'these 6 cpus for serpent, these 3 -- for rsa' if yer packets are in 1 queue ?
mircea_popescu: this machine for serpent, this machine for rsa, is the model here.
asciilifeform: aa
asciilifeform: ok makes sense
mircea_popescu: but re your q : these 6 workers pick rsa from queuer ; and these 3 pick serpent from queue.
mircea_popescu: what's problem then ?
mircea_popescu: not like the queued items are not tagged.
diana_coman: mircea_popescu, that's precisely why I made it that way; I suppose it's not clear there at all but yes - because processing of rsa/s is meant to be easily and entirely separated physically, aka machines
asciilifeform: mircea_popescu: a 'queue' in the usual sense doesn't have a 'pick an X', it has 'pick from top'
mircea_popescu: diana_coman you did good.
mircea_popescu: asciilifeform afaik you can "get top X" rather than "get top" neh ?
mircea_popescu: diana_coman can you ?
asciilifeform: that aint called a queue, normally
mircea_popescu: but ada does this.
asciilifeform: can do it, but the resulting data structure called sumthingelse.
diana_coman: mircea_popescu, the way I implemented it it's as asciilifeform says but the reason it is *this* data structure is because of intended use so linked to above
asciilifeform: ( 'priority queue', i believe. but from my brief look at diana_coman's posted item, it dun do this )
diana_coman: i.e. yes, it could have been implemented as mircea_popescu describes if I didn't aim for this specifically
mircea_popescu: well now i hafta go read this
asciilifeform: diana_coman seems to have an ordinary queue.
mircea_popescu: yes. diana_coman mind explaining how this works ? so, queue has 55 elements, 22 of which rsa packets. now what happens ?
diana_coman: my implementation is just a bounded queue fifo, 1 item at a time in /out; and yes, I looked again at Ada's standard stuff and I could use I think a bounded_synchronized_queue container but then it forces me to put/get full structure
diana_coman: mircea_popescu, what is to happen?
mircea_popescu: well, serpent processor wants a serpent item to process.
mircea_popescu: if it gets, and it gets a rsa item ?
asciilifeform: what happens is that nothing behind the 22 rsa items is eaten until they are. as one'd expect from an ordinary fifo. hence asciilifeform's nitpick.
diana_coman: q1 has 22 elements all of which are rsa packets; q2 has 33 items all of which are s packets ; rsa processor eats from q1 , s processor from q2
mircea_popescu: oh so you DO have two queues then ?
asciilifeform: so then 2 queues lol
diana_coman: mircea_popescu, I thought you got that?
diana_coman: ugh, confusion all over
asciilifeform: ( item can be made as mircea_popescu described, either from 2 fifos or 1 priorityqueue. but the latter is actually much moar complicated, in re moving parts, than the former )
diana_coman: "as asciilifeform describes" aka 1 item put/get at a time; 2 different queues, one for rsa one for s
mircea_popescu: i see.
asciilifeform: + priorityqueues dun have O(1) insertion.
mircea_popescu: and then if we get two boxes, there's gonna be an allocated and always-empty queue on each of these.
diana_coman: mircea_popescu, no
diana_coman: why?
diana_coman: one sender each too
mircea_popescu: so you're gonna run different code on them ?
diana_coman: you don't have to deploy rsa sender on s box
asciilifeform: why wouldja have an empty queue (unless no traffic) ..?
diana_coman: uhm, it's "different" in the sense of one parameter
diana_coman: create one rsa_sender or one s_sender
diana_coman: they are same code except payload_len parameter
mircea_popescu: well, i had thought you did it the other way lol.
diana_coman: which other way?
mircea_popescu: ok, so the idea here is, that while maintaining different code on different boxes is costly and undersirable, nevertheless that is mitigated by the relative ease of the genericization/prototyping mechanism in ada ; whereas single queue model, as logically tempting as it may be, is costlier than it seems (not necessarily because insertion can't be o1, but still, machinery involved).
mircea_popescu: something like that ?
asciilifeform: mircea_popescu: from my reading, diana_coman will have same proggy on 2 boxen, but routine-a runs on box a, and routine-b on b
mircea_popescu: right.
diana_coman: mircea_popescu, yes
mircea_popescu: alright, i'm sold.\
mircea_popescu: "I'm not even sure whether a sender/receiver should be in fact part of smg_comms" << while this has merit, i'd still keep them in.
mircea_popescu: not like can't separate later. but generally speaking the tendency of v-trees is integration.
diana_coman: given the decision for thin, it makes sense, yes
diana_coman: because they are non-client/app specific really
mircea_popescu: right.
asciilifeform: diana_coman: 2nd link in post (to asciilifeform's www) malformed
mircea_popescu: do they check and signal when queue is fuller than some percentage << i expect the task manager will have to do this. not the wrapper, no.
diana_coman: aha; thin sender/receiver can't do anything about it anyway
mircea_popescu: right.
diana_coman: they will just get potentially stuck waiting for queue to empty
mircea_popescu: we make the queue large :D
diana_coman: asciilifeform, fixed
asciilifeform: ty
diana_coman: mircea_popescu, well, in principle you can run out of space and that'll raise an exception and program dies :D
mircea_popescu: hehehe
asciilifeform: mircea_popescu, diana_coman: re queues filling : per my reading of http://trilema.com/2018/euloras-communication-protocol-restated/#selection-673.0-673.234 , well-behaved clients cannot cause queue to overfill, as it's a synchronous back/forth. so overfilled queue indicates somebody for the chopping block.
mircea_popescu: asciilifeform where do you read this ?
asciilifeform: linked snip
mircea_popescu: eg, client can (and well behaved client is expected to) send multiple serpent keys upon first connection.
asciilifeform: sect. 6.4
asciilifeform: hm
mircea_popescu: yes, "i move here" is tightly coupled.
mircea_popescu: but "here's the 256 serpent keys i want you to pick amongst" is not.
asciilifeform: yea strike that. ( asciilifeform mistaken in >1 way, it is also possible for '9000' legit clients to issue hello and overfill , even if it were actually the case that 1:1 handshake )
mircea_popescu: right ?
asciilifeform: aha
asciilifeform bbl,teatime
asciilifeform: meanwhile, for pro entomologists only, https://archive.is/UFTWQ ( e.g. 'Some like SNS Server have no reported breaches over almost 30 years. Companies wouldn’t buy them. FOSS folks don’t build them. To this day and uniquely to this sub-field, most folks well-known in security act like none of that work ever happened, ignore those methods that got results, and slowly reinvent them or knockoffs of them with less results. Their kern
asciilifeform: els and VMM’s still have code injections and leaks the 1990’s versions prevented. Recent example being cache-based, side channels originally reported in 1992 in VAX VMM using analysis method from 1991.' )
asciilifeform: ( from backlink lint trap )
BingoBoingo: In local news, the people are now dying waiting in line https://www.elobservador.com.uy/nota/sindicato-y-autoridades-del-bps-dan-versiones-diferentes-sobre-muerte-de-jubilados-haciendo-cola--20181213193244