mircea_popescu: lemme retrospectively confirm mp_en_viaje was actually indeed me, an' carry on.
snsabot: Logged on 2019-08-20 21:33:49 trinque: motherinthemiddle
mircea_popescu: i'm starting to suspect the actual market for gangbang porn is really ~diane keaton
snsabot: Logged on 2019-08-20 22:39:42 snsabot: Logged on 2016-09-16 22:54:18 trinque: BingoBoingo: aha, in fact there was a thread where mircea_popescu explained that y'know, you teach the women things
snsabot: Logged on 2019-08-08 16:13:35 mircea_popescu: do you realise every time i do a keyop it's ~half hour of slavegirl time going blind on asciisoup ?
mircea_popescu: this is in fact the definition, jungle as above, camp as in, <1minute.
snsabot: Logged on 2019-08-20 22:47:29 lobbes: but it is true that I was also failing *her* by not taking the reigns as I should have. The next girls, however, will be taught properly.
lobbes: wb to somewhat-civilisation mircea_popescu
lobbes: in other news, I'm in the process of provisioning a dedi server (for primarily a second trb node). I grabbed one with 2 512GB SSD drives. Now my question is: should I bother with RAID 1? Or will this just be stupid because they will wear at the same rate?
mircea_popescu: raid was immensely useful for the older drives. with ssds its' not clear you gain so much in either speed or reliability
mircea_popescu: in any case, there's not much point to two disk raid arrays ; nor to software raid.
lobbes: sounds reasonable to me. aite, I'ma tell em' no raid I think
lobbes: once this thing is up I'll probably be asking in #a (unless #mod6 still lives?) about doing a 'hot-start' with trb
lobbes: will also spin up a copy of alf's logger
mircea_popescu: bvt 's story of linux kernel retardation is eyewatering.
mircea_popescu: could you simply throw out the whole damn thing and replace with from-scratch random.c / h ?
mircea_popescu: in any case it is obvious that using it as intended (ie, pretending fg is what the linuxtards call a "hardware random generator") is ~wasting it. i dun wanna initialize the middle 32 bytes out of anything.
mircea_popescu: incidentally, the fucking notion of a byte-counted entropy pool is fucking ridiculous.
mircea_popescu: considering the keys we use are 4kb, it seems reasonable we should keep entropy pools of no less than 16kb ?
snsabot: Logged on 2019-08-22 00:13:36 mircea_popescu: raid was immensely useful for the older drives. with ssds its' not clear you gain so much in either speed or reliability
spyked: grrrr, this is annoying. ftr, I set the delay knob for feedbot msg delivery to 2 seconds and it still gets disconnected for some reason. I suspect it's something other than fleanode simply disconnecting, so I will ask users who are waiting on pending PMs from feedbot to bear with me for a while.
spyked: I think I caught the bug. will fix by the end of the day and bring teh rss bot back up.
lobbesbot: nicoleci: Sent 3 weeks, 4 days, 2 hours, and 34 minutes ago: <mp_en_viaje> State of Florida Vs. Ruby McCollum, Defendant by C. Arthur Ellis << download this
snsabot: Logged on 2018-10-12 12:56:05 mircea_popescu: in the 1980s engineers / cstronicists' defense, it was not yet understood how important entropy is to individuality and human existence.
spyked: mircea_popescu, meanwhile I found it wasn't the issue I initially thought! I'ma bring the bot back online shortly
spyked: to detail: trinque's bot has a thread that pings the irc server and does lag tracking (the lag then is: pong_response_timestamp - ping_sent_timestamp); if it detects that the lag is high, then it tries to reconnect. so when feedbot spends a lot of time in the notification loop, it doesn't receive the pong and gets disconnected.
spyked: the fix I'm currently applying is to have feedbot send notifications in short bursts so that it doesn't take over the main program loop
mircea_popescu: why doesnt the main program loop call the sender thing ONCE AT A TIME ?
mircea_popescu: can't, in general speaking, when plumbing the synch-asynch divide (such as for instance tryuibng to resolve through design the impedance mismatch between non-threqaded process and synchonous messaging) commit to any activity of an open-ended length. main loop gotta know at least approximately how long each call will take, or else it can't make them
spyked: mircea_popescu, for PM notifications, the sender is called only when the target nick is online; to find out whether a nick is connected, it sends an ISON and waits for a reply; and on the reply handler, it (until now) tried to process the entire message queue for that nick, which... yeah, that's a really bad idea.
spyked: the downside is that now messages are going to arrive somewhat slower -- ISONs aren't sent too often, so as to not abuse that command; but probably not that much of a problem either way. if a user was offline for a while, then he can wait the extra minutes to receive the messages.
snsabot: Logged on 2019-08-22 07:54:59 mircea_popescu: can't, in general speaking, when plumbing the synch-asynch divide (such as for instance tryuibng to resolve through design the impedance mismatch between non-threqaded process and synchonous messaging) commit to any activity of an open-ended length. main loop gotta know at least approximately how long each call will take, or else it can't make them
mircea_popescu: this is the first time i hear of some actually useful lisp improvement
mircea_popescu: logically, it'd be exactly the sort of spitshine fit for its shoes.
mircea_popescu: but yes, functional language should be able to get closest to your 0 penalty.
snsabot: Logged on 2017-03-30 10:50:38 asciilifeform: trinque: erlang wasn't simply about 'uptime', or even 'no pointer arithmetic', it also was the only case i know of where process migration actually worked
snsabot: Logged on 2019-08-14 10:43:52 asciilifeform: both, however, occasionally forced to make 'unprincipled exception', cuz the set of what can be done by deskilled monkey with 'cluck' tool is never 100% .
snsabot: Logged on 2019-08-22 07:50:22 spyked: to detail: trinque's bot has a thread that pings the irc server and does lag tracking (the lag then is: pong_response_timestamp - ping_sent_timestamp); if it detects that the lag is high, then it tries to reconnect. so when feedbot spends a lot of time in the notification loop, it doesn't receive the pong and gets disconnected.
snsabot: asciilifeform: time since my last reconnect : 6d 2h 12m
snsabot: Logged on 2019-08-22 00:18:27 mircea_popescu: bvt 's story of linux kernel retardation is eyewatering.
snsabot: Logged on 2019-08-22 00:18:54 mircea_popescu: could you simply throw out the whole damn thing and replace with from-scratch random.c / h ?
mircea_popescu: nah, pretty sure you need two, to protect self from attrition attack
mircea_popescu: imo correct design is 16kb to cpu-cache-sized inner ring buffer, wherein fg material is simply written into a loop, plain ; and from where high quality entropy is read blockingly. whenever the writing head threatens to overwrite the reading head, the overwritten bits are instead fed into outer ring
☟︎ mircea_popescu: this outer ring should use two cprngs to stretch the flow-in, one fast and one good.
mircea_popescu: such that the outer ring is always full, and the inner ring is always good.
mircea_popescu: no, it's not the same length, for one thing. 2nd buffer should be mb or larger ; and it gives the effect that there's an always-full entropy buffer
mircea_popescu: ring buffers : Inner (small, 16kb to cpu-cache-size) ; Outer (large, 1 MB to swap partition size). each buffer has a writing head moving around it and a reading head moving around it, their position is W and R at any time.
mircea_popescu: hash functions : Fast (takes one byte, produces many bytes), Good (takes one byte, produces one byte).
mircea_popescu: the operation then consists of : 1. FG -> I.W 2. if I.W = I.R, I.R -> O.W, such that if O.R >= O.W/2, next O.W goes through HF filling many offset bytes ; if O.R <= O.W/2, next OW goes through HG, filling one offset byte.
mircea_popescu: this way - O is "always full" from the pov of userland ; I is protected from userland reading O.
mircea_popescu: such that it can't either deplete the machine entropy by reading mb/s nor can it figure out the internals by reading straight fg bytes
mircea_popescu: that's why i say o is up to swap size. ti should be large enough to not be emptyable.
mircea_popescu: HF "many" setting could in principle be 1 byte -> buffer size
mircea_popescu: but use my formalisms. so what, I is 16kb and O is 2mb ?
mircea_popescu: user asks for say 1gb, O feeds 1mb, at which point reading head is more than halfway writing head, so HF gets called, and fills the half that was just read
mircea_popescu: this cycle can continue until 1GB is pissed out. if any FG bytes make it in during the interval, they are the source for the writing, stretched by HF. if not, whatever, HG applies on already read bytes
mircea_popescu: asciilifeform, only applicable re I. O, never blocks, because H.
mircea_popescu: you, stanislav, asked "where is the shop". i told you "go this and therefore" and you came back with "but where is the shop". at this point, this question can not be answered, BECAUSE YOU, STANISLAV, DO NOT READ.
mircea_popescu: but let's try it again. so, the I buffer is 16 kb, the O buffer is 2 MB. if the FG spits out 8kb/s or so, then the I buffer spits about 8kb/s or so into O, after the first two seconds,
mircea_popescu: now, the O buffer is, say, 2mb. if someone decides to read 1GB/s out of it,
mircea_popescu: then in the first ms, the R head of O will have moved halway towards the W head of it.
mircea_popescu: at this point, the HF (fast hash) will take one byte out of the next position of the R head, and produce MANY (ie, 1mb) worth of O filler from it.
mircea_popescu: if that one byte is not yet available, from I, then the HG (good hash) will take half the O that was already read, and replenish it
mircea_popescu: that's why the two-hash system : you either have a byte of FG, to put into O, or you don't.
mircea_popescu: if you do, you stretch it into a "many" bytes. if you don't, you just prng those many bytes.
mircea_popescu: asciilifeform, they are allowed to read I. that blocks.
mircea_popescu: now, the magic numbers are only here by need of example.
mircea_popescu: if indeed a stretch of say 8:1 is preferred, HF takes 1 byte makes 8, then the HG will work on 8byte buffers, take 8 bytes make 8 byres.
mircea_popescu: anyway, exactly what stretch factor to use is a bit of an open question. may be worth it to permit the thing to self-adjust, based on O read volume.
mircea_popescu: though this comes at cost of complexity. imo only correct approach is to have this set ~at kernel compile~, and there it stays. if you declare I 16kb and O 2mb, then therefore your stretch factor is 256
mircea_popescu: nothing prohibits proggy reading 2mb ring buffer at gb/s speeds. it'll get... well, a lotta hashmaterial.