Forum logs for 13 Dec 2018
| 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:27] |
| 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) | [06:29] |
| diana_coman: | lmao | [06:46] |
| phf: | the people must know! | [06:52] |
| 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:58] |
| 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 | [06:59] |
| 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 | [07:02] |
| 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! | [07:18] |
| asciilifeform: | holyfuq, that fella | [09:12] |
| asciilifeform: | http://p.bvulpes.com/pastes/XAWtr/?raw=true << selfsame lulzspamola preserved for l0gz. | [09:13] |
| diana_coman: | eh, he prolly found therefore a vulnerability in deedbot too!! look, he can still speak even if no voice | [09:48] |
| 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... | [10:58] |
| 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:00] |
| 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:01] |
| asciilifeform: | fwiw i have nfi why d00d is banging on ~this~ door, there's 9000 others where could bang | [11:02] |
| 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:03] |
| 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:05] |
| 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:08] |
| BingoBoingo: | Maybe the kid just needs ai) peanut internship with avik? | [11:09] |
| asciilifeform: | mircea_popescu: https://archive.is/D8JfE << orig form | [11:10] |
| 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:11] |
| 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:13] |
| asciilifeform: | mircea_popescu: the 'normies', to the great wrath (and eventual demise) of that empire, imitated the 'bright' | [11:14] |
| 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:31] |
| 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:36] |
| 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:44] |
| 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:51] |
| feedbot: | http://ossasepia.com/2018/12/13/smg-comms-chapter-12-thread-safe-queues/ << Ossasepia -- SMG Comms Chapter 12: Thread-Safe Queues | [11:52] |
| diana_coman: | trinque, ah, that would explain it yes at any rate it's no rush at all and no real trouble caused | [11:53] |
| asciilifeform: | diana_coman: i could've sworn that the standard provided queues | [11:54] |
| 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:55] |
| 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 | [11:56] |
| asciilifeform: | in other lulz, asciilifeform finally bought that bolix | [12:45] |
| 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:46] |
| 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:48] |
| asciilifeform: | mircea_popescu: i'ma try an' bribe a dentist to take those xray pics, seems like cheapest pill. | [12:49] |
| asciilifeform: | ( might have to soft-stitch the shots, dental film aint quite large enuff ) | [12:50] |
| 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:51] |
| juliankunkel: | hi all. Interesting stuff with your WOT and game. | [12:52] |
| 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:56] |
| asciilifeform: | juliankunkel: you will find the logs ( http://btcbase.org/log/ ) to be of interest | [12:57] |
| 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 | [12:59] |
| juliankunkel: | side-channel attacks seem fun how much longer you'd expect until it works and is proof? | [13:01] |
| 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:02] |
| 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:03] |
| juliankunkel: | asciilifeform: interesting stuff. going home now see you! | [13:07] |
| asciilifeform: | laters. | [13:07] |
| 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:39] |
| asciilifeform: | guten tag mircea_popescu ! | [13:40] |
| mircea_popescu: | hola. | [13:40] |
| 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:41] |
| mircea_popescu: | they measure in microsieverts (ie, grays) for some reason. but anyway, the latest ones do like 12 uSv | [13:45] |
| 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:48] |
| 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:49] |
| 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:50] |
| 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:51] |
| 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:53] |
| 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:54] |
| 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 | [13:55] |
| 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:00] |
| 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:01] |
| * 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:03] |
| 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:06] |
| asciilifeform: | really a 'sapper errs once' sorta job, if i zap so much as 1 GAL i'ma need whole new orchestra again. | [14:07] |
| 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:09] |
| asciilifeform: | ( not banking on it tho, i suspect their heads have fully tissue grafted into arse at this pt ) | [14:10] |
| 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:12] |
| 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:13] |
| 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:14] |
| 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:15] |
| 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:16] |
| 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:18] |
| 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:19] |
| 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:20] |
| 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:21] |
| 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:22] |
| 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:23] |
| 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:24] |
| 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:25] |
| 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:26] |
| 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:27] |
| 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:28] |
| 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:29] |
| 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:30] |
| 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:32] |
| 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:33] |
| 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:34] |
| 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:36] |
| 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:37] |
| 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:38] |
| 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:39] |
| 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:40] |
| 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:41] |
| 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:42] |
| 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:43] |
| 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:44] |
| 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:45] |
| 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:46] |
| mircea_popescu: | i guess this is a spot youll 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:47] |
| 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:49] |
| mircea_popescu: | asciilifeform indeed. | [14:50] |
| mircea_popescu: | in the other line, have you played with ada threads any ? are you friends ? | [14:50] |
| 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:51] |
| 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:52] |
| 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:53] |
| 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:54] |
| 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:55] |
| 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:56] |
| 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:57] |
| 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:58] |
| 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 | [14:59] |
| mircea_popescu: | well now i hafta go read this | [15:00] |
| asciilifeform: | diana_coman seems to have an ordinary queue. | [15:00] |
| 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:01] |
| 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:02] |
| 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:03] |
| 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:04] |
| 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:05] |
| 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:06] |
| 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:07] |
| 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:10] |
| 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:11] |
| 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:12] |
| 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:13] |
| diana_coman: | asciilifeform, fixed | [15:14] |
| asciilifeform: | ty | [15:14] |
| 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:15] |
| 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:16] |
| 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:17] |
| mircea_popescu: | right ? | [15:18] |
| asciilifeform: | aha | [15:18] |
| * asciilifeform | bbl,teatime | [15:19] |
| 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:05] |
| asciilifeform: | ( from backlink lint trap ) | [18:06] |
| 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 | [18:09] |
| 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:14] |
| 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:21] |
| asciilifeform: | i gotta take to drink, so i can quit!11 | [19:22] |
| BingoBoingo: | I dunno if that will work with your Russian physiology | [20:26] |
| asciilifeform: | worx 100% , just takes moarwork | [20:27] |
| asciilifeform: | ( see e.g. eltsin ) | [20:27] |
| asciilifeform: | or moar litrage, anyway | [20:27] |
| mircea_popescu: | yeah, what the hell happened with sns ? | [20:55] |
| asciilifeform: | mircea_popescu: according to commenter, nsa killed. | [20:56] |
| mircea_popescu: | tbh, a recuperative scholarly series on sns would be most apt use of scholar's time. | [20:57] |
| asciilifeform: | verily | [20:57] |
| feedbot: | http://danielpbarron.com/2018/thank-you-for-your-opinion-and-concern/ << Daniel P. Barron -- Thank you for your opinion and concern. | [23:33] |
| trinque: | danielpbarron: "From reddit:" << are you just militantly anti-republican by now, or what | [23:37] |
| danielpbarron: | no | [23:37] |
- (packing [↩]
Category: Logs
