Forum logs for 01 Aug 2018
| diana_coman: | BingoBoingo, thanks! confirmed back on + 1 fg available unfortunately the simple test from smg_rsa (./tests 11 11 ) still hangs | [04:04] |
| diana_coman: | I start suspecting it's maybe something to do with short+frequent reads as weirdly enough tests that read 4096 bytes seem... fine | [04:07] |
| diana_coman: | well, uhm, scratch that, I just got one of those stuck too, lol it took longer to get stuck, nothing else | [04:08] |
| asciilifeform: | diana_coman: i've built eucrypt and replicated your hang | [09:41] |
| diana_coman: | asciilifeform, any clue as to cause? | [09:42] |
| diana_coman: | on what machine is this? | [09:43] |
| asciilifeform: | dulap | [09:43] |
| asciilifeform: | not discovered culprit yet, literally 5min ago finished pressing & building ( used ave1's gcc , for completeness ) | [09:43] |
| diana_coman: | aha good to know at least it's not *just* that machine might be worth to try replicating the dd hang as well , although by now I expect it will happen | [09:45] |
| asciilifeform: | diana_coman: what was the exact process for dd hang ? | [09:45] |
| asciilifeform: | ( fwiw i've dd's from dulap's FGs previously, with 0 signs of any problem ) | [09:46] |
| asciilifeform: | this box is running traditional gentoo, however, it more closely resembles primary s.mg machine than the test box | [09:46] |
| diana_coman: | machine with 2 fgs reboot without init of any fgs stty on only one fg dd on that fg | [09:46] |
| diana_coman: | the first time it usually hangs | [09:46] |
| diana_coman: | dd seems to be more resilient but I suspect it's mainly because it's not that sort of little&frequent | [09:47] |
| diana_coman: | i.e. if you run the eucrypt tests 0 or 1 that read more they tend to take longer to get to the hang (although they still do eventually) | [09:48] |
| diana_coman: | fwiw same tests of eucrypt ran perfectly fine on all machines I have around here with fgs | [09:48] |
| asciilifeform: | hm, over here dd ( with only 1 FG init'd ) is working correctly | [09:49] |
| asciilifeform: | eucrypt's test reliably hangs, however, ~every other run | [09:50] |
| asciilifeform: | 1048576 bytes (1.0 MB, 1.0 MiB) copied, 151.838 s, 6.9 kB/s << | [09:50] |
| asciilifeform: | ^ dd | [09:50] |
| diana_coman: | a bit slow though? | [09:51] |
| asciilifeform: | not really, the nominal production is 7 | [09:51] |
| diana_coman: | anyways, if you find something the matter specifically with eucrypt code, I'd be quite happy really since it's easiest to fix tbh | [09:51] |
| asciilifeform: | ( evidently the dc has pretty good cooling ) | [09:51] |
| diana_coman: | hm, I usually get that above 7, closer to 8 | [09:51] |
| asciilifeform: | it's not a constant rate, 7 is the empirical avg., and depends on environmental temp | [09:52] |
| diana_coman: | anyways, dd hangs *sometimes*, harder to pin down ftr I DID go and read the dd code too but I can't say I'm any wiser as to why/how it is more resilient | [09:52] |
| asciilifeform: | well the 1 obvious diff, is that it defaults to 512byte blocks | [09:53] |
| asciilifeform: | and reads from buffered tty | [09:53] |
| diana_coman: | hence my diana_coman> dd seems to be more resilient but I suspect it's mainly because it's not that sort of little&frequent | [09:53] |
| asciilifeform: | aha | [09:53] |
| diana_coman: | but a. WHY don't I have same trouble on any of the machines here b. WHY does it hang anyway c. wtf do I do | [09:55] |
| asciilifeform: | diana_coman: ok, finally managed to get a stuck dd | [09:57] |
| diana_coman: | a-ha | [09:57] |
| asciilifeform: | i suspect an oddity with the linux tty subsystem. the Right Thing solution would be to find it. the alternative, ugly solution, is 1) 512 byte buffered reads 2) with timeout . | [09:58] |
| asciilifeform: | so far can't think of a third. | [09:58] |
| asciilifeform: | fwiw dd never stuck midway, only on opening tty. | [09:59] |
| asciilifeform: | 0 bytes copied, 99.8535 s, 0.0 kB/s | [10:00] |
| asciilifeform: | ^ 1 run | [10:00] |
| asciilifeform: | 1048576 bytes (1.0 MB, 1.0 MiB) copied, 150.483 s, 7.0 kB/s | [10:00] |
| asciilifeform: | ^ subsequent | [10:01] |
| asciilifeform: | ( the former, ctrl-c'd ) | [10:01] |
| asciilifeform: | note that FG outputs not only random bytes, but at random ~rate~ . currently i wonder if we've unearthed an 'impedence mismatch' in linux tty. | [10:02] |
| asciilifeform: | no other device does the random ~rate~ thing. | [10:03] |
| asciilifeform: | possibly asciilifeform is doomed to write the FG-reading daemon after all. | [10:05] |
| asciilifeform: | ( observe, if tty ~does~ successfully open, can read 4evah, i had one dd going for 6 months without problem ) | [10:06] |
| diana_coman: | <asciilifeform> i suspect an oddity with the linux tty subsystem. the Right Thing solution would be to find it. the alternative, ugly solution, is 1) 512 byte buffered reads 2) with timeout . -> this is pretty much my current understanding as well | [10:12] |
| diana_coman: | but I'm not comfortable with not knowing wtf in there because it has the potential to blow up very nastily indeed | [10:12] |
| diana_coman: | fwiw eucrypt always gets stuck on the actual "read(" | [10:13] |
| asciilifeform: | diana_coman: i'ma have to do a detailed dig in re the linux tty thing. but this could take a while, and no guarantee of finding culprit in the 100s of MB of open sores liquishit. so you will need the buffer+timeout thing, i suspect. | [10:17] |
| asciilifeform: | ( oughta log the timeouts ) | [10:17] |
| diana_coman: | I'm going to dig around a bit more too to see if I can find any more clues of sorts | [10:19] |
| diana_coman: | but yes, this is certainly not going to get solved in 1-2 days by the looks of it | [10:19] |
| asciilifeform: | the ideal ugly-an'-reliable pill is prolly a demon that reads both FG 24/7 and alarms if rate is substantially below rated | [10:19] |
| diana_coman: | myeah, as battlefield solution that might be the direction to take | [10:20] |
| asciilifeform: | i ~would~ prefer a sanely-behaving OS. unfortunately i dun have one up my sleeve. | [10:21] |
| * asciilifeform | brb,teatime | [10:21] |
| diana_coman: | enjoy! | [10:21] |
| * asciilifeform | back | [11:25] |
| asciilifeform: | diana_coman: lulzily, turns out that our horror show is not unknown, https://archive.fo/kRfZy ( spoiler: none of the proposed pills, have any effect | [11:42] |
| asciilifeform: | ) | [11:42] |
| diana_coman: | oh joy | [11:43] |
| Mocky: | whoa, haven't seen that trilema.com header before | [11:51] |
| Mocky: | super happy, lol | [11:52] |
| asciilifeform: | diana_coman: i confirmed ( coupla dozen shots ) hang only ever takes place on 1st read() after open(). | [12:00] |
| asciilifeform: | diana_coman: further pl2303 mod lulz, https://archive.is/CefaN | [12:03] |
| diana_coman: | asciilifeform, ah,ah, the "modprobe -r " lulz, yes | [12:03] |
| asciilifeform: | 'After much researching it seems this is NOT a driver bug but a CHANGE in the kernel Serial API semantics. What has happened is that the API now blocks when a Serial device is not indicating it is ready. This included 'open' on a serial device which now can block. Since lots of RS232 serial devices do not bother with any control signals such as DCD (data carrier detect) they never indicate they are ready and open blocks. This is the | [12:03] |
| asciilifeform: | 'HANG' we are seeing' | [12:03] |
| asciilifeform: | ^ suggests shitgnomery | [12:03] |
| asciilifeform: | the given 'solution' is absolutely prohibited for FG, tho, it ~must~ operate as blocking read | [12:04] |
| diana_coman: | ugh, uglier and uglier | [12:06] |
| asciilifeform: | confirms my earlier suspicion tho. | [12:07] |
| asciilifeform: | 2 possible tacks -- 1) kill, with flamethrower, 'new api' 2) FG opened once per machine boot and left running into buffer | [12:08] |
| asciilifeform: | i'ma let mircea_popescu say, whether Right Thing is to start with (2) and proceed to (1), or straight to (1) . | [12:09] |
| diana_coman: | myeah, 1 promises to eat up a lot of time | [12:09] |
| mircea_popescu: | http://btcbase.org/log/2018-08-01#1838608 << incidentally, maybe the correct move re the day's ninjashogun would be to redirect them to whatever castle one feels like ? trilema-mod6 or such. | [12:13] |
| a111: | Logged on 2018-08-01 02:55 mod6: douchebag wants the mic | [12:13] |
| mircea_popescu: | speaking of which, i wonder how that fellow's business/revolutionary/technico-theoretical/etc idea is faring these days. | [12:13] |
| mircea_popescu: | http://btcbase.org/log/2018-08-01#1838691 << da fuck buffered state machine, defeats the whole purpose of the thing. | [12:16] |
| a111: | Logged on 2018-08-01 13:58 asciilifeform: i suspect an oddity with the linux tty subsystem. the Right Thing solution would be to find it. the alternative, ugly solution, is 1) 512 byte buffered reads 2) with timeout . | [12:16] |
| diana_coman: | mircea_popescu, read on for...deeper uncovered shit | [12:17] |
| mircea_popescu: | on it. | [12:17] |
| mircea_popescu: | http://btcbase.org/log/2018-08-01#1838720 << ahahaha | [12:20] |
| a111: | Logged on 2018-08-01 15:52 Mocky: super happy, lol | [12:20] |
| asciilifeform: | btw, diana_coman , mircea_popescu , there's visible sys log barf from pl2303 when operating diana_coman's test : | [12:31] |
| asciilifeform: | [8621835.122044] pl2303 ttyUSB0: pl2303_get_line_request - failed: -110 | [12:31] |
| asciilifeform: | [8621835.122919] pl2303 ttyUSB0: pl2303_set_line_request - failed: -32 | [12:31] |
| asciilifeform: | [8621835.463377] pl2303 ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32 | [12:31] |
| asciilifeform: | diana_coman: do you observe same on your box ? | [12:33] |
| mod6: | guy says '<douchebag> can I be upped? I have some productive things to say' in PM, and I think "hmm. alright" | [12:33] |
| diana_coman: | asciilifeform, I certainly say the last line, don't recall the first 2 but I might have missed them | [12:33] |
| diana_coman: | lemme see again | [12:33] |
| mod6: | it never fails. answering the door just doesn't work out too well for ole mod6 | [12:33] |
| mod6: | begone fuckwads | [12:33] |
| asciilifeform: | mod6: lol, 'productive things' | [12:34] |
| diana_coman: | "productive things to say " lol | [12:34] |
| asciilifeform: | d00d could 'productive' any fucking time he feels like it. | [12:34] |
| asciilifeform: | but not holding breath. | [12:34] |
| mod6: | i should have just ignored. typically I do. | [12:35] |
| mod6: | thought he might wanna talk about his rockchip, so was willing to give him the chance. | [12:36] |
| mod6: | WRONG | [12:36] |
| mod6: | shit on the rug in the foyer. | [12:36] |
| asciilifeform: | 'most people are just going to go with a cheaper & higher performance alternative' dontchaknow. | [12:36] |
| diana_coman: | mod6, I'd say don't worry about it as a rule though productive people do stuff, not as if they need to "say" productively things | [12:36] |
| diana_coman: | asciilifeform, I get as I recalled this "[63939.499700] pl2303 ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32" but I don't see the others, hmm | [12:37] |
| diana_coman: | that one I got even 8 times in a row there | [12:37] |
| asciilifeform: | diana_coman: the line_request one is sporadic ( erry dozen or so runs ) | [12:37] |
| diana_coman: | ah, that might explain why I haven't yet noticed it | [12:38] |
| mircea_popescu: | modprobe -r option << does ditching the "option" bs do anything ? | [12:41] |
| mircea_popescu: | seems like a fine candidate for cuntoo banlist, if so. | [12:41] |
| asciilifeform: | mircea_popescu: we dun have this item to begin with | [12:42] |
| asciilifeform: | ( at least dulap kernel -- does not ) | [12:42] |
| mircea_popescu: | usure ? | [12:42] |
| mircea_popescu: | as in, "i checked, we don't have" or as in "we couldn't possibly have something this fucking stupid o oops there it is how the hell did it sneak in" | [12:43] |
| asciilifeform: | dulap ~ # zcat /proc/config.gz | grep CONFIG_USB_SERIAL_OPTION | [12:43] |
| asciilifeform: | # CONFIG_USB_SERIAL_OPTION is not set | [12:43] |
| mircea_popescu: | kk | [12:43] |
| mircea_popescu: | this is looking more and more like we're going to have to write a pl replacement does it | [12:44] |
| asciilifeform: | 'usb_serial_generic_read_bulk_callback - urb stopped: -32' specifically, reported also for other usb2ttl chipsets, incl ftdi | [12:48] |
| asciilifeform: | bug may very well be an interaction with upstream linux usb subsys | [12:49] |
| asciilifeform: | ( https://archive.is/sYqkk for dedicated entomologist ) | [12:50] |
| asciilifeform: | supposedly, forcing usb1 speed for whole jack, curative | [12:51] |
| asciilifeform: | ( not tried yet ) | [12:51] |
| asciilifeform: | dwc_otg.speed=1 on kernel param line. | [12:53] |
| mircea_popescu: | still tbh i'm kinda pleased with how this ratchet works. mystery meat in fg-machine interaction had to await s.mg to be found. item's been out what, years, undergone all sorta testing... | [12:54] |
| asciilifeform: | ok confirmed, forcing usb1 cures | [12:59] |
| asciilifeform: | http://p.bvulpes.com/pastes/xAQ4U/?raw=true << manual example , testable without rebooting kernel | [13:00] |
| asciilifeform: | dozen runs of diana_coman's test all work | [13:00] |
| asciilifeform: | ( forcing 12MB/s usb1 speed has no effect on FG performance, even 10 FG on 1 jack falls considerably below the max usb1 rate ) | [13:01] |
| asciilifeform: | diana_coman ^ | [13:02] |
| asciilifeform: | ( the above is == to the 'Tip for Linux Users' item in http://nosuchlabs.com/hardware.html , which i listed as workaround for 'more than 3 pl2303' infamous bugola ) | [13:04] |
| mircea_popescu: | not like we use usb for anything else anyway, so this may well work ad interim. | [13:05] |
| asciilifeform: | fwiw asciilifeform's official FG tester rig runs always in this mode. | [13:05] |
| mircea_popescu: | asciilifeform is there some way to connect as a tty bypass the usb altogether ? i really dun wanna include usb if can be helped. | [13:05] |
| asciilifeform: | mircea_popescu: there's no ttl serial on pc mobo | [13:06] |
| * mircea_popescu | adds to wishlist for eventual fab. | [13:06] |
| asciilifeform: | mircea_popescu: there is sometimes 1 or even 2 rs232 ports , but they go at -12v/+12v , and needs level shifter, which in turn oscillates, and potentially pollutes rng | [13:06] |
| deedbot: | http://trilema.com/2018/qntra-sqntr-july-2018-statement/ << Trilema - Qntra (S.QNTR) July 2018 Statement | [13:07] |
| asciilifeform: | mircea_popescu: fwiw rockchip and similar boards actually include several ttl-level serial ports. | [13:07] |
| mircea_popescu: | myeah | [13:07] |
| asciilifeform: | pc is the hardcore tard reservation. | [13:08] |
| asciilifeform: | ( i've yet to find ~one~ pc board, of any vintage, with ttl ports ) | [13:08] |
| asciilifeform: | usb is a massive cistern of liquishit, with all kinds of corner-case breakages, see also http://btcbase.org/log/2014-02-21#520765 . it Must Die. | [13:10] |
| a111: | Logged on 2014-02-21 03:28 asciilifeform: usb is a highly-stateful protocol with a book-length standard | [13:10] |
| mod6: | !!sent-invoices | [13:19] |
| deedbot: | http://p.bvulpes.com/pastes/YRYRx/?raw=true | [13:19] |
| asciilifeform: | usb is evil in 9000 ways. not only the ridiculous complexity, which makes it impractical to use with ~simple~ microcontrollers, msdos boxen, etc. but also the fact that it is impossible to make a ~transmit only~ (or , for that matter, receive-only) usb device, they are mandatorily stateful. which is the fundamental reason why asciilifeform refused to put a usb chip on FG proper. | [13:24] |
| asciilifeform: | FG is transmit-only. there is literally nothing the attached pc can do ~to~ it, other than cycle the +5 supply ( and even this, strictly if the +5 supply is tied to the pc's ) | [13:25] |
| asciilifeform: | thing eats 8ma, could easily run off, e.g., solar cell in a well-lit room. | [13:30] |
| asciilifeform: | diana_coman: usb1 switchover also confirmed to cure log barfola. | [13:31] |
| asciilifeform: | diana_coman, mircea_popescu lemme know if the given cure, is curative. ( no change to diana_coman's coad is needed ) | [13:48] |
| asciilifeform: | incidentally, there is also a potential iron cure, currently FG at pizarro are attached to miniature usb2 hubs. ( asciilifeform was not able to source pure usb1 hubs, but potentially these exist somewhere. ) | [13:51] |
| deedbot: | http://qntra.net/2018/08/vandalia-outdoors-retailer-hit-by-multi-agency-usg-raid/ << Qntra - Vandalia Outdoors Retailer Hit By Multi Agency USG Raid | [14:31] |
| diana_coman: | oh hey, asciilifeform that cure seems to work | [14:53] |
| diana_coman: | so basically that's not for "if more than 2" but rather "always do it" | [14:54] |
| diana_coman: | for future ref: echo first barfed with "invalid argument" it turns out it was appending a newline so it had to be "echo -n portnumber > ..." | [14:55] |
| asciilifeform: | diana_coman: interestingly, in my (conventional gentoo) userland, worked as posted ( i.e. with the newline ) | [14:57] |
| diana_coman: | this was on the smg test machine | [15:00] |
| asciilifeform: | aaha so cuntoo | [15:00] |
| asciilifeform: | diana_coman: you'll probably want to make it happen on boot. | [15:01] |
| diana_coman: | makes sense how do I do that best on gentoo? still line in /boot/cmdline.txt ? | [15:07] |
| asciilifeform: | diana_coman: afaik that's the only reliable way, usb bus numbering isn't iirc stable across boots | [15:08] |
| diana_coman: | k, test server is for testing will do | [15:08] |
| asciilifeform: | BingoBoingo: from other fishwraps, re qntra, 'The grandson said they’re not selling guns, but reported that two men recently knocked on the door asking if they had gun parts or body armor. Hanabarger reportedly said “no” and showed them inside a storage container. But now they’re wondering if there’s a connection between those men and Tuesday’s raid.' | [15:09] |
| BingoBoingo: | asciilifeform: The other fishwrap refused to archived cleanly. Failed with a generic "content not available in your region" error page being archived instead. | [15:33] |
| deedbot: | http://qntra.net/2018/08/reddit-hacked-user-data-taken/ << Qntra - Reddit Hacked, User Data Taken | [16:18] |
| diana_coman: | after reading around on this mess with the usb speeds, the summary + questions would be: 1. the dwc_otg seems actually specific to raspberry pi so I don't see how it's directly useful atm am I missing something? 2. the manual/runtime pill so far relies on the companion mechanism to force a USB port down from "high speed" to "full speed" so basically from ehci to uhci/ohci wouldn't it make more sense to blacklist ehci, xhci and whatever | [17:28] |
| diana_coman: | other "improved" xxxxhci and stick with uhci/ohci? | [17:28] |
| diana_coman: | asciilifeform, perhaps ^ | [17:29] |
| diana_coman: | trinque, esp re why ehci if you can shed some light ^ | [17:30] |
| asciilifeform: | diana_coman: seems that you're right re the flag, it is specific to a nonstandard kernel | [17:32] |
| asciilifeform: | building a kernel without xhci would almost certainly do the job tho | [17:33] |
| diana_coman: | I'm actively looking for any reason why xhci should be allowed in | [17:34] |
| asciilifeform: | diana_coman: on server ? can't think of any, aside from 'backups to/from external drives' | [17:36] |
| asciilifeform: | ( i can't afford it on dulap, because it also doubles as reimaging station for rockchippen , but s.mg prolly can safely say goodbye to usb3 ) | [17:36] |
| asciilifeform: | err, usb2 | [17:36] |
| asciilifeform: | ( 3 by implication also ) | [17:36] |
| asciilifeform: | iirc ehci == usb2 , xhci == usb3 | [17:37] |
| diana_coman: | well yes, and 10 or whatever they come up with next | [17:37] |
| asciilifeform: | diana_coman: 'nexts' wouldn't affect the existing iron tho. | [17:38] |
| asciilifeform: | one type of existing machine where we can't afford to lose usb3 is the rockchip, it would be quite unusable without it ( main disk is solely usb3 ) | [17:39] |
| diana_coman: | so hm, on rockchip then FG are actually usable only with manual downgrade of usb port ? | [17:39] |
| asciilifeform: | diana_coman: problem dun seem to exist on my desk rockchip. ( and in the end we'll move the rk FGs over to the convenient built-in TTL serialports ) | [17:40] |
| asciilifeform: | diana_coman: re usb1 forcing, i was thinking the proper pill might be to write a shell thing that parses output of lsusb -t and does the correct magics rather than modded kernel | [17:41] |
| diana_coman: | ah, built-in ttl serialports sounds good, yes re problem dun seem to exist, mhm, I'd rather expect it would pop up sooner or later if used intensively in this little&frequent style | [17:41] |
| asciilifeform: | ( if diana_coman wants to take a crack at this, worx, otherwise asciilifeform will do it later this wk ) | [17:41] |
| diana_coman: | and yes, otherwise I was thinking that a script can't be all that difficult to write for it too | [17:41] |
| asciilifeform: | really a sed/awk 1liner | [17:41] |
| diana_coman: | but now I admit I got angry with ehci after all of today's barfing on the topic | [17:42] |
| asciilifeform: | for all the usb2/3 suckage, it sadly remains the only means to connect fast external disks to pc. | [17:44] |
| asciilifeform: | ( i won't dignify 'esata' with a mention, it is flaky in asciilifeform's experience, and not really usable on racked boxen ) | [17:44] |
| mircea_popescu: | http://btcbase.org/log/2018-08-01#1838724 << on the positive score, kernel patch for cuntoo killing this with fire quite feasible. | [18:02] |
| a111: | Logged on 2018-08-01 16:03 asciilifeform: 'After much researching it seems this is NOT a driver bug but a CHANGE in the kernel Serial API semantics. What has happened is that the API now blocks when a Serial device is not indicating it is ready. This included 'open' on a serial device which now can block. Since lots of RS232 serial devices do not bother with any control signals such as DCD (data carrier detect) they never indicate they are ready and open blocks. This is the | [18:02] |
| asciilifeform: | mircea_popescu: eat the l0g... | [18:02] |
| mircea_popescu: | eating, eating. | [18:02] |
| mircea_popescu: | http://btcbase.org/log/2018-08-01#1838730 << 1. put the old thing back in. | [18:03] |
| a111: | Logged on 2018-08-01 16:08 asciilifeform: 2 possible tacks -- 1) kill, with flamethrower, 'new api' 2) FG opened once per machine boot and left running into buffer | [18:03] |
| mircea_popescu: | there is no such thing as data that is all three of 1) random 2) useful and 3) buffered. | [18:03] |
| mircea_popescu: | pick any two. | [18:03] |
| mircea_popescu: | 1-3 is exactly http://btcbase.org/log/2018-08-01#1838591 1-2 is FG 2-3 is science, as in http://trilema.com/2017/is-it-still-rape-if-i-write-science-on-my-penis-first/ item. | [18:04] |
| a111: | Logged on 2018-08-01 01:52 asciilifeform could not muster the fuck-giving to read the payload, has nfi what the thing wants | [18:04] |
| mircea_popescu: | and that's a complete world-enumeration. | [18:04] |
| asciilifeform: | mircea_popescu: observe that i did not put a ram buffer in FG (aside from the 16bit debias/accumulator ) , it was not happenstance. | [18:05] |
| mircea_popescu: | right. and i didn't say anything about this then, either. also not :) | [18:06] |
| asciilifeform: | ( erry heathen rng i know of , includes... ) | [18:06] |
| mircea_popescu: | but ofcourse. | [18:07] |
| asciilifeform: | there's likewise a reason i did not publish a 'demon' to go with FG. ideally random bitz oughta live the shortest possible life, and walk shortest possible path from point of birth to use. | [18:11] |
| asciilifeform: | if somebody absolutely positively MUST buffer his FG, because, idk, he's generating a icbm launch key and wants to xorlemma 8 weeks of entropy into 4096b, oughta do it ~in his proggy~ imho. | [18:12] |
| mircea_popescu: | http://btcbase.org/log/2018-08-01#1838829 << this is quite conceivably the right solution, and imo a fine candidate for cuntoo list. | [18:17] |
| a111: | Logged on 2018-08-01 21:33 asciilifeform: building a kernel without xhci would almost certainly do the job tho | [18:17] |
| mircea_popescu: | yes, you miss out on downloading sony camera contents in such a manner as the "your media contains pictures!!!" popup can shoot "usefully fast". this is not a permitted usecase anyway. | [18:17] |
| mircea_popescu: | losers shouldn't evne have cameras in the first place. | [18:17] |
| mircea_popescu: | http://btcbase.org/log/2018-08-01#1838832 << i'll bet you you'll very much want to, and soon enough. | [18:18] |
| a111: | Logged on 2018-08-01 21:36 asciilifeform: ( i can't afford it on dulap, because it also doubles as reimaging station for rockchippen , but s.mg prolly can safely say goodbye to usb3 ) | [18:18] |
| asciilifeform: | i ain't waiting 3 wks to reimage a motherfuckign 64GB stick. | [18:19] |
| mircea_popescu: | sure. | [18:19] |
| asciilifeform: | ( bad enuff that i only even have usb2, not 3, on dulap, and it takes 3hrs ) | [18:20] |
| asciilifeform: | imho at the very least usb jacks oughta default to 1, and if really needs the uglyhax of 2/3 should have to manually trigger. rather than the current sad. | [18:21] |
| mircea_popescu: | i can see it. | [18:22] |
| asciilifeform: | incidentally , lack of a sane usb2 chipset is what's holding up the lyso crystal super-FG item | [18:23] |
| asciilifeform: | ( there's no reasonable way to connect it to pc , currently ) | [18:23] |
| mircea_popescu: | but in any case usb-+ should not be on mainline kernel. let he who runs rockchip farm patch in the ugly. | [18:23] |
| mircea_popescu: | asciilifeform could you make it a board ? use the agpx connector lol | [18:23] |
| asciilifeform: | mircea_popescu: the only board holes in current boxen are pcie, and that's megatonne of stateful logic | [18:24] |
| asciilifeform: | ( not even sure it'd fit on an ice40 ) | [18:24] |
| mircea_popescu: | aww | [18:24] |
| asciilifeform: | 'can't have nice things'(tm)(r) | [18:24] |
| mircea_popescu: | yeah, ye olde boards weren't unusable enough, had to get rid of amirite. | [18:24] |
| asciilifeform: | it'dve made an ideal isa card, lol | [18:25] |
| mircea_popescu: | you know '? | [18:25] |
| mircea_popescu: | ftr, i still have boards running my amds with proper isa cards... | [18:25] |
| asciilifeform: | ( isa was a joy to interface, dun even need fpga, 3-4 ttl chips and you're cooking ) | [18:25] |
| mircea_popescu: | heck, right now typing on one. | [18:25] |
| asciilifeform: | mircea_popescu: metoo, soundblaster64gold 4evah | [18:25] |
| mircea_popescu: | asciilifeform no, i know. | [18:25] |
| mircea_popescu: | you know, i'm tempted to put "must have 4x isa" on the reqs list for tmsr mobo ANYWAY. | [18:26] |
| mircea_popescu: | might as well make isa lyso. | [18:26] |
| asciilifeform: | mircea_popescu: so happens i have a seekrit draft of ice40+isa toy | [18:27] |
| mircea_popescu: | lol. | [18:27] |
| mircea_popescu: | surprised, i am not. | [18:27] |
| asciilifeform: | ( it wants 5v, which is a bitch, but not particularly hard to levelshift ) | [18:27] |
| asciilifeform: | phunphakt : the slot connectors are still made. | [18:28] |
| mircea_popescu: | yup. | [18:29] |
| mircea_popescu: | we're not the only ones to have noticed | [18:29] |
| mircea_popescu: | (if the putative fast oscilloscope ever got interfaced with killer micro box, it'd be through isa also, i'm sure.) | [18:29] |
| asciilifeform: | not only, but one can still get astonishingly fast adc isa cards secondhand, ready to roll. | [18:30] |
| mircea_popescu: | yup. | [18:30] |
| asciilifeform: | there's a whole 'underground' market in ye olde goodstuff. | [18:30] |
| * asciilifeform | brb,tea | [18:34] |
| mod6: | BingoBoingo: feel free to wipe mats' rockchip when you have a spare moment. | [19:23] |
| BingoBoingo: | mod6: The one in question is "C" correct? | [19:24] |
| mod6: | I don't have information on which letter assignment is which. | [19:27] |
| mod6: | ben_vulpes: can you send me this mapping if you have it? | [19:28] |
| mod6: | All I know is that mats has number '196'. | [19:28] |
| BingoBoingo: | Aite, alf should be able to confirm when he gets back from tea | [19:29] |
| mod6: | cool. the '196' number is what I received from ben in that latest document that I marked up. | [19:35] |
| mircea_popescu: | you know, all these "Random names" have a distinct handmade flavour. | [19:40] |
| BingoBoingo: | Well, that's why they call the beast "Dirty Randy" | [19:40] |
| mircea_popescu: | lol | [19:43] |
| BingoBoingo: | Whitened and bleached the random to the point the sweat stains leaked a very pattered yellowing | [19:47] |
| asciilifeform: | BingoBoingo, mod6 : *196 == 'C' , confirmed | [19:48] |
| BingoBoingo: | Aite, I'll walk over and stretch the legs now. | [19:49] |
| asciilifeform: | mircea_popescu: it wouldn't surprise me if the spamola bots were fleanode lusers pwnd via http://btcbase.org/log/2018-08-01#1838823 | [19:49] |
| a111: | Logged on 2018-08-01 20:18 deedbot: http://qntra.net/2018/08/reddit-hacked-user-data-taken/ << Qntra - Reddit Hacked, User Data Taken | [19:49] |
| mircea_popescu: | me either. | [19:50] |
| mircea_popescu: | then again, 0 cloacks, so maybe not. | [19:51] |
| mircea_popescu: | but it wouldn't surprise me if it were lusers, which is close enough. | [19:51] |
| asciilifeform: | ( i.e. pre-existing lusers, rather than sybils baked for the occasion ) | [19:52] |
| mircea_popescu: | lessee... what was the test ? | [19:58] |
| mircea_popescu: | !$ssh 115.84.92.92 | [19:58] |
| mircea_popescu: | apparently this is dead ? | [20:00] |
| mircea_popescu: | !$help | [20:00] |
| mircea_popescu: | !$ ssh 115.84.92.92 | [20:01] |
| asciilifeform: | was Framedragger_'s , neh | [20:01] |
| mircea_popescu: | !$ ssh 197.53.92.104 | [20:01] |
| mircea_popescu: | !$ ssh 159.192.248.185 | [20:01] |
| mircea_popescu: | !$ ssh 209.107.210.162 | [20:01] |
| mircea_popescu: | !$ ssh 216.151.183.64 | [20:01] |
| mircea_popescu: | !$ ssh 197.39.84.100 | [20:01] |
| mircea_popescu: | asciilifeform apparently they're all domestic routers. | [20:02] |
| asciilifeform: | lol!! | [20:02] |
| asciilifeform: | not terribly astonishing tho. | [20:02] |
| mircea_popescu: | !$ ssh 200.62.176.35 | [20:03] |
| mircea_popescu: | http://btcbase.org/log/2017-03-22#1630856 << apparently it's actually dead tho. | [20:04] |
| a111: | Logged on 2017-03-22 16:49 scriba: ssh banner of 200.62.176.35 as seen on 2016-06-13: SSH-2.0-OpenSSH_4.3p2 Debian-9 | [20:04] |
| mircea_popescu: | !Qlater tell spyked any interest adding ^ functionality to spykedbot ? | [20:04] |
| lobbesbot: | mircea_popescu: The operation succeeded. | [20:04] |
| asciilifeform: | in other quasi-noose, asciilifeform derived the general form of pulse equation for http://btcbase.org/log/2018-07-22#1837163 . and the antenna geometry... | [20:06] |
| a111: | Logged on 2018-07-22 17:07 asciilifeform: interestingly, both tx and rx end is considerably simpler, physically, than conventional periodic radio -- you dun need oscillators, tuners, at all. aside from pulse shaper, whole thing fits in fpga. | [20:06] |
| asciilifeform: | turns out, pretty simple. | [20:07] |
| mod6: | <+asciilifeform> BingoBoingo, mod6 : *196 == 'C' , confirmed << thanks asciilifeform! | [20:11] |
| BingoBoingo: | mod6 asciilifeform Drive is in place for reimaging | [20:24] |
| asciilifeform: | ty BingoBoingo . will be ready be end of wk. | [20:24] |
| mod6: | nice! | [20:30] |
| mod6: | Lords and Ladies, one rockchip has become available (ready by end of the week), who wants it! $75/mo if you sign up for a quarter, $100/mo on a month to month. | [20:32] |
| mod6: | BingoBoingo asciilifeform ben_vulpes : correct me if I'm wrong, but we have a bunch of FGs available (with cables now) right? | [20:33] |
| BingoBoingo: | mod6: we do indeed | [20:33] |
| mod6: | nice | [20:33] |
| mod6: | All: 0.00104167 BTC/mo. to attach an FG to your newly rented Rockchip! | [20:34] |
| mod6: | First come, first serve. Let us know. :] | [20:34] |
| BingoBoingo: | * neo-cool21 has quit (Killed (Unit193 (Spam is not permitted on freenode.)) << Oh the IRC-Cops have a filter nao? | [22:24] |
Category: Logs
