| 01:57.53 | *** join/#qi-hardware atommann (~atommann@222.248.72.156) |
| 02:14.11 | *** join/#qi-hardware sb0 (~sb0@124244181048.ctinets.com) |
| 03:44.03 | *** join/#qi-hardware Haswell (~Haswell@unaffiliated/haswell) |
| 04:00.20 | *** join/#qi-hardware xiangfu (~xiangfu@115.231.174.141) |
| 04:29.08 | *** join/#qi-hardware atgreen (~user@CPE687f74122463-CM84948c2e0610.cpe.net.cable.rogers.com) |
| 04:40.39 | kyak | whitequark: 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 limbo |
| 04:44.13 | kyak | had your bot's nickname been registered, i'd also speculate that there could be a problem re-identifying with nickserv |
| 04:44.34 | kyak | which could lead to your bot disconnection, depending on nickname settings |
| 04:44.44 | kyak | btw, you really should register the nickname |
| 04:51.15 | *** join/#qi-hardware atgreen (~user@CPE687f74122463-CM84948c2e0610.cpe.net.cable.rogers.com) |
| 04:52.16 | whitequark | I still don't know what benefit would that give me |
| 05:30.56 | kyak | first of all, there is a problem of personation, second, you nickname can be stolen |
| 05:30.57 | DocScrutinizer05 | the benefit of ghosting and definitely getting the nickname you want |
| 05:31.49 | DocScrutinizer05 | and that's pretty damn annoying when somebody steals your nickname and spams channels until you get klined or ignored or banned |
| 05:34.50 | DocScrutinizer05 | actually bot that don't authenticate can not get associated with a user who's responsible and thus are strongly deprecated or even forbidden |
| 05:37.18 | DocScrutinizer05 | and during netsplits you canot join under same name since that name still is considered online, so unless you ghost it you canot re-use it |
| 05:39.59 | kyak | oh 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 online |
| 05:41.44 | DocScrutinizer05 | you 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 delayed |
| 05:41.50 | DocScrutinizer05 | kyak: right |
| 05:49.58 | whitequark | hmm |
| 05:51.14 | kyak | whitequark: 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.28 | whitequark | the bot can do that alright |
| 05:51.36 | kyak | ah, ok |
| 05:51.40 | whitequark | I'm just too lazy to actually register on freenode |
| 05:51.46 | whitequark | and I don't want to bring it down too |
| 05:52.11 | kyak | can you issue commands on behalf of the bot? |
| 05:52.18 | kyak | like send messages? |
| 05:53.02 | whitequark | no |
| 05:53.57 | DocScrutinizer05 | an 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 bots |
| 05:54.11 | DocScrutinizer05 | see /msg nickserv info infobot |
| 05:55.44 | DocScrutinizer05 | infobot account has "[Notice] -NickServ- apt has enabled nick protection" which I strongly discourage to do |
| 05:57.20 | DocScrutinizer05 | you also have less join restrictions regarding throttling etc when you're registered, and bot *accounts* can even get extended number of channels allowed |
| 06:28.35 | 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-auth |
| 06:29.48 | DocScrutinizer05 | infobot 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 ~+chaninfo |
| 06:30.55 | DocScrutinizer05 | so you probably want to implement sth better than what infobot does now |
| 06:31.34 | DocScrutinizer05 | Tim more than once said "scheduler needs a complete rewrite" - alas nobody has the time to do that |
| 06:51.27 | *** join/#qi-hardware rejon (~rejon@42-3-203-137.static.netvigator.com) |
| 06:59.49 | *** join/#qi-hardware jekhor__ (~jek@port-236-adslby-pool41.infonet.by) |
| 07:02.31 | sb0 | whitequark, seems to be both pump plus some oil |
| 07:13.30 | DocScrutinizer05 | wouldn't oil eventually start evaporating/boiling and thus limit the vacuum you could reach? |
| 07:14.33 | sb0 | yes, it does |
| 07:14.47 | sb0 | well if you use oil designed for vacuum pumps, it doesn't boil |
| 07:15.02 | sb0 | but there's always some evaporation and it's a problem in sensitive systems |
| 07:15.16 | DocScrutinizer05 | whitequark: 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 would |
| 07:16.08 | sb0 | ultra high vacuum use a liquid nitrogen cryogenic trap that condenses oil vapors before they reach the vacuum chamber, or a dry (scroll) pump |
| 07:16.59 | sb0 | #2 is what most modern/rich labs use afaict |
| 07:20.02 | DocScrutinizer05 | :nod: |
| 07:20.46 | DocScrutinizer05 | ((levitation)) we commented exactly same circuit concept here in this chan a year and some ago |
| 07:23.04 | DocScrutinizer05 | they 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 electromagnet |
| 07:24.28 | DocScrutinizer05 | that's honestly so idiotic it's amazing it works at all |
| 08:57.15 | *** join/#qi-hardware pcercuei (~pcercuei@2a02:810d:1b40:e74::4) |
| 09:02.15 | *** join/#qi-hardware kilae (~chatzilla@catv-162-034.tbwil.ch) |
| 09:09.09 | *** join/#qi-hardware jekhor_ (~jek@port-236-adslby-pool41.infonet.by) |
| 09:54.04 | *** join/#qi-hardware rejon (~rejon@223.17.155.152) |
| 10:20.11 | *** join/#qi-hardware rejon (~rejon@223.17.155.152) |
| 10:32.02 | *** join/#qi-hardware pcercuei (~pcercuei@2a02:810d:1b40:e74:1af4:6aff:fec5:1c8f) |
| 10:56.22 | *** join/#qi-hardware wej (j@gateway/vpn/mullvad/x-kjoncthwsocxiqls) |
| 11:06.22 | *** join/#qi-hardware wej (j@gateway/vpn/mullvad/x-ihxyvlllyjemiqef) |
| 11:11.01 | *** join/#qi-hardware kilae (~chatzilla@catv-162-034.tbwil.ch) |
| 11:34.55 | *** join/#qi-hardware jekhor__ (~jek@port-236-adslby-pool41.infonet.by) |
| 11:58.36 | *** join/#qi-hardware rejon (~rejon@223.17.157.191) |
| 12:14.15 | *** join/#qi-hardware xiangfu (~xiangfu@124.202.191.129) |
| 13:05.49 | *** join/#qi-hardware nicksydney (~quassel@86.211.dsl.syd.iprimus.net.au) |
| 13:38.07 | *** join/#qi-hardware astr (~astr@79-69-207-197.dynamic.dsl.as9105.com) |
| 14:10.40 | DocScrutinizer05 | the heck, deadly receiver weapon: http://www.research-electronics.com/cgi-bin/main.cgi?action=viewprod&ct=products&num=OSCOR%20Blue |
| 14:11.05 | 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:15.39 | DocScrutinizer05 | while TALAN is rather pathetic |
| 14:16.33 | DocScrutinizer05 | actually I searched for >>Non-linear Junction Detector<< |
| 14:17.19 | DocScrutinizer05 | poor man's NLJ-detector: microwave and watch the smoke ;-P |
| 14:29.07 | *** join/#qi-hardware mooseboobs (~mooseboob@c-76-108-229-101.hsd1.fl.comcast.net) |
| 14:29.59 | DocScrutinizer05 | hey, you can find useful data at the most weird locations ;-) http://www.research-electronics.com/system/products/OSCOR Green/Custom_Span_Lists.zip |
| 14:31.26 | DocScrutinizer05 | Telecom LTE.csv is funny |
| 14:34.36 | DocScrutinizer05 | LOL, quite a huge range: >> Mobile-Satellite / Radiodetermination-Satellite,2.48350E+06,2.49500E+09 << |
| 14:35.20 | DocScrutinizer05 | I guess this must be a typo |
| 14:35.44 | DocScrutinizer05 | the mantissas are too similar |
| 14:38.38 | DocScrutinizer05 | ok, 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:42.24 | DocScrutinizer05 | http://www.research-electronics.com/system/products/OSCOR Green/OSCOR_Green_Brochure.pdf awesome spectrum analyzer: 10kHz ~ 24GHz |
| 14:53.39 | *** join/#qi-hardware FrankBlues (~alex@c-174-52-202-7.hsd1.ut.comcast.net) |
| 14:55.53 | *** join/#qi-hardware jekhor_ (~jek@port-236-adslby-pool41.infonet.by) |
| 15:13.10 | DocScrutinizer05 | ooh, and actually pretty cheap: >>Our Price: $36,000.00<< |
| 15:46.19 | *** join/#qi-hardware kilae (~chatzilla@catv-162-034.tbwil.ch) |
| 16:24.14 | *** join/#qi-hardware ChanServ (ChanServ@services.) |
| 16:24.14 | *** mode/#qi-hardware [+o ChanServ] by tepper.freenode.net |
| 16:57.53 | *** join/#qi-hardware tumdedum (~tumdedum@unaffiliated/espiral) |
| 17:07.56 | *** join/#qi-hardware tumdedum (~tumdedum@unaffiliated/espiral) |
| 18:09.46 | *** join/#qi-hardware wpwrak (~werner@154-164-231-201.fibertel.com.ar) |
| 18:10.20 | wpwrak | hmm, this is what happens if you kill the busiest processes, and X is among them ... :( |
| 18:11.05 | wpwrak | i 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 system |
| 19:22.18 | larsc | pcercuei: if I understand things correctly we should not implement PIN_CONFIG_BIAS_PULL_DEFAULT |
| 19:22.36 | pcercuei | why not? |
| 19:22.56 | larsc | according to the documentation that's only for chips where you don't know the direction |
| 19:23.12 | larsc | or the direction is set dynamically by the hardware depending on other parameters |
| 19:23.20 | larsc | like the selected peripheral |
| 19:23.22 | pcercuei | ok |
| 19:23.55 | pcercuei | I thought it was to enable either pull-down or pull-up |
| 19:34.25 | mth | on the subject of pinctrl, I had to make a small change since there are no enable/disable handlers anymore, only a set handler |
| 19:34.31 | mth | when migrating to 3.18 |
| 19:35.24 | pcercuei | ok |
| 19:35.29 | mth | .set_mux to be exact |
| 19:36.11 | mth | also I put it in a subdir drivers/pinctrl/ingenic/ since many other pinctrl drivers have been grouped by hardware vendor |
| 19:42.17 | pcercuei | but it doesn't really make sense, since we only have one driver there |
| 19:45.07 | mth | there will be separate drivers for the jz47xx series, won't there? |
| 19:45.19 | pcercuei | I don't think so |
| 19:46.26 | mth | you mean all the differences can be pushed into DT? |
| 19:46.47 | mth | even so, wouldn't you need example DT configs somewhere then? |
| 19:47.12 | mth | or are those until arch/mips? |
| 19:47.23 | mth | s/until/under/ |
| 19:47.25 | qi-bot | mth meant: "or are those under arch/mips?" |
| 19:55.27 | pcercuei | I mean that there are almost no differences |
| 20:15.55 | mth | I thought the pin mapping itself is quite different |
| 20:24.03 | larsc | I refactored things to be 3 different level |
| 20:24.10 | larsc | top level, is generic stuff |
| 20:24.34 | larsc | second level is either gen1 or gen2 |
| 20:24.54 | larsc | and the bottom level is the SoC itself which has the pinmap and mux maps, etc |
| 20:25.51 | larsc | gen1 is for <=jz4760 and gen2 is for >=jz4770 |
| 20:26.11 | larsc | they kind of reshufeld the register map between those |
| 20:26.59 | larsc | when using DT the last level would be described in the DT |
| 20:28.34 | mth | ah, it seems the .dts fiels are under arch/, so maybe there wouldn't be many files in the jz pinctrl driver then |
| 20:30.27 | larsc | the subfolder probably doesn't hurt |
| 20:34.04 | *** join/#qi-hardware wej (j@gateway/vpn/mullvad/x-thsouncpjgfvsmgw) |
| 21:31.53 | *** join/#qi-hardware jekhor_ (~jek@nat3-minsk-pool-46-53-180-14.telecom.by) |
| 21:58.31 | *** join/#qi-hardware jekhor_ (~jek@nat3-minsk-pool-46-53-180-14.telecom.by) |
| 22:45.28 | *** join/#qi-hardware Haswell (~Haswell@unaffiliated/haswell) |
| 23:10.35 | *** join/#qi-hardware ChanServ (ChanServ@services.) |
| 23:10.35 | *** mode/#qi-hardware [+o ChanServ] by tepper.freenode.net |
| 23:11.00 | *** join/#qi-hardware Haswell (~Haswell@unaffiliated/haswell) |
| 23:25.07 | *** join/#qi-hardware Haswell (~Haswell@28.85-85-136.dynamic.clientes.euskaltel.es) |
| 23:28.50 | *** join/#qi-hardware ChanServ (ChanServ@services.) |
| 23:28.50 | *** mode/#qi-hardware [+o ChanServ] by tepper.freenode.net |
| 23:36.40 | *** join/#qi-hardware ChanServ (ChanServ@services.) |
| 23:36.40 | *** mode/#qi-hardware [+o ChanServ] by tepper.freenode.net |
| 23:39.35 | *** join/#qi-hardware Luke-Jr (~luke-jr@unaffiliated/luke-jr) |
| 23:42.39 | *** join/#qi-hardware Haswell (~Haswell@unaffiliated/haswell) |