Show Idle (>14 d.) Chans
← 2018-12-12 | 2018-12-14 → ↓
06:27 diana_coman !!rated douchebag
06:27 deedbot diana_coman has not rated douchebag.
06:27 diana_coman !v 26D6263DD1CF71B77F9F08B00E556AFD5151F70108D684D43B134054F28A21FF
06:27 diana_coman !!v 26D6263DD1CF71B77F9F08B00E556AFD5151F70108D684D43B134054F28A21FF
06:27 deedbot diana_coman rated douchebag -5 << obstinate time waster
06:29 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)
~ 17 minutes ~
06:46 diana_coman lmao
06:52 phf the people must know!
06:58 diana_coman I'll consider it as part of my fanbase as per http://btcbase.org/log/2018-12-11#1879491
06:58 a111 Logged on 2018-12-11 00:17 diana_coman: oh, fanbase,pfuai
06:59 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
07:02 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
~ 15 minutes ~
07:18 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!
~ 1 hours 53 minutes ~
09:12 asciilifeform holyfuq, that fella
09:13 asciilifeform http://p.bvulpes.com/pastes/XAWtr/?raw=true << selfsame lulzspamola preserved for l0gz.
~ 35 minutes ~
09:48 diana_coman eh, he prolly found therefore a vulnerability in deedbot too!! look, he can still speak even if no voice
~ 1 hours 9 minutes ~
10:58 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 ?
10:58 asciilifeform !Q later tell ben_vulpes canhaz logbot again in #a plox ? ty
10:58 lobbesbot asciilifeform: The operation succeeded.
10:58 mircea_popescu this notion is so indigestible to me...
↖
11:00 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
11:00 mircea_popescu this is how soviet-hero-pioneer worked, also.
11:00 asciilifeform aha
11:01 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.
11:01 asciilifeform carefully avoiding thought is simplest way not to 'thoughtcrime'
11:02 asciilifeform fwiw i have nfi why d00d is banging on ~this~ door, there's 9000 others where could bang
11:03 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".
11:03 mircea_popescu asciilifeform because this is the only door that ~means something~.
11:03 asciilifeform the latter is exactly the former, but perma-wedged -- rather like dwarfism
11:03 mircea_popescu i'm of the same mind.
11:05 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.
11:05 mircea_popescu a point not lost on the very soviet state in question.
11:08 asciilifeform eh even 15yos mocked the crapola. e.g. the Official 'Как повяжешь галстук, Береги его: Он ведь с красным знаменем. Цвета одного' turned into '...он ведь с носом пьяницы цвета одного' and even '...Есть на чем повеситься, В случае - чего'
11:08 mircea_popescu the brighter ones lol.
11:08 mircea_popescu not the normies.
11:08 asciilifeform ( there's ~infinitely many of these, for aficionado )
11:09 BingoBoingo Maybe the kid just needs a (((packing))) peanut internship with avik?
11:10 asciilifeform mircea_popescu: https://archive.is/D8JfE << orig form
11:11 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
11:13 BingoBoingo Of course there is the mid-long term hazard the kid outlives avik and evangalizes the predatory stupids down the line
11:13 trinque diana_coman: works for me over here. at what time were you trying?
11:14 asciilifeform mircea_popescu: the 'normies', to the great wrath (and eventual demise) of that empire, imitated the 'bright'
~ 16 minutes ~
11:31 diana_coman trinque, at ~11 and then later at 11:26; in between those it worked perfectly fine to rate
11:31 diana_coman hm, now it answers !!ledger though so I guess it was a hiccup at that time
11:36 diana_coman http://btcbase.org/log/2018-12-13#1880441 -> as in "can't stand it" or "can't make sense of it"?
11:36 a111 Logged on 2018-12-13 15:58 mircea_popescu: this notion is so indigestible to me...
11:44 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?"
11:51 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.
11:52 feedbot http://ossasepia.com/2018/12/13/smg-comms-chapter-12-thread-safe-queues/ << Ossasepia -- SMG Comms Chapter 12: Thread-Safe Queues
11:53 diana_coman trinque, ah, that would explain it yes; at any rate it's no rush at all and no real trouble caused
11:54 asciilifeform diana_coman: i could've sworn that the standard provided queues
11:55 asciilifeform ( did they end up having secondarystackism glued in, or what was it )
11:55 diana_coman asciilifeform, hm, I guess I need to search more and see exactly what it provides then
11:55 asciilifeform diana_coman: i haven't tried'em myself
11:55 asciilifeform but the 2012 rationale b00k seems to contain'em
11:56 diana_coman iirc there is some synchronized queue interface and container but it seemed overkill
11:56 diana_coman I'll read in more detail again at any rate, won't hurt
~ 48 minutes ~
12:45 asciilifeform in other lulz, asciilifeform finally bought that bolix
12:46 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... )
12:48 diana_coman !!rated juliankunkel
12:48 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.
12:48 asciilifeform oh hey
12:48 diana_coman juliankunkel, try !!up now
12:49 asciilifeform mircea_popescu: i'ma try an' bribe a dentist to take those xray pics, seems like cheapest pill.
12:50 asciilifeform ( might have to soft-stitch the shots, dental film aint quite large enuff )
12:51 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 ? )
12:51 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..
12:51 diana_coman oh hey, welcome juliankunkel !
12:52 juliankunkel hi all. Interesting stuff with your WOT and game.
↖
12:56 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.
12:56 asciilifeform welcome juliankunkel
12:57 asciilifeform juliankunkel: you will find the logs ( http://btcbase.org/log/ ) to be of interest
12:59 BingoBoingo Welcome
12:59 juliankunkel asciilifeform: thx, I will have a look; I'm looking a bit round here.
12:59 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
13:01 juliankunkel side-channel attacks seem fun; how much longer you'd expect until it works and is proof?
13:02 asciilifeform juliankunkel: it's 'proof' now. most of what remains is performance opt.
13:02 asciilifeform ( i.e. starting with ch.6 can already rsa )
13:03 asciilifeform ( see ch.1 , http://www.loper-os.org/?p=1913#selection-7.0-151.23 , re: what thing's made of and why )
13:07 juliankunkel asciilifeform: interesting stuff. going home now ; see you!
13:07 asciilifeform laters.
~ 32 minutes ~
13:39 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."
13:40 asciilifeform guten tag mircea_popescu !
13:40 mircea_popescu hola.
13:41 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.
13:41 asciilifeform mircea_popescu: 10 or so KeV oughta suffice, by my napkin reckoning
13:45 mircea_popescu they measure in microsieverts (ie, grays) for some reason. but anyway, the latest ones do like 12 uSv
13:48 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 ) .
13:48 mircea_popescu (background is about 2 uSv, for comparison)
13:48 asciilifeform so it'll be a straight subtraction ( of the visible bottom tracks ) .
13:49 mircea_popescu asciilifeform there's no metal layer in between ?
13:49 asciilifeform nope.
13:49 asciilifeform it's a board of same type as FG ( but 100% through-hole )
13:49 mircea_popescu ah ah. well ok.
13:50 asciilifeform the 1 item of concern is heatsink on the cpu, i'ma pull cpu out prior to the magic moment
13:50 asciilifeform xray i expect is the 'easy' part. the real bitch will be the GALs
13:51 asciilifeform a coupla of them are of the kind that have flipflops ( so not susceptible to pure combinatorial brute )
13:51 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)
13:51 mircea_popescu i can see it.
13:53 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.
↖
13:54 asciilifeform ( then can sell the original back to the wanker people )
13:54 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 ?
13:54 a111 Logged on 2018-12-13 17:52 juliankunkel: hi all. Interesting stuff with your WOT and game.
13:54 mircea_popescu asciilifeform not a bad idea, at that.
13:55 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
13:55 asciilifeform let weitekism run in soft that bolix helpfully wrote, at fpga speed
14:00 asciilifeform ( the crapple box the thing sits in, incidentally, is about 100bux on the junk markets, quite handily )
14:00 asciilifeform 1 of those things that was approx on par with 'amiga'
14:01 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
14:03 * 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
14:06 asciilifeform mircea_popescu: 'physical copy' + place to put logic analyzer sausage, if not obv. earlier (the orig item is pretty cramped)
14:06 mircea_popescu right.
14:07 asciilifeform really a 'sapper errs once' sorta job, if i zap so much as 1 GAL i'ma need whole new orchestra again.
14:09 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
14:10 asciilifeform ( not banking on it tho, i suspect their heads have fully tissue grafted into arse at this pt )
14:12 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
14:13 mircea_popescu should be fun to see how well "magical tech" works if plugged into LARGE ram.
14:13 asciilifeform i dun think it has any extra addr lines
14:13 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
14:13 asciilifeform so will be same thing, only less mass.
14:14 asciilifeform mircea_popescu: x86 was ~ok when 64k (i.e. prior to introducing 'segments' )
14:14 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"
14:14 a111 Logged on 2018-12-11 17:34 mircea_popescu: then ~lone man~ of wanna-be rus' yellow man copied item.
14:14 mircea_popescu asciilifeform aha!
14:15 asciilifeform re bolix, iirc of the 36bit, 28 were available for addressing, so theoretically can 256MB.
14:15 asciilifeform ( i dun recall if the 'xl' actually could be fed 256MB, possibly phf knows )
14:15 mircea_popescu can has 64GB ram on the cheap now. considering what period pricing was like, 2020 reconstructed bolix'd better have 1TB ram.
14:16 asciilifeform reconstructed can have whatever one likes, that aint the tricky bit.
14:16 mircea_popescu we'll see how this goes.
14:16 asciilifeform tricky bit is to turn thing from 'martian artifact' back into bits.
14:16 asciilifeform so folx can 'you wouldn't download a car!111' 'fuck you, would if i could' (tm)
14:18 mircea_popescu yes, but n+1 step there is... "well, bolix v2020 comes with 1tb ram. which it uses."
14:18 asciilifeform mircea_popescu: presently can't think of any reason not to put whole effort, chunk by chunk, on www
14:18 mircea_popescu me either.
14:19 asciilifeform ( witness, 2 yrs of FG and no 'chinese copy' )
14:19 mircea_popescu meanwhile, let's hijack this a little for some s.mg discussion.
14:19 asciilifeform yea subj is tapped out till i get the box in hands
14:19 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.
14:20 asciilifeform mircea_popescu: iirc diana_coman wrote one 3wk ago
14:20 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 ?
14:20 mircea_popescu even go the distance of keeping a task manager to keep spawning them, and giving them sockets ?
14:20 diana_coman asciilifeform, lol, no, the point there is the sender/receiver layer of a eulora app essentially
14:20 asciilifeform mircea_popescu: with diana_coman's variant of my udp routine, you dun need >1 socket to send
14:20 asciilifeform 1 socket can send whatever one likes
14:21 mircea_popescu asciilifeform suppose you're on a multi-core cpu, suppose the socket's not filled but the sender is.
14:21 mircea_popescu spawning another one then makes sense.
14:21 diana_coman asciilifeform, you do need because 2 different sizes i.e. 2 different udp lib types essentially
14:21 mircea_popescu that also.
14:22 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.
14:22 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.
14:22 asciilifeform you dun need a socket per client in udpism
14:22 mircea_popescu need nothing. does it help to have ?
14:22 asciilifeform imho not.
14:23 mircea_popescu any specifiable meat on that h ?
14:23 asciilifeform unix is retarded : limits total # of open sockets. so having >1 not only imposes overhead without achieving anyffing, but will eventually hit ceiling.
14:23 diana_coman asciilifeform, the q is basically: how many messages/sec clogs the socket essentially
14:23 mircea_popescu diana_coman the problem's rather, two sockets will possibly clog for fever total msg/sec than one.
14:24 asciilifeform diana_coman: you're cpu bound ( serpent ) so you likely will never hit the bandwidth bound. so the udpgrams will go in ~realtime.
14:24 asciilifeform no 'clog'
14:25 asciilifeform recall also that your udp sender is blocking
14:25 diana_coman asciilifeform, I don't follow - 1mn clients can send 1mn datagrams to server, what has serpent to do ?
14:25 asciilifeform therefore the call to it won't return until the packet has left the house
14:25 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) ?
14:25 diana_coman mircea_popescu, that was my current idea: 2 sockets, one for rsa and one for serpent, with different ports too
14:25 mircea_popescu defo diff ports.
14:25 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.
14:25 diana_coman receiver just grabs from udp lib and drops into a queue
14:26 mircea_popescu whole reason to even do it liek this so client can separate its traffic
14:26 diana_coman doesn't even bother to decrypt or whatnot because anyway it has no info as to keys and all that
14:26 asciilifeform mircea_popescu: if you have 2 sockets, can even use orig variant of udptron.
14:26 asciilifeform ( i.e. without the variant packet widths . instantiate one with rsa-width buffer, and 1 w/ serp.width )
14:27 diana_coman asciilifeform, I made it generic so I don't have to copy/paste code just for different const
14:27 mircea_popescu diana_coman the expectation that serpenting rather than netsending will be the processing bottleneck is not unfounded, imo.
14:28 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 )
14:28 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
14:28 mircea_popescu "sender waits on nic" is what is meant by clog.
14:29 diana_coman well, except for the case where 1mn simultaneous clients I suppose but possibly that gets lost before even reaching the nic
14:29 asciilifeform mircea_popescu: i thought your orig queue was specifically re clog (impedance mismatch) in the unix ip stack
14:29 mircea_popescu diana_coman conversely, if they're that thin why do they exist.
↖
14:29 diana_coman that's what I've been going round in for most of today!!
14:29 asciilifeform diana_coman: per my current understanding of mircea_popescu's protocol, it is immune to packet loss (i.e. client will retry)
14:30 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
14:30 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
14:30 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 ?
14:32 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
14:33 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
14:33 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.
14:33 a111 Logged on 2018-12-13 19:29 mircea_popescu: diana_coman conversely, if they're that thin why do they exist.
14:33 diana_coman aha
14:33 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
14:33 asciilifeform so server cannot be 'swamped'
14:33 diana_coman asciilifeform, well, client CAN send
14:34 mircea_popescu asciilifeform im not strictly aware of this. whence the notion ?
14:34 diana_coman what is there to stop it
14:34 asciilifeform diana_coman: can send, but then he's a spammer, not client, and gets kicked
14:34 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.
14:34 mircea_popescu that leave anything hanging ?
14:34 asciilifeform (i.e. added to the kicklist, which rejects packet in O(n log N) where N is number of idjits )
14:36 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
14:36 asciilifeform so imho a++
14:36 asciilifeform ( asciilifeform's item defo not adult grade, however )
14:36 diana_coman mircea_popescu, works, it's a clear decision at least
14:36 mircea_popescu weren;'t you arguing asecond ago the rescuing from nic needn't be threaded ?
14:36 asciilifeform mircea_popescu: 1 thread for tx, 1 for rx
14:37 asciilifeform ( rather than per-user )
14:37 mircea_popescu ah. "threaded" here means, "task manager spawns processes". think how apache server works.
14:37 mircea_popescu imo venerable, successful, and mandatory to copy mechanism./
14:37 diana_coman the one thing hanging would be re errors I suppose
14:37 asciilifeform mircea_popescu phrased it correctly earlier, point is to remove from ip stack the job of queueing
14:37 mircea_popescu diana_coman what errors ?
14:37 diana_coman what should sender/receiver do on udp lib barf
14:37 asciilifeform diana_coman: what sorta errors ? packet is either legit or not, neh
14:38 mircea_popescu udp lib can barf ?!
14:38 asciilifeform diana_coman: under what condition wouldja get udp lib barf ?
14:38 diana_coman eggogs
14:38 asciilifeform i can think of only 1, dead irons
14:38 diana_coman to use correct terminology
14:38 mircea_popescu ie the item died ?
14:38 asciilifeform it's like fg, the only failure mode is magic smoke release
14:38 asciilifeform ( unlike e.g. tcp, where pipe can die )
14:38 mircea_popescu if it isn't, i'd like to know about it, because i quite like the model.
14:39 diana_coman well yes, it fails to transmit
14:39 diana_coman so raises UDP_Failed_Transmit
14:39 asciilifeform diana_coman: see what happens when nic cord yank
14:39 diana_coman q is what should sender do
14:39 asciilifeform ( iirc nothing happens, udp dun guarantee delivery, lol )
14:39 mircea_popescu diana_coman you proposing it'd be better to resend than ignore ?
↖
14:39 diana_coman well, udp lib closes the socket in this case
14:40 mircea_popescu when udp fails, it's generally because op got dc'd.
14:40 diana_coman I don't know but given Close_Socket(S), ignoring seems rather ...
14:40 mircea_popescu rather what ?
14:41 diana_coman weird because no way to recover even if plugged back in or something
14:41 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)
14:41 mircea_popescu there's two possible situations here. 1. connection has transient problems, resending would help ; 2. connection died, resending will waste more time.
14:41 mircea_popescu the idea is udd_ft is 99.999x% 2 and never 1.
14:41 diana_coman but if udp lib closed the socket how would it help?
14:41 asciilifeform mircea_popescu: there ain't a 'connection' in udpology
14:41 mircea_popescu i was saying in principle.
14:41 mircea_popescu asciilifeform right.
14:41 mircea_popescu "logical" connection how shall i put it. path ? line ?
14:41 diana_coman I don't mean "resend this packet"
14:42 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
14:42 diana_coman I mean don't keep trying to send on a closed socket sort of thing
14:42 mircea_popescu well what could the wrapper possibly do other than resend ?
14:42 mircea_popescu but i mean... if the socket's closed the wrapper returns neh ?
14:42 diana_coman uhm, how/why?
14:42 diana_coman or which one do you call wrapper?
14:43 diana_coman the sender? so it's not ignore, but "abort all"?
14:43 asciilifeform diana_coman: my current understanding is that the socket won't ever close, if iron is intact.
14:43 asciilifeform ( see if this holds , for various scenarios, yank cord, yank nic )
14:44 mircea_popescu diana_coman if the socket is in fact closed, your program dies, there's no twowaysabout this.
14:44 diana_coman I suppose "ignore" in the sense of let the exception propagate and the program die
14:44 asciilifeform it's like the fg serial socket.
14:44 asciilifeform and yes death is the correct behaviour.
14:44 mircea_popescu diana_coman that's a very overloaded sense.
14:44 mircea_popescu "returns" in the sense of "return error, let machinery stop"
14:44 mircea_popescu "ignore" in the sense of "keep trying"
14:45 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?
14:45 * diana_coman re-reads
14:45 mircea_popescu no, what i'm saying is that with udp it is ~never worth "Retrying" in the tcp sense.
14:46 asciilifeform if only thing that can kill the socket is killed iron, retrying it won't bring back to life will it.
14:46 diana_coman right, that wasn't the proposed approach at any time
14:46 mircea_popescu and this is a fundamental assumption baked into the udp spec etc.
14:46 asciilifeform correct, udp quite analogous to, say, radio, you can send but no promises that anyone heard
14:46 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
14:47 mircea_popescu i guess this is a spot you;ll have to proceed on faith,
14:47 mircea_popescu "there are not enough errors you can fix for the machinery to fix errors be worth having around".
14:47 mircea_popescu like an airport where it never snows, just meteors fall now and again. snowplows not useful.
14:49 diana_coman mircea_popescu, re ignore vs retry this sent me into confusion-mode: http://btcbase.org/log/2018-12-13#1880648
14:49 a111 Logged on 2018-12-13 19:39 mircea_popescu: diana_coman you proposing it'd be better to resend than ignore ?
14:49 mircea_popescu ah ah.
14:49 mircea_popescu "wtf does he mean ignore, isn't that just resend???" sorta thing ?
14:49 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
14:49 diana_coman exactly!
14:49 mircea_popescu i see. not the best use of words on my part.
14:50 mircea_popescu asciilifeform indeed.
14:50 mircea_popescu in the other line, have you played with ada threads any ? are you friends ?
14:51 diana_coman anyway, rewinding: thin sender/receiver wrappers; on udp lib eggog, program dies (hopefully more gracefully than disgracefully but still death)
14:51 asciilifeform diana_coman's udp tester was threaded
14:51 * asciilifeform quite fond of the ada thread model, it's prolly closest one can get to sanity on pc irons
14:51 mircea_popescu yeah, it was.
14:52 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 :)
14:52 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 )
14:53 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 ?
14:54 asciilifeform you'd want'em in separate queues, neh? whole point of marking the packets distinguishable by size
14:54 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.
14:54 mircea_popescu asciilifeform no, counterintuitively hers is the right cut.
14:55 asciilifeform hm ?
14:55 asciilifeform ( i thought orig mircea_popescu spec was 'keep rsa packets in own queue, so clearly cap the resource that is spent on'em'
14:55 asciilifeform )
14:56 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"
14:56 mircea_popescu hers is the right cut.\
14:57 asciilifeform mircea_popescu: how wouldja, e.g., 'these 6 cpus for serpent, these 3 -- for rsa' if yer packets are in 1 queue ?
14:57 mircea_popescu this machine for serpent, this machine for rsa, is the model here.
14:57 asciilifeform aa
14:57 asciilifeform ok makes sense
14:57 mircea_popescu but re your q : these 6 workers pick rsa from queuer ; and these 3 pick serpent from queue.
14:57 mircea_popescu what's problem then ?
14:57 mircea_popescu not like the queued items are not tagged.
14:58 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
14:58 asciilifeform mircea_popescu: a 'queue' in the usual sense doesn't have a 'pick an X', it has 'pick from top'
14:58 mircea_popescu diana_coman you did good.
14:58 mircea_popescu asciilifeform afaik you can "get top X" rather than "get top" neh ?
14:58 mircea_popescu diana_coman can you ?
14:58 asciilifeform that aint called a queue, normally
14:58 mircea_popescu but ada does this.
14:59 asciilifeform can do it, but the resulting data structure called sumthingelse.
14:59 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
14:59 asciilifeform ( 'priority queue', i believe. but from my brief look at diana_coman's posted item, it dun do this )
14:59 diana_coman i.e. yes, it could have been implemented as mircea_popescu describes if I didn't aim for this specifically
15:00 mircea_popescu well now i hafta go read this
15:00 asciilifeform diana_coman seems to have an ordinary queue.
15:01 mircea_popescu yes. diana_coman mind explaining how this works ? so, queue has 55 elements, 22 of which rsa packets. now what happens ?
15:01 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
15:01 diana_coman mircea_popescu, what is to happen?
15:01 mircea_popescu well, serpent processor wants a serpent item to process.
15:01 mircea_popescu if it gets, and it gets a rsa item ?
15:02 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.
15:02 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
15:02 mircea_popescu oh so you DO have two queues then ?
15:02 asciilifeform so then 2 queues lol
15:02 diana_coman mircea_popescu, I thought you got that?
15:02 diana_coman ugh, confusion all over
15:03 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 )
15:03 diana_coman "as asciilifeform describes" aka 1 item put/get at a time; 2 different queues, one for rsa one for s
15:03 mircea_popescu i see.
15:03 asciilifeform + priorityqueues dun have O(1) insertion.
15:03 mircea_popescu and then if we get two boxes, there's gonna be an allocated and always-empty queue on each of these.
15:03 diana_coman mircea_popescu, no
15:03 diana_coman why?
15:04 diana_coman one sender each too
15:04 mircea_popescu so you're gonna run different code on them ?
15:04 diana_coman you don't have to deploy rsa sender on s box
15:04 asciilifeform why wouldja have an empty queue (unless no traffic) ..?
15:04 diana_coman uhm, it's "different" in the sense of one parameter
15:04 diana_coman create one rsa_sender or one s_sender
15:05 diana_coman they are same code except payload_len parameter
15:05 mircea_popescu well, i had thought you did it the other way lol.
15:05 diana_coman which other way?
15:06 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).
15:06 mircea_popescu something like that ?
15:07 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
15:07 mircea_popescu right.
15:07 diana_coman mircea_popescu, yes
15:07 mircea_popescu alright, i'm sold.\
15:10 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.
15:10 mircea_popescu not like can't separate later. but generally speaking the tendency of v-trees is integration.
15:11 diana_coman given the decision for thin, it makes sense, yes
15:11 diana_coman because they are non-client/app specific really
15:11 mircea_popescu right.
15:11 asciilifeform diana_coman: 2nd link in post (to asciilifeform's www) malformed
15:12 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.
15:13 diana_coman aha; thin sender/receiver can't do anything about it anyway
15:13 mircea_popescu right.
15:13 diana_coman they will just get potentially stuck waiting for queue to empty
15:13 mircea_popescu we make the queue large :D
15:14 diana_coman asciilifeform, fixed
15:14 asciilifeform ty
15:15 diana_coman mircea_popescu, well, in principle you can run out of space and that'll raise an exception and program dies :D
15:15 mircea_popescu hehehe
15:15 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.
15:16 mircea_popescu asciilifeform where do you read this ?
15:16 asciilifeform linked snip
15:16 mircea_popescu eg, client can (and well behaved client is expected to) send multiple serpent keys upon first connection.
15:16 asciilifeform sect. 6.4
15:16 asciilifeform hm
15:16 mircea_popescu yes, "i move here" is tightly coupled.
15:17 mircea_popescu but "here's the 256 serpent keys i want you to pick amongst" is not.
15:17 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 )
15:18 mircea_popescu right ?
15:18 asciilifeform aha
15:19 * asciilifeform bbl,teatime
~ 2 hours 46 minutes ~
18:05 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
18:05 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.' )
18:06 asciilifeform ( from backlink lint trap )
18:09 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
~ 1 hours 4 minutes ~
19:14 asciilifeform in other lulz ( and given as http://logs.bvulpes.com/asciilifeform still dead.. ) , http://p.bvulpes.com/pastes/iLAh3/?raw=true << recent proceedings from asciilifeform's outpatient tele-clinic .
19:21 asciilifeform ( can laff if you like, at the d00d, but he ~does~ apparently have a blog. and it's even 1 that aint in 'lamp stack' , and i envy the pg load latencies.. )
19:21 asciilifeform apparently quitting drink, does do ~sumthing~
19:22 asciilifeform i gotta take to drink, so i can quit!11
~ 1 hours 4 minutes ~
20:26 BingoBoingo I dunno if that will work with your Russian physiology
20:27 asciilifeform worx 100% , just takes moarwork
20:27 asciilifeform ( see e.g. eltsin )
20:27 asciilifeform or moar litrage, anyway
~ 27 minutes ~
20:55 mircea_popescu yeah, what the hell happened with sns ?
20:56 asciilifeform mircea_popescu: according to commenter, nsa killed.
20:57 mircea_popescu tbh, a recuperative scholarly series on sns would be most apt use of scholar's time.
↖
20:57 asciilifeform verily
~ 2 hours 35 minutes ~
23:33 feedbot http://danielpbarron.com/2018/thank-you-for-your-opinion-and-concern/ << Daniel P. Barron -- Thank you for your opinion and concern.
23:37 trinque danielpbarron: "From reddit:" << are you just militantly anti-republican by now, or what
23:37 danielpbarron no
← 2018-12-12 | 2018-12-14 → ↑

Random(trilema) | Download hourly DB snapshot | Get Source Code

Theme: Light | Dark | System Default