2013-10-10 00:36 panda|x201 has quit [Ping timeout: 248 seconds]
2013-10-10 00:45 pcercuei has quit [Quit: dodo]
2013-10-10 01:04 <DocScrutinizer05> apelete: please don't tell you have to mess with MG musb_core :-O
2013-10-10 01:05 <DocScrutinizer05> it's some heap of code junk almost as ugly as tty_serial, in linux. Makes your eyes bleed
2013-10-10 01:06 <DocScrutinizer05> actually musb_core engine itself gives you brain cancer
2013-10-10 01:07 <DocScrutinizer05> a state machine in hw, with no means whatsoever to externally control the state it's in, via sw
2013-10-10 01:08 <DocScrutinizer05> so musb_core kernel driver implements another state machine that mirrors the hw state machine and gets synced to it by the messages aka interrupts the hw sends
2013-10-10 01:08 <DocScrutinizer05> two state machines that run in sync, unbearably stupid design
2013-10-10 01:08 <wpwrak> routine business in communications :)
2013-10-10 01:10 <DocScrutinizer05> and then you got power management, not only for musb_core but also for the ULPI and the CPU<->musb_core bus domains
2013-10-10 01:10 <DocScrutinizer05> of course each one separate from the other ones, but with obvious dependencies
2013-10-10 01:11 <DocScrutinizer05> on top of that you get OTG suspend
2013-10-10 01:12 <DocScrutinizer05> and in the end the whole friggin mus_core hw burns an unbelievable 60mA just for idling, as soon as you power it up
2013-10-10 01:13 <DocScrutinizer05> at least that's what I wasn't able to forget, from my enterprise with N900 hostmode
2013-10-10 01:13 <DocScrutinizer05> IOW: IIRC
2013-10-10 01:15 <wpwrak> nice :) i guess the 60 mA are to provide the little demons inhabiting the design with a familiar environmental temperature ;-)
2013-10-10 01:15 <DocScrutinizer05> obviously TI thought when a device is operating in hostmode, then energy saving isn't a topic worth considering
2013-10-10 01:17 rz2k has quit []
2013-10-10 01:17 <DocScrutinizer05> I only hope for Nikolaus' statement to be correct, that the other USB cores are less greedy. Otherwise the USB link to modem in GTA04 is prone to kill the design
2013-10-10 01:17 <DocScrutinizer05> since that suspend-to-ram concept for OMAP phones is a silly idea
2013-10-10 01:18 <DocScrutinizer05> and no modem will really support it
2013-10-10 01:19 <DocScrutinizer05> OM only chosen this approach since the S3C24xx were utter crap and had NFC about zero-clock
2013-10-10 01:19 <DocScrutinizer05> at least I hope it was the reason to choose this broken-by-design approach
2013-10-10 01:21 <DocScrutinizer05> wpwrak: do you recall what's been the deal when considering zero-clock versus suspend-to-ram?
2013-10-10 01:21 <DocScrutinizer05> no kernel support (yet) for NOTICK?
2013-10-10 01:22 <DocScrutinizer05> or was it actually just the lack of static registers in S3Cxxxx?
2013-10-10 01:27 <DocScrutinizer05> I'm *really* unhappy with this USB interface to modem. I just recall that N900 keeps CPU active at 500MHz as long as anything is plugged to USB. I guess that's for a reason - prolly the musb-core can't wake the CPU
2013-10-10 01:29 <DocScrutinizer05> and - depending on modem chipset - I might figure that same happens to the ARM and usb-core used in modem
2013-10-10 01:31 dos1 has quit [Ping timeout: 248 seconds]
2013-10-10 01:31 <DocScrutinizer05> I wouldn't like to see both systems (APE and modem) power-up, enumerate, transfer 1 byte, power-down the USB 200 times per second
2013-10-10 01:31 <DocScrutinizer05> particularly since this wouldn't be possible to get done 200 times per second
2013-10-10 01:32 <DocScrutinizer05> I guess USB ENUM overhead is just too huge for doing that
2013-10-10 01:32 <wpwrak> (zero clock) hmm no, don't remember. maybe it wasn't as power-efficient as real suspend, with all the special hw tweaks ?
2013-10-10 01:32 <wpwrak> ah, no dedicated interrupt line ? that sucks :)
2013-10-10 01:34 <DocScrutinizer05> given the difficulties I recall we had with just changing CPU clock frequency in S3C24xx, I doubt it could zero-clock at all, particularly not when peripherals like UART shall still stay on standby and even operational ready to receive a byte to buffer
2013-10-10 01:35 <DocScrutinizer05> iirc everything been just cpu clock * $multiplier
2013-10-10 01:36 <DocScrutinizer05> so when changing cpu clock (by freq-governor) you had the problem of glitches in UART etc unless you temporarily suspend them, which you can do only after stopping/finishing any ongoing transmission
2013-10-10 01:36 <DocScrutinizer05> just that you don't know about 1st byte of a newly started transmissin inbound, before the byte completely is in buffer
2013-10-10 01:38 <DocScrutinizer05> (interrupt line) well for sure there's no interrupt line to wake CPU and musb_core, on ULPI level
2013-10-10 01:38 <DocScrutinizer05> dunno if there's a wake-irq from musb_core to CPU
2013-10-10 01:40 <DocScrutinizer05> ok, on hindsight - and looking on the facts I just summarized - it might have been just the CPU running at 500MHz without any break that caused the 60mA increased system power consumption that we observed as soon as musb_core active
2013-10-10 01:42 <DocScrutinizer05> and funny enough this "patch" to nail cpu clock to 500 when USB, it got introduced by Nokia as late as maemo fremantle PR1.2 iirc
2013-10-10 01:42 <wpwrak> well, you lose uart either way ...
2013-10-10 01:42 <DocScrutinizer05> hmm?
2013-10-10 01:43 <DocScrutinizer05> when uart has own stable clock, you can mess around with cpu clock all you like
2013-10-10 01:43 <wpwrak> whether you stop the clock or suspend the whole cpu. uart is gone then. all you have are your interrupt lines. and maybe rtc and such.
2013-10-10 01:43 <wpwrak> okay, if :)
2013-10-10 01:44 <wpwrak> but just keeping the oscillator running is pricy ...
2013-10-10 01:44 <DocScrutinizer05> I talked about changing cpu clock (in S3C24xx) not about +stopping* it
2013-10-10 01:45 <DocScrutinizer05> been a PITA in GTA02 since you always had windows where you get transmission errors on UART, aiui
2013-10-10 01:45 <wpwrak> (interrupt line) well, the module may have some more signals than just usb ? of course, if they really do everything over usb, you lose ...
2013-10-10 01:45 <wpwrak> that's why you want robust protocols :)
2013-10-10 01:46 <DocScrutinizer05> all you can do is unset CTS and wait if another few bytes may come in, before you mess around with (uart) clock
2013-10-10 01:46 <DocScrutinizer05> I didn't get it why Nikolaus used USB to link to Option module, to start with
2013-10-10 01:47 <DocScrutinizer05> there are PCM and serial interface as well
2013-10-10 01:47 <wpwrak> ask him ?
2013-10-10 01:47 <DocScrutinizer05> I did, and I admit I forgot his rationale
2013-10-10 01:48 <DocScrutinizer05> maybe sth along the line of "so we don't need muxer"
2013-10-10 01:48 <DocScrutinizer05> which otoh opens a path for a sw fix, when we just ignore USB and actually use muxer on serial
2013-10-10 01:50 <DocScrutinizer05> heck, GTA04 even has a PHY to talk to Option module
2013-10-10 01:50 <DocScrutinizer05> :-o
2013-10-10 01:50 <DocScrutinizer05> with charge pump and all
2013-10-10 01:51 <DocScrutinizer05> just no VBUS ;-P
2013-10-10 01:52 <DocScrutinizer05> and I'm pretty puzzled that Option actually seems to work even without VBUS, in peripheral mode
2013-10-10 01:52 <DocScrutinizer05> but there's a ticker along the line of "frequent re-ENUM on modem USB"
2013-10-10 01:53 <DocScrutinizer05> ticket even
2013-10-10 01:53 <DocScrutinizer05> I wonder why ;-)
2013-10-10 01:55 <DocScrutinizer05> USB is a terribly complex module with a lot of overhead, for a simple task like "shuffle bytes between A and B, at high speed with no delay and no errorchecks"
2013-10-10 01:55 <DocScrutinizer05> s/module/protocol/
2013-10-10 01:55 <qi-bot> DocScrutinizer05 meant: "USB is a terribly complex protocol with a lot of overhead, for a simple task like "shuffle bytes between A and B, at high speed with no delay and no errorchecks""
2013-10-10 01:56 <DocScrutinizer05> *ENUM* says it all
2013-10-10 02:02 <wpwrak> no delay ? you can't mean USB then ...
2013-10-10 02:09 <DocScrutinizer05> that's my point, well one of them
2013-10-10 02:11 <DocScrutinizer05> USB is overly complex to replace a simple A<->B bytestream single channel duplex connection
2013-10-10 02:12 <DocScrutinizer05> feels like using tcp/ip to replace a rs232
2013-10-10 02:15 <DocScrutinizer05> actually cheapernet tcp/ip
2013-10-10 02:17 <DocScrutinizer05> wpwrak: do you recall who stated that USB was too power greedy and too much overhead and we shouldn't use it for the MC75, back in OM GTA03 days? The Siemens guys? Or sb of OM, even you?
2013-10-10 02:26 <wpwrak> i does sound like something i may say. not sure if i was involved in that discussion, though.
2013-10-10 02:26 <wpwrak> tcp/ip is MUCH lighter than USB
2013-10-10 02:43 <DocScrutinizer05> indeed
2013-10-10 02:45 <DocScrutinizer05> never heard of tcp/ip ENUM or SNP or HNP or suspend, and ports are only a poor description of EP, and UDP not really a similar technics than isochronous
2013-10-10 03:11 xiangfu has joined #qi-hardware
2013-10-10 04:18 xiangfu has quit [Ping timeout: 264 seconds]
2013-10-10 04:47 xiangfu has joined #qi-hardware
2013-10-10 05:57 viric has quit [Remote host closed the connection]
2013-10-10 05:58 viric has joined #qi-hardware
2013-10-10 06:05 <roh> DocScrutinizer05: the serial interfaces usually dont get you full datarates possible via 3g
2013-10-10 06:05 <roh> most end at 1.2-2mbit
2013-10-10 06:06 <roh> so for hsdpa and similar one might need usb(2) to gain from that. for long-term powersaving usb sucks. correct. thats why basically all these modules do multiple links or augment the usb with proprietary extensions.. and if it only may be 1-2 gpio/irq lines to trigger wakeups or 'resume polling'
2013-10-10 06:07 <roh> in openmoko times.. well.. usb1 host would have been what we could have done.. but without 3g on the modem that never made sense ;)
2013-10-10 06:08 <roh> also the calypso doesnt know usb, so that would have been with a hypothetical module which wasnt in discussion since we had to use the fic owned calypso design.. you remember? ;)
2013-10-10 06:33 wolfspraul has joined #qi-hardware
2013-10-10 06:39 wolfspraul has quit [Quit: leaving]
2013-10-10 06:39 wolfspraul has joined #qi-hardware
2013-10-10 06:41 wej has quit [Ping timeout: 245 seconds]
2013-10-10 06:42 wej has joined #qi-hardware
2013-10-10 06:53 panda|x201 has joined #qi-hardware
2013-10-10 07:43 <DocScrutinizer05> I remeber talking to the siemens guys about MCi75 module, for GTA03. But yes, you're basically right
2013-10-10 07:43 <DocScrutinizer05> we found serial been fast enough for edge
2013-10-10 07:45 <DocScrutinizer05> http://www.wmocean.com/siemens-mc75
2013-10-10 07:47 apelete has left #qi-hardware ["ERC Version 5.3 (IRC client for Emacs)"]
2013-10-10 07:48 apelete has joined #qi-hardware
2013-10-10 07:48 <DocScrutinizer05> I wish the Option would support SSI/HSI
2013-10-10 07:50 <DocScrutinizer05> I guess we will have lots of fun with USB drivers until this contraption works like expected, without burning energy for idle standby or introducing seconds of delay for ENUM on start of each transmissin after a few seconds of idle
2013-10-10 07:50 <DocScrutinizer05> (this contraption == Option601/801 on OMAP via USB)
2013-10-10 07:51 <wpwrak> i think you want to look for alternative signaling mechanisms to use in parallel to USB, as roh has suggested
2013-10-10 07:51 <wpwrak> e.g., get a dedicated interrupt/wakeup line, and only bring up USB when that one tells you there's work to do
2013-10-10 08:02 <apelete> Hi there
2013-10-10 08:02 <apelete> DocScrutinizer05 wpwrak: just read the log of last night conversation about dealing with musb
2013-10-10 08:03 <apelete> it's funny how every single kernel hackers seem to think that dealing with usb/musb is a messy enterprise :-)
2013-10-10 08:03 <DocScrutinizer05> wpwrak: it's not about the concept - it already occurred to me. It's about the overhead of "bringing up"
2013-10-10 08:04 xiangfu has quit [Ping timeout: 252 seconds]
2013-10-10 08:04 <DocScrutinizer05> USB prolly times out when simply stopped
2013-10-10 08:05 <apelete> since I know little about usb to begin with, I guess I can't tell the difference between what's messy and what's not ;-)
2013-10-10 08:06 <DocScrutinizer05> apelete: well for me it was, when I tried to make (and finally made) usb hostmode work on N900, despite the hw bugs
2013-10-10 08:06 <apelete> <DocScrutinizer05> apelete: please don't tell you have to mess with MG musb_core :-O
2013-10-10 08:06 <apelete> DocScrutinizer05: what does MG stands for ?
2013-10-10 08:06 <DocScrutinizer05> mentor graphics
2013-10-10 08:06 <apelete> ok
2013-10-10 08:07 <DocScrutinizer05> a company that better gets erradicated from God's great earth
2013-10-10 08:07 <apelete> :)
2013-10-10 08:09 <DocScrutinizer05> wpwrak: (USB) ...so at very least I guess you need to suspend the USB
2013-10-10 08:09 <DocScrutinizer05> if that's feasible at all with non-OTG devices
2013-10-10 08:10 <DocScrutinizer05> otherwise you need to re-ENUM and that will take seconds
2013-10-10 08:12 <DocScrutinizer05> luckily we don't plan to follow the suspend-to-ram strategy in our frankeN900 aka Neo900, and thus we can tickle USB every second with low penalty in power consumption
2013-10-10 08:13 <DocScrutinizer05> but I doubt this will help to wake up the musb-core when modem wants to talk to APE
2013-10-10 08:14 <DocScrutinizer05> would need some sort of flow control for USB, and I never heard of such thing
2013-10-10 08:14 * DocScrutinizer05 feels nausea
2013-10-10 08:15 <DocScrutinizer05> apelete: can you help me out?
2013-10-10 08:28 <apelete> DocScrutinizer05: sure, help with what ? (don't know if I can, I'm really a noob when it comes to usb :-) )
2013-10-10 08:31 <DocScrutinizer05> oh, I got you wrong then
2013-10-10 08:31 <DocScrutinizer05> hanks anyway
2013-10-10 08:31 <DocScrutinizer05> thanks*
2013-10-10 08:33 <wpwrak> suspend doesn't require OTG. not sure how long it takes, though. i regularly choose not to implement it ;-)
2013-10-10 08:34 <wpwrak> and the wakeup wouldn't come over USB itself but via some additional signal the module may have (just like it probably does for UART, etc.)
2013-10-10 09:00 wolfspraul has quit [Quit: leaving]
2013-10-10 09:10 panda|x201 has quit [Ping timeout: 240 seconds]
2013-10-10 09:25 <whitequark> wpwrak: iirc suspend takes about 5ms or so
2013-10-10 09:26 <whitequark> it counts missed frames, when it's 4 it suspends
2013-10-10 09:26 <whitequark> I think
2013-10-10 10:04 viric has quit [Ping timeout: 240 seconds]
2013-10-10 10:10 viric has joined #qi-hardware
2013-10-10 10:14 woakas has quit [Read error: Operation timed out]
2013-10-10 10:15 woakas has joined #qi-hardware
2013-10-10 10:15 viric has quit [Ping timeout: 240 seconds]
2013-10-10 10:22 viric has joined #qi-hardware
2013-10-10 10:31 <DocScrutinizer05> wow
2013-10-10 10:32 <DocScrutinizer05> so basically auto-suspend?
2013-10-10 10:33 <DocScrutinizer05> wpwrak: UART can happily idle along and resume/wake CPU when a byte in buffer
2013-10-10 10:33 <DocScrutinizer05> even on start bit getting transmitted I guess
2013-10-10 10:35 <whitequark> rechecked. it's 3ms
2013-10-10 10:35 <whitequark> DocScrutinizer05: yeah
2013-10-10 10:35 <whitequark> from the looks of it usb doesn't seem like a power hungry thing (while in idle at least)
2013-10-10 10:35 <whitequark> there's probably something I'm missing
2013-10-10 11:01 xiangfu has joined #qi-hardware
2013-10-10 11:20 <roh> whitequark: well.. maybe that without special extra lines there is no real idle
2013-10-10 11:20 <roh> one needs to poll every 100ms
2013-10-10 11:21 <roh> you only can cheat stuff, like not enumerate the bus and hardcode stuff
2013-10-10 11:21 <roh> but you cannot come around the polling while the link is active, even when there is no traffic
2013-10-10 11:22 <roh> the 'expensive' part is more in the protocol handling. wastes a lot of cputime when all you want to do is what hdlc and serial lines were designed for ;)
2013-10-10 11:23 <roh> well but thats life. sometimes there is no nice way around it. maybe there are modules with fast spi which can do full 3g/4g datarates. dunno.
2013-10-10 11:49 wej has quit [Ping timeout: 260 seconds]
2013-10-10 11:50 wej has joined #qi-hardware
2013-10-10 12:22 viric has quit [Ping timeout: 240 seconds]
2013-10-10 12:30 <wpwrak> (checked USB suspend/resume) there is non-polling wakeup from both sides. so an all-USB solution (without wakeup signal) should be sufficient. you still need to provide 5 V, though. (unless you have a private agreement among your devices to not need that)
2013-10-10 12:35 viric has joined #qi-hardware
2013-10-10 12:48 viric has quit [Ping timeout: 240 seconds]
2013-10-10 12:57 viric has joined #qi-hardware
2013-10-10 13:04 viric has quit [Ping timeout: 240 seconds]
2013-10-10 13:07 <whitequark> roh: rs485!
2013-10-10 13:07 <whitequark> why does one need to poll each 100ms?
2013-10-10 13:10 <roh> whitequark: dont ask me. thats how usb works
2013-10-10 13:11 <whitequark> roh: first time I hear that; I could use some reference
2013-10-10 13:12 <roh> usb works by pollin
2013-10-10 13:12 <roh> g
2013-10-10 13:12 <whitequark> oh
2013-10-10 13:12 <roh> there is no irq line.
2013-10-10 13:12 <whitequark> that's each 1ms
2013-10-10 13:12 <roh> basically the host needs to ask all devices periodically and the idle poll is atleast 100hz or so
2013-10-10 13:12 <whitequark> well, it depends on speed I think. full-speed has sof at each 1ms
2013-10-10 13:14 <whitequark> and on high-speed it's each 125us
2013-10-10 13:14 <whitequark> roh: but, if the device is in sleep mode, there's no activity on bus, and wakeup is asynchronous
2013-10-10 13:14 <whitequark> so it's essentially interrupt-driven if you aggressively put the bus to sleep
2013-10-10 13:14 <roh> whitequark: ive never seen that
2013-10-10 13:14 <roh> usually the bus sleeps when you suspend the machine and else not
2013-10-10 13:14 <whitequark> roh: which part?
2013-10-10 13:14 <whitequark> oh
2013-10-10 13:15 <roh> most disable suspend because its buggy with loads of devices
2013-10-10 13:15 <whitequark> true dat
2013-10-10 13:15 <roh> how should a not polled (sleeping) bus client wake up the host?
2013-10-10 13:15 <whitequark> however if you control the whole system you can make it work
2013-10-10 13:15 <whitequark> roh: it pulls up one of the lines
2013-10-10 13:15 <whitequark> or maybe both. same idea
2013-10-10 13:15 <roh> true. still nasty complicated for somesthing that simple
2013-10-10 13:16 <roh> ah. ok. like a i2c bus?
2013-10-10 13:16 <whitequark> sorta
2013-10-10 13:18 <wpwrak> more like high/low speed detection
2013-10-10 13:18 <whitequark> the timing's not cool though
2013-10-10 13:18 <whitequark> When the host wants to wake the device up after a suspend, it does so by reversing the polarity of the signal on the data lines for at least 20ms. The signal is completed with a low speed end of packet signal.
2013-10-10 13:18 <whitequark> It is also possible for a device with its remote wakeup feature set, to initiate a resume itself. It must have been in the idle state for at least 5ms, and must apply the wakeup K condition for between 1 and 15 ms. The host takes over the driving of the resume signal within 1 ms.
2013-10-10 13:19 <wpwrak> in idle/suspend, the bus is J, in resume, it's K. see also figure 11-17 on page 333 of the USB 2.0 spec
2013-10-10 13:19 <wpwrak> yeah, that one :)
2013-10-10 13:20 <whitequark> newer phones (eg SGS2) use an USB-ish protocol
2013-10-10 13:20 <whitequark> it's USB2 above physical layer, and on physical they did something to transceivers
2013-10-10 13:20 <whitequark> to make them eat less
2013-10-10 13:20 <whitequark> I'm not sure what in particular though
2013-10-10 13:22 <roh> yeah. dont worry.. in a few years we will use pci-express links anyhow for internal modems
2013-10-10 13:23 <whitequark> riiight, let them be bus masters again
2013-10-10 13:23 <whitequark> what could go wrong
2013-10-10 13:24 <wpwrak> nothing. trust us :)
2013-10-10 13:24 viric has joined #qi-hardware
2013-10-10 13:24 * whitequark . o O ( when was wpwrak recruited by NSA? )
2013-10-10 13:26 <roh> whitequark: bus masters? not the issue.. thats what iommu are for
2013-10-10 13:27 <whitequark> iommus are still 'high end' even for pcs
2013-10-10 13:27 <larsc> whitequark: who do you think sponsors the anelok development
2013-10-10 13:27 <whitequark> though I can see how that changes in ~5yrs before we see phones with pcie modems
2013-10-10 13:28 <roh> whitequark: youve seen the arduino from intel?
2013-10-10 13:28 <roh> that one has pci-e
2013-10-10 13:28 <roh> so.. lets wait ;)
2013-10-10 13:28 <whitequark> roh: yes, that was hilarious
2013-10-10 13:30 viric has quit [Ping timeout: 240 seconds]
2013-10-10 13:34 <whitequark> http://www.jinx.de/ItsNotAFeature.mp4
2013-10-10 13:38 viric has joined #qi-hardware
2013-10-10 13:52 <whitequark> interesting: http://homes.esat.kuleuven.be/~gacar/fpdetective/#paper
2013-10-10 14:17 dos1 has joined #qi-hardware
2013-10-10 14:49 panda|x201 has joined #qi-hardware
2013-10-10 14:55 kristianpaul has quit [Ping timeout: 264 seconds]
2013-10-10 15:03 kristianpaul has joined #qi-hardware
2013-10-10 15:25 <viric> whitequark: yes, interesting. thank you!
2013-10-10 15:36 rz2k has joined #qi-hardware
2013-10-10 15:51 <wpwrak> whitequark: "... howing a complete disregard towards Do-Not-Track" who would have thought ? :)
2013-10-10 15:55 <viric> the whole idea of adding a flag 'do-not-track' to firefox is evil
2013-10-10 15:56 <viric> (meaning the do-not-track http thing)
2013-10-10 15:56 <mth> do-not-track is just another data point to fingerprint
2013-10-10 16:02 <mth> advertisers already said they would use do-not-track to disable the display of targetted ads, not disable the tracking itself
2013-10-10 16:03 <mth> how hiding the results of the information they collect is supposed to make me feel better, I don't know
2013-10-10 16:10 <wpwrak> oh, if it hides ads, that could be useful. but yes, it's a fig leave, nothing more
2013-10-10 16:10 <mth> it doesn't hide ads, it just replaces targetted ads with random ads
2013-10-10 16:12 <wpwrak> so useless and annoying ads are replaced with ads that are marginally more useless and annoying. ah, the marvels of modern technology :)
2013-10-10 16:20 <viric> wpwrak: enjoy the boolean option
2013-10-10 16:26 <whitequark> the whole do-not-track idea is moronic
2013-10-10 16:27 <whitequark> kill third-party cookies, watch the advertisers burn
2013-10-10 16:39 pcercuei has joined #qi-hardware
2013-10-10 16:42 <wpwrak> we should have peer-to-peer identity swapping. when a site asks for something identifiable, present someone else's
2013-10-10 16:43 <wpwrak> would need a whitelist, though, to avoid swapping access credentials. well, unless one is okay with that :)
2013-10-10 16:44 rz2k has quit []
2013-10-10 16:46 <whitequark> that implies there is a concept of "identity"
2013-10-10 16:46 <whitequark> but it's not; it's just a thousand random ways your browser remembers stuff
2013-10-10 16:49 <whitequark> how do you separate credential cookies from identity cookies?
2013-10-10 16:55 <wpwrak> you make a list ... and maybe never visit sites with "valuable" accounts with that browser
2013-10-10 16:55 <whitequark> you could just disable cookies then
2013-10-10 16:56 <whitequark> persistence in web has surprisingly little value besides authentication
2013-10-10 17:00 xiangfu has quit [Quit: leaving]
2013-10-10 17:01 <mth> I have cookies disabled except for whitelisted sites, but it's been a pain since the EU cookie directive
2013-10-10 17:01 <mth> because sites use cookies to check if they already told you that they use cookies
2013-10-10 17:02 <mth> and often won't let you use the site until you dismiss their cookie notice
2013-10-10 17:02 <mth> the whole cookie directive is another bad idea
2013-10-10 17:03 <mth> they should either have outlawed tracking cookies, or let end users fend for themselves
2013-10-10 17:03 <mth> instead, they picked a half measure which doesn't help privacy and causes a lot of inconvenience
2013-10-10 17:19 rz2k has joined #qi-hardware
2013-10-10 17:40 FDCX has quit [Ping timeout: 264 seconds]
2013-10-10 17:54 FDCX has joined #qi-hardware
2013-10-10 18:27 panda|x201 has quit [Ping timeout: 240 seconds]
2013-10-10 18:42 dos1 has quit [Ping timeout: 248 seconds]
2013-10-10 20:22 pcercuei has quit [Ping timeout: 240 seconds]
2013-10-10 20:51 pcercuei has joined #qi-hardware
2013-10-10 21:44 woakas has quit [Ping timeout: 264 seconds]
2013-10-10 21:47 rzk has joined #qi-hardware
2013-10-10 21:50 rz2k has quit [Ping timeout: 248 seconds]
2013-10-10 22:22 FDCX has quit [Read error: Operation timed out]
2013-10-10 22:36 FDCX has joined #qi-hardware
2013-10-10 23:02 <unclouded> I have a cookie whitelist too.  it's great once set up.  I get the occasional redirect loop.  not had trouble with European sites yet though
2013-10-10 23:03 <mth> the trouble is that I need to whitelist sites now that I could leave on the default deny previously
2013-10-10 23:04 pcercuei has quit [Ping timeout: 264 seconds]
2013-10-10 23:05 wolfspraul has joined #qi-hardware
2013-10-10 23:05 pcercuei has joined #qi-hardware
2013-10-10 23:16 pcercuei has quit [Quit: dodo]