Hide Idle (>14 d.) Chans
← 2018-07-31 | 2018-08-02 → ↓
diana_coman: BingoBoingo, thanks! confirmed back on + 1 fg available; unfortunately the simple test from smg_rsa (./tests 11 11 ) still hangs
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
diana_coman: well, uhm, scratch that, I just got one of those stuck too, lol; it took longer to get stuck, nothing else
asciilifeform: diana_coman: i've built eucrypt and replicated your hang
diana_coman: asciilifeform, any clue as to cause?
diana_coman: on what machine is this?
asciilifeform: not discovered culprit yet, literally 5min ago finished pressing & building ( used ave1's gcc , for completeness )
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
asciilifeform: diana_coman: what was the exact process for dd hang ?
asciilifeform: ( fwiw i've dd's from dulap's FGs previously, with 0 signs of any problem )
asciilifeform: this box is running traditional gentoo, however, it more closely resembles primary s.mg machine than the test box
diana_coman: machine with 2 fgs; reboot without init of any fgs; stty on only one fg; dd on that fg
diana_coman: the first time it usually hangs
diana_coman: dd seems to be more resilient but I suspect it's mainly because it's not that sort of little&frequent
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)
diana_coman: fwiw same tests of eucrypt ran perfectly fine on all machines I have around here with fgs
asciilifeform: hm, over here dd ( with only 1 FG init'd ) is working correctly
asciilifeform: eucrypt's test reliably hangs, however, ~every other run
asciilifeform: 1048576 bytes (1.0 MB, 1.0 MiB) copied, 151.838 s, 6.9 kB/s <<
diana_coman: a bit slow though?
asciilifeform: not really, the nominal production is 7
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
asciilifeform: ( evidently the dc has pretty good cooling )
diana_coman: hm, I usually get that above 7, closer to 8
asciilifeform: it's not a constant rate, 7 is the empirical avg., and depends on environmental temp
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
asciilifeform: well the 1 obvious diff, is that it defaults to 512byte blocks
asciilifeform: and reads from buffered tty
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
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
asciilifeform: diana_coman: ok, finally managed to get a stuck dd
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 .
asciilifeform: so far can't think of a third.
asciilifeform: fwiw dd never stuck midway, only on opening tty.
asciilifeform: 0 bytes copied, 99.8535 s, 0.0 kB/s
asciilifeform: ^ 1 run
asciilifeform: 1048576 bytes (1.0 MB, 1.0 MiB) copied, 150.483 s, 7.0 kB/s
asciilifeform: ^ subsequent
asciilifeform: ( the former, ctrl-c'd )
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.
asciilifeform: no other device does the random ~rate~ thing.
asciilifeform: possibly asciilifeform is doomed to write the FG-reading daemon after all.
asciilifeform: ( observe, if tty ~does~ successfully open, can read 4evah, i had one dd going for 6 months without problem )
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
diana_coman: but I'm not comfortable with not knowing wtf in there because it has the potential to blow up very nastily indeed
diana_coman: fwiw eucrypt always gets stuck on the actual "read("
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.
asciilifeform: ( oughta log the timeouts )
diana_coman: I'm going to dig around a bit more too to see if I can find any more clues of sorts
diana_coman: but yes, this is certainly not going to get solved in 1-2 days by the looks of it
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
diana_coman: myeah, as battlefield solution that might be the direction to take
asciilifeform: i ~would~ prefer a sanely-behaving OS. unfortunately i dun have one up my sleeve.
asciilifeform brb,teatime
diana_coman: enjoy!
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
diana_coman: oh joy
Mocky: whoa, haven't seen that trilema.com header before
Mocky: super happy, lol
asciilifeform: diana_coman: i confirmed ( coupla dozen shots ) hang only ever takes place on 1st read() after open().
asciilifeform: diana_coman: further pl2303 mod lulz, https://archive.is/CefaN
diana_coman: asciilifeform, ah,ah, the "modprobe -r " lulz, yes
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
asciilifeform: 'HANG' we are seeing'
asciilifeform: ^ suggests shitgnomery
asciilifeform: the given 'solution' is absolutely prohibited for FG, tho, it ~must~ operate as blocking read
diana_coman: ugh, uglier and uglier
asciilifeform: confirms my earlier suspicion tho.
asciilifeform: 2 possible tacks -- 1) kill, with flamethrower, 'new api' 2) FG opened once per machine boot and left running into buffer
asciilifeform: i'ma let mircea_popescu say, whether Right Thing is to start with (2) and proceed to (1), or straight to (1) .
diana_coman: myeah, 1 promises to eat up a lot of time
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.
a111: Logged on 2018-08-01 02:55 mod6: douchebag wants the mic
mircea_popescu: speaking of which, i wonder how that fellow's business/revolutionary/technico-theoretical/etc idea is faring these days.
mircea_popescu: http://btcbase.org/log/2018-08-01#1838691 << da fuck buffered state machine, defeats the whole purpose of the thing.
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 .
diana_coman: mircea_popescu, read on for...deeper uncovered shit
a111: Logged on 2018-08-01 15:52 Mocky: super happy, lol
asciilifeform: btw, diana_coman , mircea_popescu , there's visible sys log barf from pl2303 when operating diana_coman's test :
asciilifeform: [8621835.122044] pl2303 ttyUSB0: pl2303_get_line_request - failed: -110
asciilifeform: [8621835.122919] pl2303 ttyUSB0: pl2303_set_line_request - failed: -32
asciilifeform: [8621835.463377] pl2303 ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32
asciilifeform: diana_coman: do you observe same on your box ?
mod6: guy says '<douchebag> can I be upped? I have some productive things to say' in PM, and I think "hmm. alright"
diana_coman: asciilifeform, I certainly say the last line, don't recall the first 2 but I might have missed them
diana_coman: lemme see again
mod6: it never fails. answering the door just doesn't work out too well for ole mod6
mod6: begone fuckwads
asciilifeform: mod6: lol, 'productive things'
diana_coman: "productive things to say " lol
asciilifeform: d00d could 'productive' any fucking time he feels like it.
asciilifeform: but not holding breath.
mod6: i should have just ignored. typically I do.
mod6: thought he might wanna talk about his rockchip, so was willing to give him the chance.
mod6: WRONG
mod6: shit on the rug in the foyer.
asciilifeform: 'most people are just going to go with a cheaper & higher performance alternative' dontchaknow.
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
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
diana_coman: that one I got even 8 times in a row there
asciilifeform: diana_coman: the line_request one is sporadic ( erry dozen or so runs )
diana_coman: ah, that might explain why I haven't yet noticed it
mircea_popescu: modprobe -r option << does ditching the "option" bs do anything ?
mircea_popescu: seems like a fine candidate for cuntoo banlist, if so.
asciilifeform: mircea_popescu: we dun have this item to begin with
asciilifeform: ( at least dulap kernel -- does not )
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"
asciilifeform: dulap ~ # zcat /proc/config.gz | grep CONFIG_USB_SERIAL_OPTION
asciilifeform: # CONFIG_USB_SERIAL_OPTION is not set
mircea_popescu: this is looking more and more like we're going to have to write a pl replacement does it
asciilifeform: 'usb_serial_generic_read_bulk_callback - urb stopped: -32' specifically, reported also for other usb2ttl chipsets, incl ftdi
asciilifeform: bug may very well be an interaction with upstream linux usb subsys
asciilifeform: ( https://archive.is/sYqkk for dedicated entomologist )
asciilifeform: supposedly, forcing usb1 speed for whole jack, curative
asciilifeform: ( not tried yet )
asciilifeform: dwc_otg.speed=1 on kernel param line.
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...
asciilifeform: ok confirmed, forcing usb1 cures
asciilifeform: http://p.bvulpes.com/pastes/xAQ4U/?raw=true << manual example , testable without rebooting kernel
asciilifeform: dozen runs of diana_coman's test all work
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 )
asciilifeform: diana_coman ^
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 )
mircea_popescu: not like we use usb for anything else anyway, so this may well work ad interim.
asciilifeform: fwiw asciilifeform's official FG tester rig runs always in this mode.
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.
asciilifeform: mircea_popescu: there's no ttl serial on pc mobo
mircea_popescu adds to wishlist for eventual fab.
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
deedbot: http://trilema.com/2018/qntra-sqntr-july-2018-statement/ << Trilema - Qntra (S.QNTR) July 2018 Statement
asciilifeform: mircea_popescu: fwiw rockchip and similar boards actually include several ttl-level serial ports.
asciilifeform: pc is the hardcore tard reservation.
asciilifeform: ( i've yet to find ~one~ pc board, of any vintage, with ttl ports )
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.
a111: Logged on 2014-02-21 03:28 asciilifeform: usb is a highly-stateful protocol with a book-length standard
mod6: !!sent-invoices
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.
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 )
asciilifeform: thing eats 8ma, could easily run off, e.g., solar cell in a well-lit room.
asciilifeform: diana_coman: usb1 switchover also confirmed to cure log barfola.
asciilifeform: diana_coman, mircea_popescu lemme know if the given cure, is curative. ( no change to diana_coman's coad is needed )
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. )
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
diana_coman: oh hey, asciilifeform that cure seems to work
diana_coman: so basically that's not for "if more than 2" but rather "always do it"
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 > ..."
asciilifeform: diana_coman: interestingly, in my (conventional gentoo) userland, worked as posted ( i.e. with the newline )
diana_coman: this was on the smg test machine
asciilifeform: aaha so cuntoo
asciilifeform: diana_coman: you'll probably want to make it happen on boot.
diana_coman: makes sense; how do I do that best on gentoo? still line in /boot/cmdline.txt ?
asciilifeform: diana_coman: afaik that's the only reliable way, usb bus numbering isn't iirc stable across boots
diana_coman: k, test server is for testing; will do
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.'
BingoBoingo: asciilifeform: The other fishwrap refused to archived cleanly. Failed with a generic "content not available in your region" error page being archived instead.
deedbot: http://qntra.net/2018/08/reddit-hacked-user-data-taken/ << Qntra - Reddit Hacked, User Data Taken
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
diana_coman: other "improved" xxxxhci and stick with uhci/ohci?
diana_coman: asciilifeform, perhaps ^
diana_coman: trinque, esp re why ehci if you can shed some light ^
asciilifeform: diana_coman: seems that you're right re the flag, it is specific to a nonstandard kernel
asciilifeform: building a kernel without xhci would almost certainly do the job tho
diana_coman: I'm actively looking for any reason why xhci should be allowed in
asciilifeform: diana_coman: on server ? can't think of any, aside from 'backups to/from external drives'
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 )
asciilifeform: err, usb2
asciilifeform: ( 3 by implication also )
asciilifeform: iirc ehci == usb2 , xhci == usb3
diana_coman: well yes, and 10 or whatever they come up with next
asciilifeform: diana_coman: 'nexts' wouldn't affect the existing iron tho.
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 )
diana_coman: so hm, on rockchip then FG are actually usable only with manual downgrade of usb port ?
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 )
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
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
asciilifeform: ( if diana_coman wants to take a crack at this, worx, otherwise asciilifeform will do it later this wk )
diana_coman: and yes, otherwise I was thinking that a script can't be all that difficult to write for it too
asciilifeform: really a sed/awk 1liner
diana_coman: but now I admit I got angry with ehci after all of today's barfing on the topic
asciilifeform: for all the usb2/3 suckage, it sadly remains the only means to connect fast external disks to pc.
asciilifeform: ( i won't dignify 'esata' with a mention, it is flaky in asciilifeform's experience, and not really usable on racked boxen )
mircea_popescu: http://btcbase.org/log/2018-08-01#1838724 << on the positive score, kernel patch for cuntoo killing this with fire quite feasible.
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
asciilifeform: mircea_popescu: eat the l0g...
mircea_popescu: eating, eating.
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
mircea_popescu: there is no such thing as data that is all three of 1) random ; 2) useful and 3) buffered.
mircea_popescu: pick any two.
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
mircea_popescu: and that's a complete world-enumeration.
asciilifeform: mircea_popescu: observe that i did not put a ram buffer in FG (aside from the 16bit debias/accumulator ) , it was not happenstance.
mircea_popescu: right. and i didn't say anything about this then, either. also not :)
asciilifeform: ( erry heathen rng i know of , includes... )
mircea_popescu: but ofcourse.
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.
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.
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.
a111: Logged on 2018-08-01 21:33 asciilifeform: building a kernel without xhci would almost certainly do the job tho
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.
mircea_popescu: losers shouldn't evne have cameras in the first place.
mircea_popescu: http://btcbase.org/log/2018-08-01#1838832 << i'll bet you you'll very much want to, and soon enough.
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 )
asciilifeform: i ain't waiting 3 wks to reimage a motherfuckign 64GB stick.
asciilifeform: ( bad enuff that i only even have usb2, not 3, on dulap, and it takes 3hrs )
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.
mircea_popescu: i can see it.
asciilifeform: incidentally , lack of a sane usb2 chipset is what's holding up the lyso crystal super-FG item
asciilifeform: ( there's no reasonable way to connect it to pc , currently )
mircea_popescu: but in any case usb-+ should not be on mainline kernel. let he who runs rockchip farm patch in the ugly.
mircea_popescu: asciilifeform could you make it a board ? use the agpx connector lol
asciilifeform: mircea_popescu: the only board holes in current boxen are pcie, and that's megatonne of stateful logic
asciilifeform: ( not even sure it'd fit on an ice40 )
asciilifeform: 'can't have nice things'(tm)(r)
mircea_popescu: yeah, ye olde boards weren't unusable enough, had to get rid of amirite.
asciilifeform: it'dve made an ideal isa card, lol
mircea_popescu: you know '?
mircea_popescu: ftr, i still have boards running my amds with proper isa cards...
asciilifeform: ( isa was a joy to interface, dun even need fpga, 3-4 ttl chips and you're cooking )
mircea_popescu: heck, right now typing on one.
asciilifeform: mircea_popescu: metoo, soundblaster64gold 4evah
mircea_popescu: asciilifeform no, i know.
mircea_popescu: you know, i'm tempted to put "must have 4x isa" on the reqs list for tmsr mobo ANYWAY.
mircea_popescu: might as well make isa lyso.
asciilifeform: mircea_popescu: so happens i have a seekrit draft of ice40+isa toy
mircea_popescu: surprised, i am not.
asciilifeform: ( it wants 5v, which is a bitch, but not particularly hard to levelshift )
asciilifeform: phunphakt : the slot connectors are still made.
mircea_popescu: we're not the only ones to have noticed
mircea_popescu: (if the putative fast oscilloscope ever got interfaced with killer micro box, it'd be through isa also, i'm sure.)
asciilifeform: not only, but one can still get astonishingly fast adc isa cards secondhand, ready to roll.
asciilifeform: there's a whole 'underground' market in ye olde goodstuff.
mod6: BingoBoingo: feel free to wipe mats' rockchip when you have a spare moment.
BingoBoingo: mod6: The one in question is "C" correct?
mod6: I don't have information on which letter assignment is which.
mod6: ben_vulpes: can you send me this mapping if you have it?
mod6: All I know is that mats has number '196'.
BingoBoingo: Aite, alf should be able to confirm when he gets back from tea
mod6: cool. the '196' number is what I received from ben in that latest document that I marked up.
mircea_popescu: you know, all these "Random names" have a distinct handmade flavour.
BingoBoingo: Well, that's why they call the beast "Dirty Randy"
BingoBoingo: Whitened and bleached the random to the point the sweat stains leaked a very pattered yellowing
asciilifeform: BingoBoingo, mod6 : *196 == 'C' , confirmed
BingoBoingo: Aite, I'll walk over and stretch the legs now.
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
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
mircea_popescu: me either.
mircea_popescu: then again, 0 cloacks, so maybe not.
mircea_popescu: but it wouldn't surprise me if it were lusers, which is close enough.
asciilifeform: ( i.e. pre-existing lusers, rather than sybils baked for the occasion )
mircea_popescu: lessee... what was the test ?
mircea_popescu: !$ssh 115.84.92.92
mircea_popescu: apparently this is dead ?
mircea_popescu: !$ ssh 115.84.92.92
asciilifeform: was Framedragger_'s , neh
mircea_popescu: !$ ssh 197.53.92.104
mircea_popescu: !$ ssh 159.192.248.185
mircea_popescu: !$ ssh 209.107.210.162
mircea_popescu: !$ ssh 216.151.183.64
mircea_popescu: !$ ssh 197.39.84.100
mircea_popescu: asciilifeform apparently they're all domestic routers.
asciilifeform: not terribly astonishing tho.
mircea_popescu: !$ ssh 200.62.176.35
mircea_popescu: http://btcbase.org/log/2017-03-22#1630856 << apparently it's actually dead tho.
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
mircea_popescu: !Qlater tell spyked any interest adding ^ functionality to spykedbot ?
lobbesbot: mircea_popescu: The operation succeeded.
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...
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.
asciilifeform: turns out, pretty simple.
mod6: <+asciilifeform> BingoBoingo, mod6 : *196 == 'C' , confirmed << thanks asciilifeform!
BingoBoingo: mod6 asciilifeform Drive is in place for reimaging
asciilifeform: ty BingoBoingo . will be ready be end of wk.
mod6: nice!
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.
mod6: BingoBoingo asciilifeform ben_vulpes : correct me if I'm wrong, but we have a bunch of FGs available (with cables now) right?
BingoBoingo: mod6: we do indeed
mod6: nice
mod6: All: 0.00104167 BTC/mo. to attach an FG to your newly rented Rockchip!
mod6: First come, first serve. Let us know. :]
BingoBoingo: * neo-cool21 has quit (Killed (Unit193 (Spam is not permitted on freenode.)) << Oh the IRC-Cops have a filter nao?
← 2018-07-31 | 2018-08-02 → ↑
Random(trilema) | Download hourly DB snapshot | Get Source Code