Forum logs for 22 Aug 2019
| 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:00] |
| 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:12] |
| 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:13] |
| lobbes: | sounds reasonable to me. aite, I'ma tell em' no raid I think | [00:15] |
| 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:16] |
| 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 ? | [00:18] |
| 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:45] |
| mircea_popescu: | considering the keys we use are 4kb, it seems reasonable we should keep entropy pools of no less than 16kb ? | [00:46] |
| 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:47] |
| mircea_popescu: | he did a pretty good job dissecting, imo | [00:48] |
| asciilifeform: | indeed | [00:48] |
| asciilifeform: | a++ pathologoanatomy | [00:48] |
| 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:54] |
| 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:55] |
| 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:56] |
| asciilifeform: | important point also -- ssd in raid never wins, only loses speed | [00:59] |
| 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:00] |
| asciilifeform: | 1tb ssd btw ~100bux nao. keep pile of spares, and dun hesitate to rotate prophylactically, they're a consumable. | [01:04] |
| asciilifeform: | decent card ( 3ware, more or less it ) means you can swap w/out switching off machine. | [01:05] |
| 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. ) | [01:08] |
| 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. | [04:45] |
| spyked: | I think I caught the bug. will fix by the end of the day and bring teh rss bot back up. | [05:20] |
| mircea_popescu: | could also say what it was neh ? | [06:49] |
| mircea_popescu: | o hai bimbo! | [07:00] |
| 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 | [07:02] |
| 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:39] |
| 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:47] |
| 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:50] |
| mircea_popescu: | oh | [07:51] |
| mircea_popescu: | this is bad design!! | [07:51] |
| 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:52] |
| mircea_popescu: | why doesnt the main program loop call the sender thing ONCE AT A TIME ? | [07:53] |
| 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:54] |
| 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:56] |
| 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. | [07:59] |
| mircea_popescu: | aha | [08:00] |
| feedbot: | http://trilema.com/2019/truth-or-dare-in-bed-with-madonna/ << Trilema -- Truth or Dare (in bed with Madonna) | [09:36] |
| 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:05] |
| 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:08] |
| asciilifeform: | mircea_popescu: 256 / 24.092 ~= 10.3 kB/s !! do you consistently get ~10kB/s from piz ?! | [11:10] |
| * asciilifeform | in gui browser with cleared cache -- consistently gets the expected 1.3s for that page here. | [11:12] |
| 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 | [11:16] |
| asciilifeform: | * deedbot has quit (Read error: Connection reset by peer) << trinque ?? | [12:10] |
| 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:16] |
| * 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:18] |
| 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:19] |
| 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:20] |
| 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:22] |
| 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:24] |
| mircea_popescu: | aha | [12:25] |
| 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:27] |
| 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:32] |
| asciilifeform: | spyked: mine disconnects strictly when a send() or recv() actually return eggog (i.e. indicating dead tcp pipe) | [12:35] |
| 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:36] |
| 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:40] |
| mircea_popescu: | aha. | [12:41] |
| 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. ) | [12:45] |
| 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:16] |
| asciilifeform: | open sores. | [13:17] |
| 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:22] |
| mircea_popescu: | nah, pretty sure you need two, to protect self from attrition attack | [13:23] |
| asciilifeform: | mircea_popescu: elaborate ? | [13:23] |
| 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:25] |
| 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:26] |
| 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:27] |
| 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:34] |
| 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:35] |
| 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:36] |
| 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:37] |
| 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:38] |
| 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:40] |
| 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:42] |
| 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:43] |
| 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:44] |
| mircea_popescu: | dude, I JUST EXPLAINED IT ABOVE | [13:45] |
| mircea_popescu: | read that, don't ask me to type it again, wth. | [13:45] |
| asciilifeform: | i'm stumped on what 'can not tell you, because you do not read' means in physical terms. | [13:46] |
| 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:47] |
| * 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:48] |
| 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:49] |
| 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:50] |
| 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:51] |
| 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:52] |
| 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:53] |
| 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:54] |
| 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:55] |
| * 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:56] |
| * asciilifeform | not yet eaten all of bvt's piece | [13:57] |
| 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:32] |
| BingoBoingo: | ^ In emergent lulz | [15:41] |
| mircea_popescu: | oya | [15:41] |
| lobbes: | http://qntra.net/2019/08/us-army-officer-found-not-builty-by-reason-of-insanity-in-joyriding-case/ << BingoBoingo: s/Builty/Guilty | [16:34] |
| BingoBoingo: | lobbes: ty, fxd | [16:35] |
| 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:38] |
| asciilifeform: | they are marked as 'era 2' in the db (#e has no 'era 1') . | [20:39] |
| 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:43] |
| 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:45] |
| asciilifeform: | ( possibly only on my console ? nfi ) | [20:46] |
| asciilifeform: | some spam dun show up at all | [20:47] |
| snsabot: | Logged on 2018-08-12 22:39:55 elky: | [20:47] |
| 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:48] |
| 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:51] |
| asciilifeform: | going by informal walk via 'random' button -- that spamola is a substantial % of the archive, by mass | [20:58] |
| asciilifeform: | ( the washitistan ??!?? + the randomly quoted lines from unknown heathen chans, + possibly other shannonized crapola ) | [20:59] |
| 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:01] |
| asciilifeform: | aaand of course 'era 1' of #t ( already discussed in orig. thread on trilema ) . | [21:02] |
| 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:03] |
| 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:14] |
| * 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:15] |
| trinque: | wtf lol, how would the bot spend a lot of time in the notification mechanism? | [21:25] |
| trinque: | do I start railing back about how this merry band is still relying on freenode for infrastructure or what | [21:28] |
| trinque: | or alternatively, where's my patch spyked ? | [21:29] |
| 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:38] |
| 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:45] |
| 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:48] |
| trinque: | fuck me, drop the pretense and get on facebook messenger or w/e the kids use and be done with it | [21:49] |
| trinque: | bringing things in closer, apparently phf's in the hospital or something, and is thus persona non grata? | [21:51] |
| 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:27] |
| 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:29] |
| 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:30] |
| 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:37] |
| 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:40] |
| 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:44] |
| 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. | [22:52] |
| asciilifeform: | lobbes: aha. i made no attempt to clean out the spamola, it will remain unless mircea_popescu asks ' drop xyz where... ' etc | [23:16] |
| trinque: | if I'm going to bolt znc to it, what point has a lisp bot? | [23:59] |
Category: Logs
