| 00:00.46 | *** join/#maemo atk (Arch-TK@ircpuzzles/staff/Arch-TK) |
| 00:19.39 | *** join/#maemo infobot (~infobot@rikers.org) |
| 00:19.39 | *** topic/#maemo is Welcome to #maemo http://maemo.org/intro/ | N9/harmattan related questions please in #harmattan ! | "firmware" see ~lf ~tabletsdev ~combined ~emmc ~flasher sdk: ~sb | http://wiki.maemo.org/Community_Council | Source: http://wiki.maemo.org/Sources | Chanlog: http://mg.pov.lt/maemo-irclog | #maemo-ssu is where the (few) devels and maintainers of the maemo-future meet |
| 00:36.15 | *** join/#maemo dreamer (~henk@unaffiliated/dreamer) |
| 01:01.52 | *** join/#maemo Kabouik (~quassel@32.232.202.84.customer.cdi.no) |
| 01:29.44 | *** join/#maemo Kabouik_ (~quassel@37.0.123.65) |
| 02:03.50 | *** join/#maemo keithzg_ (~keithzg@198-48-135-131.cpe.pppoe.ca) |
| 03:17.44 | *** join/#maemo mike727 (d31f1b25@gateway/web/freenode/ip.211.31.27.37) |
| 03:23.01 | *** join/#maemo pagurus` (~user@p4FDC3561.dip0.t-ipconnect.de) |
| 03:27.00 | *** join/#maemo KotCzarny (ariel@31.135.195.151) |
| 03:29.53 | mike727 | Anyone tried "shake to wake" (lockd.py)? I guess it would exhaust resources/battery? |
| 04:42.08 | *** join/#maemo Oksana (~Wikiwide@Maemo/community/ex-council/Wikiwide) |
| 05:11.59 | *** join/#maemo kalin (~kalin@128.140.177.180) |
| 05:55.59 | *** join/#maemo dafox (~dafox@92.69.239.233) |
| 06:25.38 | *** join/#maemo florian (~fuchs@x4d0940f6.dyn.telefonica.de) |
| 06:30.55 | *** join/#maemo dmth|intevation (~dmth|inte@2001:470:747a:2a:6af7:28ff:fe64:1ded) |
| 07:02.58 | *** join/#maemo louisdk (~louisdk@static-5-103-138-205.fibianet.dk) |
| 07:04.48 | *** join/#maemo xorly (~xorly@ip-86-49-24-93.net.upcbroadband.cz) |
| 07:30.48 | *** join/#maemo geaaru (~geaaru@host170-152-static.43-88-b.business.telecomitalia.it) |
| 07:46.11 | *** join/#maemo jskarvad (~jskarvad@ip4-83-240-109-95.cust.nbox.cz) |
| 07:46.11 | *** join/#maemo jskarvad (~jskarvad@redhat/jskarvad) |
| 07:46.45 | *** join/#maemo jskarvad (~jskarvad@redhat/jskarvad) |
| 07:48.32 | *** join/#maemo florian (~fuchs@Maemo/community/contributor/florian) |
| 07:54.47 | *** join/#maemo NeKit (~nekit@188.162.228.132) |
| 07:59.22 | *** join/#maemo hurrian (~textual@unaffiliated/rikanee) |
| 08:08.51 | *** join/#maemo eMHa (~mh@81.26.162.98) |
| 08:25.30 | *** join/#maemo Maxdamantus (~Maxdamant@unaffiliated/maxdamantus) |
| 09:15.05 | *** join/#maemo Kabouik (~quassel@32.232.202.84.customer.cdi.no) |
| 09:42.39 | *** join/#maemo capitanocrunch (~capitanoc@unaffiliated/capitanocrunch) |
| 09:52.27 | sixwheeledbeast^ | yes and yes |
| 10:07.57 | *** join/#maemo zGrr (~Grr@185.13.106.209) |
| 10:11.55 | zGrr | moin :) |
| 10:14.20 | *** join/#maemo qwazix (~qwazix@Maemo/community/ex-council/qwazix) |
| 10:29.33 | *** join/#maemo NeKit (~nekit@95-83-16-88.saransk.ru) |
| 10:51.05 | *** join/#maemo err0r3o3 (~err0r3o3@194-118-9-250.adsl.highway.telekom.at) |
| 10:55.52 | *** join/#maemo Konsieur (~kabouik@129.242.224.30) |
| 11:36.56 | *** join/#maemo auenf (David@CPE-139-168-183-46.lns9.woo.bigpond.net.au) |
| 11:43.00 | *** join/#maemo qwazix (~qwazix@Maemo/community/ex-council/qwazix) |
| 11:50.33 | *** join/#maemo xorly (~xorly@ip-86-49-24-93.net.upcbroadband.cz) |
| 12:33.27 | *** join/#maemo xy2_ (~xy2_@94.239.177.175) |
| 12:33.47 | *** join/#maemo at1as (~at1as@kurios.r4780y.com) |
| 12:35.54 | *** join/#maemo louisdk (~louisdk@0155800993.0.fullrate.ninja) |
| 13:05.08 | *** join/#maemo xy2_ (~xy2_@63.245.16.93.rev.sfr.net) |
| 13:51.38 | *** join/#maemo ss942 (~zeko@77-254-45-155.adsl.inetia.pl) |
| 13:56.07 | *** part/#maemo L29Ah (~L29Ah@31.173.81.18) |
| 14:00.48 | ss942 | My last phone got broken and I'm using n900 again from now. But as far as I can see repos are not working any longer. |
| 14:01.00 | ss942 | I know that I have to replace repos with community ones |
| 14:02.03 | ss942 | but I'm prrety exhausted because I installed fremantle from repository.maemo.org/community as interned said me to do |
| 14:02.42 | ss942 | and it's still not working. |
| 14:02.42 | ss942 | could anyone link me a working repos catalogue? |
| 14:12.28 | sicelo | ~maemo-repos |
| 14:12.28 | infobot | rumour has it, maemo-repos is http://wiki.maemo.org/Repository#List_of_Maemo_repositories |
| 14:15.32 | *** join/#maemo frals (~frals@Maemo/community/contributor/frals) |
| 14:17.42 | *** join/#maemo frals (~frals@c83-251-150-255.bredband.comhem.se) |
| 14:17.42 | *** join/#maemo frals (~frals@Maemo/community/contributor/frals) |
| 14:21.51 | sicelo | ss942: ^^ |
| 14:23.18 | ss942 | sicelo: thanks |
| 14:35.38 | *** join/#maemo RedW (~redw@89-74-182-178.dynamic.chello.pl) |
| 14:35.38 | *** join/#maemo frals (~frals@c83-251-150-255.bredband.comhem.se) |
| 14:35.38 | *** join/#maemo frals (~frals@Maemo/community/contributor/frals) |
| 15:06.32 | *** join/#maemo L29Ah (~L29Ah@31.173.81.18) |
| 15:17.38 | *** join/#maemo heroux (sandroco@gateway/shell/insomnia247/x-zpgagtmlftjvzuxa) |
| 15:26.26 | *** join/#maemo eMHa (~mh@p200300738E025000267703FFFE6CC360.dip0.t-ipconnect.de) |
| 15:27.19 | *** join/#maemo Pali (~pali@Maemo/community/contributor/Pali) |
| 15:28.29 | *** join/#maemo xy2_ (~xy2_@63.245.16.93.rev.sfr.net) |
| 15:28.51 | DocScrutinizer05 | shake to wake - drains battery only when implemented without a clue |
| 15:29.25 | DocScrutinizer05 | this is exactly the point how embedded differs massively from coding for a standard desktop PC |
| 15:30.31 | DocScrutinizer05 | it's a pity not even the maemo lis302 kernel driver is really a comprehensive decent implementation |
| 15:31.43 | DocScrutinizer05 | for "shake to wake" you'd basically need to use your own kernel driver or go for I2C plus your own IRQ handler |
| 15:35.16 | DocScrutinizer05 | correct way to implement: set up the filters and thresholds in LIS302 so it triggers IRQ on shake (use high pass filter to detect fast movements rest changes in orientation), set up an IRQ handler that reads out LIS302 (to filter out false positives) and wakes the device. For this you need to tell MCE to keep its fingers off the LIS302 |
| 15:36.10 | DocScrutinizer05 | what MCE does to LIS302 filters is total brainfart |
| 15:38.14 | DocScrutinizer05 | s/MCE/MCE and lis302dl.ko kernel driver/ |
| 15:39.25 | DocScrutinizer05 | ~tell sicelo about jrrepos |
| 15:49.05 | DocScrutinizer05 | ~jrrepos |
| 15:49.05 | infobot | from memory, jrrepos is http://maemo.cloud-7.de/maemo5/et_al/HAM-catalogs/ |
| 15:50.15 | DocScrutinizer05 | seems to still have to learn "you NEVER must change a URL on your server" |
| 15:55.36 | sixwheeledbeast^ | It's python so basically has a loop polling the accel while locked. I tested it but cannot justify the battery drain. |
| 15:56.40 | DocScrutinizer05 | loops and polling are both absolute nogo on embedded |
| 15:56.59 | *** join/#maemo err0r3o3 (~err0r3o3@194-118-75-133.adsl.highway.telekom.at) |
| 15:57.15 | bencoh | sixwheeledbeast^: it means core keeps exiting sleep / low power states |
| 15:57.22 | DocScrutinizer05 | you *always* have to use event driven design, here event=IRQ |
| 15:57.23 | *** part/#maemo L29Ah (~L29Ah@31.173.81.18) |
| 15:57.36 | sixwheeledbeast^ | exactly |
| 15:58.06 | DocScrutinizer05 | actually _always_ event=IRQ |
| 15:58.16 | DocScrutinizer05 | even on touch events and keypress events |
| 15:58.42 | DocScrutinizer05 | that's embedded programming |
| 15:59.30 | DocScrutinizer05 | it SHOULD be generic concept for all platforms/environment. But on desktop often developers get away with crappy polling |
| 16:01.41 | DocScrutinizer05 | a busy loop should throw an error in compiler already ;-P - A fat WARNING if the loop event is a timer (with less than 5 seconds interval) |
| 16:04.01 | DocScrutinizer05 | on kernel level in maemo, processes that don't stop on a IRQ for at least 99% of time during one minute should get terminated hard with BUSERR or somesuch |
| 16:05.20 | DocScrutinizer05 | OHM should take care |
| 16:08.31 | DocScrutinizer05 | you know those "the program is not responding within time, do you want to wait longer or terminate it?" requesters (KDE for example)? Similar requester on maemo Hildon should be "the process is using more than 50% of time slots available to it, during last 60s. Do you want to stop the process, or allow for another minute, or allow permanently for all processes with this name?" |
| 16:09.34 | DocScrutinizer05 | #s/permanently/for one week/ |
| 16:12.16 | DocScrutinizer05 | s/stop/stop, or kill/ |
| 16:12.29 | *** join/#maemo louisdk (~louisdk@ruc-007.ruc.dk) |
| 16:14.47 | DocScrutinizer05 | prolly a selection offering 1, 5, 60 minutes, 6h, 24h, 1 month (, forever with root password) - should be sufficiently versatile |
| 16:17.34 | DocScrutinizer05 | plus "[_] apply to whole process group" and "[_] apply to all processes with name regex '_________' " with the regex already preset to the process name of the triggering process, but editable |
| 16:19.04 | *** join/#maemo dafox (~dafox@92.69.239.233) |
| 16:19.31 | DocScrutinizer05 | *might* need patches to scheduler |
| 16:21.42 | DocScrutinizer05 | well, you _could_ check CPU-time elabsed for all processes every minute and compare to last check, to detect those processes that together consumed more than 30s CPU time and blame the one of them with highest CPU time increase |
| 16:23.22 | DocScrutinizer05 | problem arises when one or more of those processes are already whitelisted for high CPU usage |
| 16:24.35 | DocScrutinizer05 | it's tricky to handle the situation where 4 processes hog the CPU 100% and one of them is whitelisted |
| 16:25.51 | DocScrutinizer05 | the other three might actually be humble and only use all their available CPU time because there isn't much CPU time left for them due to the whiteliszed hog process |
| 16:30.22 | DocScrutinizer05 | btw it's one of the major tasks in maemo-testing evaluation to check for those CPU hogs and kick their ass |
| 16:30.44 | DocScrutinizer05 | ~pkg |
| 16:30.44 | infobot | pkg is, like, http://maemo.org/packages/ |
| 16:32.49 | DocScrutinizer05 | no freking f*ing clue how http://maemo.org/packages/package_instance/view/fremantle_extras_free_armel/shaketowake2/2.2.3-2/ made it into extras |
| 16:33.18 | DocScrutinizer05 | would be council's duty to remove it from maemo-extras |
| 16:34.05 | DocScrutinizer05 | http://maemo.org/packages/package_instance/view/fremantle_extras-testing_free_armel/shaketowake2/2.2.3-2/ even ivgalvez OMG |
| 16:34.39 | DocScrutinizer05 | >>There have been no comments so far.<< tells a story |
| 16:35.01 | DocScrutinizer05 | people think testing evaluation is a sympathy contest |
| 16:36.39 | DocScrutinizer05 | @council: please consider removing http://maemo.org/packages/package_instance/view/fremantle_extras_free_armel/shaketowake2/2.2.3-2/ since evaluation in testing (see above) failed to detect a major flaw - CPU hogging - in this app |
| 16:37.18 | KotCzarny | didnt he say he reduced cpu usage? |
| 16:38.26 | DocScrutinizer05 | from 100% to 50% ? ;-P |
| 16:38.40 | KotCzarny | better than original, so that's improvement? |
| 16:38.54 | KotCzarny | anyway, 2011, seems to be long time ago |
| 16:39.25 | DocScrutinizer05 | that's no argument |
| 16:39.25 | KotCzarny | wonder if maintainer is still alive in maemo |
| 16:39.57 | DocScrutinizer05 | all packages in maemo-extras are supposed to be safe to use, not cause any issues like massive battery drain |
| 16:39.59 | DocScrutinizer05 | unless obvious, like in games etc |
| 16:42.36 | KotCzarny | or audio player :P |
| 16:42.36 | DocScrutinizer05 | the average user has no means to find out why their phone only stays as short as 10h with one battery charge, after they installed a dozen packages |
| 16:42.36 | DocScrutinizer05 | audio player must at least provide a maybe 10h |
| 16:42.36 | KotCzarny | yeah, and no resource drain when paused/idle |
| 16:42.36 | DocScrutinizer05 | yep |
| 16:42.36 | DocScrutinizer05 | this is the basic rule for ALL apps |
| 16:42.36 | KotCzarny | which means keeping evilaudio in the kennel when not playing anything, as i've found out few years ago |
| 16:42.37 | DocScrutinizer05 | shake2waje violates it |
| 16:43.04 | KotCzarny | maybe there should be a page with violators |
| 16:43.06 | *** join/#maemo L29Ah (~L29Ah@31.173.81.18) |
| 16:43.13 | KotCzarny | and versions tested |
| 16:43.47 | KotCzarny | easier than contacting authors purging packages (that might be useful otherwise) |
| 16:43.47 | DocScrutinizer05 | this page is "testing", basically |
| 16:45.17 | DocScrutinizer05 | ponders a generic patch to preinstall script that opens up a requester with bold fat "WARNING! this app is not recommended to use, since it has the following issues: ....*)...." |
| 16:45.32 | DocScrutinizer05 | easy to add to existing packages |
| 16:46.18 | DocScrutinizer05 | though I actually would prefer that stuff getting purged from maemo-extras. Back to maemo-extras-testing |
| 16:50.00 | KotCzarny | i would vote for warning with a list of pkg-ver |
| 16:50.13 | KotCzarny | as long user knows what drains the battery he/she might choose it consciously |
| 16:50.22 | KotCzarny | or even fix |
| 16:50.44 | DocScrutinizer05 | huh? the warning requester is bound to the particular version's pre-install script |
| 16:51.05 | DocScrutinizer05 | when user want to "choose conciously" they are free to use the package from maemo-extras-devel or -testing |
| 16:51.38 | DocScrutinizer05 | such package has no place in maemo-extras (plain) |
| 16:52.07 | DocScrutinizer05 | I'm not going to fix a package that is broken by design |
| 16:53.09 | DocScrutinizer05 | particularly this package that's basically impossible to fix without massive fixes/improvements to the kernel driver for lis302 |
| 16:57.13 | DocScrutinizer05 | juiceme: ^^^^ |
| 16:57.18 | DocScrutinizer05 | sicelo: ^^^^ |
| 16:57.55 | DocScrutinizer05 | @council: please consider removing http://maemo.org/packages/package_instance/view/fremantle_extras_free_armel/shaketowake2/2.2.3-2/ since evaluation in testing (see above) failed to detect a major flaw - CPU hogging - in this app |
| 16:58.59 | DocScrutinizer05 | should go back to maemo-extras-testing, with comment "promoted based on flawed evaluation, please fix CPU hogging" |
| 17:02.33 | DocScrutinizer05 | is temped to take adminustrative measures already, on the packages web |
| 17:07.23 | DocScrutinizer05 | *COUGH* |
| 17:07.25 | DocScrutinizer05 | <PROTECTED> |
| 17:07.27 | DocScrutinizer05 | f=os.popen('cat /sys/class/i2c-adapter/i2c-3/3-001d/coord').read() |
| 17:09.58 | DocScrutinizer05 | now WHAT THE FUCK?!? http://paste.ubuntu.com/25113245 |
| 17:11.48 | DocScrutinizer05 | this is so terribly wrong, I have no wards for it. Best part: it actually doubles what mce already does, just waaaay inferior |
| 17:13.17 | DocScrutinizer05 | coor = self.get_rotation() |
| 17:13.18 | DocScrutinizer05 | <PROTECTED> |
| 17:13.20 | DocScrutinizer05 | <PROTECTED> |
| 17:13.21 | DocScrutinizer05 | <PROTECTED> |
| 17:14.53 | DocScrutinizer05 | THIS is something you get from MCE already, and MCE at least does The Right Thing[TM] which is: set uf filters in lis302 exactly like that (y<-1300 or y>1300) and waiting for IRQ from the filters |
| 17:15.13 | DocScrutinizer05 | set up* |
| 17:17.24 | DocScrutinizer05 | well, almost exactly like that |
| 17:19.07 | DocScrutinizer05 | this isn't very smart in MCE, but it's totally braindead in the way shake2wake does it by *polling* the accel and then only checking for Y axis |
| 17:20.13 | DocScrutinizer05 | hint: iirc 1000 is 1g aka "device has no other acceleration than gravity" |
| 17:21.51 | DocScrutinizer05 | MCE uses static threshold of iirc 900 somesuch on Y - without any highpass filters - to detect if device is facing up (>900) or down (<900) |
| 17:21.55 | DocScrutinizer05 | iirc |
| 17:22.17 | DocScrutinizer05 | actually the kernel driver does that |
| 17:22.32 | *** join/#maemo vahe[m] (vahediaspi@gateway/shell/matrix.org/x-steoorxanpbjwtdi) |
| 17:23.33 | DocScrutinizer05 | should have used highpass filters and same threshold (like 100/s) on two axes to trigger the IRQ |
| 17:23.33 | DocScrutinizer05 | s/same/sane/ |
| 17:25.20 | *** join/#maemo chfoo[m] (chfoomatri@gateway/shell/matrix.org/x-mfgiyeyltdlfhbrr) |
| 17:26.08 | DocScrutinizer05 | plus MCE and kernel driver should have API to modify the filters. MCE must keep a list of requests for filter settings from userland and choose the most sensitive one. Much like liblocation |
| 17:29.07 | DocScrutinizer05 | see http://wiki.maemo.org/PyMaemo/Using_Location_API |
| 17:35.01 | *** join/#maemo louisdk (~louisdk@ruc-007.ruc.dk) |
| 17:37.03 | DocScrutinizer05 | >>Location resources are shared between applications, and applications can request different location methods. Fixes for all requested methods are sent for all applications listening to GPSDevice's "changed" signal, therefore application should judge whether fix it is receiving, is one that it needs. See GPSDeviceFix section for discussion.<< and >>An application receiving a fix cannot know if the fix is a result from location method |
| 17:37.04 | DocScrutinizer05 | it requested. Therefore application should study whether fix is accurate enough to satisfy application's needs.<< s/fix/acceleration event/ s/location method/lis302 filter/ |
| 17:47.46 | *** join/#maemo florian (~fuchs@x4d0940f6.dyn.telefonica.de) |
| 17:47.46 | *** join/#maemo florian (~fuchs@Maemo/community/contributor/florian) |
| 17:57.24 | DocScrutinizer05 | the kernel driver must expose the filter settings, the middleware (MCE) must have an API with abstract filer settings for the userland to register for an event based on those filters. The middleware will keep a list of those registrations and adjust the filers in kernel driver to the most sensible ones. with no active registrations the middleware will disable the accel sensor |
| 18:01.40 | DocScrutinizer05 | if a userland process requests filer settings that collide with the ones in effect, the response from middleware will notify to the userland process which filter setting are in effect and which failed on the request. For example LIS302 has only two engines to monitor sensors and trigger IRQ, so only 2 of the XYZ axes can get monitored. If filers monitor X,Y then a request for X,Z will return with "Z ignored, resouce occupied" |
| 18:07.16 | DocScrutinizer05 | logical consequence: the API in middleware allows to request the theoretical maximum for filters/triggers, I.E "Xmin,max,hp_parameters Ymin,max,hp_parameters Zmin,max,hp_parameters Xclick Xdoubleclick Yclick Ydoubleclick Zclick Zdoubleclick " |
| 18:07.16 | *** join/#maemo mavhc (~mavhc@cpc77319-basf12-2-0-cust433.12-3.cable.virginm.net) |
| 18:08.08 | *** join/#maemo cyteen (~cyteen@cyteen42.plus.com) |
| 18:08.23 | DocScrutinizer05 | obviously some sort of plaintext interface is best suited for that, to have the most generic interface design suitable for other sensors as well |
| 18:14.55 | DocScrutinizer05 | "X:<-1300,>1300,abs;Y:>30,hpwindow=2s;Z:>-5,<5,abs" |
| 18:17.00 | DocScrutinizer05 | X triggers when value outside the interval -1300..+1300; Y triggers when value change is >30 in 2 seconds; Z triggers when value inside interval -5..+5 |
| 18:20.46 | DocScrutinizer05 | parameters in request are satisfied from left to right. so for the lis302 the response from middleware could be "X*:>50,hpwindow=10s;Y:>30,hpwindow=2s;Z:EAVAIL" |
| 18:22.01 | *** join/#maemo LauRoman (~LauRoman@5-14-1-79.residential.rdsnet.ro) |
| 18:23.57 | DocScrutinizer05 | this is due to existing filter for X from another app, which overrides the mere left to right. a request "X:<-1300,>1300,abs" might get response "X*:>50,hpwindow=10s;X:<-1300,>1300,abs" however, when the resource "2nd engine" wasn't occupied previously |
| 18:24.31 | sixwheeledbeast^ | There is no requirement for packages to be tested for CPU usage. As a package tester you QA to the guidelines set. |
| 18:25.17 | DocScrutinizer05 | I thought the guidlines explicitly mention excessive resource usage |
| 18:25.34 | sixwheeledbeast^ | Not that I recall, also define excessive. |
| 18:25.45 | DocScrutinizer05 | I even thought this was first prio for test evaluation |
| 18:27.52 | DocScrutinizer05 | https://wiki.maemo.org/Extras-testing/QA_checklist just to refer to what we're talking about. Now reading... |
| 18:28.40 | DocScrutinizer05 | 8. [ ] No power management issues. |
| 18:28.40 | DocScrutinizer05 | 7. [ ] No performance problems. |
| 18:30.42 | DocScrutinizer05 | Power management issues |
| 18:30.44 | DocScrutinizer05 | Battery life is diminished beyond acceptable standards by having the application running in the background |
| 18:31.06 | sixwheeledbeast^ | But still it's in the package testers opinion. It's not a set amount like say 0.3MB of root space. |
| 18:31.24 | DocScrutinizer05 | this is pretty much common sense |
| 18:31.25 | KotCzarny | but did anyone measured battery drain of it? |
| 18:31.59 | sixwheeledbeast^ | As long as the package does not cause the battery to drain within a day, it could be seen as a pass but not ideal. |
| 18:32.16 | DocScrutinizer05 | also you got >>The use case of a full day without charging should not be compromised.<< |
| 18:32.44 | KotCzarny | but that system('cat') instead of read is fubar |
| 18:34.00 | sixwheeledbeast^ | I noticed a drop in battery life when I tested it but never did my full package test procedure on it to rate the package. This was several years ago. |
| 18:34.21 | sixwheeledbeast^ | has to run bbl |
| 18:35.08 | DocScrutinizer05 | shake2wake polls accel with a 1s period aiui and it does a lot of nonsense with a 0.05s period during each cycle http://paste.ubuntu.com/25113635 |
| 18:36.19 | DocScrutinizer05 | honestly for such code you should get banned from civilized world, to an island what only has a ZX81 and an old b&w TV, and an ergometer dynamo to power it |
| 18:36.29 | DocScrutinizer05 | for at least one year |
| 18:37.14 | KotCzarny | nah, zx81 has basic, not a good educational example |
| 18:37.14 | DocScrutinizer05 | indeed |
| 18:39.03 | DocScrutinizer05 | anyway for 'cat /sys/class/i2c-adapter/i2c-3/3-001d/coord' alone, it should get rated down due to risks in that |
| 18:40.57 | DocScrutinizer05 | if not for risks then for ugliness despite gaving better alternative |
| 18:41.02 | DocScrutinizer05 | having |
| 18:41.44 | *** join/#maemo LauRoman (~LauRoman@5-14-1-79.residential.rdsnet.ro) |
| 18:49.30 | DocScrutinizer05 | what the.... |
| 18:49.33 | DocScrutinizer05 | # Regular cron jobs for the stow2-2.2.2 package |
| 18:49.34 | DocScrutinizer05 | # |
| 18:49.36 | DocScrutinizer05 | 0 4* * *rootstow2-2.2.2_maintenance |
| 18:49.53 | DocScrutinizer05 | ARRRGH |
| 18:55.51 | *** join/#maemo xy2_ (~xy2_@94.239.177.175) |
| 19:02.07 | *** join/#maemo Kabouik (~kabouik@129.242.224.30) |
| 19:02.24 | *** join/#maemo Kabouik (~kabouik@129.242.224.30) |
| 19:05.38 | DocScrutinizer05 | I should eventually create that sanity checker I planned for so long. One of the checks would look at CPU time total of all processes and check the topmost 2 or 3 that are not whitelisted, then notify user about them |
| 19:06.03 | DocScrutinizer05 | http://wstaw.org/m/2017/07/17/plasma-desktopyX8317.png |
| 19:07.52 | DocScrutinizer05 | the problem with shake2wake: it's an applet so won't even show up in there >:-( |
| 19:09.46 | DocScrutinizer05 | idly wonders if sleep() is allowed at all in applets |
| 19:11.31 | DocScrutinizer05 | that's prolly the reason for that >> while gtk.events_pending(): gtk.main_iteration(False) time.sleep(0.05)<< madness |
| 19:15.14 | DocScrutinizer05 | so hildon desktop gets a chance to axt on a (me counts)... 10 events during 0.5s |
| 19:15.21 | DocScrutinizer05 | act* |
| 19:28.27 | *** join/#maemo Vajb_ (~Vajb@85-76-161-216-nat.elisa-mobile.fi) |
| 20:07.09 | *** join/#maemo clopez (~tau@neutrino.es) |
| 20:27.53 | *** join/#maemo dafox (~dafox@2a02:a448:c25a:1:7061:3b2a:37df:ded3) |
| 21:13.19 | *** join/#maemo dafox (~dafox@2a02:a448:c25a:1:7061:3b2a:37df:ded3) |
| 21:38.47 | *** join/#maemo Kabouik (~quassel@32.232.202.84.customer.cdi.no) |
| 21:56.27 | *** join/#maemo troulouliou_div2 (~troulouli@unaffiliated/troulouliou-div2/x-0271439) |
| 21:58.06 | *** join/#maemo louisdk (~louisdk@static-5-103-138-205.fibianet.dk) |
| 22:10.29 | *** join/#maemo cyteen_ (~cyteen@cyteen42.plus.com) |
| 23:13.55 | *** join/#maemo LjL (~ljl@unaffiliated/ljl) |
| 23:25.25 | *** join/#maemo jon_y (~enforcer@2001:e68:4075:a487:f64d:30ff:fe63:5a5a) |
| 23:35.50 | *** join/#maemo DocScrutinizer05 (~saturn@openmoko/engineers/joerg) |
| 23:43.47 | *** join/#maemo pagurus (~user@p50837838.dip0.t-ipconnect.de) |
| 23:48.54 | Wizzup | somehow I missed this https://lkml.org/lkml/2016/12/19/313 |
| 23:49.04 | Wizzup | sweet. should try that. |
