**** BEGIN LOGGING AT Thu Nov 29 02:59:59 2012
Nov 29 06:29:00 <PaulFertser> DocScrutinizer05: i'm not sure but i think some android devices do that, else there wouldn't be any wakelocks intra in their kernel.
Nov 29 06:30:59 <DocScrutinizer05> hmm, fair enough
Nov 29 06:31:19 <DocScrutinizer05> but then I don't want to know what android defines as "suspend"
Nov 29 06:37:40 <DocScrutinizer05> anyway for OMAP I strongly deprecate suspend, since the processor is built to do zeroclock
Nov 29 06:38:49 <DocScrutinizer05> so zeroclock comes naturally, while suspend is full of cruft and complexity
Nov 29 06:40:01 <DocScrutinizer05> and wake from zeroclock is 10^5..10^7 times faster
Nov 29 06:41:52 <DocScrutinizer05> which means that despite a few hundred wakes / second the CPU still can idle for 99.9% of time. You can't do that with suspend
Nov 29 06:50:56 <lindi-> DocScrutinizer05: of course then the problem is that you have existing userland applications that cause extra wakeups
Nov 29 06:51:05 <lindi-> like icewm which updates its clock every second
Nov 29 06:51:18 <DocScrutinizer05> :shrug:
Nov 29 06:51:23 <lindi-> you either need to fix all of those separately or have the kernel somehow freeze the processes
Nov 29 06:51:59 <DocScrutinizer05> I have no problem whatsoever with some process updating its clock once a second
Nov 29 06:52:03 <lindi-> not to mention javascript doing that
Nov 29 06:52:33 <DocScrutinizer05> well, either you fix the crappy apps, or you ruin the OS
Nov 29 06:53:10 <lindi-> working on it
Nov 29 06:53:26 <lindi-> what OS do you run? ;)
Nov 29 06:53:32 <DocScrutinizer05> developers using timer based polls for anything except updating clocks should get shot with owl shit
Nov 29 06:54:38 <DocScrutinizer05> basically any busy loops are forbidden, even with a usleep() in it
Nov 29 06:55:24 <DocScrutinizer05> apps doing busyloops are broken by design and the devels should get ... I mentioned that
Nov 29 06:56:51 <DocScrutinizer05> stopping processes to fix their rogue greedy resource-hogging behaviour is a deadend concept
Nov 29 07:00:24 <DocScrutinizer05> lindi-: which OS? where?
Nov 29 07:01:49 <DocScrutinizer05> lindi-: and jeah, JS is BS, even on my desktop linux
Nov 29 07:01:56 <DocScrutinizer05> yeah*
Nov 29 07:02:58 <DocScrutinizer05> basically the browser should stop any JS after max 30s
Nov 29 07:03:55 <PaulFertser> lindi-: Doc meant to say that Maemo on n900 managed to handle that "ok" if you do not install additional stupid apps. And if you do, you can find then with the help of powertop.
Nov 29 07:04:12 <DocScrutinizer05> and occasionally I see warnings from my browser "some script is consuming resources, shall I stop it?"
Nov 29 07:04:50 <PaulFertser> DocScrutinizer05: but lindi-'s point is that if some app misbehaves then with suspend it's not that relevant and with zeroclock you have to manually search for it.
Nov 29 07:06:18 <DocScrutinizer05> well, I'm not interested in a conceptual botch "fix" in OS for rogue apps. Since this botch will also 'fix' all my other apps that are supposed to run, like IRC, WLAN, whatnot else
Nov 29 07:08:30 <DocScrutinizer05> and indeed a monitoring and alerting supervisor process similar to that JS-warning in browser, only for general OS processes, is on my ToDo list since long time
Nov 29 07:08:51 <DocScrutinizer05> so I'd automate the 'manual' searching
Nov 29 07:09:35 <DocScrutinizer05> there's already a similar app in KDE
Nov 29 07:10:11 <DocScrutinizer05> just a itsy bit too simplistic, since it has no whitelists afaik
Nov 29 07:12:06 <PaulFertser> I agree, zeroclock is a cool thing to have.
Nov 29 07:16:48 <DocScrutinizer05> and, as mentioned above, I have no problems with programs even waking CPU 5 times per second, since waking from zeroclock is utterly lightweight and the CPU load still stays extremely low, while with waking from suspend 5 times a second you quite possibly have no CPU cycles left to do the task you're waking the CPU for
Nov 29 07:18:09 <DocScrutinizer05> so for the majority of cases you create the problem by implementing the fix
Nov 29 07:22:34 <DocScrutinizer05> http://maemo.cloud-7.de/maemo5/usr/local/sbin/bq27200.sh with parameter 5 (seconds interval) runs on N900 for days from battery. Do that on a OS with suspend ;-D
Nov 29 07:23:42 <DocScrutinizer05> I actualy tested exactly that `bq27200.sh 5 >>~user/MyDocs/battery.log` recently
Nov 29 07:24:27 <DocScrutinizer05> it was running like 15 days while I used my phone as usual, charging it once a day
Nov 29 07:25:26 <DocScrutinizer05> and of course I have xchat running all the time as well
Nov 29 07:26:13 <DocScrutinizer05> on WLAN it does at least one full day, even when on 9 active channels
Nov 29 07:26:44 <DocScrutinizer05> on 2G it's 8..18h, on 3G 4..7h
Nov 29 07:29:32 <DocScrutinizer05> shadowJK came up with a nice little netfilter hack that bundles IRC traffic into chunks sent every 30s only, on ZNC bouncer. Eventually I have to test that, might improve standby time on 2G and especially 3G massively
Nov 29 11:58:37 <jluis>  ~logs
Nov 29 11:58:37 <apt> All conversations are logged to http://apt.rikers.org/%23openmoko%2dcdevel/ Lines starting with spaces are not logged. Logs are updated daily  ---  livelogs are on http://logs.nslu2-linux.org/livelogs/openmoko-cdevel.txt
Nov 29 13:17:52 <ayaka> GNUtoo-hplaptop, hello, althought there is cmod 10 for evo 3d gsm but it is no official. so it doesn't release source
Nov 29 13:46:54 <GNUtoo-hplaptop> ayaka, ah?
Nov 29 13:47:08 <GNUtoo-hplaptop> ayaka, they probably have sources somewhere
Nov 29 13:47:23 <ayaka> http://forum.xda-developers.com/showthread.php?t=1826747
Nov 29 13:47:36 <GNUtoo-hplaptop> they're at least legally obligated to release kernel sources and all the sources of what's copyleft, such as GPL, LGPL etc...
Nov 29 13:49:31 <ayaka> GNUtoo-hplaptop, but the actual boot image is missing from the package
Nov 29 13:49:58 <GNUtoo-hplaptop> the thread is 101 page long, I cannot read it right now fully
Nov 29 13:51:39 <ayaka> GNUtoo-hplaptop,  I think only the first two pages has information
**** ENDING LOGGING AT Fri Nov 30 02:59:58 2012