#qi-hardware IRC log for Saturday, 2014-12-13

kyakwhitequark: dunno, maybe there is a problem handling connection to server. For example, the connection has died, but bot hasn't been notified and hangs in a limbo04:40
kyakhad your bot's nickname been registered, i'd also speculate that there could be a problem re-identifying with nickserv04:44
kyakwhich could lead to your bot disconnection, depending on nickname settings04:44
kyakbtw, you really should register the nickname04:44
whitequarkI still don't know what benefit would that give me04:52
kyakfirst of all, there is a problem of personation, second, you nickname can be stolen05:30
DocScrutinizer05the benefit of ghosting and definitely getting the nickname you want05:30
DocScrutinizer05and that's pretty damn annoying when somebody steals your nickname and spams channels until you get klined or ignored or banned05:31
DocScrutinizer05actually bot that don't authenticate can not get associated with a user who's responsible and thus are strongly deprecated or even forbidden05:34
DocScrutinizer05and during netsplits you canot join under same name since that name still is considered online, so unless you ghost it you canot re-use it05:37
kyakoh no, ghosting will not happend during netsplit.. It will happen if connection between you and server is broken, but server doesn't know that. You reconnect, but server still thinks you are online05:39
DocScrutinizer05you however should _not_ enable nick protection or you need comstantly check if some services have renamed you to protect the nick, since your auth somehow temporarily failed to work or simply got delayed05:41
DocScrutinizer05kyak: right05:41
kyakwhitequark: anyway, other users of your irclogger might approach you any time and ask for a feature that let's bot authorize with services and maintain authorization :)05:51
whitequarkthe bot can do that alright05:51
kyakah, ok05:51
whitequarkI'm just too lazy to actually register on freenode05:51
whitequarkand I don't want to bring it down too05:51
kyakcan you issue commands on behalf of the bot?05:52
kyaklike send messages?05:52
DocScrutinizer05an account also has associated email addr, it's the proof the bot is legit and also the point of contact when anything goes haywire. Best common practice is to unhide mail for bots05:53
DocScrutinizer05see /msg nickserv info infobot05:54
DocScrutinizer05infobot account has "[Notice] -NickServ- apt has enabled nick protection" which I strongly discourage to do05:55
DocScrutinizer05you also have less join restrictions regarding throttling etc when you're registered, and bot *accounts* can even get extended number of channels allowed05:57
DocScrutinizer05((<whitequark> if you have any robust anti-netsplit measure in mind, I'm happy to oblige)) the only strategy is to detect when bot isn't really online anymore (for that you ideally send a ping message to yourself every few minutes) and in case any conectivity issues are detected, the bot ideally does a complete relogin/re-auth06:28
DocScrutinizer05infobot is pretty bad at that, she doesn't detect when a netsplit kicked her off some channels. You always get an "all ok" when you ask ~+chaninfo06:29
DocScrutinizer05so you probably want to implement sth better than what infobot does now06:30
DocScrutinizer05Tim more than once said "scheduler needs a complete rewrite" - alas nobody has the time to do that06:31
sb0whitequark, seems to be both pump plus some oil07:02
DocScrutinizer05wouldn't oil eventually start evaporating/boiling and thus limit the vacuum you could reach?07:13
sb0yes, it does07:14
sb0well if you use oil designed for vacuum pumps, it doesn't boil07:14
sb0but there's always some evaporation and it's a problem in sensitive systems07:15
DocScrutinizer05whitequark: in latest c't-hacks err make: there's an awesome fsckdup magnetic "levitation" circuit that only works because the circuit doesn't do what the designer thought it would07:15
sb0ultra high vacuum use a liquid nitrogen cryogenic trap that condenses oil vapors before they reach the vacuum chamber, or a dry (scroll) pump07:16
sb0#2 is what most modern/rich labs use afaict07:16
DocScrutinizer05((levitation)) we commented exactly same circuit concept here in this chan a year and some ago07:20
DocScrutinizer05they placed a light sensor next to the flashlight's bulb to sense distance to object by increase of brightness from reflected flashlight light by object. errr, make that a hall sensor and electromagnet07:23
DocScrutinizer05that's honestly so idiotic it's amazing it works at all07:24
DocScrutinizer05the heck, deadly receiver weapon: http://www.research-electronics.com/cgi-bin/main.cgi?action=viewprod&ct=products&num=OSCOR%20Blue14:10
DocScrutinizer05>>The OSCOR Blue is listed on the United States Munitions List (USML) and requires an export license under the International Traffic in Arms Regulations (ITAR) <<14:11
DocScrutinizer05while TALAN is rather pathetic14:15
DocScrutinizer05actually I searched for >>Non-linear Junction Detector<<14:16
DocScrutinizer05poor man's NLJ-detector: microwave and watch the smoke ;-P14:17
DocScrutinizer05hey, you can find useful data at the most weird locations ;-)  http://www.research-electronics.com/system/products/OSCOR Green/Custom_Span_Lists.zip14:29
DocScrutinizer05Telecom LTE.csv is funny14:31
DocScrutinizer05LOL, quite a huge range: >> Mobile-Satellite / Radiodetermination-Satellite,2.48350E+06,2.49500E+09 <<14:34
DocScrutinizer05I guess this must be a typo14:35
DocScrutinizer05the mantissas are too similar14:35
DocScrutinizer05ok, this .zip has some nonsense in it:  >> WiFi 802.11,2.40E+09 [START!], 5.82500E+09[STOP!] << followed by line >> WiFi 2.4 GHz band (802.11b/g/n/ad),2.40E+09,2.50E+09 <<14:38
DocScrutinizer05http://www.research-electronics.com/system/products/OSCOR Green/OSCOR_Green_Brochure.pdf awesome spectrum analyzer: 10kHz ~ 24GHz14:42
DocScrutinizer05ooh, and actually pretty cheap: >>Our Price: $36,000.00<<15:13
wpwrakhmm, this is what happens if you kill the busiest processes, and X is among them ... :(18:10
wpwraki wish chromium would just not run tabs that aren't selected. then all those auto-reloading sites that have some sort of memory leak wouldn't have such an easy time crippling the system18:11
larscpcercuei: if I understand things correctly we should not implement PIN_CONFIG_BIAS_PULL_DEFAULT19:22
pcercueiwhy not?19:22
larscaccording to the documentation that's only for chips where you don't know the direction19:22
larscor the direction is set dynamically by the hardware depending on other parameters19:23
larsclike the selected peripheral19:23
pcercueiI thought it was to enable either pull-down or pull-up19:23
mthon the subject of pinctrl, I had to make a small change since there are no enable/disable handlers anymore, only a set handler19:34
mthwhen migrating to 3.1819:34
mth.set_mux to be exact19:35
mthalso I put it in a subdir drivers/pinctrl/ingenic/ since many other pinctrl drivers have been grouped by hardware vendor19:36
pcercueibut it doesn't really make sense, since we only have one driver there19:42
mththere will be separate drivers for the jz47xx series, won't there?19:45
pcercueiI don't think so19:45
mthyou mean all the differences can be pushed into DT?19:46
mtheven so, wouldn't you need example DT configs somewhere then?19:46
mthor are those until arch/mips?19:47
pcercueiI mean that there are almost no differences19:55
mthI thought the pin mapping itself is quite different20:15
larscI refactored things to be 3 different level20:24
larsctop level, is generic stuff20:24
larscsecond level is either gen1 or gen220:24
larscand the bottom level is the SoC itself which has the pinmap and mux maps, etc20:24
larscgen1 is for <=jz4760 and gen2 is for >=jz477020:25
larscthey kind of reshufeld the register map between those20:26
larscwhen using DT the last level would be described in the DT20:26
mthah, it seems the .dts fiels are under arch/, so maybe there wouldn't be many files in the jz pinctrl driver then20:28
larscthe subfolder probably doesn't hurt20:30
--- Sun Dec 14 201400:00

Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!