asciilifeform: mircea_popescu: i think trinque & ben also walked in with this, given as they used a heathen 'cl-irc' lib for some reason (thinking, i suspect, 'irc, grrr, gnarly to implement' )
asciilifeform: spyked: the tricky bit re 'steal the ultralight threads' is that in order for it to work, you more or less have to have same degree of 'fascism' as in actual erlang, i.e. can't have shared memory, easily-mutable variables, all the other knobs that make 'earthling' threads 'heavy'
asciilifeform: or for that matter , the function calls. e.g. #'start-ring/2 . dafuq, if it's a sexpr, it ~knows already~ that it needs the 'start-ring' that eats 2 args , not 1, not 3, not 17
asciilifeform: ... their coad example. observe how yes they added paren, but... with various infixisms somehow still preserved and freely intermixed ?!!
asciilifeform: http://logs.nosuchlabs.com/log/trilema/2019-08-23#1930335 << this find is so monumentally terrible, that it is worth preserving in amber. ( and not on acct of the shithub, roundedcornerism, and misc. redditisms, but strictly from pov of the proggy per se . ) behold :
asciilifeform: ^ that way dun need any locking, no async speed will ever take place during a 'pong' or a synchronous reply to command.
asciilifeform: ( if anyone wants to put async-sends in mine, the natural place to do so is imho where recv() times out, pop (nonblockingly) string from a queue and speak() . )
asciilifeform: decided in the end that it is easier to pour a cup of tea an' write one from 0, than to wade through the rubbishes
asciilifeform: ( when set out to write it, asciilifeform looked at coupla dozen published heathen bots, but threw'em all out, the smallest were still 1000+ ln for no detectable reason )
asciilifeform: trinque: potentially could use my wartime bot, but it doesn't do asynchronous sends
asciilifeform: lobbes: aha. i made no attempt to clean out the spamola, it will remain unless mircea_popescu asks ' drop xyz where... ' etc
asciilifeform: trinque: re 'irc, wish to see end' -- i also balked, but turns out even this chore had some interesting wtf-discoveries lying in wait, e.g. the apparently massive nonflatness of net lag topology
asciilifeform: trinque: from the (very fragmentary) clues , seems to me that fella was demoralized somehow, for long time ( and possibly into bottle, tho tbf nothing specifically pointed to bottle )
asciilifeform: trinque: i cannot resist to wonder if the problem is in the hoster -- iirc deedbot used to stand up for weeks at a time , in earlier days
asciilifeform: trinque: i may be able to help w / bot ( would like a working cl bot at any rate ). how current is the published src ( that i used in pehbot ) ?
asciilifeform doesn't give a damn in either direction, the archive doesn't weigh even within order of magnitude enuff to impact overall speed of indexing in any detectable way
asciilifeform: thinkin' about it moar -- mircea_popescu et al, if you wanna nix the spamola, simplest way is to import the db and sort the users, there's i think 100 or so spamola nicks , could simply drop'em if want.
asciilifeform: aaand the db dump has been triggered manually ( it takes approx 10sec ) , in case anyone wants to get his hands on the updated db Right Nao .
asciilifeform: aaand of course 'era 1' of #t ( already discussed in orig. thread on trilema ) .
asciilifeform: archives remaining to import : #a ( if ben_vulpes turns up, i'd like to use his mimisbrunnr log to close the gaps; otherwise will use own znc ) ; #p ( again ditto )
asciilifeform: ( the washitistan ??!?? + the randomly quoted lines from unknown heathen chans, + possibly other shannonized crapola )
asciilifeform: going by informal walk via 'random' button -- that spamola is a substantial % of the archive, by mass
asciilifeform: mircea_popescu, lobbes , et al : prolly could easily purge ~100% of spam, simply by detecting these. lemme know if you want.
asciilifeform: oh hrm actually he does have a segment re subj
asciilifeform contemplates what a bvt-style dissection of the current 'urandom' might reveal.
asciilifeform: it seems like the obv. Right Thing. i.e. let tetris read from urandom, rsatron -- from random, etc.
asciilifeform: ftr this is how i formerly thought the existing linux worked.
asciilifeform: then makes sense. i had missed 'stretched by...' when 1st reading.
asciilifeform: ok so the classical pair of 'random vs urandom' devs ?
asciilifeform: seems to spec a somewhat diff item than originally contemplated tho ( where all userland proggies are guaranteed to get, if slowly, actual unique FG bits )
asciilifeform: so, in mircea_popescu's model, i asked for 3MB, while FG has only produced yet 2MB. what do i get ?
asciilifeform: same 'thermodynamic' problem , no matter how the output of FG is massaged, tho. if proggies ask for moar FG bits than FG has actually produced, they gotta block. ( linus fraudulently gave folx shitropy instead of entropy, so 'not block', but imho that's not even worth to discuss )
asciilifeform: then i'm defo thick. let's work example ? machine booted up 5min ago. ergo primary FG buffer contains ~2MB. now i'ma a user, and i ask for dd if=/dev/random of=foo bs=1M count=3 , i.e. 3MB. nao what ?
asciilifeform: or is the idea that there's a per-user buffer which actually contains his ration, and reads block on ~that~ ?
asciilifeform: 1 FG gives ~7.5kB/s . it isn't difficult to read , from buffer, GB/s
asciilifeform: possibly i'm thick, but what happens if particular user requests continuously ?
asciilifeform: you still gotta rate-limit the users' reads tho, or 1 could empty whole thing in burst, starving the rest, neh
asciilifeform: the 1st half of this , i get, is same as what i sketched. but for what is the outer buf ? seems like a single ring of same length as the 2, gives same effect ?
asciilifeform: ( what means here 'attrition' ? and for what is the 2nd buffer ? )
asciilifeform: http://logs.nosuchlabs.com/log/trilema/2019-08-22#1930033 << naively seems to asciilifeform that whole thing oughta be replaced with a single ring buffer, where 1) root can write 2) users can read (w/ settable max byte/sec quota/ea. perhaps) 3) erry read consumes a segment of the buffer, i.e. no 2 users get same chunk of FG tape 4) if buffer empties, machine goes into single-user mode and rings alarm .
asciilifeform: http://logs.nosuchlabs.com/log/trilema/2019-08-22#1930032 << to return to this : when asciilifeform laid out the (~8 y.o.!) kernel , to bake the 'demo' image for 'M' , found that ~whole thing~ is written in this style. ( last dealt with kernel internals at length in '06-07, when wasn't ~quite~ this nauseating . or perhaps my stomach were stronger..? )
asciilifeform: ( for the curious : 'erlang' had 0 'shared memory' b/w threads. all inter-thread motion was in the form of messages (received in 'atomic' queues internally). these could consist of whatever -- symbols (a la lisp) , for simple 'a/b/c' cases ; strings of bits; etc. a message could be eaten, or forwarded to yet another thread, or even sent back to the sender. )
asciilifeform: mircea_popescu: i keep coming back in my notes to the swedes, simply b/c in their notation, a 'bulletproof' net of mutually-synchronized bots is suddenly ~trivial.
asciilifeform: if the 'silent wedge' effect actually exists (rather than , say, an artifact of trinque's async mechanisms) i expect it will eventually be found to wedge
asciilifeform: spyked: mine disconnects strictly when a send() or recv() actually return eggog (i.e. indicating dead tcp pipe)
asciilifeform: by this merciless slicing, he was able to make so that almost entire state of a program is reducible to 'which threads are alive', and thus was able to achieve interesting results
asciilifeform: author (one armstrong, recently dead) sewed it by taking various fp langs of the time, and mercilessly cutting cpu-expensive features (e.g. the infamous np-complete reductor of prolog, the 'lazy' of haskell, etc)
asciilifeform: 'erlang' was ultra-fascist 'functional' , i.e. even to make variable in the usual sense is difficult
asciilifeform: mircea_popescu: i've a pile of'em in notebook, but generally dun like to throw in unless pertinent to thrd
asciilifeform: ( 'erlang' has a pretty martian syntax that most folx who didn't program in 'ml' or similar , dun have the digestive enzymes for )
asciilifeform: imho would be 9000x better to simply steal the technique and port to e.g. cmucl .
asciilifeform actually has working copy of that compiler, 'erlang' , from 2000s (i.e. before the webtards got to 'improving' it) if anyone at some pt wants to experiment with this particular sunken uboat
asciilifeform: http://logs.nosuchlabs.com/log/trilema/2019-08-22#1930071 << the swedes had a model of programming which asciilifeform always wanted to steal, which was especially good fit for cases like this -- '9000' ultralight threads with ~0 spawn/die penalty, if you wanted to wait for an event, could spawn thread that does nuffin but ( and in turn if times out sends correct signal to
asciilifeform: * deedbot has quit (Read error: Connection reset by peer) << trinque ??
asciilifeform: to where retire ssd? if still 'worx', e.g. trb node. lappies. if end of life ? stoke furnace. ( see mircea_popescu's piece with furnace. )
asciilifeform: decent card ( 3ware, more or less it ) means you can swap w/out switching off machine.
asciilifeform: 1tb ssd btw ~100bux nao. keep pile of spares, and dun hesitate to rotate prophylactically, they're a consumable.
