log☇︎
22300+ entries in 0.013s
mircea_popescu: now help me out here. is the answer "late aug/early sept i will publish my sept workplan which'll include a date at which i intend to publish the answer to that q" ?
snsabot: Logged on 2019-08-22 21:29:11 trinque: or alternatively, where's my patch spyked ?
mircea_popescu: look, it's no great mystery i don't think, but in any case, here's what i do : i read the log, line by line, in order. currently i'm processing line http://logs.nosuchlabs.com/log/trilema/2019-08-22#1930228
spyked: just didn't get to report in this month's report, because it happened yesterday.
spyked: mircea_popescu, no. feedbot is patched upon ircbot, not genesized (as per earlier log discussion), i.e. http://thetarpit.org/posts/y05/08a-feedbot-i.html ; http://thetarpit.org/posts/y05/08b-feedbot-ii.html ; http://thetarpit.org/posts/y05/08c-feedbot-iii.html ; this was planned to be the complete code, but sure, I'm testing the changes that I made and will publish a patch for it.
mircea_popescu: so is the idea feedbot gets abandoned a la lobbes' orig bot ?
spyked: e.g. right now the plan for september is to get thetarpit comments and new logger.
spyked: there is a longer term plan that I have at http://thetarpit.org/posts/y05/090-tmsr-work-ii.html , but experience shows that usually changes.
mircea_popescu: yes, that wasn't in discussion. but the current plan takes you to week 35, after which comes week 36 and a new plan ?
spyked: well, I made the last and only mod to it since http://thetarpit.org/posts/y05/08c-feedbot-iii.html yesterday; I am going to add it to the queue as it comes, right now I'm sticking to the current plan.
mircea_popescu: not necessarily. but you're running eg feedbot, you make improvements to it, nobody gets to see.
spyked: mircea_popescu, why should the output of weekly work be necessarily genesis? for now, it's a review of coad; the review will be followed by a genesis, as stated.
snsabot: Logged on 2019-08-22 21:48:34 trinque: the thing's literally built atop tcp which supposedly has "connections" and it wants this ping/pong mechanism atop. ask me how many more hours of my life I wish to dedicate to this duck cunt that just wants a bit more.
mircea_popescu: spyked, you know, it occurs to me your workplan is fundamentally weak in that it includes no "will genesis material / publish patches". am i guessing right in that the next edition, seeing how week 35 is just about the corner, will include prior plan performance review and that ?
snsabot: Logged on 2019-08-22 21:29:11 trinque: or alternatively, where's my patch spyked ?
mircea_popescu: http://logs.nosuchlabs.com/log/trilema/2019-08-22#1930228 << this is definitely a good q. /me goes to see on thetarpit.org, when's publishing scheduled.
mircea_popescu: so long as we don't exceed it by mass, it'll be the correct approach.
mircea_popescu: it's this device that transforms inca (circular motion) into republic (linear motion) by the principle of only permitting rotary motion in one direction, thereby using the inca mass against itself.
snsabot: Logged on 2019-08-22 21:38:59 trinque: more broadly, the question isn't so much what I could do with whatever IRC bot, it's what the hell should motivate me to sink more time into shit caked atop the thing I wish to see end.
snsabot: Logged on 2019-08-22 20:51:35 asciilifeform: mircea_popescu, lobbes , et al : prolly could easily purge ~100% of spam, simply by detecting these. lemme know if you want.
mircea_popescu: http://logs.nosuchlabs.com/log/trilema/2019-08-22#1930218 << nah. notice how these didn't exist on trilema except when specifically quoted. i let it go in eulora intentionally.
mircea_popescu: http://logs.minigame.biz/2018-09-22.log.html << maybe not, his logger shows most of them.
mircea_popescu: http://logs.nosuchlabs.com/log/trilema/2019-08-22#1930209 << it's likely this is because they got re-encoded on his end ; it's also the case nobody gives a shit.
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 )
trinque: they have python ones that don't need any such prosthetic
trinque: if I'm going to bolt znc to it, what point has a lisp bot?
asciilifeform: lobbes: aha. i made no attempt to clean out the spamola, it will remain unless mircea_popescu asks ' drop xyz where... ' etc
snsabot: Logged on 2019-08-22 20:51:35 asciilifeform: mircea_popescu, lobbes , et al : prolly could easily purge ~100% of spam, simply by detecting these. lemme know if you want.
lobbes: http://logs.nosuchlabs.com/log/trilema/2019-08-22#1930218 << 'tis mircea_popescu's chan, so his call. Though I imagine there is reason to keep them (e.g. maybe one day in the future someone wants to make a post re: "hey remember how IRC sucked?"). Point being: it was logged, so it is in the logs.
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 )
snsabot: Logged on 2019-08-22 21:51:18 trinque: bringing things in closer, apparently phf's in the hospital or something, and is thus persona non grata?
asciilifeform: http://logs.nosuchlabs.com/log/trilema/2019-08-22#1930234 << near as i can tell , mp drilled him a new arse and consigned him to штрафбат for cowering in a cave for yr+ , rather than for sitting in hospital. ( see also mp's 'nickel' article )
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
snsabot: Logged on 2019-08-22 21:38:59 trinque: more broadly, the question isn't so much what I could do with whatever IRC bot, it's what the hell should motivate me to sink more time into shit caked atop the thing I wish to see end.
asciilifeform: http://logs.nosuchlabs.com/log/trilema/2019-08-22#1930229 << ftr i agree entirely with this , but -- did write bot, when mp blew into the bugle, sometimes gotta be done
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 ) ?
trinque: bringing things in closer, apparently phf's in the hospital or something, and is thus persona non grata?
trinque: fuck me, drop the pretense and get on facebook messenger or w/e the kids use and be done with it
trinque: the thing's literally built atop tcp which supposedly has "connections" and it wants this ping/pong mechanism atop. ask me how many more hours of my life I wish to dedicate to this duck cunt that just wants a bit more.
snsabot: Logged on 2019-08-22 20:38:48 asciilifeform: ACHTUNG lobbes et al : the #e archive created earlier by lobbes , is now imported into http://logs.nosuchlabs.com/log/eulora . as usual plox to report any oddities .
trinque: more broadly, the question isn't so much what I could do with whatever IRC bot, it's what the hell should motivate me to sink more time into shit caked atop the thing I wish to see end.
trinque: do I start railing back about how this merry band is still relying on freenode for infrastructure or what
trinque: wtf lol, how would the bot spend a lot of time in the notification mechanism?
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.
snsabot: Logged on 2019-08-15 21:23:52 asciilifeform: 'I mean literally, the guy's from Washitistan, they write things with their own excrement there, and the Unicode Foundation introduced actual excrement in the standard so now whenever someone asks for the networking code in your project they are delivered physical faeces on cardboard. About fifty eight acres of it. Where would you like this put, sir ?' (tm)(r)(mp)
asciilifeform suspects that they were orig. encoded in http://logs.nosuchlabs.com/log/trilema/2019-08-15#1928981 and thereby didn't even get into lobbes's db
asciilifeform: ty for the converter fixes and archive, lobbes .
asciilifeform: orcograms appear to render 100% correctly .
asciilifeform: they are marked as 'era 2' in the db (#e has no 'era 1') .
asciilifeform: ACHTUNG lobbes et al : the #e archive created earlier by lobbes , is now imported into http://logs.nosuchlabs.com/log/eulora . as usual plox to report any oddities .
BingoBoingo: lobbes: ty, fxd
asciilifeform contemplates what a bvt-style dissection of the current 'urandom' might reveal.
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
asciilifeform: it seems like the obv. Right Thing. i.e. let tetris read from urandom, rsatron -- from random, etc.
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: asciilifeform, this is how linux should have worked.
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.
asciilifeform: ftr this is how i formerly thought the existing linux worked.
mircea_popescu: now, the magic numbers are only here by need of example.
asciilifeform: ok so the classical pair of 'random vs urandom' devs ?
mircea_popescu: asciilifeform, they are allowed to read I. that blocks.
mircea_popescu: if you do, you stretch it into a "many" bytes. if you don't, you just prng those many bytes.
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 )
mircea_popescu: that's why the two-hash system : you either have a byte of FG, to put into O, or you don't.
asciilifeform: ok then makes sense.
mircea_popescu: in exchange, they get non blocking "entropy" reads.
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
asciilifeform: ah so users who read moar than the available ration, get prngism?!
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: then in the first ms, the R head of O will have moved halway towards the W head of it.
mircea_popescu: now, the O buffer is, say, 2mb. if someone decides to read 1GB/s out of it,
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,
asciilifeform officially stumped re how to convert mircea_popescu's formalism into program. perhaps bvt will crack this nut ? presently it eludes me.
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.
asciilifeform: i'm stumped on what 'can not tell you, because you do not read' means in physical terms.
mircea_popescu: read that, don't ask me to type it again, wth.
mircea_popescu: i can not tell you, because you do not read.
mircea_popescu: whicjh is even tje point of having both rings.
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
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 )
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
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
mircea_popescu: then the buffer cycles continuously.
asciilifeform: possibly i'm thick, but what happens if particular user requests continuously ?
mircea_popescu: that's why i say o is up to swap size. ti should be large enough to not be emptyable.
mircea_popescu: asciilifeform, neh, hence the many.
asciilifeform: you still gotta rate-limit the users' reads tho, or 1 could empty whole thing in burst, starving the rest, neh