Show Idle (>14 d.) Chans
← 2019-08-21 | 2019-08-23 → ↓
00:00 mircea_popescu http://logs.nosuchlabs.com/log/trilema/2019-08-20#1929954 << there's certainly substance to that "also failing her" portion.
00:00 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.
00:12 lobbes wb to somewhat-civilisation mircea_popescu
00:12 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?
00:13 mircea_popescu raid was immensely useful for the older drives. with ssds its' not clear you gain so much in either speed or reliability
↖
00:13 mircea_popescu in any case, there's not much point to two disk raid arrays ; nor to software raid.
00:15 lobbes sounds reasonable to me. aite, I'ma tell em' no raid I think
00:16 lobbes once this thing is up I'll probably be asking in #a (unless #mod6 still lives?) about doing a 'hot-start' with trb
00:16 lobbes will also spin up a copy of alf's logger
00:18 mircea_popescu bvt 's story of linux kernel retardation is eyewatering.
↖
00:18 mircea_popescu could you simply throw out the whole damn thing and replace with from-scratch random.c / h ?
↖
~ 26 minutes ~
00:45 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.
00:45 mircea_popescu incidentally, the fucking notion of a byte-counted entropy pool is fucking ridiculous.
00:46 mircea_popescu considering the keys we use are 4kb, it seems reasonable we should keep entropy pools of no less than 16kb ?
00:47 asciilifeform mircea_popescu: nao you know why i skipped the ' feed linux random ' stack entirely in '16. ( admittedly didn't get even half as far as bvt before barfed )
00:48 mircea_popescu he did a pretty good job dissecting, imo
00:48 asciilifeform indeed
00:48 asciilifeform a++ pathologoanatomy
00:54 asciilifeform http://logs.nosuchlabs.com/log/trilema/2019-08-22#1930027 << i run (iron) raid w/ ssd, but must point out, i rotate'em
00:54 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
00:54 mircea_popescu and 4 ? or 6 ?
00:55 asciilifeform ( i.e. prophylactically pull one erry yr or so and insert fresh replacement )
00:55 asciilifeform 4 is the min. that makes any sense
00:55 mircea_popescu quite.
00:56 asciilifeform algo -- simple, you pull the 1 that a) has nonzero write failure counter, or if none such, b) the one with highest blocks-written count .
00:59 asciilifeform important point also -- ssd in raid never wins, only loses speed
01:00 asciilifeform 'gain speed' applied strictly to mech hdd, they could be spun out of phase, i.e. cut seek time
01:00 asciilifeform seek on ssd already ~0.
01:04 asciilifeform 1tb ssd btw ~100bux nao. keep pile of spares, and dun hesitate to rotate prophylactically, they're a consumable.
01:05 asciilifeform decent card ( 3ware, more or less it ) means you can swap w/out switching off machine.
01:08 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. )
~ 3 hours 37 minutes ~
04:45 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.
~ 35 minutes ~
05:20 spyked I think I caught the bug. will fix by the end of the day and bring teh rss bot back up.
~ 1 hours 28 minutes ~
06:49 mircea_popescu could also say what it was neh ?
07:00 mircea_popescu o hai bimbo!
07:02 nicoleci mircea_popescu, helllo :)
07:02 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
07:02 lobbesbot nicoleci: Sent 3 weeks, 3 days, 14 hours, and 48 minutes ago: <mp_en_viaje> http://p.bvulpes.com/pastes/4Ug9B/?raw=true
07:02 mircea_popescu spyked, feed bot quit on me again lol
~ 36 minutes ~
07:39 mircea_popescu asciilifeform, got 1 for you : $ time curl http://logs.nosuchlabs.com/log/trilema/2018-10-12#1861054 > real 0m24.902s user0m0.011s
↖
07:39 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.
07:47 spyked mircea_popescu, meanwhile I found it wasn't the issue I initially thought! I'ma bring the bot back online shortly
07:47 mircea_popescu kk
07:50 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.
↖
07:51 mircea_popescu oh
07:51 mircea_popescu this is bad design!!
07:52 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
07:53 mircea_popescu why doesnt the main program loop call the sender thing ONCE AT A TIME ?
07:54 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
↖
07:56 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.
07:56 mircea_popescu yeah ok
07:59 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.
08:00 mircea_popescu aha
~ 1 hours 36 minutes ~
09:36 feedbot http://trilema.com/2019/truth-or-dare-in-bed-with-madonna/ << Trilema -- Truth or Dare (in bed with Madonna)
~ 1 hours 28 minutes ~
11:05 asciilifeform http://logs.nosuchlabs.com/log/trilema/2019-08-22#1930062 << 4.1s here (1.3 if curl -H "Accept-Encoding: gzip" , weighs 256k naked, 58 w/ gzip )
11:05 snsabot Logged on 2019-08-22 07:39:04 mircea_popescu: asciilifeform, got 1 for you : $ time curl http://logs.nosuchlabs.com/log/trilema/2018-10-12#1861054 > real 0m24.902s user0m0.011s
11:05 asciilifeform mircea_popescu: what do you get when http://18.195.64.227/log/trilema/2018-10-12#1861054 ?
11:08 asciilifeform ftr , on dulap itself : time curl http://127.0.0.1:5002/log/trilema/2018-10-12 > /dev/null yields 0.161s .
11:08 asciilifeform ( i.e. how long takes to actually birth that page )
11:10 asciilifeform mircea_popescu: 256 / 24.092 ~= 10.3 kB/s !! do you consistently get ~10kB/s from piz ?!
11:12 * asciilifeform in gui browser with cleared cache -- consistently gets the expected 1.3s for that page here.
11:16 mircea_popescu .441 s
11:16 mircea_popescu 400-ish anyways
11:16 asciilifeform this from frankfurt ?
11:16 mircea_popescu the 18. a class you quited yes
11:16 asciilifeform aha, frankfurt copy
~ 53 minutes ~
12:10 asciilifeform * deedbot has quit (Read error: Connection reset by peer) << trinque ??
12:16 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
12:16 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
12:16 snsabot Logged on 2019-08-11 20:36:42 asciilifeform: looked even at ancient rusty 'five nines' behemoths that apparently work , for potential dusting off a la gnat.
12:16 asciilifeform parent ) etc.
12:18 * 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
12:19 asciilifeform imho would be 9000x better to simply steal the technique and port to e.g. cmucl .
↖ ↖
12:19 mircea_popescu this is the first time i hear of some actually useful lisp improvement
12:19 asciilifeform ( 'erlang' has a pretty martian syntax that most folx who didn't program in 'ml' or similar , dun have the digestive enzymes for )
12:20 mircea_popescu logically, it'd be exactly the sort of spitshine fit for its shoes.
12:20 asciilifeform mircea_popescu: i've a pile of'em in notebook, but generally dun like to throw in unless pertinent to thrd
12:20 mircea_popescu makes sense
12:20 mircea_popescu but yes, functional language should be able to get closest to your 0 penalty.
12:20 asciilifeform 'erlang' was ultra-fascist 'functional' , i.e. even to make variable in the usual sense is difficult
12:22 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)
12:24 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
12:24 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
12:25 mircea_popescu aha
12:27 asciilifeform phunphakt -- ericsson at one pt sacked him and ordered their pbx rewritten in cpp. and nearly tanked, had to beg him to come back.
12:27 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% .
12:32 asciilifeform http://logs.nosuchlabs.com/log/trilema/2019-08-22#1930066 << ftr i've yet to observe this 'silent wedge' effect in my bot (i.e. where the tcp pipe is 'alive' but not doing anyffin useful). tbf it is, what, only 3rd week of this bot.
12:32 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.
12:35 asciilifeform spyked: mine disconnects strictly when a send() or recv() actually return eggog (i.e. indicating dead tcp pipe)
↖
12:36 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
12:36 asciilifeform !q uptime
12:36 snsabot asciilifeform: time since my last reconnect : 6d 2h 12m
12:36 asciilifeform ^ thus far only planned resets .
12:40 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.
12:41 mircea_popescu aha.
12:45 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. )
~ 30 minutes ~
13:16 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..? )
13:16 snsabot Logged on 2019-08-22 00:18:27 mircea_popescu: bvt 's story of linux kernel retardation is eyewatering.
13:16 mircea_popescu "open source"
13:17 asciilifeform open sores.
13:22 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 .
13:22 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 ?
13:23 mircea_popescu nah, pretty sure you need two, to protect self from attrition attack
13:23 asciilifeform mircea_popescu: elaborate ?
13:25 asciilifeform ( what means here 'attrition' ? and for what is the 2nd buffer ? )
13:25 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
↖
13:26 mircea_popescu this outer ring should use two cprngs to stretch the flow-in, one fast and one good.
13:26 mircea_popescu such that the outer ring is always full, and the inner ring is always good.
13:26 mircea_popescu is this comprehensible ?
13:27 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 ?
13:27 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
13:27 mircea_popescu let me formalize this, 1sec.
13:34 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.
13:34 mircea_popescu hash functions : Fast (takes one byte, produces many bytes), Good (takes one byte, produces one byte).
13:34 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.
13:34 mircea_popescu this way - O is "always full" from the pov of userland ; I is protected from userland reading O.
13:35 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
13:35 asciilifeform you still gotta rate-limit the users' reads tho, or 1 could empty whole thing in burst, starving the rest, neh
13:36 mircea_popescu asciilifeform, neh, hence the many.
13:36 mircea_popescu that's why i say o is up to swap size. ti should be large enough to not be emptyable.
13:37 asciilifeform possibly i'm thick, but what happens if particular user requests continuously ?
13:37 mircea_popescu then the buffer cycles continuously.
13:37 asciilifeform 1 FG gives ~7.5kB/s . it isn't difficult to read , from buffer, GB/s
13:37 mircea_popescu HF "many" setting could in principle be 1 byte -> buffer size
13:38 asciilifeform or is the idea that there's a per-user buffer which actually contains his ration, and reads block on ~that~ ?
13:38 mircea_popescu nope.
13:38 mircea_popescu O reads do not block.
13:40 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 ?
13:42 mircea_popescu but use my formalisms. so what, I is 16kb and O is 2mb ?
13:42 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
13:43 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 )
13:43 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
13:43 mircea_popescu asciilifeform, only applicable re I. O, never blocks, because H.
13:44 mircea_popescu whicjh is even tje point of having both rings.
13:44 asciilifeform so, in mircea_popescu's model, i asked for 3MB, while FG has only produced yet 2MB. what do i get ?
13:44 mircea_popescu i can not tell you, because you do not read.
13:44 asciilifeform i.e. eggog ?
13:45 mircea_popescu dude, I JUST EXPLAINED IT ABOVE
13:45 mircea_popescu read that, don't ask me to type it again, wth.
13:46 asciilifeform i'm stumped on what 'can not tell you, because you do not read' means in physical terms.
↖
13:47 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.
13:48 * asciilifeform officially stumped re how to convert mircea_popescu's formalism into program. perhaps bvt will crack this nut ? presently it eludes me.
13:48 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,
13:49 mircea_popescu now, the O buffer is, say, 2mb. if someone decides to read 1GB/s out of it,
13:49 mircea_popescu then in the first ms, the R head of O will have moved halway towards the W head of it.
13:49 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.
13:49 mircea_popescu thus replenishing what was read.
13:50 asciilifeform ah so users who read moar than the available ration, get prngism?!
13:50 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
13:50 mircea_popescu asciilifeform, users who read O, get prng
13:50 asciilifeform aaa.
13:50 mircea_popescu in exchange, they get non blocking "entropy" reads.
13:50 asciilifeform ok then makes sense.
13:51 mircea_popescu yay.
13:51 mircea_popescu that's why the two-hash system : you either have a byte of FG, to put into O, or you don't.
13:51 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 )
13:51 mircea_popescu if you do, you stretch it into a "many" bytes. if you don't, you just prng those many bytes.
13:51 mircea_popescu asciilifeform, they are allowed to read I. that blocks.
13:52 mircea_popescu entirely userland option.
13:52 asciilifeform ok so the classical pair of 'random vs urandom' devs ?
13:52 mircea_popescu exactly.
13:52 asciilifeform then makes sense. i had missed 'stretched by...' when 1st reading.
13:52 mircea_popescu right ?
13:52 mircea_popescu now, the magic numbers are only here by need of example.
13:52 asciilifeform ftr this is how i formerly thought the existing linux worked.
13:53 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.
13:53 mircea_popescu asciilifeform, this is how linux should have worked.
13:54 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.
13:54 asciilifeform it seems like the obv. Right Thing. i.e. let tetris read from urandom, rsatron -- from random, etc.
13:54 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
13:55 mircea_popescu nothing prohibits proggy reading 2mb ring buffer at gb/s speeds. it'll get... well, a lotta hashmaterial.
13:55 mircea_popescu which is imo exaclty right.
13:56 * asciilifeform contemplates what a bvt-style dissection of the current 'urandom' might reveal.
13:56 mircea_popescu heh.
13:56 asciilifeform oh hrm actually he does have a segment re subj
13:57 * asciilifeform not yet eaten all of bvt's piece
~ 1 hours 35 minutes ~
15:32 feedbot http://qntra.net/2019/08/philadelphia-home-defender-who-shot-6-cops-allegedly-federal-snitch-violence-likely-intrausg-dispute/ << Qntra -- Philadelphia Home Defender Who Shot 6 Cops Allegedly Federal Snitch, Violence Likely IntraUSG Dispute
15:41 BingoBoingo ^ In emergent lulz
15:41 mircea_popescu oya
~ 52 minutes ~
16:34 lobbes http://qntra.net/2019/08/us-army-officer-found-not-builty-by-reason-of-insanity-in-joyriding-case/ << BingoBoingo: s/Builty/Guilty
16:35 BingoBoingo lobbes: ty, fxd
~ 4 hours 3 minutes ~
20:38 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 .
↖
20:39 asciilifeform they are marked as 'era 2' in the db (#e has no 'era 1') .
20:43 asciilifeform orcograms appear to render 100% correctly .
20:43 snsabot Logged on 2016-12-06 08:51:15 mircea_popescu: !~calc 137×999*1.52*2
20:43 asciilifeform ty for the converter fixes and archive, lobbes .
20:45 asciilifeform hrm, correctly but with exception of certain spam lol
↖
20:45 snsabot Logged on 2018-09-03 17:59:44 c111: Alⅼah ⅰs doing
20:46 asciilifeform ( possibly only on my console ? nfi )
20:47 asciilifeform some spam dun show up at all
20:47 snsabot Logged on 2018-08-12 22:39:55 elky:
20:48 asciilifeform these ^ however are empty in lobbes's orig. archive snapshot.
20:48 * 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
20:48 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)
20:51 asciilifeform http://logs.nosuchlabs.com/log/eulora/2018-09-22 << ugh
20:51 asciilifeform mircea_popescu, lobbes , et al : prolly could easily purge ~100% of spam, simply by detecting these. lemme know if you want.
↖ ↖
20:58 asciilifeform going by informal walk via 'random' button -- that spamola is a substantial % of the archive, by mass
20:59 asciilifeform ( the washitistan ??!?? + the randomly quoted lines from unknown heathen chans, + possibly other shannonized crapola )
21:01 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 )
21:02 asciilifeform aaand of course 'era 1' of #t ( already discussed in orig. thread on trilema ) .
21:03 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 .
21:14 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.
21:15 * 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
21:25 trinque wtf lol, how would the bot spend a lot of time in the notification mechanism?
↖
21:28 trinque do I start railing back about how this merry band is still relying on freenode for infrastructure or what
21:29 trinque or alternatively, where's my patch spyked ?
↖ ↖ ↖
21:38 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.
↖ ↖ ↖
21:45 lobbes http://logs.nosuchlabs.com/log/trilema/2019-08-22#1930204 << win!
21:45 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 .
21:48 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.
↖
21:49 trinque fuck me, drop the pretense and get on facebook messenger or w/e the kids use and be done with it
↖
21:51 trinque bringing things in closer, apparently phf's in the hospital or something, and is thus persona non grata?
↖ ↖
~ 35 minutes ~
22:27 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 ) ?
22:29 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
22:29 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.
22:30 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
22:37 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 )
22:37 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?
22:40 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 )
↖
22:44 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
22:52 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.
22:52 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.
~ 24 minutes ~
23:16 asciilifeform lobbes: aha. i made no attempt to clean out the spamola, it will remain unless mircea_popescu asks ' drop xyz where... ' etc
~ 43 minutes ~
23:59 trinque if I'm going to bolt znc to it, what point has a lisp bot?
↖ ↖
← 2019-08-21 | 2019-08-23 → ↑

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

Theme: Light | Dark | System Default